
Security Issue February 2019: FAQ - JeremyBanks
https://support.500px.com/hc/en-us/articles/360017752493-Security-Issue-February-2019-External-FAQ
======
izuchukwu
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.

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

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

~~~
mystickphoenix
> 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?

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

~~~
mystickphoenix
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!

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

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

