NYCPHP Meetup

[tedd]

At 2:14 PM -0400 5/6/10, Nicholas Ilyin wrote:
>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

Excellent advice. Saving a copy of it for my reference.

Cheers,

tedd
-- 
-------
http://sperling.com  http://ancientstones.com  http://earthstones.com