4

I am making a system for storing hashed version of some secrets. I have read through dropbox's blog about how they store their passwords, and have taken inspiration from what they are doing.

Dropbox, as far as I understand, does this:

  1. Get password
  2. One-way hash with SHA512 (to combat possible truncation of password in bcrypt)
  3. One-way hash with bcrypt
  4. Two-way encrypt with AES256 password based encryption with global server-side password
  5. Store in database.

I see one potential weakness with this system in point 4.

When using the server side password-based encryption, encrypting the bcrypt value, will the predictable bcrypt headers weaken the strategy?

The bcrypt hash looks something like this:

$2a$10$q16tPq1UQXP9n8yrcm0TMeWriU4F..i4S5Gs78zBWKDG3ourZXvCK

The start, header, will most likely always be the same for the same system: $2a$10$. Of course, they might be some other value, but they are most likely shared among all your stored password hashes.

Thus, for the password-based encryption system, an attacker could then look for patterns matching this header, and potentially find your encryption password.

Would a better approach be to extract the bcrypt headers, and then encrypt the remaining salt + hash only?

As far as I understand this will not have any predictable component, and thus be more secure.

I am doing this in java currently. Maybe there are some pre-existing solutions for this type of problem?

(PS. I am fairly new to cryptography, so please correct me if I use the wrong jargon/tags etc.)

  • If you manage to decrypt the AES256 encryption, then what? You still need to crack the bcrypt. As the dropbox blog post mentioned, the AES step is just defense in depth. The core of the system is still the SHA512+bcrypt. – Lie Ryan Dec 21 '16 at 13:00
  • @LieRyan Yes indeed, but if the header of the bcrypt makes the AES256 step very weak, then it is better to skip it completely to create a less complicated system. – Automatico Dec 21 '16 at 13:26
  • at best you could predict that which you already know, the relation to bytes before and after is non-existent. – dandavis Dec 22 '16 at 3:28
2

Thus, for the password-based encryption system, an attacker could then look for patterns matching this header, and potentially find your encryption password.

There are no such patterns in the ciphertext. In the olden days, crypto algorithms were vulnerable to things like known plaintext attacks and you should avoid sending the same plaintext over and over again. Indeed, the Brittish were helped in cracking the Enigma ciphers by the Germans sending words like "wetteruebersicht" in a predictable way.

But that was then. Modern crypto is different. AES, if used right, produce something that is indistinguishable from random garbage unless you have the key, no matter how predictable your input is.

So there is no need to cut the prefix from the bcrypt output.

  • This is really interesting. Do you have any more information about how modern crypto is protected against this, or simply what this concept is called so I can find it myself? – Automatico Dec 22 '16 at 9:02
  • @Cort3z I would recommend you to read up on "plain text attacks", "encryption mode" and "IV". To be honest, I don't know exactly how it works myself, only that it does work. If you have specific questions, you can always ask on Crypto.SE. – Anders Dec 22 '16 at 9:27

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.