Printable View
I am running this test on my own forum......
I created a user for my forum and then I grabbed the md5 password from the database.
Now when I try to login to the forum using the username and md5 password, I get an "invalid password error".
Is it possible to login using the md5 password?
How dangerious is it if someone snatched my md5 password.
....thanks
Hi
Usually, the password, which you send (mostly in plaintext..) from your
client, will be md5'd on server side. The md5-hash of the password
then is compared with the entry in the database.
If you send the md5-hashed version of your password, it will again
be md5'd, which results in a different md5-hash, hence the "invalid
password error".
The password is not stored as plain-text in the database for obvious
reason. Usually, you cannot do much if you somehow snatch the md5-
hash of a "good" password. Note, however, that md5-hashes of
short or simple passwords, like "12345" or "password" are known
by standard tools.
Cheers
some sites, like yahoo also md5 passwords using javascript in the browser. In that case, a grabbed md5 password might be useful if u disable javascript or bypass the hashing but in yahoo's case, other checks are performed to prevent this.
Hmmm. If you know the MD5-encrypted value then you can attempt to calculate a matching password. This doesn't have to be the same password as the user used though, but when your forum checks this password by encoding it, it will generate the same MD5 value as the real password and thus seem to be valid.
Well, knowing this you would think that cracking a password by the MD5 value is easy. And it is easy. All it takes is a lot of time trying to find a proper value that would generate the MD5 value. With today's computers, you might be lucky if you succeed at this in this lifetime, using a single computer...
But people are trying to find algorithms that will reduce the amount of time required.
You could always try Clusterknoppix
Hi
I am confused. Let us forget for a moment more sophisticated authentication methods,
and consider these plain simple logins :)
Local MD5.
Where is the difference between
- sending a plaintext password, that is compared server-side with a database entry,
which stores the password in plaintext,
and
- sending an md5-hash (generated locally) of my plaintext password, that is
compared server-side with a database entry, which stores the "md5"?
Anything, that is performed local, does not really count as a security "layer", since
one can sniff anything that is leaving the local machine (remember: nothing sophisticated).
Clusterknoppix.
Clusterknoppix, Djohn[1], ... may be useful to crack LM-hashes and thelike, but
MD5? Was anyone successfull to identify a decent password (or one of its collisions)
given a MD5 hash? Then, we could always add salt to it.
Collisions.
Can you actually generate a collision from a given MD5 hash?
First, one has found collisions, ie. messages with the same hash. However,
the messages were not given and were random. Then, one has found some
"kind of pre-image" attack: given 2 files with the same hash, what can I "swap"
or "add" - these are blocks: 512bit, in special circumstances 128bit[2]. Two
postscripts[3] have been found, and some colliding X.509 certificates. I lost track
of further development.
I don't say "use MD5" it is safe. Use SHA-1 and/or MD5 with salt etc.
But for one out of thousands of forums out there, such a MD5 password hash
is of no interest for the groups able to do something out of it...
I conjecture that the likelyhood that someone will successfully run an exploit to
your server is larger, than he will recover the password from the MD5 hash :)
hseatch, what kind of forum software are you running, and to which extend
does it allow you to use salt/SHA-1 etc.?
Cheers
[1] http://www.securiteam.com/tools/6R00E2K8UA.html
[2] Kind of Summary: http://www.doxpara.com/ (bottom)
http://www.doxpara.com/md5_someday.pdf (and many other papers)
[3] http://www.cits.rub.de/MD5Collisions/
Hey Hey,
I agree with everything you said sec_ware (and usually do) except for this not counting as an added layer of security.Quote:
Originally posted here by sec_ware
Local MD5.
Where is the difference between
- sending a plaintext password, that is compared server-side with a database entry,
which stores the password in plaintext,
and
- sending an md5-hash (generated locally) of my plaintext password, that is
compared server-side with a database entry, which stores the "md5"?
Anything, that is performed local, does not really count as a security "layer", since
one can sniff anything that is leaving the local machine (remember: nothing sophisticated).
Think, for a second, about the average home users security concerns. 'Someone has a key logger on my computer', 'What if the website get's hacked, will they find my password?'.
I realize that people prefer client side MD5 hashing, but in my mind it's no better.
Sniffers are used, there's no doubt about that, but when was the last time you heard about someone sniffing the backbone that your ISP uses? It's more likely that the sniffing will occur inside a corporate network.
So let's look at some common scenerios..
Key Logger: No matter what happens, you're screwed. Client or Server side hasing.. it doesn't matter.
What if the website is hacked: Client or Server side hashing means they'll only get the hash if they access the database.. Your actual password is still safe.
So as far as the home user is concerned it doesn't matter where (but as you can see having the MD5 adds a layer of security if the database is compromised)
Now.. sniffing the password (hopefully anything transmitting a password is over SSL.. but like you said basics only, however if it was SSL, then again it wouldn't matter which side the hashing took place)
That leaves us with our last option. sniffing without SSL. If you use Client Side hashing, and it's sniffed, all the malicious user has to do is bypass the client side hashing process and they've accessed the site. If you use server side hashing, the malicious user has the password and can log in. Either way... they gain access.
Either way is flawed (without the use of SSL or similar) but they do provide a layer of security. That layer of security though is server side, not client side.
That's my take on it anyways.
Peace,
HT
There's two way (that I can see!) you could use md5 hasing on the client side:
Simply hashing the passwords client side (with or without salt, which would have to be sent along anyways) is mear obfuscation of the cleartext password; can be replayed easily.
Or:
Use a challenge/response style authentication mechanism:
The server could send a piece of "challenge"-text (a good number of random chars), to which the client would prepend/append his password and hash the resulting string. Hash is sent to the server, which does the same process( to validate the secret...
This way you prevent replay attacks (to the extent that the challenge-text is random enough and unlikely enough to show up twice... Including a timestamp in that challenge-text might help further...)
*Now said like that, it would imply that the server as stores the password in cleartext. If the password was stored as an hash on the server, you'd have to pre-hash the password client-side, append/prepend with challenge-text, re-hash resulting string, then send to server for validation... You could do variations on that to add a salt or whatever also...
Ammo
Ok, I think I could summarize everything here.
- Mainly, snatching a md5 password won't be helpful to anyone since it's not easily converted (decrypted) to plain text.
My question was just out of curiosity, I just wanted to know if it's possible to login using a username and a md5 password.
Thanks all, especially sec_ware
Hey Hey,Quote:
Originally posted here by hseatch
Ok, I think I could summarize everything here.
- Mainly, snatching a md5 password won't be helpful to anyone since it's not easily converted (decrypted) to plain text.
My question was just out of curiosity, I just wanted to know if it's possible to login using a username and a md5 password.
Thanks all, especially sec_ware
Getting the MD5 could be helpful and that all depends in part on your question is it possible to login using the username and the md5 hash of the pasword. That would depend on how exactly the login system works. If you have the Achillies Proxy and stop the data before it leaves your PC (after it's been hashed by the client side hashing (if there is client side hashing) then yes.. you could use the MD5 Hash to login... If it is hashed on the server side, then it's useless to you because the server will hash your hash and get a completely different hash.
Peace,
HT
Ok, I put together a description of the possible uses of hashing on passwords and login authentication processes and what the help with or not...
Code:
pwd = cleartext password
pwd-hash = md5'ed password resulting hash
hash-hash = pwd-hash re-hash
hash2-hash = pwd-hash, re-hash, re-hash
chlg = "Challenge-text": sufficient length of random characters
resp-hash = challenge + pwd hash
--submit--> = password submition
--md5--> = hashing process
<--compare-- = compare from stored password
<--sends-- = server sent data
+ = "Append with"
Scenario 1: pwd sent in clear, stored as cleartext, databse is compromised
client | server | database
pwd --submit--> pwd <--compare-- pwd
hacker | server | database
pwd --sumbit--> pwd <--compare-- pwd
Result: login successful
Scenario 2: pwd sent in clear, stored as hash, databse is compromised
client | server | database
pwd --submit--> pwd --md5--> pwd-hash <--compare-- pwd-hash
hacker | server | database
pwd-hash --sumbit--> pwd-hash --md5--> hash-hash <--compare-- pwd-hash
Result: comparaison doesn't match, login denied
Scenario 3: pwd sent in clear, stored as cleartext or hash, transmission intercepted
client | server | database
pwd --submit--> pwd --md5--> pwd-hash <--compare-- pwd-hash
pwd --submit--> pwd <--compare-- pwd
hacker | server | database
pwd --submit--> pwd --md5--> pwd-hash <--compare-- pwd-hash
pwd --submit--> pwd <--compare-- pwd
Result: in both cases comparaison matches, login successful
Scenario 4: pwd sent as hash, which is stored as-is (cleartext), transmission intercepted OR database compromised
client | server | database
pwd --md5--> pwd-hash --submit--> pwd-hash <--compare-- pwd-hash
hacker | server | database
pwd-hash --submit--> pwd-hash <--compare-- pwd-hash
Result: comparaison matches, login successful
Scenario 5: pwd sent as hash, which is re-hashed before being stored, database compromised
client | server | database
pwd --md5--> pwd-hash --submit--> pwd-hash --md5--> hash-hash <--compare-- hash-hash
hacker | server | database
hash-hash --submit--> hash-hash --md5--> hash2-hash <--compare-- hash-hash
Result: comparaison doesn't matche, no login
Scenario 6: pwd sent as hash, which is re-hashed before being stored, transmission intercepted
client | server | database
pwd --md5--> pwd-hash --submit--> pwd-hash --md5--> hash-hash <--compare-- hash-hash
hacker | server | database
pwd-hash --submit--> pwd-hash --md5--> hash-hash <--compare-- hash-hash
Result: comparaison matches, login successful
Scenario 7: challenge/repsonse style authentication, password stored as hash, transmission intercepted
client | server | database
chlg1 <--sends-- chlg1 pwd-hash
pwd --md5--> pwd-hash+chlg1 --md5--> resp-hash --submit--> resp-hash <--compare--> resp-hash <--md5-- pwd-hash+chlg1 <---- pwd-hash
client | server | database
chlg2 <--sends-- chlg2 pwd-hash
resp-hash ???? --submit--> ????????? <--compare--> resp-hash <--md5-- pwd-hash+chlg2 <---- pwd-hash
Result: nothing much to do with the response hash! login failes
Scenario 8: challenge/repsonse style authentication, password stored as hash, database compromised (aka: "Passing the hash")
client | server | database
chlg1 <--sends-- chlg1 pwd-hash
pwd --md5--> pwd-hash+chlg1 --md5--> resp-hash --submit--> resp-hash <--compare--> resp-hash <--md5-- pwd-hash+chlg1 <---- pwd-hash
hacker | server | database
chlg2 <--sends-- chlg2 pwd-hash
pwd-hash +chlg2 --md5--> resp-hash --submit--> resp-hash <--compare--> resp-hash <--md5-- pwd-hash+chlg2 <---- pwd-hash
Result: comparaison matches, login successful
Moral of the story:
Protection || Login info vulnerable* in
Client-side | Server-side || Transmision | Database
-------------------------------------------------------
Cleartext | Cleartext || y | y
Cleartext | MD5 hash || y | n
MD5 hash | Cleartext** || y | y
MD5 hash | MD5 hash*** || y | n
Chlg/Rexp | MD5 hash || n | y
* Might not be cleartext password but login possible with that info
** Stored as received from client
*** Re-hashed a second time