6 ms·

Password Security The Right Way

40 points by chunsaker 14y ago

deleted 14y ago
[deleted]
tptacek 14y ago
No. http://codahale.com/how-to-safely-store-a-password/ 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.
- chunsaker 14y ago
  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-shiro 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?"
  - tptacek 14y ago
    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.
    - chunsaker 14y ago
      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.
      - tptacek 14y ago
        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.
      - mikeash 14y ago
        At what point does he attribute any unicorn-like properties to bcrypt? All he says is that SHA2 is worse, which is completely true.
  - asalazar 14y ago
    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 http://bit.ly/GFfpdk
- MattRogish 14y ago
  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."
  - tptacek 14y ago
    I'm pretty sure your actual bcrypted password doesn't have that cost factor on it.
    - AgentConundrum 14y ago
      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.
    - MattRogish 14y ago
      That's how rails stores it in the database, so trying to be as transparent as possible.
      - tptacek 14y ago
        It takes 3 minutes to log into your application?
        MattRogish 14y ago
        You are absolutely right. This is not our production app (ours is at 12 IIRC) but some internals app I've been playing with.
        14y ago
- lhazlewood 14y ago
  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.
  - tptacek 14y ago
    You feel that you're protecting password hashes from government sponsored attackers, and yet you're iterating SHA2 as your password hash?
    - lhazlewood 14y ago
      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).
  - amalcon 14y ago
    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.
- Retric 14y ago
  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.
  - peterwwillis 14y ago
    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.
    - Retric 14y ago
      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.
      - peterwwillis 14y ago
        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.
      - tptacek 14y ago
        If there's some place you can put salts where attackers can't get them, I advise you to put your passwords there too.
        Retric 14y ago
        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.
sixothree 14y ago
The hey girl crap needs to end. Now.
jgrahamc 14y ago
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.
- lhazlewood 14y ago
  Great questions. With regard to CSPNG, this SO post answer is good: http://stackoverflow.com/questions/536584/non-random-salt-for-password-hashes 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.
  - tptacek 14y ago
codegeek 14y ago
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.
strictfp 14y ago
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.
- chunsaker 14y ago
  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/ http://blog.cloudpassage.com/) that I think is really well informed, and we're going to do a followup on backend security.
bruceboughton 14y ago
Too offensive;didn't read
asalazar 14y ago
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?
tzs 14y ago
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.
- stan_rogers 14y ago
  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.)
peterwwillis 14y ago
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.
- tptacek 14y ago
  You don't need to disable CBC ciphersuites. Implementing DNSSEC and IPv6 will do approximately zero for your security, too.
  - peterwwillis 14y ago
    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.
cookingrobot 14y ago
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.

40 points by chunsaker 14y ago

deleted 14y ago

[deleted]

No. http://codahale.com/how-to-safely-store-a-password/ 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.

chunsaker 14y ago
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-shiro 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?"
- tptacek 14y ago
  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.
  - chunsaker 14y ago
    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.
    - tptacek 14y ago
      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.
    - mikeash 14y ago
      At what point does he attribute any unicorn-like properties to bcrypt? All he says is that SHA2 is worse, which is completely true.
- asalazar 14y ago
  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 http://bit.ly/GFfpdk
MattRogish 14y ago
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."
- tptacek 14y ago
  I'm pretty sure your actual bcrypted password doesn't have that cost factor on it.
  - AgentConundrum 14y ago
    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.
  - MattRogish 14y ago
    That's how rails stores it in the database, so trying to be as transparent as possible.
    - tptacek 14y ago
      It takes 3 minutes to log into your application?
      - MattRogish 14y ago
        You are absolutely right. This is not our production app (ours is at 12 IIRC) but some internals app I've been playing with.
        14y ago
lhazlewood 14y ago
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.
- tptacek 14y ago
  You feel that you're protecting password hashes from government sponsored attackers, and yet you're iterating SHA2 as your password hash?
  - lhazlewood 14y ago
    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).
- amalcon 14y ago
  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.
Retric 14y ago
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.
- peterwwillis 14y ago
  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.
  - Retric 14y ago
    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.
    - peterwwillis 14y ago
      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.
    - tptacek 14y ago
      If there's some place you can put salts where attackers can't get them, I advise you to put your passwords there too.
      - Retric 14y ago
        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.

sixothree 14y ago

The hey girl crap needs to end. Now.

jgrahamc 14y ago

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.

lhazlewood 14y ago
Great questions. With regard to CSPNG, this SO post answer is good: http://stackoverflow.com/questions/536584/non-random-salt-for-password-hashes 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.
- tptacek 14y ago

codegeek 14y ago

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.

strictfp 14y ago

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.

chunsaker 14y ago
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/ http://blog.cloudpassage.com/) that I think is really well informed, and we're going to do a followup on backend security.

bruceboughton 14y ago

Too offensive;didn't read

asalazar 14y ago

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?

tzs 14y ago

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.

stan_rogers 14y ago
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.)

peterwwillis 14y ago

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.

tptacek 14y ago
You don't need to disable CBC ciphersuites. Implementing DNSSEC and IPv6 will do approximately zero for your security, too.
- peterwwillis 14y ago
  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.

cookingrobot 14y ago

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.