后端密码加密vs哈希 [英] Back end password encryption vs hashing

问题描述

对于确保用户身份验证的最佳方式，我有疑问。

我遇到了加密用户的网络应用程序 后端中的密码。但是，使用与所有密码相同的密钥来完成此加密。
此外，这个密钥在后端是hardcoded。

他们（应用开发者）声称这是完全安全的。但我有疑虑我相信这种方法可能会导致两个问题：

• 密码加密的原因是为了避免访问如果未经授权的数据库访问，则密码。但是，如果将密钥存储在同一个服务器中，那么他们也可以获取密钥。




• 同样的密码将产生相同的加密值攻击系统会更容易。

我的问题如下： / p>

• 我对我的要求是对的吗？如果真的不安全，我应该向他们提出可能的威胁吗？




• 而不是使用哈希+盐方法的优缺点？

谢谢！

解决方案

我不知道你是否可能错误地将加密和散列混合在一起。如果用户的密码被加密而不是，那么在数据泄露的情况下，攻击者可能会窃取所有的用户密码。

在认证方面，您似乎正在考虑一些因素。首先，任何哈希应该在后端进行，而不是在前端。前端的哈希还是让您容易受到哈希攻击。

一些开发人员采用双哈希方式，在前端将哈希密码在后端重新排序它。我相信这是不必要的，前端密码应该被HTTPS层覆盖（ TLS ）但是这是需要讨论的。

首先，在解释如何安全地存储和验证用户之前，先澄清两个关键术语。

加密

您指定用户的密码正在加密，而不是散列。加密功能的作用是将输入（用户密码）以1对1的方式映射到输出（加密的密码），这意味着这是可逆的。

这意味着如果黑客获得访问加密密钥（私钥），他们可以轻松地逆转整个流程。

Hashing

相反，用户的密码应该在服务器端散列。为什么？因为您可以通过比较两个散列值来检查它们是否匹配，而不用存储该值的纯文本表示。

再次，你可能会问：为什么？好吧，因为散列函数是单向的，这意味着纯文本值不能被逆转（好的，它们很难），我不会详细介绍。

我应该怎么做？

用户的密码绝对不能作为纯文本存储在Web服务器的任何部分。相反，您应该存储用户的哈希。当用户然后尝试登录时，您将通过HTTPS / TLS安全地收到他们的纯文本密码，将其哈希，并且如果这两个哈希匹配，则验证该用户。

所以数据库表可能如下所示：

  +  - ------------------------------------- + 
 | ID |用户名|密码哈希| 
 + -------------------------------------- + 
 | 1 | foo | $ 2a $ 04 $ / JicM | 
 | 2 |酒吧| $ 2a $ 04 $ cxZWT | 
 + -------------------------------------- + 
  

• 请注意，哈希会被截断为四轮的BCrypt散列（AKA - 无效）

现在让我们举个例子，介绍Alice和我们的服务器之间。不要太数据了。

爱丽丝发送一个请求以登录她的凭据，首先通过我们的安全传输层：

{username：foo，password：bar} - > TLS（） - > ZwUlLviJjtCgc1B4DlFnK - > |服务器|

我们的服务器接收到，然后使用它的证书密钥解密：

ZwUlLviJjtCgc1B4DlFnK - > KEY（） - > {username：foo，password：bar} - > Web应用程序

很棒！我们的凭证已经安全通过，现在是什么？哈希该密码并与我们的数据库中的密码进行比较。

BCRYPT（'bar'） - > $ 2a $ 04 $ / JicM

  if（$ 2a $ 04 $ / JicM == user.get_password_hash ）{
 authenticate（）; 
} 
 else {
 return status_code（401）; 
} 
  

我们现在已经能够验证用户，存储不可逆的哈希值和而不用存储明文值。这应该回答了你的第一和第二个问题。

I have questions regarding the best way to secure the authentication of users.

I have come across a web application that encrypts the user password in the back end. However this encryption is done with the same key to all passwords. Also, this key is "hardcoded" in the back end.

They (the app developers) claim that this is perfectly secure. However I have my doubts. I believe that this method can cause two problems:

• The reason to encrypt passwords is to avoid access to the passwords in the event of an unauthorized database access. However if you store the key in the same server chances are they will also be able to obtain the key.

• The same password will yield the same encrypted value therefore it will be easier to attack the system.

My questions are the following:

• Am I right about my claims? And if it is really that insecure, should I warn them about the possible threat?

• What would be the pros and cons of using a hash + salt approach instead?

Thanks!

解决方案

I'm not sure if you might mistakenly mixed up encryption and hashing together. If the user's password is be encrypted and not hashed then there is potential for an attacker to steal all the user password in the event of a data breach.

There are a number of factors that you seem to be looking over when it comes to authentication. Firstly, any hashing should be done in the back-end and never in the front-end. Hashing in the front-end still leaves you vulnerable to hash attacks.

Some developers adopt a double-hash approach in which they hash the password in the front-end and then re-hash it in the back-end. I believe this is unnecessary, the front-end password should be covered by the HTTPS layer (TLS), however that is subject to discussion.

First, let's clarify two key terms before explaining how to securely store and authenticate users.

Encryption

You specify that the user's passwords are being encrypted, rather than hashed. What encryption functions do is map an input (user's password) to an output (encrypted password) in a 1-to-1 fashion, meaning that this is reversible.

This means that if the hacker gains access to the encryption key (private key), they can reverse the entire process easily.

Hashing

Instead, the user's password should be hashed on the server-side. Why? Because you can get away with comparing two hashes to check whether they match without ever storing the plain-text representation of that value.

And once again, you may be asking, "Why"? Well because hashing functions are one-way, meaning that the plain-text value cannot be reversed (well, they are very hard to), I shall not be going into to much detail.

What should I do?

The user's passwords should never be stored as plain-text in any part of the web server. Instead, you should be storing the user's hash. When the user then tries to login, you receive their plain-text password securely over HTTPS/TLS, hash it and if both hashes match, authenticate the user.

So a database table might look like so:

+--------------------------------------+
|  ID  |  Username  |   Password Hash  |       
+--------------------------------------+
|  1   | foo        | $2a$04$/JicM     |
|  2   | bar        | $2a$04$cxZWT     |
+--------------------------------------+

• Note, the hashes are truncated BCrypt hashes with 4 rounds (AKA - Invalid)

Now let's take an example, between Alice and our server. Don't take the data too literally.

Alice sends a request to login with her credentials, which first passes through our secure transport layer:

{username: "foo", password: "bar"} -> TLS() -> ZwUlLviJjtCgc1B4DlFnK -> | Server |

Our server receives this, then uses it's certificate key to decrypt this:

ZwUlLviJjtCgc1B4DlFnK -> KEY() -> {username: "foo", password: "bar"} -> Web Application

Great! Our credentials have been passed securely, now what? Hash that password and compare against what we got in our database.

BCRYPT('bar') -> $2a$04$/JicM

if ($2a$04$/JicM == user.get_password_hash) {
    authenticate();
}
else {
    return status_code(401);
}

We have now been able to authenticate a user, storing an irreversible hash value and without ever storing the plain-text value. This should have answered your first and second question.

这篇关于后端密码加密vs哈希的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！