Hacker News new | past | comments | ask | show | jobs | submit login
Security Issue February 2019: FAQ (500px.com)
31 points by JeremyBanks on Feb 15, 2019 | hide | past | favorite | 9 comments



The title here may be a bit misleading. From the article, it actually sounds like 500px used MD5-encryption for a subset of their users’ passwords, and this is the subset that they’ve prioritized forced password resets for due to higher risk.

As per tachang’s comment, MD5-hashing passwords isn’t secure, but also per their comment, this is also an opportunity for them to migrate that subset of users to the presumably more secure hashing function used for the rest of their user base.


We've reverted the title from the editorialized ‘500px: don't worry, your passwords were “MD5-encrypted”’.


For those wondering MD5 by itself is a terrible hash for passwords. It’s really fast and without salting you can build rainbow tables against it with reasonable speed.

If the passwords were salted it still means that a determined adversary can find your password relatively quickly.

Other better hash functions for passwords include things like bcrypt. Though I do understand it is a pain to migrate users over since you can only do it when they login.


> Though I do understand it is a pain to migrate users over since you can only do it when they log in.

Had a thought on this, but I'm no security expert so if someone else could weigh in, that'd be awesome. Couldn't you just add a layer to the password hashing?

I.e., you start with MD5 because that's the best at the current point in history. Bcrypt comes around and you want to do a migration of all your users, so you take the stored MD5 hashes and run them through bcrpyt. Making sure, of course, that your login system does the same, MD5 followed by bcrypt. When the next-gen hashing algorithm comes around, you do the same, now the path is MD5->bcrypt->next-gen.

That way you're relying on the strongest algorithm "wrapping" the weaker one(s) without having to make everyone login again to generate the new hashes to be stored.

Curious to know if there are downsides to this (performance is an obvious one) or whether you're weakening the stronger hash by hashing a weaker one?


> Curious to know if there are downsides to this (performance is an obvious one) or whether you're weakening the stronger hash by hashing a weaker one?

You're weakening the stronger hash by hashing the weaker one. The two main problems of MD5 are entropy (128-bit maximum) and collisions (because of lack of entropy).

By always hashing to MD5, you are losing the entropy of the stronger hashing algorithm.


Confirms a suspicion I had that it might be an issue. I assume it's a problem whenever you hash a weaker with a stronger, not just MD5 in particular.

Thanks!


It does cap it at 128 bits, but it is not an issue. 128 bits of entropy is plenty.


This is what Facebook has done and it works.


How is ‘how did they get in’ not a Frequently Asked Question?




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

Search: