Switch from MD5 to bcrypt (or similar) about ifcomp HOT 14 CLOSED

Okay - I'm confident this is something we can do. I've assigned this issue to myself - I expect I'll submit a PR in the next week or two.

from ifcomp.

Hi,

Thanks for your interest in ifcomp. We are still in the early stages of planning and implementing, but we appreciate your feedback.

[SATIRE]
MD5 is plenty secure. You would need several hours and four or five Pentium 100s to find the plain text content of the hash!
[/SATIRE]

Indeed, MD5 is no longer cryptographically secure. However it is widely supported. We do not yet know exactly where the production version of ifcomp.org will live. This may force us to look at a smaller subset of hashing algorithms, but clearly we will be using something stronger than MD5 (I am leaning toward SHA-256 personally, but Jmac runs this project).

Thanks again for the feedback. It helps to know there is some interest in this.

--Joe

from ifcomp.

Just to throw some muddy on this issue:
http://stackoverflow.com/questions/1561174/sha512-vs-blowfish-and-bcrypt

from ifcomp.

Some sample usage (for me):

use strict;
use Crypt::Eksblowfish::Bcrypt ('bcrypt_hash');
use MIME::Base64;
use Time::HiRes;

my $start = Time::HiRes::time();
my $password = "secret";
my $salt = "1234567890123456";
my $settings = {
    key_nul => 1,
    cost => 12,
    salt => $salt,
};

my $hash = bcrypt_hash($settings, $password);
my $end = Time::HiRes::time();
printf("Password '%s' hashes to '%s' in %.2f secs\n",
       $password,
       encode_base64($hash),
       ($end-$start));

from ifcomp.

Just to keep this issue warm, this article presents an interesting solution: http://www.fngtps.com/2010/moving-to-a-safer-password-solution/

from ifcomp.

This issue has stayed open for three years because (1) migrating between two password encryption systems is a pain, and (2) the fact that three websites using it makes it extra-painful.

While I agree that MD5 isn't the best system, I'm tempted to close this issue on grounds that what we have is good enough, especially when paired with basic monitoring against attack and pretty good server security practices on our end.

If I understand correctly, the danger is not in the password being decrypted (which is essentially impossible), but that access to the account can be jimmied open with a brute-force dictionary attack, given that the "collision space" for MD5 passwords is larger than is optimal?

If so, then the worst-case scenario is a malefactor taking control of someone else's IFComp/Introcomp/XYZZYAwards login, right? That wouldn't be great, but to my eye there's very little super-interesting that one can do with a suborned account, at least at present and for the foreseeable future. It seems very unlikely to me that it would be worth anyone's effort to try -- and even then, their attempt would be extremely obvious, since there's nothing to do but spam the IFComp server with password attempts.

from ifcomp.

The worst-case scenario is if someone gets access to machine and steals the password database. Then they find that the problem of cracking everybody's IFComp login is much easier than it should be. I.e. we're a step closer to "storing passwords in cleartext" than we really ought to be.

from ifcomp.

I agree with your concluding statement, but I would posit that we're still on the right side of safety, enough to just punt this issue.

And frankly we've already blown the "uh oh, hope nobody finds out that IFComp logins are MD5" thing as soon as this thread was first posted in 2014... That is, as far as passwords go, there's nothing that someone in possession of a raw DB dump could learn that they wouldn't already know from reading this thread.

from ifcomp.

The danger is because most people reuse passwords on multiple sites. Though there's nothing valuable here, we don't want to be the weak link which exposes people's more valuable data on other sites.

Are the passwords at least uniquely salted?

from ifcomp.

Passwords set prior to 2014 used a hardcoded salt value; passwords set since 2014 have used unique-per-user salt.

To make sure we're talking about the same thing, confirm that the danger you're thinking of is this: Alice finds, via a dictionary attack on ifcomp.org's login page (or -- worst-case -- a dump she has obtained of IFComp's database) that "foo" works as a password for [email protected]'s IFComp account. This doesn't mean that Bob chose "foo" as a password, only that it MD5-collides with whatever password he did choose. Alice now knows that "foo" might work as a password on any other web service Bob uses, so long as (1) that service also encrypts its passwords with MS5, (2) that site salted Bob's password the same way as IFComp did, and (3) Bob re-used the same password there.

Is that a correct summary?

from ifcomp.

How many of those pre-2014 passwords are still around? Perhaps just those could be invalidated.

Yeah that's a good summary. I'm not an expert at security, but I have been forced to change my passwords from password leaks on other sites. (I should start using a password manager I guess.)

Another thing entirely really: adding support for OAuth 2 would be nice, so that we could log in through other 2FA secured systems.

from ifcomp.

I'm very much against closing this issue as something that doesn't need to be addressed.

I'd like to steer the conversation away from 'is MD5 good enough' (which it absolutely isn't, IMO) to 'what are the technical difficulties with making the change'.

(1) migrating between two password encryption systems is a pain, and

I've made this sort of transition at least twice before, on applications using the same software stack in use with the IFComp app. I'd be happy to do it again on this project.

It's worth noting that we can update each account's hashing method on a successful login - we don't need to wait for (or force) users to change their password. And we can update salts at the same time, too.

(2) the fact that three websites using it makes it extra-painful.

Can somebody tell me more about this? Assuming the main IFComp site is one of the three, what are the other two sites? How do they interact with the user records? Do we pass the MD5 hash off to other websites and let them verify passwords against it?

from ifcomp.

The other two sites are http://xyzzyawards.org/awards/login.php and http://www.allthingsjacq.com/introcomp/ . I don't know anything about how they interact, however.

from ifcomp.

They can be ignored for purposes of this - when people log into one of them, their password gets sent to the main ifcomp site which auths them. I don't remember if the code to auth them uses the main flow or not, but in any case we can change the implementation without affecting the other sites.

from ifcomp.