为什么很多网站在更改账户密码后，原 cookie 仍然有效？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 3795 天前的主题，其中的信息可能已经有所发展或是发生改变。

我更改了自己的账户密码，改完后我仍然还是登录状态，可以进行操作。印象中很多站点在更改密码后没有强制重新登录的设计，这是为什么？
如果我的cookie被盗，对方就可以冒充我的身份，我改密码都没有用。大家设计自己网站的时候，会在一个账户更改完密码时在数据库中注销掉它以前所有的有效session吗？

更改

账户

密码

26 条回复 • 2014-08-07 10:19:18 +08:00

raincious

2014-08-06 12:09:41 +08:00

不知道你说的是哪些网站。但改密码要注销是常规吧？

我的设计是改密码必须重新输入原密码+新密码+新密码确认。如果原密码输入错了3次也会注销。

love

2014-08-06 12:18:24 +08:00

是这些网站的问题，把userid简单地做个hash存在cookie里，而不是和密码+邮箱一起做个hash，这样密码改变后cookie里的userid还是能通过验证。

airyland

2014-08-06 12:23:59 +08:00 via Android

可能cookie包含了用户信息没有清除，或者session没有destroy。总之就是网站的问题。

hizhengfu

2014-08-06 12:24:53 +08:00

改密码成功后重新把有效的cookie设置下就可以了。这样设计不觉得方便一些吗？

bjzhush

2014-08-06 12:26:31 +08:00

这取决于具体的凭证是否密码相关,举个简单的例子,

密码相关
session[auth] = md5(passwd+salt)
密码无关
session[auth] = md5(userid+salt)

关于:　印象中很多站点在更改密码后没有强制重新登录的设计，这是为什么？
大部分这种情况还是设计考虑的不到位，没有深入考虑到安全

explon

2014-08-06 12:28:19 +08:00

因为把 Session 里的信息也改了

mornlight

2014-08-06 12:35:37 +08:00

@explon 唔，你说得很有道理。如果是这样的话那就免除了重新登录的步骤，是个好的体验。

不过应该有很多网站的确没考虑到这个风险，我遇到过不少在Chrome上更改了密码，在Firefox上以前的登录状态还保留的情况。

humiaozuzu

2014-08-06 12:49:29 +08:00

很多网站用的 client side session

jasontse

2014-08-06 12:55:41 +08:00 via Android

@love
密码不应该以任何形式包含在 cookie 里，即使它 hash 过。

huangyan9188

2014-08-06 13:08:54 +08:00

楼上的楼上说的是对的，cookie里面应该放sha1（token+username）而不是密码，不管铭文还是密文都不要出现

Narcissu5

2014-08-06 13:41:46 +08:00

cookie被盗为什么要改密码，重新登录不就完了么？

mornlight

2014-08-06 14:01:33 +08:00

@Narcissu5 嗯，的确是。但也有可能，保存cookie的浏览器我不使用了或者清理cookie了。不注销的话服务端那边还会一直认为有效的吧。

alex321

2014-08-06 14:12:13 +08:00

有一些这类网站是保存当前的登录状态的。
流程上来看，如果你更改密码，那么先验证之前的密码或者已经设置的安全手机或邮箱，然后输入并确认新密码，完成密码更换操作后，你的登录状态还是有效的，没必要一定要退出来让你重新登陆一遍。
一般情况下，只有在你需要访问敏感数据或者即将产生关系个人财产的时候采取要做密码的输入验证操作。

love

2014-08-06 14:29:56 +08:00

@jasontse @huangyan9188 都和服务器保密串hash过了凭什么不能放在cookie？不放密码怎么做到改密码后使所有设备的cookie立即失效？

@Narcissu5 当你丢了台笔记本，紧急回家换台电脑改各种帐号密码，然后小偷却还能用笔记本上的cookie保持在登录状态你是什么心情？

mornlight

2014-08-06 14:46:11 +08:00

@love 密码内容不放到cookie里是有道理的，hash过也存在被逆向的可能。

让cookie失效只需要在服务端保存session的地方将这个session设置为失效即可。验证session通过数据库或者缓存的内容来，而不是根据算法来。

love

2014-08-06 14:56:28 +08:00

@mornlight 加密要么是可靠的，要么是不可靠的，不存在有可能被解密的可能。

jarlyyn

2014-08-06 17:55:07 +08:00

为啥改好密码要注销？
记住登录状态不是记录uid么。
要从安全期间，不是因该是进行敏感操作需要再次输入密码么？
一般网页都是可以在多个浏览器/地址登录同一个地址吧，不会去做这种强制登出啊。

jarlyyn

2014-08-06 17:59:57 +08:00

@love
1.我掉了笔记本也不会去修改密码，crypt-dm全盘加密的。只能看到的/boot

2. 我不觉得小偷能用cookie保持在线登录有啥特别大的问题。。。。凡是安全敏感的应该都不会有长时间的session有效期。

3.凡是加密都是不可靠的，只不过是在指定时间内可靠而已，不存在可靠的加密。

mornlight

2014-08-06 20:35:55 +08:00

@jarlyyn 你知道服务端一般是怎么得知是哪个用户请求了页面的吗？修改了密码，但有效cookie没有更改的话，其他人可以偷取cookie然后冒充你。

zoudm

2014-08-06 21:12:55 +08:00

@love
hash（例如md5）还是不给出来还是有道理的。
别人如果拿到了真实的md5，就存在彩虹表、暴力枚举求md5比对的可能
而不给出来每次都要在服务器上比对，就能很好的控制这件事。

jarlyyn

2014-08-06 23:58:15 +08:00

@mornlight 我想我知道。然后呢，被冒充了又怎么样呢？
对于服务器来说，每次访问页面都验证session中的密码信息，这未免也代价太大了。
多个页面/浏览器可以同时登录，修改密码不注销，关键业务再次验证密码，不是现在通用的方式么？

huangyan9188

2014-08-07 00:35:14 +08:00

@love 这个年代你还在信hash真心年轻了。。。。。。cookie里面放的是signature 也就是签名，但是这个签名是属于token机制的，它与时间戳等其他相关，修改完密码之后原来signiture就会失效，换成了新的token和新的signature。。。。还像你那样，简单的XSS攻击就足够知道你的信息了

huangyan9188

2014-08-07 00:49:48 +08:00

@mornlight @love 关于你的
“@mornlight 加密要么是可靠的，要么是不可靠的，不存在有可能被解密的可能”就是在抬杠，如此无意义的言论。。。。不懂cookie跟session随机状态机制就别来搀和

huangyan9188

2014-08-07 01:00:00 +08:00

@jarlyyn @mornlight 用户的信息确实要验证，但是现在的验证部分要通过比对，但是大部分的请求采用很快的的方法了，通过memcache类型的数据，在nginx端就直接将要验证的信息作为索引去取cache中的内容，但是如果用户关键信息变了的话，如果还是这样的请求，会将response状态转为重新登录，然后memcache中的该用户信息就会换为新的，你去试试微信，大象笔记，利用heartbeat保持session，如果用户的签名发生改变，就会让所有的heartbeat的客户端全部重新登录，cookie失效

jarlyyn

2014-08-07 10:06:48 +08:00

@huangyan9188 你说的是APP/应用程序吧？非web的程序当然可以把控制精度做到连接，那么只需要在链接以及重连的状态时验证身份就可以了。同时，可以采取断开连接的方式，来进行强制操作。
而web/http天生是无状态的。一般很少用连接的方式去做，由于无法有断开链接/推出的事件，一般的程序也不会倾向于按照链接当时来做吧。
我的理解是这样，有什么问题吗？

jarlyyn

2014-08-07 10:19:18 +08:00

@huangyan9188 去检查了，的确，github,v2ex都是修改密码后注销用户所有连接的。看来的确是自己考虑不周。