我司前端把密码明文扔到 cookie 里面，这样做对吗

[392039757]

我不是前端，不懂也不敢问 eg: Cookie: userPwd=123456; userName=ws201907

[no1xsyzy]

但是其实还要担心一点：现在大部分服务器是运行在 VPS 上的，实际上如果过程中以明文存储在内存上，如果 VPS 提供商扫描内存的话是可以知道密码的。试问在座有几个人会对自己服务器上传入的数据在 HTTP 层面先做随机化分布？（即 SSL/TLS 层解密后在内存位置是打乱的）
Cookie 的另一个问题就是反授权时 token 之流方便一点，存用户名密码就需要重置密码了。

[no1xsyzy]

@l4ever get 不是 http ？没太明白

[l4ever]

@no1xsyzy 按快了, 少了个 s 我就

[l4ever]

@no1xsyzy 你看,又按快了, 少了个 s 我就 ctrl+enter 了.

[w99wen]

@fumichael
对于加密
有两个基本概念：对称加密，非对称加密
对于 hash 之类的，其实是取得摘要，指纹，或者说特征值，不是加解密。
每个固定内容，特征值应该是唯一的。同时我们不能直接从特征值得到原内容，除非你计算过或者说记得这么一个对照表，有这些一一对应关系。
但是这其中有一个问题，大部分需要取摘要的内容都很短，很容易被人们计算出来，并且保存到对照表中（这个表，就叫彩虹表），所以才要加盐，加上一段随机字符，将内容变长，比如扩充到 50 位，那这个 50 位的彩虹表，就已经无法建立了，太大了。
加盐，是为了对抗彩虹表。这个是根本目的。

[w99wen]

@fumichael

加盐之后，攻击者不能从彩虹表获得 md5 之前的原内容。也就是我们的密码。

[aaronhua]

@chennqqi +1。有朋友做安全的，这种明文的是过不了等宝的。

[no1xsyzy]

@fumichael 数据库加盐加密主要是为了防止彩虹表和哈希字典的。
人们早就知道 'E10ADC3949BA59ABBE56E057F20F883E' = md5('123456')
但如果你采用加盐的方法，你看到 'hellomyzebra,yestheyaresocute:' '3A64C835017B142A97B5ADAECF249673' 又怎么知道密码是多少？
没盐的情况下，你可以直接 select * from users where passhash = 'E10ADC3949BA59ABBE56E057F20F883E' 得到这些人密码是 '123456'，甚至给一个哈希字典能够直接 select users.*, hashdict.hashee as password from users left join hashdict on users.passhash=hashdict.hashed 取出所有弱密码，整个耗时不过几秒。
用上彩虹表的话 20 位以下密码也花不了多久。

但加盐首先直接破坏彩虹表，其次弱密码爆破也需要很久，脱裤后有足够久的时间告警所有用户改密码了。

数据库中更标准的是采用 bcrypt 等方式，单密码校验需要 1 秒（可调参使得时间更长），简单 6 位纯数字密码，数据空间达 100 万，就是十几天，还多半不会命中。

[no1xsyzy]

@w99wen 彩虹表不是对照表，而是一个依赖于特定的哈希函数 hash 和随意指定的、反转了定义域和目标域的函数（实质上是另一种 hash，不过通常生成的是变长字符串） rehash 构造的简化对照表，它的结构和 hash 强对应，

彩虹表就算你在 6 位数字上加一位数字的盐，因为哈希算法被改变 new_hash = d=>hash(salt+d)，导致整个彩虹表不可用，但对照表的话刚开始就构造 7 位对照表的话还是可以使用的。
这就是为什么需要每个用户独立生成盐，否则还是可以用彩虹表。

[kiracyan]

明文保存密码都是弱智.不管在哪

[nnnToTnnn]

@codehz
@zckevin
@msg7086

方案一，可能说的不够详细但是 HSTS 是可以绕过的，包括现在的浏览器的硬编码

攻击方案一

------ 1. 拦截用户的 dns 请求，将 google.com 请求跳转到 google.com.hook
------ 2. 将 google.com 降级为 http(正常请求获取到 google.com 的数据)
------ 3. google.com.hook 用正常的证书进行签发，然后代理 google.com （步骤二的数据）的 https 请求
------ 4. 用户访问 google.com.hook，即可获取解密出来的所有数据


和原始访问的差距是

之前访问的是 google.com

拦截后访问的是 google.com.hook


talk is cheap，show me the cod

https://github.com/LeonardoNve/sslstrip2

[cydysm]

反正不能明文就对了

[noobcoder1]

你让他加个密不就完了 前面+个密 后面加个盐 这样就能防止 cmd5 那种网站搞撞库解密

[noobcoder1]

@keepeye 这种做法上古时代了吧 现在都是前后分离 都是本地存 token 直接带过去鉴权的啊 没有直接重定向登陆的，如果登陆是有效的 直接跳到 next 后的地址就行了 不用手工点登陆了

[hakono]

@codehz 因为 .net .com 这些一般意义上的常用域名并不在内置的顶级域名里
虽然谷歌内置了 40 多个顶级域名，但实际上这些域名基本都是很少用的域名

可不是所有的网站都可以动不动换个域名的

[hspeed18]

不知道为什么那么多人觉得有问题。
如果没有用 https，前端加密了也没什么卵用。
如果用了 https，前端加密不是多此一举吗？

[ctblns]

你不把账号密码加密存储到数据库，你丢到 cookie 像被日啊

[codehz]

@nnnToTnnn #171 你看看你给的链接，只是原始的 SSLStrip 加一点改进的版本，还是 4 年前 HSTS Preload 还没实施的时候的仓库。。。

[nnnToTnnn]

@codehz 这是对抗 HSTS 的原理，因为 HSTS 是对于域名的。

[nnnToTnnn]

@codehz HTTPS 否认这个是漏洞，当然 sslstrip2 也不是针对 https 而是绕过 https 的 hsts，并非真正的解决了 https 的 hsts