使用 cookie 而不是会话来存储用户名和密码是否错误？
Is using cookies instead of a session for storing username and password wrong?
我已经开始自学PHP，一开始，我经常会选择最简单的方法而不是最好的方法来完成任务。现在我正在开发需要 100% 安全的重要网站，我遇到了这个难题，
我在主页上使用 cookie 来存储登录会话。基本上，用户名和散列密码存储在 cookie 中，并在用户访问 mustbeloggedin 页面时加载并对照数据库检查。对于我的主页，我使用的是 md5。不是因为我想，而是因为我不得不。我知道这会给用户带来很大的安全风险，因为键盘记录攻击基本上可以随意获取他的密码。
在这个新网站上，我将使用 sha256，所以这应该不是问题。
这是我的问题：将此类数据存储在 cookie 中而不是会话中还有哪些其他安全问题？
这是我的：
任何可以物理访问计算机的人都可以通过手动设置他的 cookie 来获取用户的哈希值并存储它以备后用。
任何受感染的计算机都会执行与上述相同的操作
每次加载都会加载、解析、检查数据（不是安全问题，但仍然是优化方面的，不是很好，但我不介意）
还有什么吗？
cookie 中的域变量是否足够安全，不会被任何其他网站读取？
Edit:: 我还读到有人拦截从客户端发送到服务器的数据。会话与此有何不同？如果我存储了一个session，标识符cookie是不是还会被劫持，被别人利用？还会向 cookie 添加 ip 地址，然后在验证 cookie 时，还要检查 IP 地址，如果不同，则再次打印登录表单帮助？
饼干的一些外卖。
您想限制其中保存的任何敏感信息，因为它不安全。
Cookie 非常适合会话 ID，您可以使用它来查询您的数据库并检查它是否已过期、匹配 ip、匹配用户代理以及您想要在您之前执行的任何其他 security/validation 检查重新登录或恢复会话的路由。
您提到了用户身份验证。大多数加密协议都可以通过使用来破解，此时 md5 被视为 'broken'，因为查找表具有所有哈希的完整性以及哈希之间的细微变化。
How can I make MD5 more secure? Or is it really necessary?
对你的哈希进行加盐是至关重要的，它增加了另一层安全性，因为对 block/restrict 暴力攻击的额外 cdn/server 限制：
https://crackstation.net/hashing-security.htm
http://www.cs.virginia.edu/~csadmin/gen_support/brute_force.php
如果一个人过于偏执，您可以实施双因素身份验证（昂贵？）：
https://isc.sans.edu/forums/diary/Implementing+two+Factor+Authentication+on+the+Cheap/9580/
http://www.twilio.com/docs/howto/two-factor-authentication
不要在 cookie 中存储任何凭据。有会话 cookie，这就足够了。在您的数据库中，您可以创建一个 table，您将在其中存储 PHP 会话 ID 和用户 ID。在登录时检查一次用户的登录名和密码就足以建立会话。
我和你做的一样：在 cookie 中存储登录名、密码和会话 ID 并且有很多问题 - 偶尔由于未知原因浏览器没有删除其中一个 cookie，或者我遇到了这些 cookie 的路径问题饼干。我不得不开发非常复杂的方法来确保这些 cookie 已正确设置并且所有 cookie 在给定时刻都存在 - 我尝试在浏览器中手动删除和添加这些 cookie，并且不得不想出新的方法来防止这些活动引起的问题，但我总能想出新的方法来打破它，并且不得不想出新的机制来防止它。
当我最终决定只留下一个 cookie - 会话 ID 时，所有这些混乱都停止了，我在每次 session_start() 调用之前验证它 - 你可以检查是否存在这样的会话，甚至可以将当前浏览器占用空间与以前保存过一个。然后很容易预见到糟糕的情况——当有人删除这个 cookie 时，会话结束，垃圾收集将清理它。如果有人更改它或添加假的 - 你可以将它与你的会话进行比较 table 而不是开始会话。要更好地控制会话，请使用 session_set_save_handler 功能。
您选择的实现有很多错误。
the username and the hashed password is stored in a cookie
不要那样做。您应该认为 cookie 的内容不安全。
and is loaded and checked against the database any time the user visits a mustbeloggedin page
如果您知道用户已经登录（会话），则完全没有必要这样做。
I'm using md5
完全使用 md5 会排除任何表面上的安全性。
On this new website, I'm gonna use sha256
如果凭据仍存储在 cookie 中，那几乎没有什么区别。
那你该怎么办？
- 当用户验证自己时将他们的用户信息存储在会话中。任何时候您需要检查当前访问者是否已经通过身份验证检查会话数据。会话的数据存储在服务器上——它是安全的。如果用户的数据存储在会话中，则无需调用数据库来找出每个页面加载时的用户。
- 不要使用 cookie 来存储用户凭据，尤其是 如果您将密码散列存储在数据库中。
- 不要使用 md5 - 如果您 "forced" 这样做，请在第一时间更改它。
看来您正在尝试进行一些改进，但实际上还不够。
永远不需要将密码存储在 cookie、会话、数组或其他任何内容中。
密码应该在数据库中，而不是为了进一步访问它或以某种方式操纵数据持有者而被取出。
否则，您高度安全的数据库在密码上使用散列和盐，仅与 framework/scripts 和您存储密码的变量或 cookie 一样安全（不如上述数据库设置安全）！
来自您的评论：
Your question and statement makes no sense, you're describing a login
page and I'm describing about how the website knows you're logged in.
The cookie has the username and the hashed password, not plain text
password
所以你将 Bob 的密码存储在一个 cookie 中，使用哈希等
我偷了 Bob 的密码 cookie。它是散列的，所以安全吗？
好的，所以我 (James) 在您的网站上使用它。你的网站怎么知道我是詹姆斯，而不是鲍勃？不能。
它会检查我窃取的 cookie，并且 密码 hash/salt/whatever 你在检查中 匹配（否则它不会对 Bob 也没有用）。
它认为我是鲍勃。
所以现在你开始检查其他东西，如果我有另一个 cookie，也许是用户名。
我已经偷了那个。
所以现在你的网站查看我的 cookie，看到用户名和密码，检查它们，然后说 "welcome Bob, here's your personal/sensitive details, do as you wish..."。
密码留在数据库中！
您可以尝试检查用户代理、IP 和其他可能少于 useful/sometimes 有用的东西等，但这些是您可以做的事情 "as well" as password+has+salt，同时 不 将密码存储在 cookie 或会话中。
如果阻止黑客使用被盗的 golden 密码 cookie（散列与否）的唯一方法是检查用户代理、IP 和其他容易伪造的内容，那么您的网站不安全。
此外，只要用户需要更改密码或电子邮件地址，或检查他们在您网站上的任何敏感数据，您要求他们重新输入他们的密码。
可能会重置存储在 DB 中的 cookies/hash/hash+salt，但实际上取决于具体情况。
编辑 {
使用 cookie 存储 Session 引用，以及会话中的任何敏感数据。
同样，你应该在会话中存储什么取决于它是什么数据，如果你运行你自己的服务器，或共享等。共享主机可能有错误的配置，打开解决其他安全问题，甚至扩展会话安全问题。
（信息在下面的 links - 正如评论中所说，阅读是你的朋友 ATM - 然后是对你的特定需求的一些评估和考虑）
}
这里有一些严肃的读物供您阅读：
首先，您的 MD5 甚至 SHA256 都不安全：
http://php.net/manual/en/faq.passwords.php#faq.passwords.fasthash
Hashing algorithms such as MD5, SHA1 and SHA256 are designed to be
very fast and efficient. With modern techniques and computer
equipment, it has become trivial to "brute force" the output of these
algorithms, in order to determine the original input.
Because of how quickly a modern computer can "reverse" these hashing
algorithms, many security professionals strongly suggest against their
use for password hashing.
另请阅读 link 以了解该引用 - 关于您 应该如何 散列的内容，以及关于盐的内容。
此外，重要的是，阅读有关如何正确存储盐和哈希值的信息。那里有很多错误的建议，这些建议会误导您最终获得的安全性几乎不比使用 MD5 更高。
使用散列密码将盐存储在数据库中很好，也可以使用独特的盐等（都在 link、关于 mcrypt/blowfish 等）
A 必须阅读，即使你只从中提取一些信息（即使你忽略我的其余回答）：
The definitive guide to form-based website authentication
Faking Session/Cookies?
更多阅读：
What is the best way to prevent session hijacking?
另请阅读：
会话固定；会话劫持；跨站脚本;
再一次，鉴于你这样说：
Now that I'm developing important websites that need to be 100% secure
你真的应该花很多时间阅读所有这些东西。
Cookie/session 劫持是真实的，而且通常很简单（脚本小子的东西）。
如果你想制作安全的网站和应用程序，你确实需要了解相当多的攻击方法、预防措施等。
最好的方法是阅读我给出的 links，然后阅读任何源自该内容的 "branches"。
最终，您将对范围广泛的安全问题有更全面的了解并解决这些问题。
我已经开始自学PHP，一开始，我经常会选择最简单的方法而不是最好的方法来完成任务。现在我正在开发需要 100% 安全的重要网站，我遇到了这个难题，
我在主页上使用 cookie 来存储登录会话。基本上，用户名和散列密码存储在 cookie 中，并在用户访问 mustbeloggedin 页面时加载并对照数据库检查。对于我的主页，我使用的是 md5。不是因为我想，而是因为我不得不。我知道这会给用户带来很大的安全风险，因为键盘记录攻击基本上可以随意获取他的密码。
在这个新网站上，我将使用 sha256，所以这应该不是问题。 这是我的问题：将此类数据存储在 cookie 中而不是会话中还有哪些其他安全问题？
这是我的：
任何可以物理访问计算机的人都可以通过手动设置他的 cookie 来获取用户的哈希值并存储它以备后用。
任何受感染的计算机都会执行与上述相同的操作
每次加载都会加载、解析、检查数据（不是安全问题，但仍然是优化方面的，不是很好，但我不介意）
还有什么吗？
cookie 中的域变量是否足够安全，不会被任何其他网站读取？
Edit:: 我还读到有人拦截从客户端发送到服务器的数据。会话与此有何不同？如果我存储了一个session，标识符cookie是不是还会被劫持，被别人利用？还会向 cookie 添加 ip 地址，然后在验证 cookie 时，还要检查 IP 地址，如果不同，则再次打印登录表单帮助？
饼干的一些外卖。
您想限制其中保存的任何敏感信息，因为它不安全。
Cookie 非常适合会话 ID，您可以使用它来查询您的数据库并检查它是否已过期、匹配 ip、匹配用户代理以及您想要在您之前执行的任何其他 security/validation 检查重新登录或恢复会话的路由。
您提到了用户身份验证。大多数加密协议都可以通过使用来破解，此时 md5 被视为 'broken'，因为查找表具有所有哈希的完整性以及哈希之间的细微变化。
How can I make MD5 more secure? Or is it really necessary?
对你的哈希进行加盐是至关重要的，它增加了另一层安全性，因为对 block/restrict 暴力攻击的额外 cdn/server 限制：
https://crackstation.net/hashing-security.htm
http://www.cs.virginia.edu/~csadmin/gen_support/brute_force.php
如果一个人过于偏执，您可以实施双因素身份验证（昂贵？）：
https://isc.sans.edu/forums/diary/Implementing+two+Factor+Authentication+on+the+Cheap/9580/ http://www.twilio.com/docs/howto/two-factor-authentication
不要在 cookie 中存储任何凭据。有会话 cookie，这就足够了。在您的数据库中，您可以创建一个 table，您将在其中存储 PHP 会话 ID 和用户 ID。在登录时检查一次用户的登录名和密码就足以建立会话。
我和你做的一样：在 cookie 中存储登录名、密码和会话 ID 并且有很多问题 - 偶尔由于未知原因浏览器没有删除其中一个 cookie，或者我遇到了这些 cookie 的路径问题饼干。我不得不开发非常复杂的方法来确保这些 cookie 已正确设置并且所有 cookie 在给定时刻都存在 - 我尝试在浏览器中手动删除和添加这些 cookie，并且不得不想出新的方法来防止这些活动引起的问题，但我总能想出新的方法来打破它，并且不得不想出新的机制来防止它。
当我最终决定只留下一个 cookie - 会话 ID 时，所有这些混乱都停止了，我在每次 session_start() 调用之前验证它 - 你可以检查是否存在这样的会话，甚至可以将当前浏览器占用空间与以前保存过一个。然后很容易预见到糟糕的情况——当有人删除这个 cookie 时，会话结束，垃圾收集将清理它。如果有人更改它或添加假的 - 你可以将它与你的会话进行比较 table 而不是开始会话。要更好地控制会话，请使用 session_set_save_handler 功能。
您选择的实现有很多错误。
the username and the hashed password is stored in a cookie
不要那样做。您应该认为 cookie 的内容不安全。
and is loaded and checked against the database any time the user visits a mustbeloggedin page
如果您知道用户已经登录（会话），则完全没有必要这样做。
I'm using md5
完全使用 md5 会排除任何表面上的安全性。
On this new website, I'm gonna use sha256
如果凭据仍存储在 cookie 中，那几乎没有什么区别。
那你该怎么办？
- 当用户验证自己时将他们的用户信息存储在会话中。任何时候您需要检查当前访问者是否已经通过身份验证检查会话数据。会话的数据存储在服务器上——它是安全的。如果用户的数据存储在会话中，则无需调用数据库来找出每个页面加载时的用户。
- 不要使用 cookie 来存储用户凭据，尤其是 如果您将密码散列存储在数据库中。
- 不要使用 md5 - 如果您 "forced" 这样做，请在第一时间更改它。
看来您正在尝试进行一些改进，但实际上还不够。
永远不需要将密码存储在 cookie、会话、数组或其他任何内容中。
密码应该在数据库中，而不是为了进一步访问它或以某种方式操纵数据持有者而被取出。
否则，您高度安全的数据库在密码上使用散列和盐，仅与 framework/scripts 和您存储密码的变量或 cookie 一样安全（不如上述数据库设置安全）！
来自您的评论：
Your question and statement makes no sense, you're describing a login page and I'm describing about how the website knows you're logged in. The cookie has the username and the hashed password, not plain text password
所以你将 Bob 的密码存储在一个 cookie 中，使用哈希等
我偷了 Bob 的密码 cookie。它是散列的，所以安全吗？
好的，所以我 (James) 在您的网站上使用它。你的网站怎么知道我是詹姆斯，而不是鲍勃？不能。
它会检查我窃取的 cookie，并且 密码 hash/salt/whatever 你在检查中 匹配（否则它不会对 Bob 也没有用）。
它认为我是鲍勃。
所以现在你开始检查其他东西，如果我有另一个 cookie，也许是用户名。
我已经偷了那个。
所以现在你的网站查看我的 cookie，看到用户名和密码，检查它们，然后说 "welcome Bob, here's your personal/sensitive details, do as you wish..."。
密码留在数据库中！
您可以尝试检查用户代理、IP 和其他可能少于 useful/sometimes 有用的东西等，但这些是您可以做的事情 "as well" as password+has+salt，同时 不 将密码存储在 cookie 或会话中。
如果阻止黑客使用被盗的 golden 密码 cookie（散列与否）的唯一方法是检查用户代理、IP 和其他容易伪造的内容，那么您的网站不安全。
此外，只要用户需要更改密码或电子邮件地址，或检查他们在您网站上的任何敏感数据，您要求他们重新输入他们的密码。
可能会重置存储在 DB 中的 cookies/hash/hash+salt，但实际上取决于具体情况。
编辑 {
使用 cookie 存储 Session 引用，以及会话中的任何敏感数据。
同样，你应该在会话中存储什么取决于它是什么数据，如果你运行你自己的服务器，或共享等。共享主机可能有错误的配置，打开解决其他安全问题，甚至扩展会话安全问题。
（信息在下面的 links - 正如评论中所说，阅读是你的朋友 ATM - 然后是对你的特定需求的一些评估和考虑）
}
这里有一些严肃的读物供您阅读：
首先，您的 MD5 甚至 SHA256 都不安全：
http://php.net/manual/en/faq.passwords.php#faq.passwords.fasthash
Hashing algorithms such as MD5, SHA1 and SHA256 are designed to be very fast and efficient. With modern techniques and computer equipment, it has become trivial to "brute force" the output of these algorithms, in order to determine the original input.
Because of how quickly a modern computer can "reverse" these hashing algorithms, many security professionals strongly suggest against their use for password hashing.
另请阅读 link 以了解该引用 - 关于您 应该如何 散列的内容，以及关于盐的内容。
此外，重要的是，阅读有关如何正确存储盐和哈希值的信息。那里有很多错误的建议，这些建议会误导您最终获得的安全性几乎不比使用 MD5 更高。
使用散列密码将盐存储在数据库中很好，也可以使用独特的盐等（都在 link、关于 mcrypt/blowfish 等）
A 必须阅读，即使你只从中提取一些信息（即使你忽略我的其余回答）：
The definitive guide to form-based website authentication
Faking Session/Cookies?
更多阅读：
What is the best way to prevent session hijacking?
另请阅读：
会话固定；会话劫持；跨站脚本;
再一次，鉴于你这样说：
Now that I'm developing important websites that need to be 100% secure
你真的应该花很多时间阅读所有这些东西。
Cookie/session 劫持是真实的，而且通常很简单（脚本小子的东西）。
如果你想制作安全的网站和应用程序，你确实需要了解相当多的攻击方法、预防措施等。
最好的方法是阅读我给出的 links，然后阅读任何源自该内容的 "branches"。
最终，您将对范围广泛的安全问题有更全面的了解并解决这些问题。