这是一个合适的登录和注册加密系统 [英] Is this an appropriate login and registration encryption system

问题描述

显然，散列用户名和密码并将其保存为Cookie并使用经过清理的Cookie数据登录对于您的人（或我的网站的安全）来说不够好。

Apparently, hashing the username and password and saving them as cookies and logging in with sanitized cookie data is not good enough for you people (or my site's safety).

这种方法是否足够好？

注册程序：

$salt= date('U');
$username= hash('sha256', $salt. $_POST['username']);
$password= hash('sha256', $salt. $_POST['password']);
$token = hash('sha256', $salt. (rand(1,10000000000000000000000000000000000000000000)));

要手动登录，用户键入其用户名和密码，通过哈希并匹配。

To login manually, users type in their username and password, it is passed through the hash and matched.

成功登录后，将为用户创建两个烹饪。一个持有未清除的用户名，另一个持有散列的令牌。

Upon successful login, two cookes are created for the user. One holding the unhashed username, the other holding the hashed token.

用户访问时，如果设置了Cookie，则网站会冻结用户名，然后使用这两个值

When the user visits, if the cookies are set, the site hashes the username and then uses these two values to login.

这种方法的优点是它避免了将用户密码存储在他们计算机上的任何地方。有人可能破解令牌并访问他们的帐户，但至少我不会危及用户的密码...

The advantage of this approach is that it avoids storing the user's password anywhere on their computer. Someone could crack the token and gain access to their account but at least I wouldn't have jeopardized the user's password...

回答 MySQL real_escape 字符串和Cookie 表示错误将用户数据存储在Cookie中。这是否会转移问题？

The people who answered MySQL real_escape string and cookies say it is wrong to store user data in cookies. Does this divert the problem?

推荐答案

为什么你需要存储密码，甚至加密版本？您的网站是否在访问HTTP基本验证或某些内容的后端第三方API？

Why do you need to store the password at all, even an encrypted version? Is your site accessing a 3rd-party API in the backend that does HTTP Basic auth or something?

不幸的是，您的问题没有确定的答案。 适当对不同的人意味着不同的东西。有了安全问题，我不确定它是否有可能足够合适或足够安全。也就是说，这里是如何处理登录和密码安全。在我的数据库的 users 表中，我有3个与登录相关的列：

Unfortunately there's no definitive answer to your question. "Appropriate" means different things to different people. And with security questions, I'm not sure it's ever possible to be "appropriate enough" or "secure enough." That said, here's how I handle logins and password security. In my database's users table, I have 3 login-related columns:

2. 盐


3. passwordHash

c $ c> username 列是纯文本。 salt 列是一个64个字符的随机选择的字母数字字符串。 passwordHash 列是用户的密码连同它们的 salt 值，然后不可逆地散列。我使用sha256为我的哈希。盐是64个字符，因为这是sha256产生的。为了在散列的字符串中产生足够的可变性，最好使用一个salt值。

The username column is in plain text. The salt column is a 64-character string of randomly chosen alphanumeric characters. The passwordHash column is the user's password concatenated with their salt value, and then irreversibly hashed. I use sha256 for my hashes. The salt is 64 characters because that's what sha256 produces. It's good to have a salt value at least as long as the hash in order to produce enough variability in the hashed string.

当用户提交登录表单时，用户名的数据库查询。如果找不到用户名，我会向用户显示用户名和/或密码无效错误。如果找到用户名，我将salt与密码连接，对其进行哈希，然后查看它是否等于 passwordHash 值。如果没有，用户显示完全相同的错误。

When the user submits the login form, I do a database query for the username. If the username isn't found, I show an "Invalid username and/or password" error to the user. If the username is found, I concatenate the salt with the password, hash it, and see if it equals the passwordHash value. If not, the user is shown the exact same error.

无论用户名是否错误或密码错误，显示完全相同的错误消息是很好的，或两者。你给黑客的线索越少越好。此外，每当用户更改密码时，我也给他们一个新的 salt 。在这个时间点，这很容易做到这一点，并且它使盐的值更清新一些。

It's good to show the exact same error message regardless of whether the username was wrong, or the password was wrong, or both. The fewer clues you give to a hacker, the better. Also, whenever a user changes their password, I give them a new salt too. It's really easy to do this at that point in time, and it keeps the salt values a little fresher.

这个每个用户有不同盐的系统被称为动态盐析。如果他们尝试使用彩虹表对用户的密码进行逆向工程，这会大大增加黑客的工作复杂性。更不用说，以不可逆散列形式存储密码对于确保用户密码的确定，即使他们有权访问数据库和PHP代码，也需要很长时间。

This system of having a different salt per user is called dynamic salting. This greatly complicates a hacker's job if they try to use rainbow tables to reverse-engineer your users' passwords. Not to mention that storing passwords in irreversibly hashed form goes a very long way toward keeping anyone from determining a user's password, even if they have access to the database and the PHP code.

这也意味着如果你的用户忘记密码，没有办法退出。相反，你编写你的系统只是将它重置为一个新的随机确定的值，发送给他们，伴随着强烈的鼓励，一旦他们再次登录更改他们的密码。您甚至可以编写您的系统，以在下次成功登录时强制这样做。

This also means if your user forgets their password, there's no way to retrive it. Instead, you write your system to just reset it to a new randomly-determined value that is sent to them along with strong encouragement to change their password as soon as they log in again. You can even write your system to force this upon the next successful login.

我需要密码至少为8个字符。理想情况下，它还应该包括数字和特殊字符，但我还没有决定我应该要求这个。也许我应该！

I require passwords to be at least 8 characters. Ideally, it should also include numbers and special characters, but I haven't decided I should require this yet. Maybe I should!

为了防止暴力-force 攻击，我跟踪在前10分钟内所有失败的登录。我跟踪他们在每个IP地址的基础上。在3次尝试失败后，系统使用 sleep（）函数来延迟对进一步登录尝试的响应。我使用一块代码如下：

To protect against brute-force attacks, I keep track of all failed logins during the previous 10 minutes. I track them on a per IP address basis. After 3 failed login attempts, the system uses the sleep() function to delay responding to further login attempts. I use a block of code like this:

$delay = ($failedAttempts - 3);
if ($delay > 0) {
    sleep($delay);
}

IMHO这比锁定用户的失败。它减少了您将获得的客户支持查询的数量，它更加优雅的合法用户，只是不记得自己的密码。暴力攻击需要每秒进行许多尝试，以获得任何效率，因此延迟在 n = x 的基础上，使他们不会变得非常远。

IMHO this is much better than locking users out of their accounts after a hard number of failures. It reduces the number of customer support inquiries you'll get, and it's more graceful for legitimate users who simply can't remember their own passwords. Brute-force attacks need to do many attempts per second in order to have any sort of efficiency, so delaying on an n = x basis keeps them from getting very far at all.

使用PHP会话跟踪登录会话。当您网站上的每个网页都加载时，调用 session_start（）。 （如果你有一个公共的 header.php 文件，这很容易。）这使得 $ _ SESSION 变量可用。当用户成功登录时，您可以使用它来存储您的网站需要的任何信息，以便知道用户已登录。我通常使用其用户ID，用户名，以及特定于该网站的一些其他详细信息。但我不要在此包含密码或其哈希。如果黑客进入用户的会话数据（存储在您的服务器上），他们仍然没有机会通过这种方式找到用户的密码。

Login sessions are tracked with PHP sessions. Call session_start() when every page on your site is loaded. (This is really easy if you have a common header.php file.) This makes the $_SESSION variable available. When a user successfully logs in, you can use this to store whatever info your site needs in order to know the user is logged in. I typically use their User ID, Username, and maybe some other details specific to the site. But I don't include the password or a hash of it here. If somehow a hacker got into the user's session data, which is stored on your server, they still wouldn't have a chance at finding the user's password this way.

日志当发生以下两种情况之一时发生错误：1）用户的会话cookie被删除，例如通过清除浏览器缓存或有时只是关闭浏览器窗口，或2）服务器删除其会话数据。当用户在您的网站上按下注销按钮时，可以通过调用 session_destroy（）来强制后者。否则，您可以使会话在一段时间后自动过期。这可能涉及调整 php.ini 中的 session.gc _ * 参数。

Logging out happens when one of 2 things occur: Either 1) The user's session cookie is deleted, such as by clearing the browser cache or sometimes just by closing the browser window, or 2) Your server deletes their session data. You can force the latter to happen via calling session_destroy() when the user presses your "Log out" button on your site. Otherwise you could make sessions automatically expire after a certain period of time. This may involve tweaking your session.gc_* params in php.ini.

如果您在初始登录阶段后绝对必须知道用户的密码，您可以将其存储在 $ _ SESSION 中。执行此操作IF和仅如果您的网站需要SSL连接，并且您已经这样做的网站将不工作没有一个。这样，密码将被加密，因此受到数据包嗅探的保护。但是，如果黑客能够访问您的服务器的会话数据，那么这是一个安全风险。

If you absolutely must know the user's password after the initial login phase, you can store it in $_SESSION. Do this IF AND ONLY IF your site requires an SSL connection and you've made it so the site won't work without one. This way the password is encrypted and so is protected against packet sniffing. But know that it's a security risk if a hacker gets access to your server's session data.

这篇关于这是一个合适的登录和注册加密系统的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！