10 ms·

This is so relevant. Just 10 mins ago, I got a short, casual, no-reply email from Teachable about an email & passwords breach. If you're a startup and you're s

by curo 8y ago

This is so relevant. Just 10 mins ago, I got a short, casual, no-reply email from Teachable about an email & passwords breach. If you're a startup and you're storing plaintext passwords out of expediency, realize you're doing a massive disservice to your customers. It seems they changed this in 2015, but didn't go back and fix it for their earliest adopters. Your early adopters make you what you are! Protect their data. And if you do mess up, don't send out a self-focused apology from a no-reply address. We are writing to inform you of a suspected data breach involving accounts created between September 17, 2013 and November 21, 2015. We have reason to suspect that personal information related to accounts on Bitfountain (joined 2014-08-18) may have been compromised. This includes the email addresses and passwords associated with the school's Teachable (formerly Fedora) account. As a precaution we are enforcing password resets...If you happen to use this password with any other service, we highly recommend updating your password there as well. We apologize for the inconvenience, and thank you for your understanding in helping us keep Teachable safe.

pc86 8y ago
Storing plaintext passwords is no faster than storing a cryptographically secure hash of the same password. We're not even talking lines of extra code, just a few extra characters actually hash the input. It's not expediency, it's laziness bordering on criminal stupidity/negligence.
- hamandcheese 8y ago
  Or maybe just ignorance?
  - pc86 8y ago
    Protecting a user's password is such a basic level of understanding I think ignorance falls under "criminal stupidity" for this one.
  - dragonwriter 8y ago
    Ignorance of facts that any reasonable exploration of best practices in the area you are working in would reveal, in a commercial venture, is a product of laziness (or hubris) bordering on (or crossing into) negligence.
- jmeyer2k 8y ago
  Well it should be faster than storing a cryptographically secure hash. If hashing the data is too fast, an attacker could just brute force all of the passwords.
  - kingo55 8y ago
    That's why you should always use salt with your hash. Unsalted, your password hash = Hash({{Your Password}}) The attacker can brute force it from a dictionary or stepping through characters (possibly from another breach somewhere, or a silly password like boobies123). Salted hashes are way more secure: Hash({{Your Password}} + {{Secret}}) Now the attacker has to guess an extra secret phrase, which is often really long, that was fed into the hash function along with the user's password. And due to the beauty of one way hash functions both salted and unsalted hashes use the same amount of bytes in the DB... It's a no brainer.
    - dancek 8y ago
      The reason to use a salt is mostly that an attacker doesn't then have a precomputed library of hash values. Say, if someone uses the password 'gwpmkq' and a site uses plain MD5, they store cc733aac12981561dfc4944dd34a595f in their database. Now, even a stupid attacker can google for a hash search engine, input the hash and get the password in seconds. On the other hand, with salting the value to be hashed could be something like 'luser@fail.com:@362#^h6329hgtew:gwpmkq'. That won't be precomputed anywhere. Of course it's also a good idea to either try to keep the salt secret or use a per-user random salt (which you store in the database). But when someone gets a full database dump, chances are they'll also get the salt.
      - kibibu 8y ago
        The specific attack that per-user random salts are designed to prevent are pre-computed rainbow tables. Brute-forcing MD5 is nearly as fast as using rainbow tables, so the benefits are possibly dubious.
        8y ago
jstarfish 8y ago
There's no excuse for plaintext passwords in 2019. Even the barest of frameworks provided mechanisms to hash and salt the damn things years before 2013. Not salting/hashing at this point is more than a disservice, it's the equivalent of deliberately not washing your hands after wiping your ass, then going on to serve sandwiches.
- lotyrin 8y ago
  I believe Unix passwords were salted and hashed in the 70's and those weren't typically for customer-facing accounts nor obviously for public internet-facing systems. It boggles the mind that the 90s internet boom had to reinvent all the security wheels with such a great history to draw from -- then now that we have bothered to reinvent these wheels yet still decade or two back people are still delinquent in their use.
  - kingo55 8y ago
    At some point it should become law. Credentials are so common and the best practices around handling them have been around for what sounds like half a century. There's no protection for the average Joe who may reuse passwords and subsequently have it exposed in plain text or through an unsalted hash. It's logical... In fact the GDPR makes some steps to enforce better handling of personal data and announcing beaches but I don't believe it enforces strong handling of passwords.
  - tialaramex 8y ago
    A salted presimised hash, of roughly the same sort we'd use today except that salt was only 12 bits (which seemed reasonable if your Unix systems have 500 users but not if your social network site has 500 million users) and the loop just runs the DES S-Boxes a bunch of times with no way to tune how many. By the 1990s Unix systems were mostly using PHK's version which had a larger salt and ran MD5 a configurable amount of times instead of DES some fixed number of times.
    - acdha 8y ago
      > By the 1990s Unix systems were mostly using PHK's version which had a larger salt and ran MD5 That timing seems a bit optimistic to me, especially at large shops where the original crypt() implementation was necessary because you were using things like NIS, Radius, LDAP, etc. and had devices which didn't support MD-5 or better. I was still seeing that into the mid-to-late 2000s.
tracker1 8y ago
Just as an example once when changing the hashing for users on a relatively popular site. Implemented new prefix + hash + salt system. On login, if old system was used, verify and re-hash with new password system. Notify users to login after 60 days of inactivity. After 90 days, clear all passwords that didn't have the new hashing system, forcing out of band change-password process. Worked out very well in practice. It helps to have a plan to deprecate older hashing approaches to passwords.

by curo 8y ago

pc86 8y ago

Storing plaintext passwords is no faster than storing a cryptographically secure hash of the same password. We're not even talking lines of extra code, just a few extra characters actually hash the input. It's not expediency, it's laziness bordering on criminal stupidity/negligence.

hamandcheese 8y ago
Or maybe just ignorance?
- pc86 8y ago
  Protecting a user's password is such a basic level of understanding I think ignorance falls under "criminal stupidity" for this one.
- dragonwriter 8y ago
  Ignorance of facts that any reasonable exploration of best practices in the area you are working in would reveal, in a commercial venture, is a product of laziness (or hubris) bordering on (or crossing into) negligence.
jmeyer2k 8y ago
Well it should be faster than storing a cryptographically secure hash. If hashing the data is too fast, an attacker could just brute force all of the passwords.
- kingo55 8y ago
  That's why you should always use salt with your hash. Unsalted, your password hash = Hash({{Your Password}}) The attacker can brute force it from a dictionary or stepping through characters (possibly from another breach somewhere, or a silly password like boobies123). Salted hashes are way more secure: Hash({{Your Password}} + {{Secret}}) Now the attacker has to guess an extra secret phrase, which is often really long, that was fed into the hash function along with the user's password. And due to the beauty of one way hash functions both salted and unsalted hashes use the same amount of bytes in the DB... It's a no brainer.
  - dancek 8y ago
    The reason to use a salt is mostly that an attacker doesn't then have a precomputed library of hash values. Say, if someone uses the password 'gwpmkq' and a site uses plain MD5, they store cc733aac12981561dfc4944dd34a595f in their database. Now, even a stupid attacker can google for a hash search engine, input the hash and get the password in seconds. On the other hand, with salting the value to be hashed could be something like 'luser@fail.com:@362#^h6329hgtew:gwpmkq'. That won't be precomputed anywhere. Of course it's also a good idea to either try to keep the salt secret or use a per-user random salt (which you store in the database). But when someone gets a full database dump, chances are they'll also get the salt.
    - kibibu 8y ago
      The specific attack that per-user random salts are designed to prevent are pre-computed rainbow tables. Brute-forcing MD5 is nearly as fast as using rainbow tables, so the benefits are possibly dubious.
      - 8y ago

jstarfish 8y ago

There's no excuse for plaintext passwords in 2019. Even the barest of frameworks provided mechanisms to hash and salt the damn things years before 2013. Not salting/hashing at this point is more than a disservice, it's the equivalent of deliberately not washing your hands after wiping your ass, then going on to serve sandwiches.

lotyrin 8y ago
I believe Unix passwords were salted and hashed in the 70's and those weren't typically for customer-facing accounts nor obviously for public internet-facing systems. It boggles the mind that the 90s internet boom had to reinvent all the security wheels with such a great history to draw from -- then now that we have bothered to reinvent these wheels yet still decade or two back people are still delinquent in their use.
- kingo55 8y ago
  At some point it should become law. Credentials are so common and the best practices around handling them have been around for what sounds like half a century. There's no protection for the average Joe who may reuse passwords and subsequently have it exposed in plain text or through an unsalted hash. It's logical... In fact the GDPR makes some steps to enforce better handling of personal data and announcing beaches but I don't believe it enforces strong handling of passwords.
- tialaramex 8y ago
  A salted presimised hash, of roughly the same sort we'd use today except that salt was only 12 bits (which seemed reasonable if your Unix systems have 500 users but not if your social network site has 500 million users) and the loop just runs the DES S-Boxes a bunch of times with no way to tune how many. By the 1990s Unix systems were mostly using PHK's version which had a larger salt and ran MD5 a configurable amount of times instead of DES some fixed number of times.
  - acdha 8y ago
    > By the 1990s Unix systems were mostly using PHK's version which had a larger salt and ran MD5 That timing seems a bit optimistic to me, especially at large shops where the original crypt() implementation was necessary because you were using things like NIS, Radius, LDAP, etc. and had devices which didn't support MD-5 or better. I was still seeing that into the mid-to-late 2000s.

tracker1 8y ago

Just as an example once when changing the hashing for users on a relatively popular site. Implemented new prefix + hash + salt system. On login, if old system was used, verify and re-hash with new password system. Notify users to login after 60 days of inactivity. After 90 days, clear all passwords that didn't have the new hashing system, forcing out of band change-password process. Worked out very well in practice. It helps to have a plan to deprecate older hashing approaches to passwords.