Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Password Security The Right Way

stormpath.com

Post reply on HN
Print view View original

21–30 of 50 posts

Re: Password Security The Right Way

#21

Post by AgentConundrum »

tptacek wrote: post #17
MattRogish wrote: post #11

Earlier quoted context omitted.

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 c…

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

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.

Re: Password Security The Right Way

#22

Post by chunsaker »

strictfp wrote: post #13

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.…

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.

Re: Password Security The Right Way

#23

Post by lhazlewood »

jgrahamc wrote: post #8

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…

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.

Re: Password Security The Right Way

#24

Post by tptacek »

MattRogish wrote: post #19
tptacek wrote: post #17

Earlier quoted context omitted.

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?

Re: Password Security The Right Way

#25

Post by amalcon »

lhazlewood wrote: post #14
tptacek wrote: post #3

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.

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…

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.

Re: Password Security The Right Way

#26

Post by tptacek »

lhazlewood wrote: post #23
jgrahamc wrote: post #8

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…

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 depend…

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.

Re: Password Security The Right Way

#27

Post by jayflux »

MattRogish wrote: post #11
tptacek wrote: post #3

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.

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 c…

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

Re: Password Security The Right Way

#28

Post by jgrahamc »

lhazlewood wrote: post #23
jgrahamc wrote: post #8

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…

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 depend…

"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.

Re: Password Security The Right Way

#29

Post by AgentConundrum »

jayflux wrote: post #27
MattRogish wrote: post #11

Earlier quoted context omitted.

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 c…

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.

Re: Password Security The Right Way

#30

Post by Retric »

tptacek wrote: post #3

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.

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.

Post reply on HN