PHP md5: relative speed?

jasonla

Relatively, how fast is the md5() function in PHP? Will it bog down the server with 4 calls to md5() in one script?

I'm working on an authentication script that uses MD5 on the the client side (Javascript) to create a hash of a password that a user enters. I know it's not as secure as SSL, but it's better than sending passwords as clear text.

On the server side, the script receives the MD5 hash from the client. It creates a random value, probably using some for of micotime(), and MD5's that value. Then, the hash of the random value will be concatenated with the hash from client. The concatenated value will then be MD5'ed again.

Then, a call to the DB will get the user password. The password from the DB will be MD5'ed, then concatenated with the hash of the random value, then MD5'ed.

If the two resulting concatenated hashes match, the user is authenticated.

Also, if anyone sees any problems with my methodology, please inform me as well.

Any help is appreciated.

ednark

1) ok so you want to md5 the password before sending it... ok thats a little bit of security... but not really... what are you using to md5 it with... if your are md5ing it straight that is as good as no security... as the same md5 will be passed to your server for every password (by the same user)... were i to mimc the users login... i don't need to use the real password.. i just need to fake a post with the md5ed value i saw.. which is sent plain text across the internet

2) if you store the password plain text in your database then thats as good as no security... a hacker isn't going to screwing aroudn with your php stack to try and pull out information as its running... if they are on your computer they will just use read your databse... and all your passwords will be theirs... so either encrypt before storing or don't bother with it

md5 is pretty fast... fast enough that 4 calls won't blow your php... unless you are running apache off cygwin in windows that you installed in wine under redhat 8 that you just hacked onto your dreamcast... 🙂

you might just do think about somehting more along these lines...

1) encrypt your users password before storing in the database... md5 username and password together would work...

2) when the login form loads... start a session... store a random number there in the session and write the same id into your javascript... so now the server and the client both have the same random number that is unique to all other login pages loaded

3) before you send the password have javascript md5 the passord with the username...

4) now theoretically the password about to be sent matches the md5ed password stored in the database, so we want to do one more md5 on it. have javascript md5 it with the random number and submit the page..

5) on the server... grab the random id from the session... grab the md5ed password form the database that belongs to the user... we should be in the same boat as step 3) on the client side

6) now md5 the db password with the random id... now we should be where step 4) was on the client side

7) if it matches the one sent by the client... you win...

and this produces a unique check every login... so that a sniffer watching page requests won't see the same password being sent across to your server...

even if they see all transaction... the session_id being sent... the random number being sent... and the username and md5ed password being sent... they still won't be able to fake a login request themselves as there will be no matching session to work with...

however if they are sniffing all your traffic and have access to your server to read/write the session files so they can create a fake session file to match a fake session_id... if they have that much power already your are far beyond fucked and they are probably in a far more serious game than trying to steal your users passwords...

did i understand your script correctly... maybe i misinterpretted what you were doing and you are actually doing somehting more better like than i thought... if so please do not hesitate to defend yourself.. 🙂

Weedpacket

My question is: "relative to what?"

On the server side, the script receives the MD5 hash from the client. It
creates a random value, probably using some for of micotime(), and MD5's
that value. Then, the hash of the random value will be concatenated with
the hash from client. The concatenated value will then be MD5'ed again.

Then, a call to the DB will get the user password. The password from the
DB will be MD5'ed, then concatenated with the hash of the random value,
then MD5'ed.

If the two resulting concatenated hashes match, the user is
authenticated.

The client takes clientpassword from the user and creates md5(clientpassword)
The server takes md5(clientpassword) from the client and generates md5(random)
The server generates md5(md5(clientpassword).md5(random))
The server then takes databasepassword from the database and generates md5(databasepassword)
The server generates md5(md5(databasepassword).md5(random))
The server checks to see if md5(md5(databasepassword).md5(random)) == md5(md5(clientpassword).md5(random))

Am I getting that right?

Why hash two strings that you already have "in clear" (i.e., one MD5 string from the client, concatenated with the time; and one from the database, concatenated with the time) just to see if the resulting hashes are equal? And why append the same string to both strings just to see if the resulting concatenations are equal? In short, why not just compare md5(clientpassword) with md5(databasepassword)? Store md5(databasepassword) in the database instead of just databasepassword, and the server doesn't need to do any md5() at all (except on the off-chance that the client doesn't do Javascript for some reason).

PyroX

Basically Folks,

1, Base64 the password via client before sending
2, decode the base64 and md5() it,
3, copmpare it t the DB

None of the methods discussed are viable solutions.

The only way to be really secure with web traffic is to use SSL, anything else, including anything discussed here, can be sniffed and figured out ( providing the 'hacker' is not a script kiddie )

You could forget the md5 and use PGP with a private key, but thats not any better than anything else.

The simple fact is, someone could be looking at your traffic, if they are, they can see all the data being sent, requardless of how it is encrypted. SSL is the only way to stop that from happening.

ednark

Weedpacket:

why not just compare md5(clientpassword) with md5(databasepassword)?

you are correcty in that the outer md5 isn't needed really... it is unique before that... but i was just trying to find a way every time you log in for a different 'password' to be sent from the client to the server.... if you don't do an extra md5 with something random the same bit of info will be sent every time you log in...

Pyrox:
I'm not trying to flame, but why aren't our solutions above viable.... please explain more.... im interested

PyroX

No matter what, the traffic is sent client->server

So if you don't encrypt with SSL, any method can be viewed.

The only plus in these discussions, would be the random identifier with the password, but this information has to be sent as well.

If you md5(random.password) before you send to server, the sniffer can just send the md5 string.

If you set a random id in the session or a cookie, the random id can be found as well in the traffic.

If you just send the password plaintext, it can be sniffed,

If you base64 the password, and then send, it can be sniffed and decoded.

It is also important to note that md5 is not infoulable. just 2 minutes on a system to grab the database dump and you could spend the next week grinding the passwords. Its not difficult at all. Time consuming, yes, but not difficult.

The only truely secure method is to have a very tight server, and SSL whenever you don't want people to be able to hack the users.

ednark

actually if you are there sniffing all the traffic you will be around for the initial ssl handshake and key exchange
you will have intercepted both public keys .... so at that point the ssl doesn't matter as you can just intercept and decode all the information yoself... then pass it on...

heheh i guess there really is no such thing as security

even pgp stands for pretty good privacy

PyroX

Very true, and there are things like ssldump that help do that.

But that does not mean DO NOT DO these things, as they help keep the script kiddies out.

Krush019

http://pajhome.org.uk/crypt/md5/index.html

If it's good enough for yahoo.......
Now if i can just figuer out what to do on the server side 🙂

PyroX

Just because yahoo uses it huh,,,

Good luck. By the way, what is yor website url where you will be using this?

Krush019

It was a joke, we don't use it. We use ssl for all e-commerce and something my business partner wrote for standard free services. Truth is if someone can position themselves to sniff the traffic most likely they know how run a replay attack. But what do i know. Heck if i did security for our sites infants would be hacking us with there fischer price "my first computer". 😃