Empathy List Archives

MH

Michael H Buselli

Sun, May 22, 2011 3:45 AM

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@cosine.org
"There's no such thing as a Jack of All Trades that hasn't mastered at
least one of them."

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@cosine.org> "There's no such thing as a Jack of All Trades that hasn't mastered at least one of them."

CT

Claudio Telmon

Sun, May 22, 2011 7:59 AM

On 05/22/2011 12:33 AM, Gautam wrote:

Now my delima is

SHA256(AAA) = some 256 bit hash

now

SHA256(AAABB) = is also 256 bit hash

so with this reasoning will it make sense if i say no limit or just a
reasonable limit of 14 character since the result is always going to be
128bit text be it 8 characters or 14 characters.

A good hash function can provide you an entropy which is limited by the
length of the output, but the entropy available in the input domain is
also a limit. 14 characters as input from a user are not random bits and
won't provide 128 bit of entropy for the result. If users are permitted
(and suggested) to choose long passphrases, they may end up feeding the
function with enough entropy. If they are limited to 14 characters, they
will select passwords that will be shorter that 14 characters and are
not random, so they will always feed less that 128 bit of entropy to the
function, and the output will also have less that 128 bits of entropy,
even if it is 128 bit long.

ciao

Claudio

--

Claudio Telmon
claudio@telmon.org
http://www.telmon.org

On 05/22/2011 12:33 AM, Gautam wrote: > Now my delima is > > SHA256(*AAA*) = some 256 bit hash > > now > > SHA256(*AAABB*) = is also 256 bit hash > > so with this reasoning will it make sense if i say no limit or just a > reasonable limit of 14 character since the result is always going to be > 128bit text be it 8 characters or 14 characters. A good hash function can provide you an entropy which is limited by the length of the output, but the entropy available in the input domain is also a limit. 14 characters as input from a user are not random bits and won't provide 128 bit of entropy for the result. If users are permitted (and suggested) to choose long passphrases, they may end up feeding the function with enough entropy. If they are limited to 14 characters, they will select passwords that will be shorter that 14 characters and are not random, so they will always feed less that 128 bit of entropy to the function, and the output will also have less that 128 bits of entropy, even if it is 128 bit long. ciao - Claudio -- Claudio Telmon claudio@telmon.org http://www.telmon.org

A

albino

Sun, May 22, 2011 11:07 AM

I know most of you know this but I'm not sure about the OP. SHA256(AAA)
is more likely to be guessed than SHA256(AAABB) even though the
resulting hashes are the same length. When an attacker attempts to crack
hashes they don't guess the hash directly; they guess the password then
generate the hash to check whether it was correct or not. Guessing
SHA-256 hashes directly is unfeasible with current technology. So
placing an upper limit of 14 will decrease the security of some users.

albino

-----Original Message-----
From: Gautam itsecanalyst@gmail.com
To: MustLive mustlive@websecurity.com.ua
Cc: websecurity@webappsec.org
Subject: Re: [WEB SECURITY] Max size of a password

Thanks everyone for writing, MustLive i have expressed my opinion on
mimimum limit and No maximum limit.

However while i wrote this post to this forum I was thinking in backend
about how this impacts hashing results and the length.

As we all know storing just pain-text passwords would be the biggest
blunder that anyone could do, so I recommend doing at least Salted-SHA
versions.

Now my delima is

SHA256(AAA) = some 256 bit hash

now

SHA256(AAABB) = is also 256 bit hash

so with this reasoning will it make sense if i say no limit or just a
reasonable limit of 14 character since the result is always going to be
128bit text be it 8 characters or 14 characters.

Let me know your views.

Thanks,
Gautam

I know most of you know this but I'm not sure about the OP. SHA256(AAA) is more likely to be guessed than SHA256(AAABB) even though the resulting hashes are the same length. When an attacker attempts to crack hashes they don't guess the hash directly; they guess the password then generate the hash to check whether it was correct or not. Guessing SHA-256 hashes directly is unfeasible with current technology. So placing an upper limit of 14 will decrease the security of some users. albino -----Original Message----- From: Gautam <itsecanalyst@gmail.com> To: MustLive <mustlive@websecurity.com.ua> Cc: websecurity@webappsec.org Subject: Re: [WEB SECURITY] Max size of a password Thanks everyone for writing, MustLive i have expressed my opinion on mimimum limit and No maximum limit. However while i wrote this post to this forum I was thinking in backend about how this impacts hashing results and the length. As we all know storing just pain-text passwords would be the biggest blunder that anyone could do, so I recommend doing at least Salted-SHA versions. Now my delima is SHA256(AAA) = some 256 bit hash now SHA256(AAABB) = is also 256 bit hash so with this reasoning will it make sense if i say no limit or just a reasonable limit of 14 character since the result is always going to be 128bit text be it 8 characters or 14 characters. Let me know your views. Thanks, Gautam

JM

James Manico

Sun, May 22, 2011 6:24 PM

Then again, hashing and salting is not enough for secure password storage.

Use a strong/modern hash
Use a cryptographically strong salt
2a) Isolate that salt from the actual hash
Iterate the hashing of the pass and salt 1000 times (as of y2k,
doubling that iteration value every three years when you re-hash to
slow down re-construction of the custom hash table if the salt is know
by the attacker)
For %#^* sakes, stop depending on password as the only factor for
authentication. Shifting to 2-factor strategies decreases the need for
strong password policy or storage mechanisms.

Jim Manico

On May 22, 2011, at 7:46 PM, Claudio Telmon claudio@telmon.org wrote:

On 05/22/2011 12:33 AM, Gautam wrote:

Now my delima is

SHA256(AAA) = some 256 bit hash

now

SHA256(AAABB) = is also 256 bit hash

so with this reasoning will it make sense if i say no limit or just a
reasonable limit of 14 character since the result is always going to be
128bit text be it 8 characters or 14 characters.

A good hash function can provide you an entropy which is limited by the
length of the output, but the entropy available in the input domain is
also a limit. 14 characters as input from a user are not random bits and
won't provide 128 bit of entropy for the result. If users are permitted
(and suggested) to choose long passphrases, they may end up feeding the
function with enough entropy. If they are limited to 14 characters, they
will select passwords that will be shorter that 14 characters and are
not random, so they will always feed less that 128 bit of entropy to the
function, and the output will also have less that 128 bits of entropy,
even if it is 128 bit long.

ciao

Claudio

--

Claudio Telmon
claudio@telmon.org
http://www.telmon.org

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

Then again, hashing and salting is not enough for secure password storage. 1) Use a strong/modern hash 2) Use a cryptographically strong salt 2a) Isolate that salt from the actual hash 3) Iterate the hashing of the pass and salt 1000 times (as of y2k, doubling that iteration value every three years when you re-hash to slow down re-construction of the custom hash table if the salt is know by the attacker) 4) For %#^* sakes, stop depending on password as the only factor for authentication. Shifting to 2-factor strategies decreases the need for strong password policy or storage mechanisms. Jim Manico On May 22, 2011, at 7:46 PM, Claudio Telmon <claudio@telmon.org> wrote: > On 05/22/2011 12:33 AM, Gautam wrote: >> Now my delima is >> >> SHA256(*AAA*) = some 256 bit hash >> >> now >> >> SHA256(*AAABB*) = is also 256 bit hash >> >> so with this reasoning will it make sense if i say no limit or just a >> reasonable limit of 14 character since the result is always going to be >> 128bit text be it 8 characters or 14 characters. > > A good hash function can provide you an entropy which is limited by the > length of the output, but the entropy available in the input domain is > also a limit. 14 characters as input from a user are not random bits and > won't provide 128 bit of entropy for the result. If users are permitted > (and suggested) to choose long passphrases, they may end up feeding the > function with enough entropy. If they are limited to 14 characters, they > will select passwords that will be shorter that 14 characters and are > not random, so they will always feed less that 128 bit of entropy to the > function, and the output will also have less that 128 bits of entropy, > even if it is 128 bit long. > > ciao > > - Claudio > > -- > > Claudio Telmon > claudio@telmon.org > http://www.telmon.org > > > _______________________________________________ > The Web Security Mailing List > > WebSecurity RSS Feed > http://www.webappsec.org/rss/websecurity.rss > > Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA > > WASC on Twitter > http://twitter.com/wascupdates > > websecurity@lists.webappsec.org > http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

G

Gautam

Sun, May 22, 2011 6:46 PM

Claudio, Albino and James, You gave me the exact answer I was looking for,
i know about hashing and other things, however the entropy stuff probably
was known to me in full. I read a couple of papers from NIST last night to
understand this better.

I am also going to add the 2nd factor auth in my recommendation, since most
of the stuff is what you know, what you have is where I want to take this
and probably What you are will be next.

Thanks to all.

Gautam

On Sun, May 22, 2011 at 11:24 AM, James Manico jim@manico.net wrote:

Then again, hashing and salting is not enough for secure password storage.

Use a strong/modern hash
Use a cryptographically strong salt
2a) Isolate that salt from the actual hash
Iterate the hashing of the pass and salt 1000 times (as of y2k,
doubling that iteration value every three years when you re-hash to
slow down re-construction of the custom hash table if the salt is know
by the attacker)
For %#^* sakes, stop depending on password as the only factor for
authentication. Shifting to 2-factor strategies decreases the need for
strong password policy or storage mechanisms.

Jim Manico

On May 22, 2011, at 7:46 PM, Claudio Telmon claudio@telmon.org wrote:

On 05/22/2011 12:33 AM, Gautam wrote:

Now my delima is

SHA256(AAA) = some 256 bit hash

now

SHA256(AAABB) = is also 256 bit hash

so with this reasoning will it make sense if i say no limit or just a
reasonable limit of 14 character since the result is always going to be
128bit text be it 8 characters or 14 characters.

A good hash function can provide you an entropy which is limited by the
length of the output, but the entropy available in the input domain is
also a limit. 14 characters as input from a user are not random bits and
won't provide 128 bit of entropy for the result. If users are permitted
(and suggested) to choose long passphrases, they may end up feeding the
function with enough entropy. If they are limited to 14 characters, they
will select passwords that will be shorter that 14 characters and are
not random, so they will always feed less that 128 bit of entropy to the
function, and the output will also have less that 128 bits of entropy,
even if it is 128 bit long.

ciao

Claudio

--

Claudio Telmon
claudio@telmon.org
http://www.telmon.org

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org

http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

Claudio, Albino and James, You gave me the exact answer I was looking for, i know about hashing and other things, however the entropy stuff probably was known to me in full. I read a couple of papers from NIST last night to understand this better. I am also going to add the 2nd factor auth in my recommendation, since most of the stuff is what you know, what you have is where I want to take this and probably What you are will be next. Thanks to all. Gautam On Sun, May 22, 2011 at 11:24 AM, James Manico <jim@manico.net> wrote: > Then again, hashing and salting is not enough for secure password storage. > > 1) Use a strong/modern hash > 2) Use a cryptographically strong salt > 2a) Isolate that salt from the actual hash > 3) Iterate the hashing of the pass and salt 1000 times (as of y2k, > doubling that iteration value every three years when you re-hash to > slow down re-construction of the custom hash table if the salt is know > by the attacker) > 4) For %#^* sakes, stop depending on password as the only factor for > authentication. Shifting to 2-factor strategies decreases the need for > strong password policy or storage mechanisms. > > Jim Manico > > On May 22, 2011, at 7:46 PM, Claudio Telmon <claudio@telmon.org> wrote: > > > On 05/22/2011 12:33 AM, Gautam wrote: > >> Now my delima is > >> > >> SHA256(*AAA*) = some 256 bit hash > >> > >> now > >> > >> SHA256(*AAABB*) = is also 256 bit hash > >> > >> so with this reasoning will it make sense if i say no limit or just a > >> reasonable limit of 14 character since the result is always going to be > >> 128bit text be it 8 characters or 14 characters. > > > > A good hash function can provide you an entropy which is limited by the > > length of the output, but the entropy available in the input domain is > > also a limit. 14 characters as input from a user are not random bits and > > won't provide 128 bit of entropy for the result. If users are permitted > > (and suggested) to choose long passphrases, they may end up feeding the > > function with enough entropy. If they are limited to 14 characters, they > > will select passwords that will be shorter that 14 characters and are > > not random, so they will always feed less that 128 bit of entropy to the > > function, and the output will also have less that 128 bits of entropy, > > even if it is 128 bit long. > > > > ciao > > > > - Claudio > > > > -- > > > > Claudio Telmon > > claudio@telmon.org > > http://www.telmon.org > > > > > > _______________________________________________ > > The Web Security Mailing List > > > > WebSecurity RSS Feed > > http://www.webappsec.org/rss/websecurity.rss > > > > Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA > > > > WASC on Twitter > > http://twitter.com/wascupdates > > > > websecurity@lists.webappsec.org > > > http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org >

NK

nilesh kumar

Mon, May 23, 2011 12:54 PM

Exactly Gautam,

If the website is imposing a length restriction on your passwords
entered, it's possible that they are storing it in clear text. May be in
backend the password field is VARCHAR with maximum length defined. On
the other hand, if they are hashing the password before storing it, they
need not worry about the length of the password entered by the end user
as the hashed password will be of 'fixed' maximum size, no matter how
long/short the user enters his password. How does that sound?

One nice post here:http://off-the-wall-security.blogspot.com/2011/03/signs-of-broken-authentication-part-1.html

Thanks & Regards,

Nilesh Kumar,
Engineer-Security Analyst
http://nileshkumar83.blogspot.com
http://linkedin.com/in/nileshkumar83
Mobile- +91-9019076487

--- On Sun, 22/5/11, Gautam itsecanalyst@gmail.com wrote:

From: Gautam itsecanalyst@gmail.com
Subject: Re: [WEB SECURITY] Max size of a password
To: "MustLive" mustlive@websecurity.com.ua
Cc: websecurity@webappsec.org
Date: Sunday, 22 May, 2011, 4:03 AM

Thanks everyone for writing, MustLive i have expressed my opinion on mimimum limit and No maximum limit.

However while i wrote this post to this forum I was thinking in backend about how this impacts hashing results and the length.

As we all know storing just pain-text passwords would be the biggest blunder that anyone could do, so I recommend doing at least Salted-SHA versions.

Now my delima is

SHA256(AAA) = some 256 bit hash

now

SHA256(AAABB) = is also 256 bit hash

so with this reasoning will it make sense if i say no limit or just a reasonable limit of 14 character since the result is always going to be 128bit text be it 8 characters or 14 characters.

Let me know your views.

Thanks,
Gautam

On Sat, May 21, 2011 at 1:52 PM, MustLive mustlive@websecurity.com.ua wrote:

Hello Gautam!

My recommendations concerning minimum and maximum password's length are the

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).

in case anyone got it to perform offline attack.

Not only offline, but online attacks are possible. And in case if Brute

Force vulnerability will be in your system and nothing will be made to

prevent such attacks, then only strong passwords will be the last barrier

before attackers.

So take into account my recommended minimum length of password. Because too

short passwords can be not only easily picked up at offline attack, but

also at online attack.

Best wishes & regards,

MustLive

Administrator of Websecurity web site

http://websecurity.com.ua

----- Original Message ----- From: Gautam

To: websecurity@webappsec.org

Cc: MustLive

Sent: Friday, May 20, 2011 6:23 PM

Subject: Max size of a password

Hi,

I was recently reviewing a internal document and noticed that the the

requirement for password mentioned that it should be minimum 7 characters

and maximum 14 characters.

While i was ok with the minimum, I was not ok with maximum 14 since I

believe that we should not put a restriction on the maximum and user can

stretch it as per their comfort. I suggested that you can have it as 256 if

at all you want to make any limits. I know people use automated tools for

pwd generation and management these days and larger (complex) passwords

would always add more work factor in case anyone got it to perform offline

attack.

I want to know from you experts,

- Since whatever goes will be hashed to SHA-256 (Salted) will my

above point make any difference if the original pwd is 7 characters or 14 or

larger.

- I also wanted to know any pointers on documents that industry

refers for password best practices. Working with industry baseline is easy

for me.

Appreciate your help

Thanks,

Gautam.

-----Inline Attachment Follows-----

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

Exactly Gautam, If the website is imposing a length restriction on your passwords entered, it's possible that they are storing it in clear text. May be in backend the password field is VARCHAR with maximum length defined. On the other hand, if they are hashing the password before storing it, they need not worry about the length of the password entered by the end user as the hashed password will be of 'fixed' maximum size, no matter how long/short the user enters his password. How does that sound? One nice post here:http://off-the-wall-security.blogspot.com/2011/03/signs-of-broken-authentication-part-1.html Thanks & Regards, Nilesh Kumar, Engineer-Security Analyst http://nileshkumar83.blogspot.com http://linkedin.com/in/nileshkumar83 Mobile- +91-9019076487 --- On Sun, 22/5/11, Gautam <itsecanalyst@gmail.com> wrote: From: Gautam <itsecanalyst@gmail.com> Subject: Re: [WEB SECURITY] Max size of a password To: "MustLive" <mustlive@websecurity.com.ua> Cc: websecurity@webappsec.org Date: Sunday, 22 May, 2011, 4:03 AM Thanks everyone for writing, MustLive i have expressed my opinion on mimimum limit and No maximum limit. However while i wrote this post to this forum I was thinking in backend about how this impacts hashing results and the length. As we all know storing just pain-text passwords would be the biggest blunder that anyone could do, so I recommend doing at least Salted-SHA versions. Now my delima is SHA256(AAA) = some 256 bit hash now SHA256(AAABB) = is also 256 bit hash so with this reasoning will it make sense if i say no limit or just a reasonable limit of 14 character since the result is always going to be 128bit text be it 8 characters or 14 characters. Let me know your views. Thanks, Gautam On Sat, May 21, 2011 at 1:52 PM, MustLive <mustlive@websecurity.com.ua> wrote: Hello Gautam! 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). in case anyone got it to perform offline attack. Not only offline, but online attacks are possible. And in case if Brute Force vulnerability will be in your system and nothing will be made to prevent such attacks, then only strong passwords will be the last barrier before attackers. So take into account my recommended minimum length of password. Because too short passwords can be not only easily picked up at offline attack, but also at online attack. Best wishes & regards, MustLive Administrator of Websecurity web site http://websecurity.com.ua ----- Original Message ----- From: Gautam To: websecurity@webappsec.org Cc: MustLive Sent: Friday, May 20, 2011 6:23 PM Subject: Max size of a password Hi, I was recently reviewing a internal document and noticed that the the requirement for password mentioned that it should be minimum 7 characters and maximum 14 characters. While i was ok with the minimum, I was not ok with maximum 14 since I believe that we should not put a restriction on the maximum and user can stretch it as per their comfort. I suggested that you can have it as 256 if at all you want to make any limits. I know people use automated tools for pwd generation and management these days and larger (complex) passwords would always add more work factor in case anyone got it to perform offline attack. I want to know from you experts, - Since whatever goes will be hashed to SHA-256 (Salted) will my above point make any difference if the original pwd is 7 characters or 14 or larger. - I also wanted to know any pointers on documents that industry refers for password best practices. Working with industry baseline is easy for me. Appreciate your help Thanks, Gautam. -----Inline Attachment Follows----- _______________________________________________ The Web Security Mailing List WebSecurity RSS Feed http://www.webappsec.org/rss/websecurity.rss Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA WASC on Twitter http://twitter.com/wascupdates websecurity@lists.webappsec.org http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org