4

If you first encrypt a password using a secure key, and then hash the result, and both algorithms are fast, say sha_256(salt+aes_256(password, secure_key)), would that make the hash expensive to brute-force without making it expensive to generate?

[Addendum for clarification]

I have a security concern with slow hashes in that they weaken availability. If I use a slow hash that requires my server to be CPU-bound for, say, 500ms per user, and I get a flood of new users all at once, then I will have given poor or no service to many potential customers as their first experience with a site. It also seems to be an easy vector for a DOS attack. A slow hash intuitively feels like a brute-force defense to me, and I'm questioning whether a lot of CPU effort from the defender is really necessary to thwart an attacker.

  • Do you expect someone to break the AES356? Besides, where do you plan to keep this key? – kelalaka Dec 14 '19 at 18:01
  • I don't, but I also don't want a corrupt administrator to be able to decrypt all the passwords. Assume I provide a key-providing service that can only be accessed from the web server. – phatfingers Dec 15 '19 at 1:07
  • Maybe clarifying your use case in your question will make it more clear. Are you considering this corrupt administrator for the application server or database server or both? How do you plan to keep the AES key safely? – kelalaka Dec 15 '19 at 7:25
  • This may be taken as flip, but it is not intended that way; I have a tendency to try to over-engineer things, and it is helpful for me when other people call me out on it, so I'm going to offer you the advice I would want. Specifically, I hear your concern about availability and inadvertent denial of service. I suspect that by the time you have that problem, you will have other, more important problems that come with success. I think solving those problems will lead you to successfully mitigate this problem inadvertently as a part of solving them. – Slartibartfast Dec 16 '19 at 2:12
  • You're probably right, although I have worked on some jobs where that level of scale was relevant. I suppose my question could be reduced to sha_256(salt + secret + plaintext) vs bcrypt(salt + plaintext). – phatfingers Dec 16 '19 at 4:16
1

You would essentially me using encryption as a "pepper". I.e. a salt that is shared among all the database entries and is not stored with the database. Normally this is just another random value that is added to the password hash but as far as I can tell with a few minutes reflection, encrypting the password instead before hashing should accomplish the same thing.

Here's the thing with peppers: they don't increase the brute force complexity at all. What they do accomplish is to make it impossible to brute force at all from only a dump of the password hashes. Directly attacking a password hash without knowing the pepper becomes roughly equivalent to brute-forcing the random value used as an encryption key/pepper value, which is not possible at all with a sufficiently large key/pepper value. This can add security through defense in depth because the attacker must compromise your system more fully or compromise multiple systems in order to find the pepper before attacking you. For example, your password database would no longer be at risk from a simple SQL injection because the attacker would not obtain your pepper. But, depending on how the key is stored, obtaining read access to all files on your web server could, could yield both the password database and the pepper. If this happens, the password is only protected by a single round of your hash. Using a nonstandard pepper method, in your case using encryption, does not help in this scenario. Symmetric encryption is too fast to make a difference, and while asymmetric encryption takes longer, it is not clearly better than just using a larger number of iterations on a standard password hash. Even if you use a miniscule iteration count in order to compare it to a round of asymmetric encryption, your method is almost certainly less secure than a purpose-built hash like Argon2, which spent 2 years in development and testing by expert cryptographers before winning the Password Hashing Competition and has received fixes and improvements since in order to combat weaknesses specific to the task of hashing passwords. Using a normal number of iterations, to bring the hashing time up to tenths of a second or more per password, but with a standard pepper, would greatly surpass the security of your algorithm even with a weaker hash like bcrypt or PBKDF-2.

In short: just use a standard password hash with a high number of iterations and solve the DOS problem in a different way. Add a pepper if you want more defense-in-depth and to prevent compromise by some common attacks but don't fully rely on it for your security.

| improve this answer | |
2

Yes this would make brute-forcing more expensive, but as was pointed out by “kelalaka” it creates an additional key management problem.

The more classic way to make brute-force more expensive is by iteration. A hash of a hash of a hash … of a hash a few hundred thousand times can be made arbitrarily slow without creating additional key management problems.

Fundamentally the expense to generate is what makes it expensive to brute-force, all other things being equal.

An unequal example would be a too small hash space. If I assume an arbitrarily complex hash-encryption-magic method that produces a 32-bit hash result, I only have to find a password among 4 billion, and it’s probably not even the one you used but it will still work because of the small collision space.

| improve this answer | |
  • Along similar lines, let's say you double the number of bits in your hash and it doubles the amount of time to produce it, say from 1ms to 2ms. You would have substantially increased the expense of brute forcing a solution without substantially increasing the expense of generating the hash. Fundamentally, I don't agree that expense to generate is the only way to make something expensive to brute force. – phatfingers Dec 16 '19 at 3:54
  • Not quite true. If you've increased hash generation time twice, you've increased brute force time only twice - 'brute forcing' a hash is literally computing hash function for different inputs. The complexity of that does not grow exponentially – DarkWanderer Dec 16 '19 at 5:13
  • For a dictionary attack against a simple hashed password, I would heartily agree. For a full brute force attack of all possible hashes matching a password combined with a sufficiently large secret, the number of attempts needed to randomly coincide with a result would roughly double with each added bit. – phatfingers Dec 16 '19 at 7:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.