[WEB SECURITY] Max size of a password

Gautam gautam.edu at gmail.com
Mon May 23 12:51:23 EDT 2011


Thanks Nilesh, that link helped,

@Erlend, I am going to suggest 256 as max length, since i don't think anyone
would even go close to it and then everything is going be salted-hashed
anyways. One reason i would want to set some MAX length is the client team
wants to check the input again some max value instead of accepting a large
buffer (not fully convinced on this, but have to live with it).

Let me know if it makes sense.

Thanks,
Gautam

On Mon, May 23, 2011 at 6:56 AM, Erlend Oftedal <erlend at oftedal.no> wrote:

> I'm wondering if you might want a max size, but just not 14 characters.
> Maybe 256 or 1024.
> Reason: you don't want to hash a 2 GB password 1000 times => DOS.
>
> Erlend
>
> Gautam <itsecanalyst at gmail.com> 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 at 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 at 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 at 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 at lists.webappsec.org
> >> >
> >>
> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.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 at lists.webappsec.org
> >
> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.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 at lists.webappsec.org
> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
>



-- 

Regards,

Gautam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20110523/ecd8267a/attachment-0003.html>


More information about the websecurity mailing list