4 ms·

I agree. One of our big financial clients has an automated tool to scrub such data, but then they have social security numbers as well as lots of other juicy fi

I agree. One of our big financial clients has an automated tool to scrub such data, but then they have social security numbers as well as lots of other juicy financial data. So they're worried about all sorts of stuff that most of us never ponder as a business risk. One of the santizing steps is to replace all passwords with a set value, such as six/seven of a letter (like "A") or a number (eg, "111111"). Another sanitizing step is to scramble names and addresses. Usually the first letter gets preserved, and the rest gets replaced with a hash (say, MD5 it, and then base64 it and truncate it to length, that way it preserves max lengths and typical size of words). example: John Doe, 1313 Mockingbird Lane might get munged into Jiqw Dyh, 1313 Masdfasdfas Lfds We just have username/password/address/phone, so all we do is set all passwords to a default value (all emails, if any, get set to mine), and munge up telephone numbers. Later this year I'll cobble up a better sanitizer. Our parent company has to worry about GLBA compliance, but our little apps don't "collect" enough information to worry about GLBA at this time.

timf 18y ago
> replace all passwords with a set value They're storing passwords directly and not hashes? Wish I could ask you which company so I could avoid them...
- timf 18y ago
  Downvote all you want but I would seriously like to know. http://www.matasano.com/log/958/enough-with-the-rainbow-tables-what-you-need-to-know-about-secure-password-schemes/ http://www.matasano.com/log/958/enough-with-the-rainbow-tabl...
  - Tangurena 18y ago
    I guess I wasn't clear enough. The "user" tables get updated so that the password used to log in will be "111111" or such, and that means all the salts and hashes will be the same value.
    - timf 18y ago
      Oh OK, sorry for the tangent.
- inerte 18y ago
  Who said they're storing passwords in plain text? They could be paranoid enough to remove hashed passwords. If you know what makes the hash you can reproduce. If it's a database with financial information, I can see crackers devoting time to do this, making their rainbow tables and botnets or whatever to guess the passwords.
- sho 18y ago
  I don't understand this obsession about only storing hashes, as if that's the primary critical issue with site security. There are plenty of reasons to store the plaintext, and in a well secured database I really don't think it is much of an issue. Or as I heard someone say once, "If you can break into my database, and show me how, I will quite literally give you a million dollars". Off the top of my head, here's a couple of very good reasons to store plaintext: - password recoverability: if the user knows they can recover the password, they're more likely to use a more complex one - flexibility with authentication: to use something like HTTP Digest Auth, you need the plaintext to be able to hash it with a one-time nonce And like many will no doubt point out, hashing it isn't all THAT secure anyway. If it's not a very strong hash, or there's enough information to reset it somehow, they can get what they want anyway. Not to mention that if your database has been cracked they probably have everything they want anyway - why even bother logging in? I just don't get it. Sure, defence in depth is the best strategy and everyone should practise it whereever possible. But whether the password is stored hashed or not is not the lynchpin security issue many make it out to be, IMO.
  - timf 18y ago
    "obsession about only storing hashes, as if that's the primary critical issue with site security" Can you point me to something I said that implies this is an obsession or that this is what I think the primary critical issue is with site security? " password recoverability: if the user knows they can recover the password, they're more likely to use a more complex one" Why would I as a user care at all if I could retrieve the actual value of a complex password -- and why would knowing I could recover it make me then choose a more complex one? (The user should be given an option of resetting the password via a link sent by email. Sending passwords themselves over email is a great way to have it revealed for someone else to use later.) "to use something like HTTP Digest Auth" Good thing no one needs this mediocre authentication method if SSL is available. The majority of people use the same passwords at different sites. So even if someone's cracked your database, it's still a good idea. Storing passwords in plaintext is a non-neighborly thing to do.
    - sho 18y ago

timf 18y ago

> replace all passwords with a set value They're storing passwords directly and not hashes? Wish I could ask you which company so I could avoid them...

timf 18y ago
Downvote all you want but I would seriously like to know. http://www.matasano.com/log/958/enough-with-the-rainbow-tables-what-you-need-to-know-about-secure-password-schemes/ http://www.matasano.com/log/958/enough-with-the-rainbow-tabl...
- Tangurena 18y ago
  I guess I wasn't clear enough. The "user" tables get updated so that the password used to log in will be "111111" or such, and that means all the salts and hashes will be the same value.
  - timf 18y ago
    Oh OK, sorry for the tangent.
inerte 18y ago
Who said they're storing passwords in plain text? They could be paranoid enough to remove hashed passwords. If you know what makes the hash you can reproduce. If it's a database with financial information, I can see crackers devoting time to do this, making their rainbow tables and botnets or whatever to guess the passwords.
sho 18y ago
I don't understand this obsession about only storing hashes, as if that's the primary critical issue with site security. There are plenty of reasons to store the plaintext, and in a well secured database I really don't think it is much of an issue. Or as I heard someone say once, "If you can break into my database, and show me how, I will quite literally give you a million dollars". Off the top of my head, here's a couple of very good reasons to store plaintext: - password recoverability: if the user knows they can recover the password, they're more likely to use a more complex one - flexibility with authentication: to use something like HTTP Digest Auth, you need the plaintext to be able to hash it with a one-time nonce And like many will no doubt point out, hashing it isn't all THAT secure anyway. If it's not a very strong hash, or there's enough information to reset it somehow, they can get what they want anyway. Not to mention that if your database has been cracked they probably have everything they want anyway - why even bother logging in? I just don't get it. Sure, defence in depth is the best strategy and everyone should practise it whereever possible. But whether the password is stored hashed or not is not the lynchpin security issue many make it out to be, IMO.
- timf 18y ago
  "obsession about only storing hashes, as if that's the primary critical issue with site security" Can you point me to something I said that implies this is an obsession or that this is what I think the primary critical issue is with site security? " password recoverability: if the user knows they can recover the password, they're more likely to use a more complex one" Why would I as a user care at all if I could retrieve the actual value of a complex password -- and why would knowing I could recover it make me then choose a more complex one? (The user should be given an option of resetting the password via a link sent by email. Sending passwords themselves over email is a great way to have it revealed for someone else to use later.) "to use something like HTTP Digest Auth" Good thing no one needs this mediocre authentication method if SSL is available. The majority of people use the same passwords at different sites. So even if someone's cracked your database, it's still a good idea. Storing passwords in plaintext is a non-neighborly thing to do.
  - sho 18y ago