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

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
-~----------~----~----~----~------~----~------~--~---

Reply via email to