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 brute force attacks are also a threat.
if I was an attacker and I find that the password field size is 32
bytes (e.g.) and the password generation always follows that rule you
described I can make a brute force attack that excludes a lot of
possible password in that 32 bytes domain such as passwords that
aren't formed by the rule you described, passwords that are smaller
than the minimum allowed password size * 3 and any password that has a
length larger than 32 bytes / 3 and I probably could go on more
password domain restrictions.
Am I wrong?
>
> 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
-~----------~----~----~----~------~----~------~--~---
