Hi Anthony, In theory, no hashing function will ever be free from brute force attacks, but this is a matter of how long one is willing to perform a brute force attack to find the variable (a password) in a one-way hashing function. In practice, some hashing functions have clear security flaws while others are not yet known to have any.
In your example it is best to stay away from MD5 as there are serious security issues with it. SHA-1 is still a safe hashing function to use. You may find papers on the internet that state that there was progress in finding collisions or algorithmic strategies in significantly reducing the security of SHA-1, but I am yet to see a solution that does not require astronomical computation to render SHA-1 insecure. However, appending any plaintext to your password and hashing that, such as SHA(username+password+username) is useless from a mathematical standpoint as the username is actually known to a potential hacker. The way that hash functions work would mean that adding any additional bits which are known will not increase the security of your resulting hash. When you mention that "all are comprimisable by that simple manner" I have to disagree. Although you are correct in saying that a brute force attack is possible, a good encryption/hashing function will require so many computations that even super computers would need to run for years to actually break your encryption. Here are some recommendations that will increase the security of your passwords: 1. Use a password strength checker which would not allow dictionary words to be used for passwords. This eliminates a dictionary attack and requires brute force. 2. Require long passwords, such as over 10 characters. Each character is 8 bits of information which can significantly reduce the chance of a collision with a brute force attack. 3. Prevent automated attacks by locking down the account after 3 attempts or so. Computation is on orders faster than a lockout time of 10 minutes which will render any brute force attack completely useless in this case. 4. Never allow an open connection on your DB server to the world, even if you have 30 character passwords to access your SQL server. You should tightly lockdown any and all access to your SQL server so that there is very minimal access (such as from a web server). Hope this helps, Nick On Thu, May 6, 2010 at 1:15 PM, Anthony Papillion <papill...@gmail.com>wrote: > So I've used encryption on a personal level and even on the server > through SSL but I've not done much more in PHP than using either the > MD5() or SHA1() functions on passwords. I tend to be a very paranoid > type with user information and I'm constantly thinking about > weaknesses in systems and how they could be exploited. > > My initial encryption method was to either md5 or SHA1 passwords, and > stick them in the database. While I know it's difficult to 'reverse > the sausage machine' on these encrypted strings, it's not impossible. > An attacker could determine an MD5 or SHA1 password through a simple > dictionary attack. So, in essence, the encryption is useless. > > My current method is to concatenate the username+password+username and > then either MD5 or SHA1 that and store that as the password in the > database. But, really, is this anymore secure to a sophisticated, > thinking attacker? Certainly, if I could think of it, they could, and > it would again be trivial to write a script to execute a simple > dictionary attack and figure out the password. > > I also know there are many other encryption methods out there but, > isn't it true that *all* of them are compromisable by that simple > manner or am I missing something critical here? Perhaps the only way > to mitigate the risk is to institute a 3 strikes policy (which pisses > users off but is secure) and to them change the users password to some > absolutely random 50 digit gobbledygook string of characters. > > Am I being overly paranoid here or are these valid concerns? Am I > simply missing something? > > Thanks! > Anthony > > Blog: www.cajuntechie.com > Facebook: www.facebook.com/cajuntechie > Twitter: www.twitter.com/cajuntechie > _______________________________________________ > New York PHP Users Group Community Talk Mailing List > http://lists.nyphp.org/mailman/listinfo/talk > > http://www.nyphp.org/Show-Participation >
_______________________________________________ New York PHP Users Group Community Talk Mailing List http://lists.nyphp.org/mailman/listinfo/talk http://www.nyphp.org/Show-Participation
