On Jul 31, 10:13 am, Jonathan Lundell <jlund...@pobox.com> wrote:
>
> We should be clear about which problem(s) we're trying to solve.
>
Hey Jon,
I think this is the easiest part, we are trying to secure our
passwords (without using encryption) so in the event they are stolen
they would be *very hard* to crack, simple (at least to say anyway).
I repeat myself, any approach to salting, deterministic as you refer
to or pseudo-random yields the exact same results, they will be hard
[er] to crack, but crackable none the less, consider this:
>>> md5.md5('hello').hexdigest()
'5d41402abc4b2a76b9719d911017c592'
Then google the results (more than 20,000 hits right?)
Now let's harden it:
>>> md5.md5('%shello' % (md5.md5('hello').hexdigest())).hexdigest()
'f62b484dd6745a5065fe4fa7b0004100'
0 results
Now, let's do this:
>>> md5.md5('764928348712hello').hexdigest()
'8cbf1c0ce99bad31172e9e9584d11454'
0 google results
Now, you may say, the "random" number pre-pended to the password is
more "secure" than using a unique (per record) salt, when in fact they
are both crackable to the exact same degree, since the "salt" used is
stored somewhere anyway.
Now salting, as long as the salt is unique (not random) per record all
it does it that it makes too much harder to crack using rainbow
tables, since for each record in your stolen table you will need to
generate the entire rainbow table with each individual salt, a very
time consuming task, that's it.
>
> Here's another test you can apply to salting systems. If two users
> choose the same (plaintext) password, what are the chances that
> they'll end up with the same hash? With simple md5, with or without a
> deterministic transformation of the plaintext, the hashes will always
> be the same. With random salt, even if the salt is not secret, the
> chance of a collision can be made arbitrarily small.
So what's the problem? we are hashing, not encrypting, meaning that it
is possible that my password is v...@1dr897 and some other user having
the password as 77d772s!@ we both end up with the same hashed data
effectively causing a collision.. For the hacker, he'll just see two
hashes with the same value.. does this mean that they are both the
same password?..
I mean for the most part I agree with you, the issue I am trying to
prove is that salting, as long as it is unique does not matter if it
comes from a pseudo random salt value or a unique value assigned to
each record (assuming that the random value used for the salting
process is also stolen)..
Julio
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
