为什么我应该在Cookie中使用会话ID，而不是在Cookie中存储登录名和密码(哈希值)?

本文介绍了为什么我应该在Cookie中使用会话ID，而不是在Cookie中存储登录名和密码(哈希值)?的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

(令我惊讶的是，现在还没有在Stack上问这个问题，但是我已经做了一些搜索，但是找不到任何东西)

(I was surprised that this question wasn't asked on Stack for now, but I've done some searching and couldn't find anything o.O)

我正在开发基于服务的Webapp，我想知道什么是处理用户登录的最佳方法.到目前为止，我有:

I am working on service-based webapp and I wonder what is the best way for handling user logins. So far I have:

用户登录时，他们提供贷方.密码会在本地撒盐和散列，然后再通过POST传输到服务器(因此，嗅探用户将无法检索原始密码，即无法在其他站点上对其进行检查)

登录名和哈希密码存储在TTL为15分钟的Cookie中(每次Webaction均被撤消)

Passwod在服务器端被重新加盐并进行哈希处理，然后将其与存储在数据库中的密码进行比较(因此，密码是使用不同的盐进行两次哈希处理的，这是针对那些会闯入数据库的人的，他们仍然不会能够恢复登录信用凭证)

用户每5分钟最多只能通过单个IP进行3次登录尝试

用户获得有关上次成功和失败登录尝试的信息以及日期和IP

有人指出，最好在cookie中存储唯一的会话ID而不是哈希密码，我想知道为什么它如此重要-如果有人嗅探数据包，无论会话ID与否，他们仍然可以从登录中获取数据包冒充合法用户并登录自己所需的所有数据.那么，存储会话ID方法比将登录名和哈希密码存储在Cookie方法中还有其他优势吗?

Someone had noted that it's better to store unique session id instead of hashed password in cookie and I wonder why it is so important - if someone sniff packets, than it's no matter session id or not - they still can get packet from login with all data needed to pose as legitimate users and login themselves. So are there any other advantages of stored session-id approach over storing login and hashed-password in cookie appraoach?

推荐答案

将散列密码存储为cookie是非常讨厌的漏洞，并且是违反OWASP .对密码进行哈希处理的全部要点是，您在迫使攻击者破坏哈希值以进行登录.如果攻击者只能从数据库中提取哈希值然后登录，那么您拥有一个等效于以纯文本存储密码的系统.

Storing the hashed password as a cookie is very nasty vulnerability and is an OWASP Violation. The whole point in hashing a password is you are forcing the attacker to break the hash in order to login. If the attacker can just pull the hash from the database and then login, then you have a system that is equivalent to storing password in plain text.

每个平台都有一个会话处理程序，在php中只需使用session_start()和$ _SESSION超级全局即可.通过编写自己的会话处理程序，您的安全性将降低.

Every platform has a session handler, in php just use session_start() and the $_SESSION super global. By writing your own session handler you will be less secure.