3 ms·

Salt length and hash speed are orthogonal. Increasing the length of your nonces doesn't make your passwords less crackable. If this is news to you, don't design

Salt length and hash speed are orthogonal. Increasing the length of your nonces doesn't make your passwords less crackable. If this is news to you, don't design your own password scheme; use someone else's good one, so you aren't accidentally exposing people's bank accounts.

aston 19y ago
Increasing the length of the nonce definitely makes the password less crackable. Since brute force methods search the entire space, the more space, the better. It's still possible to crack in by finding a hash collision, but the longer your non-password trash, the harder it is to recover the password via brute force.
- thomasptacek 19y ago
  All due respect, but you shouldn't be designing password schemes. Modern password schemes are cracked using incremental crackers. This "rainbow table" stuff has totally confused the developer community. John the Ripper doesn't make a time/space tradeoff; it uses the (public) salt and the hash and iteratively recomputes hashes, and it is terrifyingly fast even on good password schemes.
  - aston 19y ago
    That's one attack vector. Assuming someone does attempt to use a brute force method, longer salts do matter. I think that qualifies as non-orthogonal to "crackability," even if orthogonal in some cases. Truthfully, this isn't even worth talking about. If your user's passwords are compromised, you've already lost the security battle. Hopefully you weren't actually storing something important.
    - thomasptacek 19y ago
      That's horribly irresponsible. Using your logic, you might as well just store the passwords in plaintext. Most people don't use different passwords for different applications, and your web application is inevitably going to expose all your users passwords, like every other web app that has been SQL-injectable (ie, almost all of them).
      - aston 19y ago
        As a person interested in security, you're well-familiar with the fact that nothing is 100% secure. Choosing a less secure option over a more secure one is not tantamount to choosing no security at all. That said, I personally don't mind plaintext passwords if there's a good usability story that goes along with it and if the security tradeoff is negligible. I put the odds of my user database being exposed at approximately zero, so generally it's a fine design decision. When was the last time you heard of passwords being stolen en masse from a major site that didn't also include a hard drive being stolen?
        thomasptacek 19y ago
        As a person who spends 3-4 days a week assessing other people's web apps, I'm well-familiar with the fact that it's a very good bet that everyone's web app is SQL-injectable, whether they've tried to stop that attack or not. For example, do you know how internationalization works? I have no idea why you think the public is told every time a a password table is dumped. In fact, change that "every" to "any". Here, let me make this easier for you: if you ever plan to monetize your application, you will fail PCI audits for doing a crappy job with password storage. But I'll do you one better and give you a tip from the trenches: if some lame PCI auditor sees that you don't know what you are doing, his company is going to roll you for 8 billable weeks, laughing at you the whole time, before they give you the meaningless stamp of approval that lets your process credit cards.
        nostrademons 19y ago
        So where's the best-practices security checklist? I'm not a security expert. I write webapps. I'm open to learning new techniques and using other people's libraries. However, I need to balance that against the need to get something out the door. As mynameishere put it, I'd love to have a website that's even worth breaking in to. If there's some sort of tutorial out there that says "For passwords, use this library. For SQL injection, escape your parameters with this procedure. Here's how to secure your server from being rooted. Add these lines to your mailserver's config to avoid being used as a spam vector", I'd love to read it.
  - jsjenkins168 19y ago
    Whether the attack is brute force or a time/space trade-off, longer salts increase addressable space which increases time or space required to achieve a collision. It doesn't matter how you're doing it, this is a simple fact. A larger key is always more secure.
    - thomasptacek 19y ago
      The salt is public. If you have the password table, you have the salt. The attacker doesn't have to guess the salt with an incremental password cracker (read: almost any password cracker). The mistake you're making is your misuse of the word "key". Larger keys are more secure. A salt is a nonce, not a key. Can I say again that people shouldn't be rolling their own password scheme? This is a problem that has been well-addressed for decades, but the majority of new applications still ship with code that is inferior to public domain code from 1976.
      - deleted 19y ago
        [deleted]
        thomasptacek 19y ago
        Your hash function needs to be slow, so that incremental cracking is infeasable. This is much more important than the length of your salt. No offense, but you should read the articles you comment on.
        deleted 19y ago
        [deleted]
        thomasptacek 19y ago
        Seriously, all three of the articles you're implicitly commenting on answer this question directly.
      - deleted 19y ago
        [deleted]
deleted 19y ago
[deleted]
brlewis 19y ago
Are you saying that nobody uses hash dictionaries anymore and one need only worry about brute-forcing of individual passwords? I'm not ready to stop thinking about hash dictionaries, and the 4-character salt I prepend to passwords before hashing is too short. A 4-character salt plus a 7-character password is a value that could be vulnerable to dictionaries roughly the size of the Rainbow tables. But if you can cite a paper demonstrating that brute-force cracks of individual passwords are the only thing one need be concerned about, I'll look at it and see if it changes my mind.
- thomasptacek 19y ago
  Nobody is saying you don't need to use salted passwords. What we're saying is, if your password scheme is (user, nonce, SHA1(nonce, password)), don't bother; just store your passwords in plaintext. Your users passwords are so weak (dictionary word + number) that a 200 line incremental cracker is going to blaze through it in hours. The answer to this is to use someone else's (good) password scheme. If you're shipping on Unix, your system undoubtedly comes with one. Use it.
  - brlewis 19y ago
    If you mean to say that users should be forced to choose strong passwords, that's a different thing from saying longer salts don't make a set of passwords less crackable.
    - thomasptacek 19y ago
      I don't understand why people are hyper-focusing on this one attack. Attackers have been cracking passwords, quite effectively, long before tools like Ophcrack were available. Any decent salt scheme beats Ophcrack; it doesn't take much to make hash chain storage infeasible. But you can make your salts longer than JSESSIONID's and they still won't be a speed bump to a "conventional" password cracker. I'm not arguing that users should be forced to choose secure passwords. They should, of course, but we're talking about how you store them. If you store them using a single-iteration SHA1 hash, then no matter how you structure your nonces, your scheme is insecure and you should be embarassed.

aston 19y ago

Increasing the length of the nonce definitely makes the password less crackable. Since brute force methods search the entire space, the more space, the better. It's still possible to crack in by finding a hash collision, but the longer your non-password trash, the harder it is to recover the password via brute force.

thomasptacek 19y ago
All due respect, but you shouldn't be designing password schemes. Modern password schemes are cracked using incremental crackers. This "rainbow table" stuff has totally confused the developer community. John the Ripper doesn't make a time/space tradeoff; it uses the (public) salt and the hash and iteratively recomputes hashes, and it is terrifyingly fast even on good password schemes.
- aston 19y ago
  That's one attack vector. Assuming someone does attempt to use a brute force method, longer salts do matter. I think that qualifies as non-orthogonal to "crackability," even if orthogonal in some cases. Truthfully, this isn't even worth talking about. If your user's passwords are compromised, you've already lost the security battle. Hopefully you weren't actually storing something important.
  - thomasptacek 19y ago
    That's horribly irresponsible. Using your logic, you might as well just store the passwords in plaintext. Most people don't use different passwords for different applications, and your web application is inevitably going to expose all your users passwords, like every other web app that has been SQL-injectable (ie, almost all of them).
    - aston 19y ago
      As a person interested in security, you're well-familiar with the fact that nothing is 100% secure. Choosing a less secure option over a more secure one is not tantamount to choosing no security at all. That said, I personally don't mind plaintext passwords if there's a good usability story that goes along with it and if the security tradeoff is negligible. I put the odds of my user database being exposed at approximately zero, so generally it's a fine design decision. When was the last time you heard of passwords being stolen en masse from a major site that didn't also include a hard drive being stolen?
      - thomasptacek 19y ago
        As a person who spends 3-4 days a week assessing other people's web apps, I'm well-familiar with the fact that it's a very good bet that everyone's web app is SQL-injectable, whether they've tried to stop that attack or not. For example, do you know how internationalization works? I have no idea why you think the public is told every time a a password table is dumped. In fact, change that "every" to "any". Here, let me make this easier for you: if you ever plan to monetize your application, you will fail PCI audits for doing a crappy job with password storage. But I'll do you one better and give you a tip from the trenches: if some lame PCI auditor sees that you don't know what you are doing, his company is going to roll you for 8 billable weeks, laughing at you the whole time, before they give you the meaningless stamp of approval that lets your process credit cards.
        nostrademons 19y ago
        So where's the best-practices security checklist? I'm not a security expert. I write webapps. I'm open to learning new techniques and using other people's libraries. However, I need to balance that against the need to get something out the door. As mynameishere put it, I'd love to have a website that's even worth breaking in to. If there's some sort of tutorial out there that says "For passwords, use this library. For SQL injection, escape your parameters with this procedure. Here's how to secure your server from being rooted. Add these lines to your mailserver's config to avoid being used as a spam vector", I'd love to read it.
- jsjenkins168 19y ago
  Whether the attack is brute force or a time/space trade-off, longer salts increase addressable space which increases time or space required to achieve a collision. It doesn't matter how you're doing it, this is a simple fact. A larger key is always more secure.
  - thomasptacek 19y ago
    The salt is public. If you have the password table, you have the salt. The attacker doesn't have to guess the salt with an incremental password cracker (read: almost any password cracker). The mistake you're making is your misuse of the word "key". Larger keys are more secure. A salt is a nonce, not a key. Can I say again that people shouldn't be rolling their own password scheme? This is a problem that has been well-addressed for decades, but the majority of new applications still ship with code that is inferior to public domain code from 1976.
    - deleted 19y ago
      [deleted]
      - thomasptacek 19y ago
        Your hash function needs to be slow, so that incremental cracking is infeasable. This is much more important than the length of your salt. No offense, but you should read the articles you comment on.
        deleted 19y ago
        [deleted]
        thomasptacek 19y ago
        Seriously, all three of the articles you're implicitly commenting on answer this question directly.
    - deleted 19y ago
      [deleted]

deleted 19y ago

[deleted]

brlewis 19y ago

Are you saying that nobody uses hash dictionaries anymore and one need only worry about brute-forcing of individual passwords? I'm not ready to stop thinking about hash dictionaries, and the 4-character salt I prepend to passwords before hashing is too short. A 4-character salt plus a 7-character password is a value that could be vulnerable to dictionaries roughly the size of the Rainbow tables. But if you can cite a paper demonstrating that brute-force cracks of individual passwords are the only thing one need be concerned about, I'll look at it and see if it changes my mind.

thomasptacek 19y ago
Nobody is saying you don't need to use salted passwords. What we're saying is, if your password scheme is (user, nonce, SHA1(nonce, password)), don't bother; just store your passwords in plaintext. Your users passwords are so weak (dictionary word + number) that a 200 line incremental cracker is going to blaze through it in hours. The answer to this is to use someone else's (good) password scheme. If you're shipping on Unix, your system undoubtedly comes with one. Use it.
- brlewis 19y ago
  If you mean to say that users should be forced to choose strong passwords, that's a different thing from saying longer salts don't make a set of passwords less crackable.
  - thomasptacek 19y ago
    I don't understand why people are hyper-focusing on this one attack. Attackers have been cracking passwords, quite effectively, long before tools like Ophcrack were available. Any decent salt scheme beats Ophcrack; it doesn't take much to make hash chain storage infeasible. But you can make your salts longer than JSESSIONID's and they still won't be a speed bump to a "conventional" password cracker. I'm not arguing that users should be forced to choose secure passwords. They should, of course, but we're talking about how you store them. If you store them using a single-iteration SHA1 hash, then no matter how you structure your nonces, your scheme is insecure and you should be embarassed.