关于jwt前端加密之后，后端在解密的问题

Question

最近在学习jwt，但是遇到一个问题。用户输入用户名和密码之后发送给服务器，服务器将其加密后返回token，每次前端请求都带上这个token。于是我产生一个问题：用户输入账号和密码如果这个请求被拦截了就能拿到了账号密码，但是有一种叫openssl的东西，就是要求域名用https。但是这种方式也不是十分安全。既然jwt有JavaScript版，那为啥不在前端就加密了，之后后端解密去验证呢？问题：jwt前端加密账号密码，后端解密如何实现？现在做的项目也有token的做法，实现方式：1.页面加载前端发送一个16位后端就会返回一个publick_key。2.前端收到这个public_key将用户名密码还有一个16位的随机数用md5加密。3.登陆的时候将上面的加密发送给后端，后端使用private_key解密后得到加密的数据。我想上面的实现方式就跟jwt类似。

Answer 1

用戶密碼被攔截，泄露那是用戶自己的事。服務端只要驗證密碼符合規則就行。什麼對稱非對稱加密，只要驗證規則對了就承認這個用戶

Answer 2

先不管JWT和SESSION机制，我来讨论下网络安全问题，可能说的不对，欢迎指正。

假定现在你的电脑不安全，电脑中被安装了木马监听，同时网关里有也中间人：

1. 无论你的网页中是否加密，你在键盘中输入的任何数据都会被木马监听到，这是操作系统层的监听；

2. 你在网页中键入的请求以及接收到的响应，通过网关都会被中间人拦截，这是路由层的监听；

所以，加密密码必须采用哈希算法，而不是对称加密；不然中间人既然可以拦截所有的请求和响应，而js又是明文，你如何保证对称加密的秘钥不被中间人看到呢？

你可能会问加密的密码也会被看到，中间人也可以绕开网页，直接发包模拟请求。是的，确实如此；加密密码解决的是不让你的密码被明文泄露，这样中间人无法用你的账户密码去其他应用中撞库。

但是传输的主体内容是不能采用哈希算法，因为双方必须知道具体的内容，这导致了中间人会看到明文的内容；(简单的JS对称加密是无用的，因为HTML是明文的，中间人也可以看到对称加密的秘钥)

HTTPS解决的就是对称加密的问题，将证书提前准备好，并通过浏览器预先安装的根证书来避免中间人伪造证书，这从根本上解决对称加密的秘钥问题。

而JWT我觉得从根本上，并不是为了解决网页安全问题，而是想通过一种分布式无状态的方式来解决服务端的SESSION问题。

Answer 3

我只要拦截到你加密后的值，还不是一样可以用么。

假设你的账号是ABCDE，加密后是EDCBA，我完全不需要解密得到你账号，我只需要把加密后的值原样传给你的后端就能拿到权限。

Answer 4

“用户输入账号和密码如果这个请求被拦截了就能拿到了账号密码”
在发送前的密码就是被加密过的，后端存储的是加密后的密码，后端无法解密密码，也不需要

Answer 5

1. https应该是简单而有效的方法。

2. 如果你没有解决传输被偷听的问题，那么就必须解决“重放”的问题

比如，你将密码用md5加密后再传，那别人也可以截获你md5后的密码进行重放。就算你的密码不但md5加密了，还用非对称加密再包一层，别人同样截获的是你最终的加密结果来重放。

用户的密码是不变的，如何让一个“密码”只能有效一次，是解决重放的关键思路,一般可以用黑白名单的方式来实验，具体可以自己试试。

另外，登录成功后使用JWT时，要注意JWT必须有“有效时间”的判断，否则，一旦jwt被拦截窃取，会持续有效，直到你改secret

Answer 6

token被拦截，拿到token，没有key也无法破解token啊，jwt只是来表明用户身份信息的，一般不会把密码信息放入其中，客户端处理的方式不安全