围绕凭据存储阻止密码，盐，AES，MySQL和最佳实践 [英] Block ciphers, salt, AES, MySQL, and best practices around credential storage

问题描述

在构建要连接到另一个系统的系统时，我必须存储密码.该其他系统仅允许一个用户帐户，并且唯一的连接方法是通过密码.此处不适合使用散列.我必须以一种可以检索它的方式存储密码.

I have a situation where I must store a password, as I am building a system to connect to another system. This other system only allows for a single user account, and the only way to connect to it is via a password. A hash is not appropriate here. I must store the password in a way that I can retrieve it.

现在，由于知道这不是一个完美的系统，如果有人以某种方式访问​​数据库，我将尝试限制损坏.由于该数据库将需要在各种平台上使用，因此我决定使用MySQL自己的内置加密功能.这样，我不必担心为各种语言和系统找到兼容的加密/解密算法实现.我可以在查询中使用MySQL的功能.

Now, with the knowledge that this is not a perfect system, I am trying to limit damage should someone get access to the database somehow. As this database will need to be used by varying platforms, I have decided to use MySQL's own built-in encryption functions. This way, I don't need to worry about finding compatible encryption/decryption algorithm implementations for various languages and systems. I can just use MySQL's function in a query.

在存储密码时，我将使用AES_ENCRYPT("password", "encryption key").然后我意识到我可能应该使用一些盐，以便如果他们能够获得一个密码，那么很难获得其他密码.可是等等！有什么意义呢?如果他们能够获得一个密码，那么他们必须具有加密密钥，是吗?

When storing a password, I will use AES_ENCRYPT("password", "encryption key"). Then I realized that I should probably use some salt so that if they were able to get one password, it would be harder to get others. But wait! What is the point? If they are able to get one password, they must have the encryption key, yes?

此外，这是分组密码.在某些情况下，盐可能几乎是无用的.

Besides, this is a block cipher. Salts can be near-useless in some situations.

/* Returns 8CBAB2A9260975FF965E5A7B02E213628CBAB2A9260975FF965E5A7B02E21362FBB5D173CBAFA44DC406B69D05A2072C */
SELECT HEX(AES_ENCRYPT("passwordpasswordpasswordpassword", "encryption key"));

/* Returns 8CBAB2A9260975FF965E5A7B02E213628CBAB2A9260975FF965E5A7B02E21362C49AF8D5B194770E64FEF88767206391 */
SELECT HEX(AES_ENCRYPT("passwordpasswordpasswordpassworda", "encryption key"));

我的问题

• 我是对的，在我的情况下使用对称加密时没有理由不加盐吗?

  My Questions

  • Am I right in thinking that there is no reason to have a salt when using symmetrical encryption for situations like mine?

    鉴于我必须以一种允许我检索原始值的方式存储密码，我还应该考虑其他方法吗? (我知道我需要注意加密密钥的存储位置和存储方式，也需要保护MySQL日志的安全.)

    Given that I must store a password in a way that allows me to retrieve the original value, are there any other methods I should be considering? (I am aware that I need to be careful about where and how the encryption key is stored, and that I need to secure my MySQL logs as well.)

    推荐答案

    通常对于标准AES，您将提供一个随机数(IV)，以避免出现您描述的问题.

    Usually for standard AES you'd supply a nonce (the IV), in order to avoid the problem you describe.

    一种大大提高加密数据质量的方法是对每个帐户使用不同的主密码，而不用更改IV.基本上，这是一些与密码混合的数据.您可以通过多种方式执行此操作，最简单的方法就是进行连续播放.

    A way to drastically improve the quality of the encrypted data is to use a different master password for every account instead of varying the IV. Basically this is some data which you mix with the password. You can do this many ways, the simplest is to do a concat.

    例如

    1. 创建随机序列.
    2. 存储随机数||十六进制(AES_ENCRYPT(密码存储区，主密码||随机数)
    3. 通过提取随机数进行检索，然后使用master_password ||解密数据.随机数.

    这里是一个示例，它具有唯一的随机数"iej383u8fjeiw"(每次加密都需要生成一个新的随机数)

    Here is an example, with the unique nonce 'iej383u8fjeiw' (Each time you encrypt you need to generate a new one)

    SELECT CONCAT('iej383u8fjeiw', ':', HEX(AES_ENCRYPT("password", CONCAT("master_password", "iej383u8fjeiw")))) 
    -> "iej383u8fjeiw:61224653D4DA33D57A42FE5E5E10DEA9"
    
    SELECT AES_DECRYPT(UNHEX(SUBSTRING_INDEX('iej383u8fjeiw:61224653D4DA33D57A42FE5E5E10DEA9', ':', -1)), CONCAT('master_password', SUBSTRING_INDEX('iej383u8fjeiw:61224653D4DA33D57A42FE5E5E10DEA9', ':', 1))) 
    -> "password"
    

    或带有变量:

    SELECT CONCAT(nonce, ':', HEX(AES_ENCRYPT(password_to_encrypt, CONCAT(master_password, nonce)))) 
    -> encrypted password
    
    SELECT AES_DECRYPT(UNHEX(SUBSTRING_INDEX(encrypted_password, ':', -1)), CONCAT(master_password, SUBSTRING_INDEX(encrypted_password, ':', 1)))
    -> password_to_encrypt
    

    也就是说，尽管比没有随机数的版本安全得多，但是仍然存在许多弱点和攻击媒介.例如，记录查询或嗅探mysql数据包将同时显示密码和主密码！

    That said, although significantly more secure than the version without a nonce, there are plenty of weaknesses and attacking vectors left. For example, logging of queries or sniffing mysql packets will reveal both password and master password!

    这篇关于围绕凭据存储阻止密码，盐，AES，MySQL和最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！