Pardon me for jumping in here, but I thought I'd try my hand at
putting this into some concrete examples.
Let's say we have an overly simple site with just three users (Jane,
Dick and Sally) and for some odd reason have made it a policy that
they can only choose from three passwords: "password", "secret" and
"hello". We'll say that our users have chosen the following passwords:
ID: username: password
1: Jane: hello
2: Dick: password
3: Sally: secret
Now we choose two different hashing methods.
Method #1 we take the password and "salt" it by adding the reverse of
the password so
password_hash = hash(password+password[::-1])
and end up with hashes of:
Jane: 12DK789P
Dick: 486KX0AO
Sally: TY98B7C
A hacker somehow manages to steal our user table and gets our app
source so they know our salting and hashing methods. He simply runs
for password in ["password", "secret", "hello"]:
password_hash = hash(password+password[::-1])
and in three iteration has the password of all three users. In fact
even if we have 1,000 users Evil Hacker still got all 1,000 user's
passwords in only 3 iterations.
Method #2 we take the password and salt it by adding in the user's id,
so:
password_hash = hash(password + user.id)
Now Mr Evil Hacker again manages to gain access to our database and
app source. Again he tries to figure out our user's passwords. He
starts out with Jane
for password in ["password", "secret", "hello"]:
password_hash = hash(password+user.id) #user.id in this case
is "1"
Just as before after at most three iterations the password has been
figured out. BUT unlike with method #1 Evil Hacker only has Jane's
password and not Dick or Sally's. To get both Dick and Sally's
password it will take up to 6 more iterations for a total of 9 (3
times more than required if we use method #1). For each additional
user it takes another 3 passes (assuming the correct password is
always the last one we try). So our 1,000 user database now took
3,000 tries vs 3 - that's a huge improvement overall.
The thing is for any single user, it only takes 3 tries with either
method. BUT to get everyone's password it takes n*3 tries. Up the
complexity and say that our users can pick from any current English
words in the Oxford English dictionary, Method #1 only takes at most
171,476 tries while #2 takes n*171476 tries. Then let your users pick
from upper & lower case letters, numbers 0-9 and common symbols giving
96 possibilities total and require 8 characters and there are now 7.2
Quadrillion possibilities! Sure the hacker can bother to generate (or
obtain) a rainbow table for all the possibilities - if we used Method
#1 they now have the password for every single user. Switch over to
Method #2 and even with those 7.2 Quadrillion hashes in their rainbow
table Mr. Hacker only got one of our say 1,000 user's passwords - they
need to generate 1,000 more rainbow tables to get everyone's!. We'll
assume that our chosen hashing method means that there aren't any
readily available rainbow tables so our hacker needs to generate his
own rainbow tables. Check out http://www.lockdown.co.uk/?pg=combi&s=articles
to see just how long that'll take him (at best if he's got a
supercomputer It'll take 83.5 days *per user* - reality probably a few
years). Unless you've got something really, really valuable the random
hacker just isn't going to bother.
So there is deterministic vs random salting (we'll claim user ID is
basically random - it doesn't matter since it's clearly stored in the
database anyway).
Now since either way the hacker needed to somehow compromise our
database does all this really matter all that much? Which, for most
sites, is going to be more interesting - the user's passwords or all
of the other data probably stored in the clear in the other database
tables? If it's e-commerce or something then maybe the passwords are
useful, for most other things who cares, I can just read all the
user's "private" password protected data without having to worry about
figuring out their password beforehand.
Hope that clears things up a little.
~Brian
On Jul 31, 3:12 pm, Jonathan Lundell <jlund...@pobox.com> wrote:
> On Jul 31, 2009, at 12:56 PM, Julio wrote:
>
>
>
> >> If we have a deterministic (1:1) transform t() of the password, then
> >> hash(t(password)) is exactly some hash'(password). We've redefined
> >> the
> >> hash function, and all we have to do is to create a new rainbow table
> >> for that function. That is, you can consider any 1:1 pre-hash
> >> transform of the password to be part of the hash function itself.
> >> Sure, if hash() was md5(), then hash'() will be something else, and
> >> you won't be able to take advantage of public rainbow tables. But you
> >> can create your own rainbow table for hash'.
>
> > I think here is where the source of confusion is, for the record I am
> > not talking a brute force known hash attack (which incidentally the
> > "random" salt used in your approach become "known" anyway).
>
> > If I read you correctly, you are saying that all you need to do is
> > generate a custom rainbow table with hash(t(password)) and you'll be
> > set, what I am saying is that you will have to generate that custom
> > rainbow table for *each* record you'd like to crack,
>
> No, that's not the case. You need only one rainbow table for the new
> hash' function and you're done.
>
> hash(t(p)) is simply hash'(p), and all you need is the rainbow table
> for hash' instead of hash.
>
> But this only works when t(p) is a 1:1 transform, and that's not the
> case for random salt, even if the salt is non-secret.
>
> > now my point is
> > that your approach is exactly the same as the one I said earlier, by
> > adding a pseudo-random number as the salt, and that salt is 100%
> > discoverable (deterministic) you are just playing the same game but
> > with a different ball.
>
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
