Password Security The Right Way

No.<p><a href="http://codahale.com/how-to-safely-store-a-password/" rel="nofollow">http://codahale.com/how-to-safely-store-a-password/</a><p>It's really not more complicated than this. You can use scrypt instead of bcrypt if that makes you happy. The secret crypto keys in separate storage locations stuff is silly. Get the basics right.

I would be very skeptical about dealing with this company...<p>Level 2 ask for a CSPNG to be used to generate the salt. Why? Given that the salt is assumed to be a piece of public knowledge when attacking a system like this there's no need for it to be output from a CSPNG as there's no concern about a random number generator weakness as an attack vector.<p>Level 3 it's not clear if bcrypt/scrypt are used or just some SHA iterations. There's a difference between the two.<p>Levels 4 and 5 don't seem to provide much additional security over getting the hashing right. Also, there's an awful lot of 'we do secret stuff' that worries me.<p>And specifically the claim in part 5 that all the stores would have to be compromised seems erroneous to me. Suppose I compromise one store and I have part of the hash, I can still run a password cracker and compare with part of the hash I have. Sure, there's some error there but I can then take the guessed password and try it to see if I got it right.

Every time I read "military-grade" on one of their pages, my head twitches. Since your whole product hinges on HTTPS, you might want to tweak a couple things:<p>1. Disable TLS compression. (it's currently on)<p>2. Disable CBC-based ciphersuites. (they're currently enabled, or higher priority than RC4)<p>3. Get more than one IP address to host your site, preferably distributed to a different part of the world. It seems you've got two separate amazon IPs, one for www.stormpath.com and one for stormpath.com; i'm not sure if those are anycast addresses but I doubt it. I <i>really</i> hope they're not in the US East/Virginia zone, since it goes down about once a year (which makes your 100% availability guarantee for enterprise customers impossible)<p>4. Your main cert has SANs for stormpath.com, www.stormpath.com, api.stormpath.com, ci.stormpath.com, repository.stormpath.com. I know that makes it easier to manage, but when one of these hosts gets compromised and its private key stolen, the whole kit and caboodle is compromised.<p>5. Implement DNSSEC and IPv6. Your public sector clients will get a kick out of it.

Can we someday move away from password on the server, at least as an option? Give me the option of setting up my account with a public key instead of a password, and logging in by demonstrating that I have access to the corresponding private key.<p>One might object that this would mean I could only access my account from computers and devices where I keep a copy of my private key. True--but I'm ALREADY in that position for most sites, because I use long random passwords that I manage with a password manager running on my computers and devices.

The hey girl crap needs to end. Now.

While compromized passwords are one problem, leaking your data is bad in so many other ways as well. Yet almost all focus lies in obfuscating passwords to prevent extraction in the case of a breach. We don't talk as much about securing addresses and SSNs and other sensitive data.<p>Well guess what, if the attacker has access to your system he can just install a password logger and all your obfuscation would be in vain.<p>All extra security is added value, sure, but focus on other areas wouldn't hurt.

This article definitely seems like an overkill. If you are using bcrypt or scrypt properly, what else is needed other than common sense of course.

Something the article didn't cover but should is the upkeep over time of whatever algorithm you use. We can argue about todays algorithms. But what do we do when those algorithm are superseded? Or when the minimum complexity factor needs to go up. If you're an app dev or devops, will you know when that happens and how will you update?

Also realize that you don't have to build every component of your website yourself - and unless security is the focus of your business, dealing with storing passwords might not be the best use of your time.<p>We built dailycred.com to handle exactly these sorts of issues for you.

Too offensive;didn't read