Hacker News new | comments | show | ask | jobs | submit login

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.






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.


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.

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.


It's not enough to just use a global salt.

You need to use a random salt for each user, which is stored in the DB.

You also need to use an algorithm that takes a lot of time - SHA1 and the rest are designed to be fast, on purpose. Use bcrypt or something.

(FWIW, PHP has the best batteries-included password functions i've seen in a language. `password_hash` etc just do the right thing. Copy what they do and you'll be ok)


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.


The point of per-user salts is to avoid common passwords from revealing themselves, so that an attacker can't limit his brute-force attempts to just the users with shared passwords that will be easy to break.

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.

Who uses MD5 for hashing password anymore?

People one step above those who think storing plain-text passwords is okay.

I don't mean faster computationally I mean faster in terms of actually developing the product. In the scheme of even the simplest MVPs the additional developer time to hash an input twice is effectively zero.

Or maybe just ignorance?

Protecting a user's password is such a basic level of understanding I think ignorance falls under "criminal stupidity" for this one.

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.

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.


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.


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.


> 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.


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.


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.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: