Jump to content

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


Recommended Posts

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.


Link to comment
Share on other sites

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".


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?


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


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?


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:


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 by Spudinski
Link to comment
Share on other sites

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.


You've then only used the last 8 characters


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.


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


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.

Link to comment
Share on other sites

  • 1 month later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...