Web Security

[FrostWraith]

Hi everyone.

I just got hired for a new web design job and wanted your input for the best secure login system. In the past I have just mainly used php sessions/cookies.  I would prefer any tips to be for php, but I am happy for any input.  Also, how and where is the best place to store passwords. I traditionally have always md5ed them and stored them in a MySQL database.

Thanks

[Warrior]

That's usually what I do (in a nutshell) you're going to need to get a teeny bit less general in what you're looking for.

[rabbit]

Hmm..use sha1, not md5.  It's just a different function name, and is a lot harder to collide.

[indulgence]

You definately want to store the passwords as a stronger hash (SHA-1 or better), why not MD5? http://www.gdataonline.com/

Also, cookies are fine.  But you will want to secure your users from XSS or CSFR attacks.  If there is any action that modifies their account in any way - think about requiring user interaction (CAPTCHA?).  And be sure to sanitize any user input strings. (Definately want to encode <> to say the least)

Its amazing what kind of vulnerabilities are out there....

[CrAzY]

There is more to security than password encryptions...  Try making you registration file secure by using Email confirmation, IP Address logging, etc...  Be sure that you include a minimal length on the password such as... 5.  I would also think about setting up some sort of log that is stored in MySQL of login attempts; so you can limit the trials of logging into the account (to prevent brute-forcers.)  Also be sure there is no loose holes in you actual site where some user could implement their code to inject data into you SQL db. 

Thats all I can think of off the top of my head...

[Banana fanna fo fanna]

Just because you hashed the password in the database doesn't mean it isn't vulnerable to common password attacks. Lots of times, if your database gets hijacked, one can precompute the hashes of many common passwords and bruteforce them. Use a salted SHA-1 to reduce these attacks (essentially append a random string at the end of the password before hashing it, and store that string in the database).

[Barabajagal]

Personally, I'm a fan of a fun technique. use an XOR encryption to encrypt the password using the username as the key. then SHA-256 hash the result of that.

[Ersan]

A salted md5 or (if you must) sha1 hash is more than adequate...  Salting renders rainbow attacks innefective.  If someone's gained access to your database you probably have more important things to worry about than stolen passwords that will take ages to bruteforce.

[Networks]

A salted md5 or (if you must) sha1 hash is more than adequate...  Salting renders rainbow attacks innefective.  If someone's gained access to your database you probably have more important things to worry about than stolen passwords that will take ages to bruteforce.

I second this, always salt your hashes and certainly do IP session checks in your cookies to prevent XSS and use tokens in your forms to prevent CSRF. Always escape your SQL queries, I might advise you to use a MySQL escaping wrapper if you can so for future projects this is a trivial thing to worry about.

My .02 cents.

[Banana fanna fo fanna]

why does everyone ignore me

[Ersan]

I was just responding to realityripple's post...

[Networks]

Just because you hashed the password in the database doesn't mean it isn't vulnerable to common password attacks. Lots of times, if your database gets hijacked, one can precompute the hashes of many common passwords and bruteforce them. Use a salted SHA-1 to reduce these attacks (essentially append a random string at the end of the password before hashing it, and store that string in the database).

If you appended a randomized string, how could you compare the hash later?

[topaz]

LOL.

[Ersan]

and store that string in the database

[Networks]

and store that string in the database

Wow, completely missed that part. eh I think you're set without that kind of overhead honestly. I'd worry about actually hardening your code first.