Password max length with bcrypt, blowfish


Staff member
My question derives from this
<a href="">How to hash long passwords (&gt;72 characters) with blowfish</a>

I am using bcrypt(blowfish) to hash the passwords. So, as I found out from this question
<a href=""></a>

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

<a href=""></a>

<a href="">Why restrict the length of a password?</a>

<a href="">Should I impose a maximum length on passwords?</a>

All said is against that. Mentioning things, like

<li>save storage</li>
<li>old Unix system experiences</li>
<li>Interaction with legacy systems that do not support long passwords</li>
<li>Convention (i.e. "we've always done it that way")</li>
<li>Simple naivety or ignorance.</li>
<li><strong>storing in plaintext</strong></li>
a maximum length specified on a password field should be read as a SECURITY WARNING
, by this answer - <a href=""></a></li>

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

<a href="" rel="nofollow noreferrer"></a>

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)

<strong>qsn1:</strong> 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.

<strong>qsn2:</strong> 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.
<a href=""></a>
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) ?



According to Owasp, password's reasonable max length is 160
<a href="" rel="nofollow noreferrer"></a>

google has password max length of 100

<img src=" " alt="enter image description here">

Wordpress has max limit of 50

<a href="" rel="nofollow noreferrer"></a>