5 ms·

Where to store the salt is that's where the real problem is. It doesn't really matter how much encryption and hashing we throw at anything if everything is sto

by donpark 15y ago

Where to store the salt is that's where the real problem is. It doesn't really matter how much encryption and hashing we throw at anything if everything is stored on the same server. What's the point of salt if salt is in plain sight? What's the point of asking users to verify hash of downloadable files when hash is stored along side the file itself? What's the point of cryptography when code points straight to all that's necessary to dispell the protection? Ultimate shame is that we still lack the necessary infrastructure for minimum level of security despite all the cloud-related hype, leaving each server to stand-alone which is no security at all.

judofyr 15y ago
> What's the point of salt if salt is in plain sight? If you by "plain sight" mean "the same place as the hash" you're misunderstanding what the salt is for. If you want to access X servers in order to verify a password, you don't need a salt; you just split the hash in X parts and store each on different servers. Salts are for preventing rainbow tables.
- donpark 15y ago
  It doesn't matter if the hash is split into X parts and stored on X servers. We are not talking about Humpty Dumpty here and salt-specific rainbow tables can be built on-demand as long as the reward justifies the time and expense.
  - mistercow 15y ago
    Of course they can, but the point is that the time and expense is massively increased. Building a rainbow table to run against each separately salted account is way more work than building a single rainbow table and cross referencing it with a giant list of hashes to find some collisions. In general "as long as the reward justifies the time and expense" can be said about any security measure. Salting has another benefit too: it makes it virtually useless to find a mere password collision. Say, for example that I use two sites, Spacelook and Squitter, which both use a popular hash called SPARTACUS for their passwords. My password on both sites is "abracadabraSpanishFly_92@prosperity;". An attacker gets into Spacelook's database and does a cross reference with their SPARTACUS rainbow table. I happen to be very unlucky and my nice strong password has a SPARTACUS collision with the very short "a2e34". Now the attacker goes to Squitter, puts in my username and "a2e34" and logs in with no problem even though that's not my password. Now, suppose that Spacelook and Squitter had each used a different per-site salt (not good enough, but better) when they hashed my password, and this time suppose the attacker builds a custom rainbow table for Spacelook's salt and finds that my salted password collides with salted "fr-_9x32;". If they go to Squitter and try to log in with "fr-_9x32;", Squitter's use of a different salt will cause it to hash differently than my password, and so only my Spacelook account will have been compromised.
    - donpark 15y ago
      Yes, user-specific salt does raise the cost but given the usual length and complexity of passwords in-use IRL, raise is not massive enough for high security servers. Besides, the point of my original comment was the problem of placing everything in the same basket which includes the code used to hash passwords and files. How would you protect them?
  - IsTom 15y ago
    Salt should be user-specific, requiring construction of many rainbow tables turning this kind of attack ineffective.
  - deleted 15y ago
    [deleted]
  - judofyr 15y ago
    > rainbow tables can be built on-demand That's what we call bruteforce…
dpark 15y ago
> What's the point of salt if salt is in plain sight? To prevent rainbow tables and to increase attack complexity. And to prevent someone who sees a hash from being able to drop it into a search engine and get the password (works for unsalted common passwords). The point of salt has never been secrecy. > What's the point of asking users to verify hash of downloadable files when hash is stored along side the file itself? To verify data integrity. It isn't an question of security, or they would be signed properly. > What's the point of cryptography when code points straight to all that's necessary to dispell the protection? I have no idea what you're talking about. > Ultimate shame is that we still lack the necessary infrastructure for minimum level of security despite all the cloud-related hype, leaving each server to stand-alone which is no security at all. Still no idea what you're talking about.
- donpark 15y ago
  Your answers make sense in the context of servers for websites with low security needs, where privacy is of higher concern than security. They do not make sense for servers with high security needs.
  - dpark 15y ago
    I'm sorry, but you are simply incorrect. Salt is not a piece of secret data. Period. That was never the intention of salt, and it still is not. Secrecy of the salt does not improve its usefulness. As for the download hash, this has nothing to do with security at all, as I already said.
    - donpark 15y ago
      Re salt, please see project-rainbowcrack.com as an example of CUDA-driven hash cracking. Re download hash, I think we disagree on what data integrity means. By data integrity, I mean trustworthiness which implies security, meaning file content hasn't been modified in-storage or in-transit. I'm guessing you are using those words to mean protection against transport-errors or typos (credit card entry) for which checksum is commonly used. Given that HTTP is still the most common transport for file download and it's a reliable transport, file-hashing for transport-errors detection is I think meaningless. I know some browsers failed to report errors but comparing length is typically suffice to catch this. That leaves only file-hashing as protection against tempering in-storage or in-transit which is why I am saying it's security-related. Keyed-hashing can mediate but, unfortunately, is not commonly used as it requires PKI.

by donpark 15y ago

judofyr 15y ago

> What's the point of salt if salt is in plain sight? If you by "plain sight" mean "the same place as the hash" you're misunderstanding what the salt is for. If you want to access X servers in order to verify a password, you don't need a salt; you just split the hash in X parts and store each on different servers. Salts are for preventing rainbow tables.

donpark 15y ago
It doesn't matter if the hash is split into X parts and stored on X servers. We are not talking about Humpty Dumpty here and salt-specific rainbow tables can be built on-demand as long as the reward justifies the time and expense.
- mistercow 15y ago
  Of course they can, but the point is that the time and expense is massively increased. Building a rainbow table to run against each separately salted account is way more work than building a single rainbow table and cross referencing it with a giant list of hashes to find some collisions. In general "as long as the reward justifies the time and expense" can be said about any security measure. Salting has another benefit too: it makes it virtually useless to find a mere password collision. Say, for example that I use two sites, Spacelook and Squitter, which both use a popular hash called SPARTACUS for their passwords. My password on both sites is "abracadabraSpanishFly_92@prosperity;". An attacker gets into Spacelook's database and does a cross reference with their SPARTACUS rainbow table. I happen to be very unlucky and my nice strong password has a SPARTACUS collision with the very short "a2e34". Now the attacker goes to Squitter, puts in my username and "a2e34" and logs in with no problem even though that's not my password. Now, suppose that Spacelook and Squitter had each used a different per-site salt (not good enough, but better) when they hashed my password, and this time suppose the attacker builds a custom rainbow table for Spacelook's salt and finds that my salted password collides with salted "fr-_9x32;". If they go to Squitter and try to log in with "fr-_9x32;", Squitter's use of a different salt will cause it to hash differently than my password, and so only my Spacelook account will have been compromised.
  - donpark 15y ago
    Yes, user-specific salt does raise the cost but given the usual length and complexity of passwords in-use IRL, raise is not massive enough for high security servers. Besides, the point of my original comment was the problem of placing everything in the same basket which includes the code used to hash passwords and files. How would you protect them?
- IsTom 15y ago
  Salt should be user-specific, requiring construction of many rainbow tables turning this kind of attack ineffective.
- deleted 15y ago
  [deleted]
- judofyr 15y ago
  > rainbow tables can be built on-demand That's what we call bruteforce…

dpark 15y ago

> What's the point of salt if salt is in plain sight? To prevent rainbow tables and to increase attack complexity. And to prevent someone who sees a hash from being able to drop it into a search engine and get the password (works for unsalted common passwords). The point of salt has never been secrecy. > What's the point of asking users to verify hash of downloadable files when hash is stored along side the file itself? To verify data integrity. It isn't an question of security, or they would be signed properly. > What's the point of cryptography when code points straight to all that's necessary to dispell the protection? I have no idea what you're talking about. > Ultimate shame is that we still lack the necessary infrastructure for minimum level of security despite all the cloud-related hype, leaving each server to stand-alone which is no security at all. Still no idea what you're talking about.

donpark 15y ago
Your answers make sense in the context of servers for websites with low security needs, where privacy is of higher concern than security. They do not make sense for servers with high security needs.
- dpark 15y ago
  I'm sorry, but you are simply incorrect. Salt is not a piece of secret data. Period. That was never the intention of salt, and it still is not. Secrecy of the salt does not improve its usefulness. As for the download hash, this has nothing to do with security at all, as I already said.
  - donpark 15y ago
    Re salt, please see project-rainbowcrack.com as an example of CUDA-driven hash cracking. Re download hash, I think we disagree on what data integrity means. By data integrity, I mean trustworthiness which implies security, meaning file content hasn't been modified in-storage or in-transit. I'm guessing you are using those words to mean protection against transport-errors or typos (credit card entry) for which checksum is commonly used. Given that HTTP is still the most common transport for file download and it's a reliable transport, file-hashing for transport-errors detection is I think meaningless. I know some browsers failed to report errors but comparing length is typically suffice to catch this. That leaves only file-hashing as protection against tempering in-storage or in-transit which is why I am saying it's security-related. Keyed-hashing can mediate but, unfortunately, is not commonly used as it requires PKI.