Dear websites

To many people, "alphanumeric" means "containing ONLY letters and numbers" not "containing AT LEAST BOTH OF letters and numbers". I can see where that usage comes from: yes, abc123 is arguably more alphanumeric than abcdef in a metaphorical sort of way.

But I'm not sure "ooh, long scary word, that'll make unsophisticated users randomly guess secure passwords" is the right way of explaining things.

Also, I'm pretty sure non-alphanumeric characters are generally better (with the possible exception of counting spaces/hyphens/underscores as letters). The advice to use letters and numbers in your password could be more accurately phrased as "don't use a password consisting entirely of letters, or entirely of numbers". If someone uses a password composed entirely of letters and non-alphanumeric characters, that's probably BETTER than one containing at least 1 digit.

Also, yay for customisable password reminders. And yay for escaping text which you will display on your website. But if you escape the text one too many times, and the reminder box reads "blah blah &quote; blah blah &quote; blah" I don't think "wow, they escaped the text twice, that's much less likely they forgot to escape it somewhere" I think "wow, they appear to escape the text N times where N~N(1,1)" and find it quite likely that somewhere they forgot to escape it at all.

BTW, I'm sorry for picking on you. Yeah, I don't want to spend time on this either, and if you're making a good effort, or are only a hobby website, I'll cut you a lot of slack. And to be fair, the functionality of your website is really quite good. But a large company should probably hire someone who can get this stuff right.

Everything I know about storing passwords

OK, everything I know about storing passwords in databases is:

* Offering a password strength meter is helpful. Insisting a password is long is possibly useful. Mandating complicated requirements about special characters that aren't documented is NOT helpful.
* Combine the password with a salt.
* The salt should be stored in the database, it need NOT be stored encrypted in any way
* The salt should be unique across all sites (ie. do NOT use the same salt for all passwords, nor use the username/email address as the salt. I can't remember is using a unqiue but predictable salt like sitename+username MIGHT is bad or not, but a random salt should be fine.)
* Combine the password with the salt, hash it, and store the hash in the database
* Use a password hash designed for the purpose (bcrypt, etc), not a cryptographic hash (md5). This will run a hash on the input thousands of times. If you don't, brute-forcing the passwords can be nearly trivial. Never use a non-cryptographic hash function -- that means one that's hard to reverse by chance, but may be easily reversible by malicious people.
* Use a pre-existing, well known library to do the hash.
* Whatever hash is currently best will be dangerously weak in five years time. I can't remember which is best (I've never had to do this). Don't memorise one and stick to it, go on stack overflow, ask which are the three best now, and pick one. Ideally you will know the pros and cons of different functions, but going with one of the industry standards is probably the least-risky.
* If you have any clever ideas for improving the process, DON'T. At least without running them by an expert (stackoverflow can probably tell you why they're stupid in a few minutes). SEVEN TIMES NEVER, never ever use a cryptographic function you implemented yourself, unless it's been extensively tested by a cryptographic community.
* You should never be able to recover a plain text password for a user in any way. If you can, you're doing something wrong.
* If someone forgets a password, offer an easy-to-use one-time password-reset link via email. Don't email plain-text passwords.
* Don't offer secret questions where the answers are less secure than a password.
* I have almost certainly made at least one serious error above. Don't rely on this, find something written by an expert.
* Consider open-id so someone else can do all this. For something more secure, you should probably use two-factor authentication implemented in some non-stupid way.
* There can be exceptions to this, where reduced security is a reasonable trade-off. But don't start by assuming that you're one of those cases. Even on a crappy throw-away website, you might not implement everything, but don't do any of the things that are bad.

And that's what I know as a non-expert, who's never done this, and hopes never to have to do this, from occasionally browsing best-practice discussions at stack overflow. That's probably the MINIMUM you can know and not be negligent, and is riddled with errors, simplifications, and miscommunications. If you know LESS than this, and are running a big company, you should probably hire someone who knows what they're doing to handle your passwords.

Link: Prometheus FAQ

http://www.toplessrobot.com/2012/06/robs_prometheus_faq.php has had by far the funniest and most helpful summary of Promethius I've seen. I almost, but not quite, want to see it.

(Spoilers in comments.)