Best way to encrypt password in database. - Page 3

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

Re: Best way to encrypt password in database.

Quoted text here. Click to load it
With the Joomla example that I offered, the salt is stored along with
the hashed password. And yes, the salt in that case is different for
every user (and different again if they change their password).

Basically since the hashing process is one way only, knowing what the
random salt is is of no consequence. The purpose of it is to prevent
the use of a database containing a set of common hashes and adding the
salt to the plain text password before hashing it does this.

Re: Best way to encrypt password in database.

Jerry Stuckle wrote:
Quoted text here. Click to load it

I make it 2^128 = 340282366920938463463374607431768211456 with Ubuntu's
calculator :)

True that's a huge keyspace, but rainbow tables are still an issue. The
problem is that the set of passwords people actually use in real life IS
a very small subset, absolutely tiny in comparison to the whole. Also,
storage is cheap and getting cheaper every day. There may never be
enough space to store every possibility but there are places you can buy
rainbow tables by the terrabyte online today (they literally mail you
hard drives!) and those will crack well over 75% of the typical password
hashes you throw at them.

It's worth bearing in mind that if everyone in the world had access to a
computer (the majority don't even have a phone) and used ten utterly
unique passwords (most only have one or two and MANY aren't unique) that
would give you a keyspace of 60000000000. At 16 bytes per MD5 hash and
say, 32 bytes per password that would use 2880,000,000,000 bytes of
space i.e. Just under 3Gb.

It's a sobering though that, even with extremely pessimistic
assumptions, you could fit the entire world's passwords & MD5 hashes on
a couple of large hard drives!

Admittedly rainbow tables are a problem for any unsalted hash so you
need to use a salt whichever one you choose. The speed and age of MD5
makes it particularly susceptible though: people have been able to
precompute many more variations for it than for other (more CPU
intensive) hashes and normal brute forcing and dictionary techniques can
be executed against it significantly faster too. So although I can see
how extremely fast hashing can be a security liability I can't think of
any security contexts where it would really be a boon.


Re: Best way to encrypt password in database.

r0g wrote:
Quoted text here. Click to load it

So true.

In the end its all just risk analysis: leave a port open that responds
instantly to name/password  attempts, and it will be cracked. delay the
response a half second, it it will be cracked, but takes longer.
Implement 6 strikes and your account is locked, and you will be alerted
to a failed hack attempt by users complaining they can't log in..

Hopefully the perps will then move on to a juicier target.

Like stealing the laptop from the minsters car containing all the bank
details of all the government departments employees, in unencrypted
form...said laptop having been provided because of a strict firewall
policy that wont let people access data at home., so they just copy it

Quoted text here. Click to load it

Site Timeline