Re: SQL Storing Passwords?

[Davin Enigl <davinenigl () comcast net>]

Alexander is correct in many ways, but there are a few things you must
remember (if you are a naturally paranoid computer security officer).

#1. Two salts are better than one. A salt stored on the same server as
the password is less secure, than two salts: one salt on the password
server and one (master salt) on a different corporate server (say, a
hardware security module).
        
        The corporate salt is added to the password's normal salt and the
password is hashed. A double salted hash is now becoming quite common in
high security corporations due to all the breaches. It buys more time to
change passwords, the reason is attack in my #3, below.

#2. Here we also have a problem of which hash to use. All MD-5 hashes
(128-bit) have preimaged (and are in a rainbow tables). The next hacker
attack was/is continuing on salts. I estimated the large criminal
organizations and governments have preimaged all salts up to 64-bits (8
bytes), for MD-5. They would need to go up to 128-bits to be really
effective. I do not think they will go further that 64-bits because it's
too costly in time, memory, search-time. The new SHA-3 is soon to be
standardized -- that should put the attack surface on to SHA-1 and
SHA-2, away from MD-5 (because it should be "end-of-life"-ed).

There are three solutions:

        A. Salt with a higher bit length. I recommend 128-bits minimum. You
said 40 characters for the key. I usually estimate the entropy at 4-bits
per symbol, so 40 x 4 = 160-bits. This means the developer may have used
an SHA-1 hash to match the SHA-1 160-bit length. If so, good for you.
That should be enough.

        B. Hash with a longer length hash. Since SHA-1 is the next target, I
recommend SHA-256 with a minimum 128-bit salt. This will eventually
change to SHA-3 plus 128-bit salt. I do not think adding a longer salt
that 128-bits will be needed. 128-bits hides inside 256-bit hashes well
enough (see #3 exception below).

        C. Requiring the hashes go through PBKDF2 iterations set to 10,000 or
so, helps a lot.

#3. Attack on hashed and salted low entropy passwords:  Here is another
problem not usually talked about. Usually a weak (low entropy) password
can be strengthened by hashing with a salt. That is good and is normally
done.

You must assume common passwords even if high entropy, are still weak:
Crack this EXAMPLE: qw-0p-a5-k1-zx-nM

That was easy to crack, yet it's technically high entropy. It's jus the
corners of the keyboard with some leet and dashes. English (any
language, even Sanskrit) words are only 1.5 entropy, very low, weak,
plus there are straight dictionary attacks, leet, dashes, spaces, etc.

        The problem is there are password lists (100 million most used
passwords) that are the first to be rainbow-tabled. And now, they can be
extended to their salts with GPU arrays, in rainbow tables with salts up
to, say 64 bits. And here is an exception, the lists can go beyond 64,
to 128, to 160, to 256 if you have the time and energy (and can guess a
little. Poor PRNG were just discovered for SSL/TLS primes.)

        It's a chosen-plaintext preimage attack with "chosen" salt bit length.
Therefore that computational infeasibility comes down from MD-5's 2^128,
to 2^128/2. Then adding the Merkle-Damgard weaknesses a poor PRNG and it
comes down to maybe 2^48 -- which is cracked by GPU-array eventually. I
saw one cracked in 3 days and another in 3 weeks. Feel lucky?

So, bottom line: hash, salt, double salt, find the breach quickly and
change the passwords. Use *high* entropy passwords TO START WITH. EVEN
BETTER: use a pre-authentication password with a static Yubikey for
two-factor authentication or a one-time-code Yubikey. Or something
similar to a Yubikey, that is time-based.

Passwords are on LIFE-SUPPORT and dying fast. No amount of chemotherapy
will save them.

--Davin Enigl



On 09/04/2012 04:38 AM, Alexander Meesters wrote:> Well, now if somebody
want to crack them using rainbow tables, then
> need to regenerate the rainbow table every time the user changes. This
> will really slow down the whole process of cracking and might even
> make the unsub give up the project as a whole. At least it will buy
> you some time to get users to change the passwords once you detected
> your breach.

------------------------------------------------------------------------
Securing Apache Web Server with thawte Digital Certificate
In this guide we examine the importance of Apache-SSL and who needs an SSL certificate.  We look at how SSL works, how 
it benefits your company and how your customers can tell if a site is secure. You will find out how to test, purchase, 
install and use a thawte Digital Certificate on your Apache web server. Throughout, best practices for set-up are 
highlighted to help you ensure efficient ongoing management of your encryption keys and digital certificates.

http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727d1
------------------------------------------------------------------------