Password Security The Right Way | Hacker News Reader

Password Security The Right Way

stormpath.com

40 pointschunsaker47 comments

No.

http://codahale.com/how-to-safely-store-a-password/

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.

Totally agree Coda gets the basics right and I love that article. In fact, our CTO wrote a response blog article to that in February: http://www.stormpath.com/blog/strong-password-hashing-apache...

However, to quote from that post: "The author is correct assuming the attacker has direct access to your password store. This is a big assumption - most organizations go through great lengths to ensure access to say, databases, is levels of security 'deep' beyond just a web login form. Anyway, assuming that this might ever happen to you, how can you address the issue?"

Iterated SHA2 is inferior to bcrypt and far inferior to scrypt, and yet both these Stormpath.com articles recommend it. The advice in these articles is worse that Coda's articles; developers should read Coda's post and implement it.

You're talking about Bcrypt like its some magical golden unicorn that will cover your ass from all attack vectors. Sure, its awesome. But modern security requires more than just an awesome encryption algorithm.

No, I'm talking about bcrypt like it's better than iterated SHA2, which is very, very fast on GPUs. There is no such thing as a unicorn.

At what point does he attribute any unicorn-like properties to bcrypt? All he says is that SHA2 is worse, which is completely true.

Assuming the attacker has access to your password store is NOT a big assumption for most sites. In fact, 94% of data breaches are to the user DB. And 42% of those attacks are targeting the password store specifically. Check out the Verizon Data Breach Report for details. http://bit.ly/GFfpdk

Indeed. Encrypting your bcrypt'd hashes is... massively complex and doesn't provide any additional meaningful security relative to the complexity.

A properly bcrypt'd password table is functionally useless in the hands of a non nation-state. Yeah, it's not something you'd prefer to have a BadGuy(TM) get, but other than embarrassment, it's not a big deal.

Here's my bcrypt with salt. Please, waste your time trying to crack this.

"$2a$19$xZrwzkut/fj2gToExgw8qevT9DtevnuKLEVj.kNiSMclzfFqQq9z."

I'm pretty sure your actual bcrypted password doesn't have that cost factor on it.

That's how rails stores it in the database, so trying to be as transparent as possible.

It takes 3 minutes to log into your application?

You are absolutely right. This is not our production app (ours is at 12 IIRC) but some internals app I've been playing with.

Ok just so you know the default cost factor for bcrypt-ruby is a reasonable choice, and the cost factor you've used here is unreasonable.

Absolutely. Was trying (but failing) to make a joke.

BCrypt 19s are <40s to encrypt here, using Java and not even native code. Certainly not outside the realm of usability for something you don't authenticate against all the time. I wouldn't want that for my screenlock password, but I can still see it being workable.

Why not? You'd rather have inferior security than wait a minute and a half[1] to access your accounts?

Shame on you, Thomas! I thought you were a professional!

[1] Based on a remarkably unscientific test I just ran on an Ubuntu 12.04 VM on my laptop. 87.8 seconds.

A work factor of 19 seems like overkill. I read that even 08 (less than half that) would suffice in today's world.

I think somewhere between 10 and 12 is the sweet spot right now. Also, just to be clear, 08 is a little more than "less than half". The work factors are exponential. Half of 19 would be 18.

BCrypt (level 3) is getting the basics right. Levels 4 and 5 are techniques beyond the basics used to minimize potential brute force attacks, which _are_ an issue, depending on the attack target (read the Verizon report referenced by another post on this page).

Don't think for a second that certain government agencies can't brute force a BCrypt-based password hash, especially given they will know the cost factor and salt. If the hash is encrypted, and then chunked, if an attacker doesn't have the constituent encrypted chunks and/or the encryption key _for a valid time frame_, the possibility of a brute force attack with modern computing power is almost impossible.

While you may not care about such concerns, some of Stormpath's government agency customers do, and so we provide these additional safety measures. That an average website can benefit from them is icing on the cake.

You feel that you're protecting password hashes from government sponsored attackers, and yet you're iterating SHA2 as your password hash?

Depends on the customer - if it is a government agency and SHA2 is mandated for their own passwords (per NIST standards), we comply (with a huge number of iterations based on CPU/GPU target specs). Additionally, we automatically increase iterations over time as CPU/GPU targets change - something a customer never needs to worry about (which is nice). Otherwise BCrypt or SCrypt is used for most customers.

It seems like some of the finer points of your concerns aren't being covered in this thread (e.g. # of iterations, if sufficiently high, will probably address your GPU concerns). Unfortunately for me, I can't read Hacker News all day and must move on, but if you'd like, definitely give us a call at Stormpath and we'd be quite happy to geek out and talk through the all of the details. (And I apologize if any of this came across as negative - no coffee today I guess).

if an attacker doesn't have the constituent encrypted chunks and/or the encryption key _for a valid time frame_

This reads an awful lot like "If the attacker has not actually compromised the gateway." After all, the gateway needs to either be able to encrypt the password or decrypt the hash to do its job. That means the gateway needs either the key, or access to an oracle that has the key. Either way, you're compromised.

The data sharding has some merit, if only because it's more difficult to simultaneously steal systems from multiple datacenters. I suppose at some level that becomes a concern, but that's roughly the level where you start hiring people with guns to protect your computers.

> Don't think for a second that certain government agencies can't brute force a BCrypt-based password hash, especially given they will know the cost factor and salt.

I have no doubt that government agencies have much more powerful intelligence than people realize. But knowing the salt has no connection to their ability to brute-force; it only affects their ability to use rainbow tables.

(All it does is prevent them from matching up passwords by their hashed values, so for example, if one password is cracked, it protects everyone else who is using the same password.)

But it doesn't provide any protection against brute forcing. Nothing can, short of making the hash function slower (or the password domain larger).

Salting your passwords is cheap and creates a weak form of two factor authentication. Don't forget bcrypt does not help all those people using 'password'.

That said, use bcrypt.

What the fuck are you talking about? A salted password is not two-factor authentication and bcrypt definitely helps people using 'p@ssw0rd'. This is the worst troll ever.

If you don't know the salt you can't crack the password.

So, if say your backups are compromised and someone has all the user names and passwords they still need the salts before they can login to your service.

Let's completely ignore the fact that most compromises of password databases are of live systems, not extraneous backups. What the hell is the point of the backup? You didn't back up the salts, so restoring the backup leaves you with a broken, useless password database.

If there's some place you can put salts where attackers can't get them, I advise you to put your passwords there too.

It's not a question of can't just forcing them jump though one more hoop. Ideally, no single employee should be able to compromise your system and doing something as simple as xor'ing passwords with 'bob' goes a long way to prevent DBA's from having easy access to everything. So, from a cost benefit standpoint it's obvious to salt your passwords with something.

Edit: I am honestly surprised how much push-back people are giving this without saying why they actually disagree.

I would be very skeptical about dealing with this company...

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.

Level 3 it's not clear if bcrypt/scrypt are used or just some SHA iterations. There's a difference between the two.

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.

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.

Great questions.

With regard to CSPNG, this SO post answer is good: http://stackoverflow.com/questions/536584/non-random-salt-fo...

As for bcrypt/scrypt vs iterations, there is a difference, but it's minor. Bcrypt is not demonstrably any more secure than SHA-512 for example - the difference is in computation time (the Blowfish key schedule is _slow_ by nature). With enough iterations (1 million? 10 million? It depends on your CPU/GPU architecture targets), the same effect of slowing down the attacker is achieved. Increasing the number of iterations (and using the output as the next input) is similar to increasing the BCrypt cost factor. You just have to know your target threshold and pick a number accordingly.

Your summary of Level 5 is not quite right - Level 5 is about storing separate chunks of ciphertext - not chunks of the hash's MCF text (MCF = Modular Crypt Format). You can't even start to brute force a hash if you can't decrypt the ciphertext to begin with.

Finally, Stormpath doesn't do anything 'secret' and we go through diligence on these matters with our larger customers. We're happy to divulge all of our techniques (e.g. how we use multi-factor authentication, how we secure firewalls, etc). That information is just outside the scope of a password-related blog article.

That Stack Overflow post doesn't refute John Graham-Cumming's point, which is that the cryptographic strength of a salt doesn't change the security of a secure password system. The salt is there to randomize the hashes; it doesn't resist active attacks. People that obsess on the security of their salt values misunderstand the design of secure hash systems.

Bcrypt is demonstrably more secure than SHA-512. You can look to the Openwall GPU password cracking project for illustration of how. It is easier to speed up SHA2 on a GPU than it is to speed up bcrypt. Scrypt is markedly different from SHA2; it's designed specifically to be difficult to optimize with GPUs (a property bcrypt has only accidentally at present).

Moreover: the best practice for using SHA2 as a password hash is to use PBKDF2, which is not simply iterating SHA2 (you can learn more about PBKDF2 on Wikipedia). Iterated SHA2 is a fine answer for existing applications that need the simplest possible path to something better than a salted hash, but it's not a good answer for new designs.

Your responses to both these points appear to be materially wrong.

"Your summary of Level 5 is not quite right - Level 5 is about storing separate chunks of ciphertext"

Ah, I see. So you generate hash H and using some private key K you calculate C(H,K) where C is some cryptographic algorithm and then you split C(H,K) into parts and spread them around.

So my scenario is complicated by the necessity to compromise K in addition to one of the places where bits of the C(H,K) is stored.

I still feel that the real security of this system relies on the difficulty of computing H.

CSPRNG*. CSPNG is Collaborative Support Programs of New Jersey :P

Cryptographically secure pseudo-random number generator.

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:

1. Disable TLS compression. (it's currently on)

2. Disable CBC-based ciphersuites. (they're currently enabled, or higher priority than RC4)

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 really 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)

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.

5. Implement DNSSEC and IPv6. Your public sector clients will get a kick out of it.

You don't need to disable CBC ciphersuites. Implementing DNSSEC and IPv6 will do approximately zero for your security, too.

True, you can just give RC4 higher priority. Implementing DNSSEC/IPv6 is just meant to give managers who are obsessed with "military-grade" anything a hard-on.

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.

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.

You mean for web apps? Lotus Notes has done that since forever. The Notes password is just the seed of a decryption key for your user ID file; getting the password correct decrypts the keys, both private and secret (used for shared symmetrically-encrypted document fields); the actual server login is PKI. (The Domino web password for HTML apps, when enabled, is a standard hashed-values type, though.)

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.

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.

All extra security is added value, sure, but focus on other areas wouldn't hurt.

Totally Agree! I wanted to keep the scope for this narrow so it didn't turn into a total beast. The guys over at Cloud Passage have some great content on server security (http://blog.cloudpassage.com/) that I think is really well informed, and we're going to do a followup on backend security.

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.

We built dailycred.com to handle exactly these sorts of issues for you.

Too offensive;didn't read

Reply on news.ycombinator.com