MD5() and SHA1()

dw89

Hi All,

I realise that both these functions encrypt to a hash of 32 and 40 chars respectively and see the SHA1() is more crytographically secure than MD5() but in the real world just how secure are they? Can they be hacked?

I.e on my site what I want to do is protect both user and pw BEFORE calling a MySQL stored procedure which will then do something else to them in the Db. My idea is that then it is secured during and after transit from web server to Db.

So if I say SHA1'd user and pw(making sure the password is a alphanumeric string) before calling MySQL, if someone picked them up using a sniffer etc could they work them out??

Just interested to see opinions really

Thanks

Dave 😃

SamC

SHA1 remains pretty secure, supposedly the attacks on SHA1 are fairly useless in reversing a hash. Have a look at Wikipedia.

However, depending on what the password is then an attacker could sniff the hashed password and check it against a list of the hashes of common passwords. This of course is impractical with more complex passwords.

If you're really worried about security then maybe look at hashing the hash and also using a salt.

EDIT: You do realise that the username and password will be sent in their original form to PHP where PHP will hash them and the send them to MySQL? That is unless you do some clientside sha1 encryption with Javascript or something.

dw89

EDIT: You do realise that the username and password will be sent in their original form to PHP where PHP will hash them and the send them to MySQL? That is unless you do some clientside sha1 encryption with Javascript or something.

Ah the one thing I forgot! I think I will have everything else covered so I also need to work out the hashing of them using JScript to go from client to PHP in the first place. I take it I am buggered if JScript is turned off? Is JScript my only option?Then it'll only be hashed from PHP to MySQL and back?

Thanks, it's useful info which I couldn't find anywhere else!

Dave 😃

dw89

Just saying in my other post Sam that the SHA-256 code here looks intesrting:

http://forums.devnetwork.net/viewtopic.php?t=31069

Thanks

Dave

SamC

dw89 wrote:
Ah the one thing I forgot! I think I will have everything else covered so I also need to work out the hashing of them using JScript to go from client to PHP in the first place. I take it I am buggered if JScript is turned off? Is JScript my only option?Then it'll only be hashed from PHP to MySQL and back?

Thanks, it's useful info which I couldn't find anywhere else!

Dave 😃

Doing it this way is by no way the best solution. If security really is important then you probably need to look into using SSL. In other words, transfer the data from client to server using SSL, then store the data on the server using a salt and SHA1

dw89

Sam,

Well it's important but I don't know how likely it is that someone would 'sniff' out the user/pw from Client to Web Server? There's no financial data being stored on the Db but I want customers to feel secure (hence why I've been looking at SHA-256 but is it really necessary to use SSL for login? Do lots of consumer sites use it for just logging in? What's involved in implementing?

Another question I have over security is the whole sessions v cookie issue. If jscript is turned off does this automatically turn off cookies too? If it does I guess I am leaning ttowards $_session creation for security..or a combo of both...i.e a) is there a cookie, if yes then carry on otherwise b) is there a session, if yes carry on or bye bye.

So many questions about security....the rest seems relatively easy...no wonder total code newbies (i.e. never coded a thing before) want to start building straight away......I've been planning for over a month so far!

Thanks v much

Dave

SamC

dw89 wrote:
Well it's important but I don't know how likely it is that someone would 'sniff' out the user/pw from Client to Web Server? There's no financial data being stored on the Db but I want customers to feel secure (hence why I've been looking at SHA-256 but is it really necessary to use SSL for login? Do lots of consumer sites use it for just logging in? What's involved in implementing?

The fact that you've now mentioned that this is for customers makes me think that you should probably go down the route of SSL, with which I have very little knowledge of. The method I mentioned using Javascript is nowhere near secure enough. In a business situation you really need to employ something a bit more secure. Also I'm sure customers would feel a lot more comfortable this way too, knowing that what being is sent across the internet is secure is very reassuring.

Also, I would probably just stick with using SHA1 and a salt. It'll be secure enough.

dw89 wrote:
Another question I have over security is the whole sessions v cookie issue. If jscript is turned off does this automatically turn off cookies too? If it does I guess I am leaning ttowards $_session creation for security..or a combo of both...i.e a) is there a cookie, if yes then carry on otherwise b) is there a session, if yes carry on or bye bye.

Javascript being off does not stop cookies being set. Well, it would if you were setting cookies with Javscript! :p

With regards to cookies, sessions, users and all that jazz your best bet is to probably use the search, there appears to have been a lot of discussion on sessions and security already.

dw89 wrote:
So many questions about security....the rest seems relatively easy...no wonder total code newbies (i.e. never coded a thing before) want to start building straight away......I've been planning for over a month so far!

Good luck with your project, I hope it all works out for you 🙂

laserlight

I want customers to feel secure (hence why I've been looking at SHA-256 but is it really necessary to use SSL for login?

When you use a cryptographic hash in this way, your intention is to make it difficult for an attacker to obtain the original password even if the database is compromised. The attacks on MD5 and SHA1 dont affect this, but then one might as well use SHA1 instead of SHA-256 since SHA1 is implemented as sha1() in PHP, and takes slightly longer than md5(), which is desirable in this case.

The problem with applying the hash at serverside (and doing nothing else) is that the password is sent in original form from clientside - it may be intercepted in transmission.

Now, even if the password is hashed at clientside, you are still sending it in the clear. The password hash is effectively the password, just that an attacker should not be able to find out the original. SSL can be used to establish a secure channel between client and server.

dw89

Guys:

SamC: Thanks for the info....I agree on the Cookie bit...believe it or not I read it somewhere today (god knows where I've read so much on security lately!) that if JScript is off cookies don't work....which worried me as I didn't realise that was the case! Obviously not. I also agree on the customer reassurance thing. If I se a Verisign symbol it always makes me think better of the site knowing transfer is secure. Thanks again.

Laserlight: Hi, thanks for your info. Met someone from Singapore only recently whilst I was in the Maldives...spoke highly of it🙂 Especially as it took him 4 hours to get there as opposed to 20! Anyway, thanks for the insight....I'm basically getting the vibes that no matter whether I decide to hash passwords client side anyway I should still look to transfer in SSL to prevent compromising of even hashed passwords? I'll look into it more. I guess it's a case of configuring Apache and paying a CA for a cert?

Thanks very much all for the info....getting a better feel for things now.

Dave😉

SamC

dw89 wrote:
... I should still look to transfer in SSL to prevent compromising of even hashed passwords...

The Javascript thing I was talking about does little more than stop people working out what the original password is. They could still sniff and post the hashed passwords to your script and gain access that way.

tony_l

I have to agree with here that javascript is a bad thing. Javascript can easily be manipulated on the client-side. Never trust the client as the old addage says. The ONLY way to securely transfer data from client to server is via ssl (which is basically a digital signature that is encrypted went the packets are sent over the network [internet]).

What I do is this - username and password are sent back to the sever (using ssl of course). The script then adds a 'secret' password to the password sent by the client. These are combined (using a function that integrates the two in a way that can be reversed using a reverseing fuction) and then encrpted and sent to the database. This will effectively stop a database attack from being effective. If they get the password from the database and reverse engineer the hash, the hash is useless to them - because they do not know the 'secret' password that was added to the password that was sent as well as the fact that they don't have the function that will reverse the combination algorithm.

As for cookies and like - Sessions are as secure as you can get. Cookies can be corrupted, hacked and spoofed (as well as being turned off). Sessions are stored on the server side. There are lots of discussions stating that sessions are insecure - but those problems were mainly in PHP3, with PHP4 and subsequent versions and builds, security holes have been closed, and more security added.

NOTE - If you are using a database, use PHP's function to clean the data - such as mysql_real_escape_string() to avoid sql injection attacks.

One more thing - people will try to tell you that MD5 and SHA1 are "crackable". This is absolutely true.......if the person lives to be very old, or is a mathematical genius. These algorithms use a highly sophisticated means of generating a hash. Crackers will not try to crack the algorithm, what they will try to do is use the MD5() or SHA1() to hash out the dictionary (yes they will use the entire dictionary). To prevent this, ALWAYS insist that your users use a password that cannot be guessed - such as by using at least 1 number in it (preferably not at the beginning or end). You can also go one step further and issue the password to them by using a pronouncable password generator that you can easily build yourself. Also require them to change their password every 6 months.

I really did not mean to go into this long boring dissertation on security, but I have learned the hard way. I had a site that was hacked, and it was my fault. After that - I wised-up and read up on security. I encourage you to read everything you can on the subject- it will save you time, money and grief.

laserlight

Javascript can easily be manipulated on the client-side. Never trust the client as the old addage says.

In this case, you just need to perform input validation serverside. Changing the clientside scripting probably will not benefit a malicious user, except to try say, SQL injection.

The script then adds a 'secret' password to the password sent by the client. These are combined (using a function that integrates the two in a way that can be reversed using a reverseing fuction) and then encrpted and sent to the database.

You should just use the cryptographic hash (i.e. the 'secret password' is a salt), otherwise you should use a secure cryptosystem. The salt may not even need to be secret, merely sufficiently random/unique.

If they get the password from the database and reverse engineer the hash, the hash is useless to them - because they do not know the 'secret' password that was added to the password that was sent

The attacker should not be able to 'reverse engineer the hash'. A cryptographic hash algorithm such as SHA1 should be used.

as well as the fact that they don't have the function that will reverse the combination algorithm.

You should not rely on the secrecy of the algorithm, which is why you should use a cryptographic hash algorithm, or a secure cryptosystem.

robert_w_ark

MD5 and SHA1 can both be cracked. Most people use tables like what you see on the attachment. Have a look for yourself and view the attachment.

As you can see, the more passwords and hashes they have, the more chances of success when cracking the password.

laserlight

MD5 and SHA1 can both be cracked. Most people use tables like what you see on the attachment.

Careful there - the use of rainbow tables does not constitute 'cracking' MD5 and/or SHA1 for this purpose.

As you can see, the more passwords and hashes they have, the more chances of success when cracking the password.

Which is why a unique salt should be used, since the table must be re-calculated for each password hash, defeating its effectiveness.

robert_w_ark

Oh, I forgot to add, I have a PHP source to crack MD5 Hash passwords using MySQL databases. Attached is the script. Please do not abuse it. Credits to me are appreciated (codehelpers.com). Enjoy, -Rob

robert_w_ark

That is true, but IF the scriptor decides to use the default salt (or just md5() or sha1()) then they are sustainable to having their passwords cracked.

robert_w_ark

If you want to have something really secure, and you don't tell your people the encryption method (whilest you are using default salts) you can do something like this:

md5(sha1(md5(sha1(sha1(md5($password))))));

Up to you, or you can make your own salts

dw89

Tony: Thanks...no, not boring at all really🙂 Experience with security is one thing I don't have so it's all good! If you are taking the password frmo the client-side and combining with another 'secret' password where is this secret password to be kept so that it cannot be read? I intend to obfuscate all my code but wondered where you could keep info like this and Db connect info? Some kind of include file?

Thanks, I'll be looking seriously into SSL now.

Dave🙂

robert_w_ark

dw89, are you trying to compare passwords from a form and mysql?

dw89

Yes I would do...i.e. on a very 'simple' level for logins it would be comparing a hashed variable representing a user and password to hashed values stored in a mysql Db.

Just read all your other posts about using table crackers for hashed pw's.

Surely if the passwords are alphanumeric (forced on user) and not in the dictionary this is unlikely?

Interesting reading🙂

Dave