这是一个创建于 2712 天前的主题，其中的信息可能已经有所发展或是发生改变。
一般自动登录，也就是“ remember me ”的功能都是利用 Cookie 实现的，这里就涉及到一个问题，Cookie 里到底怎样存放数据才能保证系统的安全
看到很多简易的系统，直接保存了 Username 和 Password Hash，这样子设计在自动登录时可以直接传入数据库验证。但缺点是容易暴露系统的加密算法。
请结合你的项目谈一谈 Cookie 自动登录的系统设计
 |
1
oh 2017-06-22 16:53:44 +08:00 via iPhone
哪个系统会去保存 Username 和 password hash 太扯淡了…
最简单的难道不是保存登陆之后的 session id 或者 token 吗 |
 |
2
tony1016 2017-06-22 16:55:41 +08:00
简单一点，放个随机数，后端记录随机数是谁不就得了。注意定时清理
|
 |
3
FrankFang128 2017-06-22 16:56:46 +08:00 via Android
用有时效的随机数
|
 |
4
weyou 2017-06-22 16:57:49 +08:00
保存在 cookie 里等着被 CSRF ？
|
 |
5
bravecarrot 2017-06-22 16:58:10 +08:00 via iPhone
客户端放 sessionid 不就可以了吗
服务端维护一个 hash 表 |
 |
6
misaka19000 2017-06-22 16:58:12 +08:00 via Android
槽点太多，不知道怎么说了，还是楼下来帮帮楼主吧
|
 |
7
imn1 2017-06-22 17:03:49 +08:00
哪个网站放 password hash 的？我马上去拦截
|
 |
8
binux 2017-06-22 17:06:51 +08:00
remember me 不就是加大 cookie 的有效期吗？和普通的登陆有何区别？
|
 |
9
pekingzcc 2017-06-22 17:35:29 +08:00  1
remember me 实现 可以这样简单理解 ： 用户登陆后，服务端生成一个有时效性的 token,然后放回 cookie 中，下次登录直接验证 token,并生成一个新 token 覆盖。至于这个 token 是啥，简单的可以是个随机数，复杂点的会利用一个大的随机数以及加盐哈希共同验证，直接利用 Username 和 Password 做 hash 是很危险的，如果 lz 有使用这种方法，建议修改。
|
 |
10
abcbuzhiming 2017-06-22 18:02:03 +08:00
敢把 password hash 放客户端。。。。
|
 |
11
crayygy 2017-06-22 18:03:03 +08:00 via iPhone
一般存 token or session id，服务端检验
|
 |
12
jarlyyn 2017-06-22 18:13:33 +08:00
这和 cookie 有啥关系…………
一般登录信息是通过 session 存的。 一段时间之前流行 cookie based session，也就是将数据加密存在 cooke 中。 但是，没见过 session 里存密码或者密码 hash 的。 |
 |
13
eoo 2017-06-22 18:35:52 +08:00 via Android
PHP password_hash() 放 cookie 路过，会被打死吗？
|
 |
14
gdsagdada 2017-06-22 18:40:44 +08:00
“看到很多简易的系统，直接保存了 Username 和 Password Hash，这样子设计在自动登录时可以直接传入数据库验证。但缺点是容易暴露系统的加密算法。”，你再搞个随机字段生成一个 uuid 不是从用户名来的不就得了吗？
|
 |
15
v1024 2017-06-22 18:46:05 +08:00 via iPhone 1
将 cookie 对称加密，配合 secure-only，可以在客户端存任何信息
|
 |
16
bumz 2017-06-22 19:59:17 +08:00
缺点是暴露系统的加密算法——就这一句话，你这帖子我没话说。
|
 |
17
zpf124 2017-06-22 20:07:35 +08:00
看来我们的项目也应该被打死....
我们的方法是 存 username + 时间戳 + hash( username + passowd hash + 时间戳 + 内部自定义 key ) |
|
18
zpf124 2017-06-22 20:12:06 +08:00
另外 加密算法暴露了 没什么可怕的，除非你加密方法是 md5。
只要你的加密方法够高级，以现在的技术还远远无法破解就够了。 别人知道了你用的是 PBKDF2WithHmacSHA1 或者 bcrypt 又如何？ 既不知道 salt 又不知道迭代次数谁能破解。 |
 |
20
ech0x 2017-06-22 21:48:54 +08:00 via iPad
bcrypt 这种利用 hash 时间的将 password hash 放在 cookie 里的问题在哪里呢？如何解决呢？
|
 |
21
skylancer 2017-06-22 22:00:44 +08:00
说了一堆，就没一个人想到重放攻击
|
|
22
skylancer 2017-06-22 22:00:57 +08:00
..额 19 楼讲了
好吧，没看到 |
 |
23
Wuxj 2017-06-22 23:11:51 +08:00
|
 |
24
phithon 2017-06-22 23:41:17 +08:00
存：将用户账号+时间戳，进行签名。
将用户账号+时间戳+签名，进行加密。 将密文存入 cookie。 取：解密 cookie 取出签名，和用户账号+时间戳进行比对。 比对成功，再将时间和 now()进行比对，未超出 remember 的时间（如一个月），则校验成功。 记录 session。 |
 |
25
izoabr 2017-06-23 00:46:01 +08:00
你的提问有 bug，不过我提个新的思路。
之前存 sessionid 到 cookie 也确实有被劫持风险的，所以 cookie 里高级一点的我们会拿本地特征作为 salt+ID 进行验证，验证匹配才认可 session |
 |
26
killerv 2017-06-23 09:09:42 +08:00
我还没见过保存 password hash 的，一般都是本地 cookie 保存一个 token，直接跟服务器的 token 进行校验，如果不对或者超过有效期就失效。或者直接维护一个 session，直到回话结束。
|
 |
27
zjsxwc 2017-06-23 13:43:20 +08:00 via Android
当然是在 cookie 里存个 token，为了能自动登录，这个 token 比 session id 的寿命长，一般不会过期，然后服务端就是根据这 token 查询到用户咯
|
Select Language