Does anyone else think that this is a good idea for password encryption on my new site? A randomly generated 8-digit number when the user signs up. This passcode is then saved and used in an MD5 salt of the users password. This passcode is then fetched each time the user tries to log in. and the inputed password is encrypted exactly the same. Can anyone think of a better implementation that I could use?
I read this the other day and bookmarked it for when I need to implement a password protected site: Password Hash Tutorial
Password encryption is not a good idea, because an attacker can decrypt it and abuse the fact that ppl use the same nickname/password on multiple sites. You need to run the pass trough a non-reversible hash function, that way you can authenticate the user, but cannot find his password in clear text.
Wikipedia has good description about hashing and salting. A look on the following links may be helpful: http://en.wikipedia.org/wiki/Hash_table http://en.wikipedia.org/wiki/Salting_(cryptography)
won't salting be fine for password encryption with an md5 hash? like i have now. Especially now that I have a randomly generated 7 digit number as part of the encryption key?
Encryption =/= Hashing. You're confusing the terms in this context. Keeping it simple, encryption is designed to be possible to decrypt (if you have the keys or whatever other means) i.e. Two way. Hashing here involves converting a text string to another string, such that you can reliably convert the same first string into the same second string, while not being able to convert the second string back into the first. i.e. One way. As far as I can gather, you're generating a salt per user, combining it with the password to create a hash (using md5 in this case) and storing the resulting hash and the individual salt. Then pulling the salt and hash from storage and repeating the process again upon attempted login. All that correct? If so, sounds fine.
To reiterate what's been said before: Read this link It gives you an idea of how exploitable even salted hashes are, how they get exploited and how to avoid that...
Yep but before even reading that guide I have implemented a random hash for each user. Unfortunately I don't have sufficient hardware to crypt the password 100 times.
Blowfish? Just a thought. It's similar to going Code: for($i=0;$i<1000;$i++) { $hash=md5($hash); } but faster than that. It uses a cost parameter, which slows it down a bit. And trust me - that bit is hardly noticable, unless you go and run it in a couple of simultaneous requests (i.e. over 5). Also, ALWAYS use 8, rather than 6 letters minimum, and enforce complexity. Article outlines that. Also worth noting is that while the number hash is a decent idea, the moment your table gets out (sql injection), it's all over with that idea. MD5 is the first hash I'd try when breaking into a site, simply because so many people actually use it. You can still use it, though... even Blowfish uses a salt. The difference comes in in computational speed. MD5 runs, say 1 million times a second. You have 6 million possible hashes (hypothetically, to exemplify a point). That means it'll take 6 seconds until the password is broken. With blowfish, you'd essentially (a bit abstracted) make the hash run 1000 times, thus slowing the hash down to 1000 times a second. meaning it'd take 6000 seconds before the password falls. At a slight overhead of processing power, Blowidh offers 1000x the time-to-break. Mind - I reckon a lot of it boils down to how high-profile the site is. For a lot of sites, MD5 by itself is good enough, since they're simply not targeted (no valuable user info, few users, no financial data, no company secrets). The higher profile the site, the higher the security. Also: SSL is a good idea...
How do I force complexity. I have wanted to do that for a while but i could never figure out how to...
I'd do that client side (for usability). It can be done server side, though (using PHP) While there are libraries out there that do it, and one could possibly run nested "contains" checks. However, I'd hazard a guess and say there's a way top do it using regular expressions. for example the preg_match function. Regular expressions aren't easy to formulate, though... so do some researcht into that.
ssl is defeated though with sslstrip.. you have to have access to the lan though- which isn't hard with most peoples setup
A double hashed, singly salted password is what many of the large PHP/MySQL scripts do (SMF, vBulletin et al). Yes there are more secure (computationally secure, that is) methods available, but this provides plently of security for non-military uses. Heck, a very large message boards - WebHostingTalk - was hacked and the usernames and hashed passwords were leaked online. There's still not AFAIK been a case where any of the reverse enginereed were decoded and the plaintext recovered. Regarding the hashing algorithm - probably use sha1 over md5. Whilst both are considered to now be broken, sha1 still offers better overall security. So yeah, your plan of doing something like: password = sha1( sha1( original_password ) . random_salt ); Is a good one. Should provide more than enough security without being too computationally expensive.
The problem with double hashing is that the chance for hash-collision stays very similar. But yes, it's safer than single-hash. Just remember: you don't need the same password to break into a site. Just the same hash. And hashes aren't unique. See "Rainbow Tables" for more on that. +1 on sha1>md5 as well Unless you consider yourself a target, that should be good enough. I'd honestly be more concerned about SQL Injection Attacks. They are responsible for pretty much most of the website hacks these days. 90% of that is easy to catch as well. mysql_real_escape_string(), for example, is your friend. EDIT: an afterthought on this post: Remember that POST'ing an unencrypted password is setting yourself up for MITM (Man in the middle) attacks. One spoof-your-site login later, and he has a username and password, and never obstructed the flow of your site. Client side encryption of the password would eb a good idea. Then decrypt server side, and use that for password hashing
it's all owned benant.. banks.. google even uses ssl full time through gmail, owned too.. there's not much you can do when the mitm strips the encryption and sends you a modded http.. then communicates with the server like it's the client I could post videos.. even have my own scripts spent days writing but only for research purposes the easiest way to stop mitm is run static dns on all your rigs.. you can do practically anything if your acting as the guys dhcp server- spoof webpages from an apache server on your laptop.. and it's so fast over wireless and with the right equipment they won't even notice a slowdown.. most guys don't know how to do all this though.. and it's very noticeable if a newbie is trying to pull it off- usually they'll trip off firewalls while they're at it too it's why most of the stuff on it you'll see posted is just the basics.. there's a lot more to it if your good but you have to understand it over 'I am pwner' running some half ass script found this pretty funny http://www.net-security.org/secworld.php?id=10187 he's the real deal
Agree, Hippoz. 100% true, all fo what you're saying. MITM is not easy to stop, and it's overkill 9/10 times to even bother too much about that on the average site. Client site encryption of the passsword would only stop a script kiddie, and not a real-deal. Most script kiddies are incapable of hacking properly anyway. I guess the point is that sufficient security is easy enough on the avearage-traffic-site. Once you become a target, it becomes almost impossible to actually stop a targetted attack. The basic advice is good advice: Hash passwords. Sanitize inputs. Enforce Password policies.
