猿问

jwt前端加密后端解密

最近在学习jwt,但是遇到一个问题。
用户输入用户名和密码之后发送给服务器,服务器将其加密后返回token,每次前端请求都带上这个token。
于是我产生一个问题:用户输入账号和密码如果这个请求被拦截了就能拿到了账号密码,但是有一种叫openssl的东西,就是要求域名用https。但是这种方式也不是十分安全。
既然jwt有JavaScript版,那为啥不在前端就加密了,之后后端解密去验证呢?
问题:jwt前端加密账号密码,后端解密如何实现?


现在做的项目也有token的做法,实现方式:
1.页面加载前端发送一个16位后端就会返回一个publick_key。
2.前端收到这个public_key将用户名密码还有一个16位的随机数用md5加密。
3.登陆的时候将上面的加密发送给后端,后端使用private_key解密后得到加密的数据。
我想上面的实现方式就跟jwt类似。

侃侃无极
浏览 1977回答 8
8回答

素胚勾勒不出你

先不管JWT和SESSION机制,我来讨论下网络安全问题,可能说的不对,欢迎指正。 假定现在你的电脑不安全,电脑中被安装了木马监听,同时网关里有也中间人: 无论你的网页中是否加密,你在键盘中输入的任何数据都会被木马监听到,这是操作系统层的监听; 你在网页中键入的请求以及接收到的响应,通过网关都会被中间人拦截,这是路由层的监听; 所以,加密密码必须采用哈希算法,而不是对称加密;不然中间人既然可以拦截所有的请求和响应,而js又是明文,你如何保证对称加密的秘钥不被中间人看到呢? 你可能会问加密的密码也会被看到,中间人也可以绕开网页,直接发包模拟请求。是的,确实如此;加密密码解决的是不让你的密码被明文泄露,这样中间人无法用你的账户密码去其他应用中撞库。 但是传输的主体内容是不能采用哈希算法,因为双方必须知道具体的内容,这导致了中间人会看到明文的内容;(简单的JS对称加密是无用的,因为HTML是明文的,中间人也可以看到对称加密的秘钥) HTTPS解决的就是对称加密的问题,将证书提前准备好,并通过浏览器预先安装的根证书来避免中间人伪造证书,这从根本上解决对称加密的秘钥问题。 而JWT我觉得从根本上,并不是为了解决网页安全问题,而是想通过一种分布式无状态的方式来解决服务端的SESSION问题。

慕尼黑5688855

我只要拦截到你加密后的值,还不是一样可以用么。 假设你的账号是ABCDE,加密后是EDCBA,我完全不需要解密得到你账号,我只需要把加密后的值原样传给你的后端就能拿到权限。

森林海

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

莫回无

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

料青山看我应如是

https应该是简单而有效的方法。 如果你没有解决传输被偷听的问题,那么就必须解决“重放”的问题 比如,你将密码用md5加密后再传,那别人也可以截获你md5后的密码进行重放。就算你的密码不但md5加密了,还用非对称加密再包一层,别人同样截获的是你最终的加密结果来重放。 用户的密码是不变的,如何让一个“密码”只能有效一次,是解决重放的关键思路,一般可以用黑白名单的方式来实验,具体可以自己试试。 另外,登录成功后使用JWT时,要注意JWT必须有“有效时间”的判断,否则,一旦jwt被拦截窃取,会持续有效,直到你改secret

慕容3067478

token被拦截,拿到token,没有key也无法破解token啊,jwt只是来表明用户身份信息的,一般不会把密码信息放入其中,客户端处理的方式不安全
随时随地看视频慕课网APP
我要回答