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:


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
    Commented Dec 21, 2016 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
    Commented Dec 21, 2016 at 13:26
  • at best you could predict that which you already know, the relation to bytes before and after is non-existent.
    – dandavis
    Commented Dec 22, 2016 at 3:28

1 Answer 1


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
    Commented Dec 22, 2016 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
    Commented Dec 22, 2016 at 9:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .