C[omp]ute

From: andrew cooke <andrew@...>

Date: Fri, 12 Jul 2013 14:19:15 -0400

This has been deleted from StackOverflow, so I want to record some information
here.

The question was a vague one about "security".  The answer focused on password
management and gave what was best practice 10 years ago, but not now - salt
and hash.

Then there were these comments (me first):

   you should be using PBKDF2 or scrypt for passwords, not rolling your
   own. something like you describe doesn't give good enough safety for
   typical passwords - there's no adjustable work factor. someone with a
   cracker who steals your db will crack many... - andrew cooke Jun 30 at
   18:09

   @andrewcooke Actually PBKDF2 will increase your computational need in the
   server, thus slowing down the login process. This could result in over
   taxation of server resources, resulting in a crash due to low memory or a
   denial of service during peak times, even on pretty good hardware. The
   reason I suggest staying away from PBKDF2 and other memory bound KDFs is
   because it is simply unnecessary. There is no benefit except that it slows
   dictionary attacks if your database is compromised and exported for making
   local attacks. I did not "roll my own" in my answer, I used standard
   algorithms. - Mxxxxxx J. Gxxx Jun 30 at 18:14
 	
   @andrewcooke To address another point in your comment, you also need to
   realize that you shouldn't be protecting people with silly passwords. It is
   generally up to the user to be responsible for choosing a decent
   password. As long as you store it in a sane manner, you are doing your
   job. Remember that if your users can't log in because your resources are
   used entirely, you are doing worse by trying to help more. - Mxxxxxx
   J. Gxxxx Jun 30 at 18:21

Note that final gem: "YOU SHOULDN'T BE PROTECTING PEOPLE WITH SILLY
PASSWORDS".  So he's throwing what, more than half his users, under the 
bus...

Awesome.

Andrew