4 ms·

Salts might be 100 characters in length. It could be a book. It could be a jpeg. Examples - https://api.wordpress.org/secret-key/1.1/salt/ https://api.wordpre

Salts might be 100 characters in length. It could be a book. It could be a jpeg. Examples - https://api.wordpress.org/secret-key/1.1/salt/ https://api.wordpress.org/secret-key/1.1/salt/ No rainbow table will contain those. bEanx actually works pretty as a fine salt, it wrecks Rainbow tables. But just like comments people understand salts more if they look complicated. Check out this https://rsheasby.medium.com/rainbow-tables-probably-arent-what-you-think-30f8a61ba6a5 https://rsheasby.medium.com/rainbow-tables-probably-arent-wh... It explains Rainbow Tables != Lookup Tables

thaumasiotes 5y ago
> Check out this [...] It explains Rainbow Tables != Lookup Tables It explains that rainbow tables are lookup tables which use a clever method to reduce their enormous storage requirements by increasing the lookup time. That doesn't make them any less lookup tables. > Salts might be 100 characters in length. Absolutely. But in that case, the rainbow table would be having trouble with the length of the (salted) password, not with the fact that a salt exists. I will stipulate that a salt will automatically add extra resistance to rainbow tables (compared to no salt) while not adding any inconvenience to the user who has to enter their password. But in the context of a password security policy, what you're getting there is added convenience, not added security. > It could be a book. Probably not; the salt has to be stored on a per-user basis. > bEanx actually works pretty as a fine salt, it wrecks Rainbow tables. Only to the extent that it makes the password longer. There is no theoretical difficulty that salts cause for rainbow tables.
- lupire 5y ago
  You're weirdly nitpicking. Making a password longer by salting it makes a short password harder to crack, because you are less likely to have the salted password in your table that is full of dictionary words and previously hacked passwords with different salts.
  - thaumasiotes 5y ago
    > Making a password longer by salting it makes a short password harder to crack, because you are less likely to have the salted password in your table This is true if you're using a table, which password-cracking attacks don't do. It's not true if you use the actual password-cracking approach of guessing what the password is and then checking whether you were right. The salt doesn't impede that in any way.
- aaron695 5y ago
  'bEanx' in practice destroys every rainbow table in existence. It's on the line probabilisticly, so I can't make a harder statement, but 20 characters (which takes the programmer 2 more seconds to smash in) takes us to computers the size of the earth conversation which ok you win, it is possible :) > the salt has to be stored on a per-user basis. That's of no use to stop Rainbow tables. One salt across the site is fine to destroy or not destroy Rainbow tables. Either 'bEanx' or “For Sale: Baby shoes, never worn.” will work fine commonly used on all passwords. A common salt is not great for brute force though, but that's a different topic.
  - thaumasiotes 5y ago
    > 'bEanx' in practice destroys every rainbow table in existence. Yes, as your link (well, part 2) notes, publicly available rainbow tables are available up to 8 mixed-case characters or 10 lowercase characters. Salting with "2" is sufficient to avoid them. That is because rainbow tables cannot practically attack long passwords. >> the salt has to be stored on a per-user basis. > That's of no use to stop Rainbow tables. I didn't say it was. It's a requirement of salting. Salting is unrelated to rainbow tables. Instead, it defends against comparing one user's hashed password to a second user's hashed password, which I assume is what you're referring to when you say "not great for brute force". All I said here was that the salt is unlikely to be a book, because that imposes a very large per-user storage burden.
    - aaron695 5y ago
      > That is because rainbow tables cannot practically attack long passwords. It's trivial to create a rainbow table that attacks passphrases. This statement is wrong. You example 1000102772901 is easily within rainbow tables. Trivially so, it's worse than a passphrase. > it defends against comparing one user's hashed password to a second user's hashed password, This has zero value. I can only suggest you do a course on hash functions on Coursera, the mathematics is somewhat easy and interesting to know. It's fun to follow up with a Blockchain course also has very interesting mathematics around hash functions, I really enjoyed this. I can't suggest which, the one I did isn't available, but check Google reviews there's a few out there.

thaumasiotes 5y ago

> Check out this [...] It explains Rainbow Tables != Lookup Tables It explains that rainbow tables are lookup tables which use a clever method to reduce their enormous storage requirements by increasing the lookup time. That doesn't make them any less lookup tables. > Salts might be 100 characters in length. Absolutely. But in that case, the rainbow table would be having trouble with the length of the (salted) password, not with the fact that a salt exists. I will stipulate that a salt will automatically add extra resistance to rainbow tables (compared to no salt) while not adding any inconvenience to the user who has to enter their password. But in the context of a password security policy, what you're getting there is added convenience, not added security. > It could be a book. Probably not; the salt has to be stored on a per-user basis. > bEanx actually works pretty as a fine salt, it wrecks Rainbow tables. Only to the extent that it makes the password longer. There is no theoretical difficulty that salts cause for rainbow tables.

lupire 5y ago
You're weirdly nitpicking. Making a password longer by salting it makes a short password harder to crack, because you are less likely to have the salted password in your table that is full of dictionary words and previously hacked passwords with different salts.
- thaumasiotes 5y ago
  > Making a password longer by salting it makes a short password harder to crack, because you are less likely to have the salted password in your table This is true if you're using a table, which password-cracking attacks don't do. It's not true if you use the actual password-cracking approach of guessing what the password is and then checking whether you were right. The salt doesn't impede that in any way.
aaron695 5y ago
'bEanx' in practice destroys every rainbow table in existence. It's on the line probabilisticly, so I can't make a harder statement, but 20 characters (which takes the programmer 2 more seconds to smash in) takes us to computers the size of the earth conversation which ok you win, it is possible :) > the salt has to be stored on a per-user basis. That's of no use to stop Rainbow tables. One salt across the site is fine to destroy or not destroy Rainbow tables. Either 'bEanx' or “For Sale: Baby shoes, never worn.” will work fine commonly used on all passwords. A common salt is not great for brute force though, but that's a different topic.
- thaumasiotes 5y ago
  > 'bEanx' in practice destroys every rainbow table in existence. Yes, as your link (well, part 2) notes, publicly available rainbow tables are available up to 8 mixed-case characters or 10 lowercase characters. Salting with "2" is sufficient to avoid them. That is because rainbow tables cannot practically attack long passwords. >> the salt has to be stored on a per-user basis. > That's of no use to stop Rainbow tables. I didn't say it was. It's a requirement of salting. Salting is unrelated to rainbow tables. Instead, it defends against comparing one user's hashed password to a second user's hashed password, which I assume is what you're referring to when you say "not great for brute force". All I said here was that the salt is unlikely to be a book, because that imposes a very large per-user storage burden.
  - aaron695 5y ago
    > That is because rainbow tables cannot practically attack long passwords. It's trivial to create a rainbow table that attacks passphrases. This statement is wrong. You example 1000102772901 is easily within rainbow tables. Trivially so, it's worse than a passphrase. > it defends against comparing one user's hashed password to a second user's hashed password, This has zero value. I can only suggest you do a course on hash functions on Coursera, the mathematics is somewhat easy and interesting to know. It's fun to follow up with a Blockchain course also has very interesting mathematics around hash functions, I really enjoyed this. I can't suggest which, the one I did isn't available, but check Google reviews there's a few out there.