I would not specify max password unless you find you have a need to.

The only two possible reasons I can come up with that might be
legitimate reasons for Max(value) definition are:

• legacy system compatibility
• early studies showed users are more likely to write down passwords
  over a certain length and keep them on monitor/under keyboard

Regarding legacy system compatibility: once people started gluing
together modern OS/2 and Banyan Vines systems, err wait, Windows with
mainframes and web apps and all that, they would write some darn
kludgy code to provide SSO-like features. So it would be possible to
set a max size password on the more modern system (or unified web UI)
larger than the legacy systems would support. If error handling were
suboptimal, you'd wind up a with a truncated password on certain
systems and you wouldn't know what it was truncated too
so.....basically the user just couldn't log it to certain systems or
use parts of the unified app. So you'd set the max at the max of the
most limited legacy system. Ah, the memories of glue code developers.

Finally - using Occam's Razor you could just assume it is an artifact
of the disease known as Policy Wonk Myopia. This is a common
psychological condition that affects those who spend too high of a
percentage of their time writing information security and governance
policies. You can spot these folks pretty easily, they usually wind up
speaking in a monotone like Charles Cresson Wood.

Arian Evans
Perpetuating Pragmatic Practicable Policies

On Fri, May 20, 2011 at 8:23 AM, Gautam itsecanalyst@gmail.com wrote:

Those requirements tend (in my experience) to have survived via
copy-pasta from ancient systems which did store the password in
plaintext, and thus had real length limits based in the database. Each
new iteration of the system has someone who looks at the requirement
and says "hmmm... I guess there's probably a good security reason for
it to be that way, I'm not going to stick my neck out and change it".
At this point, these things should allow long characters, with a
practical length limit dictated by other limitations (maybe your
server doesn't accept POST requests over 4k, or maybe you just don't
want to hash something that large).

-Paul

On Fri, May 20, 2011 at 8:23 AM, Gautam itsecanalyst@gmail.com wrote:

Thank You for the information. I agree to your comments.

On Fri, May 20, 2011 at 11:14 AM, Paul McMillan paul@mcmillan.ws wrote:

--

Regards,

Gautam

G'day,

As implied by a couple of other posts, there were systems with 14
character limit to passwords. Typically early WindowsNT (3 and 4) systems.
With the kernel re-write for V5 (win2k and greater) this limitation was
removed - well, increased to 127 chars, and may possibly be even larger in
the V6 kernel (2k8/vista and greater).

I recall hitting this 'limit' integrating OpenVMS systems and WinNT
systems. VMS allowed long, really long passwords, but we had to restrict
them to 14 characters for interoperability with NT. This did not sit well
with the paranoid among us :)

Ah... memories...

So, the long-and-short is, if you _still_have some of the legacy systems
(either physical, virtual or emulated - e.g. Samba 2 as PDC) then this
restriction will have to stay, but if you're in the 21st Century, this
restriction can be dropped - or rather, bumped up to "127 characters".

hth,

.h

On Fri, 20 May 2011 08:23:21 -0700, Gautam itsecanalyst@gmail.com wrote:

characters

if

for

offline

my

14

industry

easy

This is a web application so I think 128 should be the limit if at all there
is a need.

Thanks for the reply and pointers.

On Fri, May 20, 2011 at 3:58 PM, harry@woodward-clarke.com wrote:

As others have pointed out, setting max size is content dependent as if you have
set a threshold for max-length, then you need to impose that. Also, certain
legacy system might trouble you in this regard.

So it is much context-specific. Along with length, one needs to design "quality"
of password too. That is , what characters are allowed, special characters,
compulsion of alpha-numeric etc. That would come with some stipulated minimum
length, say 7-8 and above criteria to make it "strong". In any case, strong
password expiration policy, lockout enabling and secure policy to deliver
"forget password" request needs to be analyzed also.

Best,
Rohit

From: Gautam itsecanalyst@gmail.com
To: harry@woodward-clarke.com
Cc: websecurity@webappsec.org
Sent: Sat, May 21, 2011 6:46:02 AM
Subject: Re: [WEB SECURITY] Max size of a password

This is a web application so I think 128 should be the limit if at all there is
a need.

Thanks for the reply and pointers.

On Fri, May 20, 2011 at 3:58 PM, harry@woodward-clarke.com wrote:

G'day,

Hello,

On Fri, May 20, 2011 at 08:23:21AM -0700, Gautam wrote:

Believe or not, but few months ago I had some problems with accessing to my
Internet banking (one new Slovak bank). It took me a lot of calls/emails to
their support center and after many weeks they finally found out where is the
problem - I set too long password (about 14-15 characters) and they simply do
not support such long passwords :-)

WTF? Is this possible in Internet banking environment? :)

Pavol

[Pavol Luptak, Nethemba s.r.o.] [http://www.nethemba.com] [tel: +421905400542]

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

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.

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.uawrote:

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

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 05/22/2011 12:33 AM, Gautam wrote:

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

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:

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: