Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I read at crackstation not to use these variants of bcrypt* ($1$, $2$, $2a$, $2x$, $3$),but I've used bcrypt ($2a$) in various sensitive implementations recently.
Can any security expert clarify why recommending ($2y$, $5$, $6$) instead of ($1$, $2$, $2a$, $2x$, $3$), what is the original version proposed by Niels Provos, and in what they differ

bcrypt is a key derivation function for passwords designed by Niels Provos and David Mazières, based on the Blowfish cipher, and presented at USENIX in 1999. Besides incorporating a salt to protect against rainbow table attacks, bcrypt is an adaptive function: over time, the iteration count can be increased to make it slower, so it remains resistant to brute-force search attacks even with increasing computation power.

share|improve this question
I don't have enough reputation to leave a comment so I have to put this as an answer. >Read this, please: $2a$ is secure in PHP>=5.3.7 – Andrey Botalov Sep 26 '12 at 12:36 Serious crypto bug in php 5.3.7 PHP 5.3.8 Fixes Serious Crypt Bug – Dave Albert Mar 22 '13 at 9:52
There is a fairly comprehensive presentation about the history of (most) password hashes, and some future directions at: – chexum Dec 22 '15 at 21:43
up vote 16 down vote accepted
  • 2 - the original BCrypt, which has been deprecated because of a security issue a long time before BCrypt became popular.

  • 2a - the official BCrypt algorithm and a insecure implementation in crypt_blowfish

  • 2x - suggested for hashes created by the insecure algorithm for compatibility
  • 2y - suggested new marker for the fixed crypt_blowfish

So 2a hashes created by the original algorithm or the java port are fine, and identical to 2y-hashes created by crypt_blowfish. But 2a hashes created by crypt_blowfish are insecure.

  • 5 is sha256crypt
  • 6 is sha512crypt

The shaXXXcrypt algorithm are inspired by bcrypt but use sha2 instead of blowfish as hash functions in order to satisfy compliance requirements in the USA.

share|improve this answer
can you further explain what you mean by insecure implementation, and in what area they are particularly insecure ? – sarepta Sep 23 '12 at 7:51
@sarepta, if the password contains characters outside the 7-bit range, some character are ignored. I added a link to the report, which explains it in detail. – Hendrik Brummermann Sep 23 '12 at 8:52
can you (if possible) provide a link to download secure implementation ($2y$, $5$, $6$) in .net, it seems as if all the libraries in the web are $2a$ and its getting in my nerves! – sarepta Sep 23 '12 at 14:23
Read this, please: $2a$ is secure in PHP>=5.3.7 – Andrei Botalov Sep 26 '12 at 12:36
@HendrikBrummermann can you comment further on how $6 would work in bcrypt for password hashing, vs. $2y$? – Shackrock May 23 '13 at 11:34

BCrypt variants

  • $2$

    The original specification used the prefix $2$. This was in contrast to the other algorithm prefixes:

    • $1$ - MD5
    • $5$ - SHA-256
    • $6$ - SHA-512
  • $2a$

    The original specification did not define how to handle non-ASCII character, or how to handle a null terminator. The specification was revised to specify that when hashing strings:

    • the string must be UTF-8 encoded
    • the null terminator must be included
  • $2x$, $2y$ (June 2011)

    A bug was discovered in crypt_blowfish, a PHP implementation of BCrypt.

    It was mis-handling characters with the 8th bit set. They suggested that system administrators update their existing password databases, replacing $2a$ with $2x$, to indicate that those hashes are bad (and need to use the old broken algorithm).

    They also suggested the idea of having crypt_blowfish emit $2y$ for hashes generated by the fixed algorithm. Nobody else, including canonical OpenBSD, adopted the idea of 2x/2y. This version marker was was limited to crypt_blowfish

  • $2b$ (February 2014)

    A bug was discovered in the OpenBSD implemenation of bcrypt.

    They were storing the length of their strings in an unsigned char. If a password was longer than 255 characters, it would overflow and wrap at 255.

    BCrypt was created for OpenBSD. So when they had a bug in their library, they decided it was ok to bump the version. This means that everyone else needs to follow suit if you want to remain current to "their" specification.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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