On Jul 31, 6:26 am, Bottiger <bottig...@gmail.com> wrote:
> > That may not be a good idea, I think. That makes your password longer but
> > with a possible cryptographic weakness because it's following a known
> > generation rule (being formed by a string repeated 3 times).
>
> The primary concern is a precomputed rainbow hash table.
>
I know, but a brute force attack becomes more achievable using a rule
like that because you are introducing a lot of restrictions to the
possible passwords domain.
I give you an example, if you have a 32 bytes field for the password
and you generate passwords according to that rule, the attacker will
know in advance that he doesn't need to try passwords with a length
higher than 32 / 3 bytes, he also doesn't need to try passwords that
are smaller than the minimum allowed size by the application * 3 and
he can reject in advance all passwords that aren't formed by a
triplication of a substring.
I would say that for serious applications just use other algorithm
such as SHA-1.
> Anything related to password generation strength depends on the
> person's original password and even a random salt does not help,
> because if the database is compromised, then the attack knows which
> salt to generate hashes for. Therefore there really isn't anything
> wrong with just doubling or tripling the password as a salt.
>
> In fact, many websites such as Reddit (which I examined the source
> code) does this.
>
> On Jul 30, 9:51 pm, Francisco Gama <francisco....@gmail.com> wrote:
>
>
>
> > On Jul 31, 5:16 am, Bottiger <bottig...@gmail.com> wrote:
>
> > > As long as the salt is different for every password, it pretty much
> > > makes it infeasible for someone to create a large enough rainbow hash
> > > table attack.
>
> > > The Unix salt of 12 random bytes is ok, but comes at the cost of extra
> > > storage and pretty much the same benefit. To put a larger barrier on
> > > computational speed, you could double or triple the original password
> > > before putting it through the hash.
>
> > That may not be a good idea, I think. That makes your password longer
> > but with a possible cryptographic weakness because it's following a
> > known generation rule (being formed by a string repeated 3 times).
> > That makes the diversity of possible passwords much smaller which
> > isn't a good password policy.
>
> > Besides, the complexity is the same (which is close to say that the
> > computational speed is also close) and an attacker would need the same
> > number of attempts to break the password by brute force because all he
> > had to for each attempt X, the attempt XXX. He doesn't need to try X
> > or XX.
>
> > > On Jul 30, 8:38 pm, Jonathan Lundell <jlund...@pobox.com> wrote:
>
> > > > On Jul 30, 2009, at 8:30 PM, Bottiger wrote:
>
> > > > > I know you have the mantra of not breaking backwards compatibility,
> > > > > but it is a pretty bad idea to have unsalted MD5 passwords.
>
> > > > > For example, let's say your password is "massimo". The MD5 hash of
> > > > > that happens to be "8cac5ac44b51f182143a43c4cdb6c4ac".
>
> > > > > Even forgetting rainbow tables, you can simply do a search for it on
> > > > > Google and you have 10+ pages telling you that it is the hash for
> > > > > "massimo".
>
> > > > How about a new validator that does the right thing, and deprecating
> > > > CRYPT?
>
> > > > I'd prefer some less-predictable salt than the suggestion below,
> > > > though. How about the old Unix passwd trick of choosing a some random
> > > > salt, and appending the salt in plaintext to the hash?
>
> > > > >http://www.google.com/search?q=8cac5ac44b51f182143a43c4cdb6c4ac
>
> > > > > On Jul 30, 8:10 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
> > > > >> We cannot break backward compatibility. People should specify a key
> > > > >> and use the HMAC+SHA512 anyway.
>
> > > > >> Massimo
>
> > > > >> On Jul 30, 9:49 pm, Bottiger <bottig...@gmail.com> wrote:
>
> > > > >>> The CRYPT validator is unsecure because it uses unsalted MD5.
>
> > > > >>> There are public rainbow tables that have unsalted MD5 passwords
> > > > >>> of up
> > > > >>> to 10 characters long including symbols.
>
> > > > >>> I highly recommend that if no "key" is specified, that CRYPT will
> > > > >>> automatically salt the password based on a substring of the password
> > > > >>> itself. For example:
>
> > > > >>> password = "secretpass"
> > > > >>> hash = md5(password+password[-1])
>
> > > > >>> This will of course break backward compatibility, but this is a real
> > > > >>> security vulnerability.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
