Can you spot the bugs? // Chapter #4 - Password Security

[Octarine]

Topic Moved

Edited February 16, 2012 by Octarine

[Spudinski]

Using MySQL to MD5() the password rather than PHP

(Security Note)

This is a curious one; but it does show an interesting problem. The original

code executed:

SELECT * FROM users WHERE username = '...' AND password = MD5('...')

which at first glance should be safe exhibits a nice little problem.

Looking at the [MySQL] process list (SHOW PROCESSLIST), it is possible to see

the plaintext password:

+-------+------+-----------+------+---------+------+-------+---------------------------------------------------------------------------+
| Id    | User | Host      | db   | Command | Time | State | Info                                                                      |
+-------+------+-----------+------+---------+------+-------+---------------------------------------------------------------------------+
| 20358 | demo | localhost | test | Query   |    0 | NULL  | SELECT * FROM users WHERE username = 'demo' AND password = MD5('seagull') |
+-------+------+-----------+------+---------+------+-------+---------------------------------------------------------------------------+

This statement is also going to appear in the server's binary logs and quite

possibly be replicated over a number of machines depending on your hosting

setup. Getting access to those binary logs is not easy; but it is possible.

Viewing the process list is itself not easy, at least from the point of view of

looking at other user's processes; however again, it does happen.

The solution here is to make sure that PHP actually hashes the password first

rather than sending that query in plain text to the database server.

Modifying a PHP extension to sendmail every plaintext string is not easy, but it is possible. 'Nuff said.

On shared hosting you don't even have access to MySQL's binary logs, neither is another users process views. You'd have to get into a superuser status to do either.

 

md5() is considered to be a touch below par these days, certainly for password

hashing; however for a lot of things it is still perfectly functional. When it

comes to passwords; sha1() with a salt is just the job.

Just to correct you here, sha1 is not considered more secure than md5 "these days", sha2xx is considered more secure.

http://ehash.iaik.tugraz.at/wiki/The_Hash_Function_Zoo

[Spudinski]

Taken from said link:

 

sha1() + an 8 character salt on a per-user basis; is impractical to defeat with current technology.

As you state; "Nuff said".

[EDIT]

After a brief consultation with a couple of friendly maths boffins, outside of

the simple fact that a large number of hash algorithms are considered to be

"broken" simply because it is mathematically possible to perform better than a

brute-force; the question remains. Is sha1 safe to use in this context?

Yes.

By the looks of it [mathematical] attacks are known to exist which can find

collisions in as low as 2^53 rather than 2^80 for a brute-force attack, this

along with the salt is still computationally impracticle with current

technology.

There is also the point to be made that security, if taken as individual

components will and often does, show considerable weaknesses; however when used

collaboratively; dramatic reductions are made in the ability for attackers to

gain access.

NSA, RSA, GCHQ, ... whomever, have superiour resources over the general

population however in all honestly I can't see them trying to break in to

mafia-games-are-us.com. As the common man in the street does not have the

computational resources; we again come back to the questions; is sha1 safe in

this context?

Yes.

This puzzle, and the discussion on the answers is *not* a dialog into security

at levels that would make the KGB proud; rather it's an effort to move away

from what I have seen as basic mistakes which are easily corrected and

understood by everybody.

Feel free of course to break my password at MWG; encoded in the form provided

by the functions above:

sha1$fa58a$027330ea3ee3e7cd30f28261fef79897b5b3abba

It's not the point, you can see past the initial post.

You don't need a "couple of friendly maths boffins" to know what you posted, a few cryptographic hashing functions has this same problem. And furthermore it would be highly impractical to attempt a dictionary attack on a hash.

The point I'm getting at is that sha1 can be broken, and shouldn't be considered as suitable for a "webgame" because it does not align with the perfection you portray a simple login script must have.

You want to have a perfect script, thus all aspects of it has to be perfect as well.

Edited January 27, 2012 by Spudinski

[sniko]

Nice Article!

I'm a little confused, mind clearing something up for me?

You've used macrotime(true) in your encryption algorithm, which returns the current unix timestamp in microseconds.

1327681158.0721

You've then only used the last 8 characters

158.0721

Ok, cool. You now store it, I assume, as the encryption method has been run. (Ignoring the rest of it, separated by "$".

So, Let's run the passcode "traintrack123" using your function, a few seconds apart.

sha1$2a1badb5$01571144934a9fb2b55a15659ca592e9352f19eb

...Waits a few seconds, and runs the same thing again....

sha1$a344fe7a$9e4b77bc97ca1258439a271b295cc17e19897118

The bold part is also encrypted using, default, sha1. They are two completely different strings.

Now I've said that. How would you look-up the stored passcode and match it with the one they just entered, as the mircotime(true) would return a different string.

[Neon]

He doesn't re-use the microtime, he stores it as a salt, and re-uses it.

[sniko]

Ah yea, I see that now!

Thanks, the both of you

[SHAD]

eh, what happened to all the articles?