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://stackoverflow.com/a/99724/932473
• 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/

Solution

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.

Comments

[Patrick]

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

[Cully]

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.

[martinstoeckli]

@Cully - 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.