[WEB SECURITY] Max size of a password

Michael H Buselli cosine at cosine.org
Sat May 21 23:45:07 EDT 2011


On Sat, 21 May 2011 23:52:02 +0300, "MustLive" wrote:

> My recommendations concerning minimum and maximum password's length are the
> next:
> 
> - minimum - 8 characters,
> - maximum - no limits (but you can add limits depending on hardware
> restrictions).
> 
> I haven't heard about industry's password best practices, but from 2005 in
> my own security manual I was recommending above-mentioned 8 characters
> minimum length (and with time it's needed to revise this limit).

A real good underlying goal of any such password policy is to try to
enforce use of passwords that have an entropy of at least some number of
bits.  I like using about 40 bits for average security needs, such as on
typical corporate systems and applications.  A completely random
6 character password using only printable ASCII characters achieves
about 40 bits, but people cannot be realistically expected to use such
passwords.  Expanding the minimum to 8 characters helps cover the gap
between usability and creating rememberable passwords with sufficient
entropy.  However, you will also need to mix in (annoying) password
complexity rules and rules forbidding dictionary words to achieve 40
bits in 8 characters.  Otherwise you need a yet larger minimum.  Keep
your user base in mind and decide which trade offs you want to make.

As time marches forward, there is no technical reason to increase the
minimum that you decide upon today that fits your organization.  New
password hashing algorithms (if they're any good for this use) increase
the time to compute accordingly and maintain a safe level of security
for passwords above 40 bits of entropy.  On this note, I recommend
against using anything in the SHA family without modification because
they're engineered to be fast, and you want a password hashing algorithm
engineered to be slow.  You can use a modified SHA algorithm with an
increased number of rounds to slow things down, or use bcrypt.  If you
do not control how things are hashed and they are hashed with a fast
algorithm, then file a bug report.

40 bits of entropy means that, on average, an attacker would need 500
trillion guesses at the password to crack it.  If you force him to use
a slow hash algorithm then the time to crack should greatly outlive the
life of the password before it is changed.  Therefore, make sure you
force your users to change their passwords as part of your policy, too.
The other reason that you force users to change their passwords is to
reduce the window of exposure if a password is sniffed, lifted, or
otherwise compromised, so thoughts on that issue need to be considered
when building your password policy as well.  I prefer 91 days (13 weeks)
for average security needs.  If you think that's too long for your
system, then I suggest you really consider using a two-factor
authentication scheme anyway.

Finally, another thing to keep in mind is how the application
authenticates its user or client.  If you are securing automated HTTP(S)
client-server communication that uses basic-auth instead of a login
followed by use of a cookie or token, you have to give up using a slow
hashing algorithm (all those HTTP requests will eat your CPU alive!) and
churn up the password entropy to compensate (maybe 64 or 80?  Plop in
128 bits of randomness in the password if you have room!).

T\_/T\_/T
Michael H Buselli         http://cosine.org/         <cosine at cosine.org>
"There's no such thing as a Jack of All Trades that hasn't mastered at
 least one of them."




More information about the websecurity mailing list