jwt前端加密后端解密
最近在学习jwt，但是遇到一个问题。
用户输入用户名和密码之后发送给服务器，服务器将其加密后返回token，每次前端请求都带上这个token。
于是我产生一个问题：用户输入账号和密码如果这个请求被拦截了就能拿到了账号密码，但是有一种叫openssl的东西，就是要求域名用https。但是这种方式也不是十分安全。
既然jwt有JavaScript版，那为啥不在前端就加密了，之后后端解密去验证呢？
问题：jwt前端加密账号密码，后端解密如何实现？
现在做的项目也有token的做法，实现方式：
1.页面加载前端发送一个16位后端就会返回一个publick_key。
2.前端收到这个public_key将用户名密码还有一个16位的随机数用md5加密。
3.登陆的时候将上面的加密发送给后端，后端使用private_key解密后得到加密的数据。
我想上面的实现方式就跟jwt类似。
先不管JWT和SESSION机制，我来讨论下网络安全问题，可能说的不对，欢迎指正。
假定现在你的电脑不安全，电脑中被安装了木马监听，同时网关里有也中间人：
1. 无论你的网页中是否加密，你在键盘中输入的任何数据都会被木马监听到，这是操作系统层的监听；
2. 你在网页中键入的请求以及接收到的响应，通过网关都会被中间人拦截，这是路由层的监听；

所以，加密密码必须采用哈希算法，而不是对称加密；不然中间人既然可以拦截所有的请求和响应，而js又是明文，你如何保证对称加密的秘钥不被中间人看到呢？
> 你可能会问加密的密码也会被看到，中间人也可以绕开网页，直接发包模拟请求。是的，确实如此；加密密码解决的是不让你的密码被明文泄露，这样中间人无法用你的账户密码去其他应用中撞库。

但是传输的主体内容是不能采用哈希算法，因为双方必须知道具体的内容，这导致了中间人会看到明文的内容；(简单的JS对称加密是无用的，因为HTML是明文的，中间人也可以看到对称加密的秘钥)
HTTPS解决的就是对称加密的问题，将证书提前准备好，并通过浏览器预先安装的根证书来避免中间人伪造证书，这从根本上解决对称加密的秘钥问题。
而JWT我觉得从根本上，并不是为了解决网页安全问题，而是想通过一种分布式无状态的方式来解决服务端的SESSION问题。