Password max length with bcrypt, blowfish

Question

My question derives from this How to hash long passwords (>72 characters) with blowfish

I am using bcrypt(blowfish) to hash the passwords. So, as I found out from this question https://security.stackexchange.com/questions/39849/does-bcrypt-have-a-maximum-password-length

it has a character limit of 72.

So, I started thinking to restrict the max length of the password, but after these questions and their answers

https://security.stackexchange.com/questions/33470/what-technical-reasons-are-there-to-have-low-maximum-password-lengths

Why restrict the length of a password?

Should I impose a maximum length on passwords?

All said is against that. Mentioning things, like

• save storage
• old Unix system experiences
• Interaction with legacy systems that do not support long passwords
• Convention (i.e. "we've always done it that way")
• Simple naivety or ignorance.
• storing in plaintext
• Also, a maximum length specified on a password field should be read as a SECURITY WARNING, by this answer - https://mcmap.net/q/126765/-should-i-impose-a-maximum-length-on-passwords
• etc

So, I do not think I match with one of these cases. Of course I agree with silly restrictions like max length of 10, or even worse, 8 or 6, but are not passwords(salted) with 30, 40 or more length deemed secure ? From this article (a little old though), but it says

it can make only 71,000 guesses against Bcrypt per second

http://arstechnica.com/security/2012/12/25-gpu-cluster-cracks-every-standard-windows-password-in-6-hours/

And this for 8 character passwords. So, I imagine how enormous will be the custom rainbow table to brute-force just one 30 or more character password(considering that each password has its own salt), as the rainbow table size increases exponentially

quote from the same article's comments

Every time you add a character to your password, you are exponentially increasing the difficulty it takes to crack via brute force. For example, an 8-char password has a keyspace of 95^8 combinations, while a 20-char password has a keyspace of 95^20 combinations.

So, for one 20 length password with bcrypt according to that will be necessary 95^20 / (71 000 * 3600 * 24 * 365) ~ 10's 28 degree years (if I did it right)

qsn1: Now, in this case with blowfish is there a meaning to NOT limit the password max length by 72, because in any case after that everything will be truncated and hence there is not extra security gain in here.

qsn2: Even if salt exists(which is unique for each user and is saved in db), after all I want to add pepper(which is hardcoded in application rather than saved in db) to the password. I know if will add little extra security, but I consider just in case if db(or db backup) is only leaked, pepper will be useful. https://security.stackexchange.com/a/3289/38200 So, to be able to add lets say 20 character pepper, I need to make the password max length to about 50. I think like this: lets say the user is using 70 characters, in most cases (if not all), it will be some phrase or smth like that, rather than generated strong one, so would not it be more secure to restrict the user by 50 max length and add another 20-22 character pepper which is definitely more secure/random. Also, lets say hacker is using rainbow table of "common phrases", I think there are higher chances, that 72 character common phrase will be hacked, than 50 character common phrase + 22 character random string. So, is this approach with pepper and 50 max length better, or I am doing smth wrong, and it is better to leave 72 max limit (if qsn1 is ok) ?

Thanks

BTW:

According to Owasp, password's reasonable max length is 160 https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet#Do_not_limit_the_character_set_and_set_long_max_lengths_for_credentials

google has password max length of 100

Wordpress has max limit of 50

https://signup.wordpress.com/signup/

Plague

I am not sure what is the actual question besides all this text, but if the underlying algo uses at most X characters you should limit your input to X characters too to explicitly indicate that more characters are simply will not be used and hence will not increase security. Also, security SO:Do any security experts recommend bcrypt for password storage? and questions linked to it can be of general interest to you. – Unscrupulous

@OlegEstekhin, the question is about approach if it is right/ok in terms of security. second qsn is about using pepper. Thanks for the link . – Plague

Answer 1

Question 1: There is simply no reason to limit the password length, BCrypt will work with much longer passwords, though only 72 characters are used. You would have no advantage at all, but theoretically you would hinder people with password managers using longer passwords. If you switch to another algorithm in future, the limit would probably be different, so no reason to limit with 72 characters.

Question 2: Instead of peppering you could better use another approach: Encrypt the password-hash with a server-side key. The reason to add a pepper is, that an attacker must gain privileges on the server, because without the key he cannot start brute-forcing the hashes (SQL-injection or thrown away backups of the database won't do). The same advantage you get with encrypting (two-way) the hash.

1. This way you do not need to reserve characters for the pepper, you can use all 72 characters from the password.
2. In contrast to the pepper, the server side key can be exchanged whenever this is necessary. A pepper actually becomes part of the password and cannot be changed until the next login.
3. Another discussed point is, that a pepper could theoretically interfere with the hash-algorithm.

Weihs

There is at least one reason to enforce the 72-byte limit. Though it is a potentially unlikely scenario. If you are verifying passwords for strength, the first 72 bytes might not be very secure while the the untruncated version could be considered very secure. So when doing the verification, your check will say the password is secure, but when encrypted, it isn't. For example, let's say instead of 72 bytes, the limit is 8 bytes. passwordvqYMzPJ3jc is strong untruncated, but once encrypted, it's essentially the most easily guessable password there is. – Hyperpituitarism

@Hyperpituitarism - That's indeed extremely unlikely, if a user cares about 72+ char passwords (s)he also cares about security and wouldn't use a weak leading 63 char part. 72+ char passwords are hardly typed in, they are copied from password managers, and such tools don't create weak passwords. Finally there isn't any sane hacker who would start brute-forcing with weak leading 63+ character parts, even more it is difficult to create a weak part with this length, one would have to write something like aaaa.... But in theory you are correct. – Weihs

Answer 2

Beyond simple hashing of a user supplied password, there are other use cases for wanting to securely hash the entirety of an arbitrarily long string using bcrypt. One may also wish to salt the password before passing it into bcrypt for an even higher level of entropy.

One algorithm I use to get around the character limit is to use an intermediate hash. So, instead of hashing the password directly, I use a weaker hashing mechanism that produces a shorter string within the length limitation of bcrypt and then hash that intermediate string using bcrypt. The intermediate hash needn't be strong hash, like bcrypt, though if you use a highly randomized and long salt you will maximize the effectiveness of this approach. My current intermediate hash is sha512.

The steps I use for hashing passwords are as follows:

1. Generate a long, cryptographically secure salt using a source such as /dev/urandom. (Do this per user. You can also append an application-wide salt as well if you like.) You will need to store this salt if you plan to do password validation in the future.
2. Concatenate the salt to the user supplied password.
3. Feed the concatenated value to sha512 and capture the result, which will be a 128 character string representing a hexidecimal number.
4. To add entropy and make use of the entire intermediate salt, loop through the entire sha512 hash taking pairs of hex digits, converting the pair's value to an ascii character and using each character to build a compacted intermediate hash that is 64 characters long where there are 256 possible characters.
5. Feed the final compacted intermediate hash into bcrypt with your preferred parameters (such as cost) and capture the resulting hash.
6. You now have a secure hash that utilizes the entirety of the value of your long password.

Imprinting

Homebrew KDF schemas are always discouraged. Use something proven like HKDF for expanding/extracting entropy to a custom length. – Hypallage