Live data from Hacker News

Password Security The Right Way

stormpath.com

31–40 of 50 posts

Re: Password Security The Right Way

#31
post #30
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.

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.

Re: Password Security The Right Way

#32
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…

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

Re: Password Security The Right Way

#33
post #30
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.

[deleted]

Re: Password Security The Right Way

#34
post #24

Earlier quoted context omitted.

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.

Re: Password Security The Right Way

#35
post #24

Earlier quoted context omitted.

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.

Re: Password Security The Right Way

#36
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.

Re: Password Security The Right Way

#37
post #35

Earlier quoted context omitted.

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.

Re: Password Security The Right Way

#38
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…

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

Re: Password Security The Right Way

#39
post #30

Earlier quoted context omitted.

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.

Re: Password Security The Right Way

#40
post #16

Earlier quoted context omitted.

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…

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

Post reply on HN