* McGill had a database of everyone's password in plaintext at the time of Heartbleed
* McGill is concerned about mitigating possible security compromises due to Heartbleed, including these plaintext passwords, which if they were compromised were compromised all at once
* Despite this concern, McGill still has a database of everyone's password in plaintext. Oh, and a large proportion of them are still the possibly-compromised ones.
* They're comfortable announcing this fact to the Web, for some reason.
I really hope the first thing they do after doubling the password is put it into a password-hashing function and throw away the plaintext, and then make those users change them anyway, because the doubled passwords are still compromised. It sounds unlikely.
I can't count how many times I've seen something that could easily be done at login time and people conclude that the service must be storing plaintext or multiple hashes.
This isn't even a direct security measure in the first place. This is to annoy people into updating their passwords.
if(userHasUpdatedPw) { checkPw(hash(pw)) }
else{ checkPw(hash(pw+pw)) } login():
needsPasswordDoubled = [has user changed password since XX date?]
username = [username post parameter]
password = [password post parameter]
if login successful:
if needsPasswordDoubled:
replace stored password hash with hash(password | password)
else:
return success
return failure
Seems a heck of a lot better than force-expiring passwords like I'd expect any other company to do.
if password_requires_rotation()
p1, p2 = split_in_half(password)
fail unless p1 == p2
verify(p1, ciphertext)
else
verify(password, ciphertext) if not check_password(submitted_password) then
HTTP 401
else if password_last_changed < threshold then
change_password(submitted_password + submitted_password)
HTTP 401
else
log_user_in()
HTTP 200
endif* hash current passwords with a salt, unique to each password entry, and throw away the plaintext entries.
* keep a history of hashes per user, to prevent changing to a past password
* ensure fair complexity of the incoming password
* once the deadline has been reached, force users who have not yet changed their password to do a password reset via an online form
* never, ever again think that doubling a password is a proper way to fix a security issue, ever...
As we all know, a typical password validator formula is a great way to encourage people to choose "Secr3t!", or something else equally bad.
I'd really like to see a password field that auto-generated pass phrases using full english words from a sufficiently large wordset (in the vein of "correct horse battery staple"), possibly even enforcing such phrases as the only valid type of password. Every user gets a strong password they can actually remember. (...although possibly a non-starter for mobile contexts.)
I don't think that's it, I think it's just to annoy people into changing it.
McGill does some beautiful IT admin stuff. And then it does some scary-ass shit like this.
Another possibility would be that they compute and send both H(a) and H(firsthalf(a)), if fisthalf(a) == secondhalf(a). That would work with any hash function, but I think would not appreciably increase security.
If H is secure then F is not computable. If they can do a trick like this then their hashing is no good.
Another possibility would be
Yeah, you can approach it like a puzzle and figure out what crazy set up they could have, but Occam's Razor has to apply at some point. I'm betting they did the dumb thing, not the strange thing that is mostly pointless.
The McGill Password length has also been increased from exactly eight
characters to a variable length of eight to 18 characters.
Every year, about 1,200 to 1,500 McGill accounts are compromised in
one way or another.
If every site properly salted and hashed passwords, reuse isn't even a problem. But as we know :
- Most people choose crappy passwords.
- Most sites use crappy hashing schemes (if they hash at all)
McGill's problem isn't Heartbleed.
It bothers me less now that I use a good password generator/safe, but still bothers me nonetheless.
Why on earth would you ever need to truncate a username?
I think it probably has something to do with this.
https://www.mcgill.ca/it/channels/news/email-subject-interna...
http://www.mcgill.ca/it/news/phishing-attack-mcgill-email-11...
Bcrypt is not the ONLY secure solution to securely store passwords (contrarily to what everyone is trying to tell you). See Thomas Pornin's answer on SO:
http://stackoverflow.com/questions/2772014/is-sha-1-secure-f...
Although I suppose this was done to force the users to change their password.
If so, it's pretty clever.
Another possible answer: Many systems can't prompt for password changes, and will just continue to log you in (because, especially for remote-access systems, that's better than denying access and hoping you find another way to get logged in). Probably the lazier of the users also don't use very many of the computing facilities, and may just use a few legacy systems.
Easiest is if they store the date of the last password change or otherwise know you haven't changed it. If it's old enough, double the plaintext before handing it to the hashing function.
>There are several ways this can be done without that.
>Easiest is if they store the date of the last password change or otherwise know you haven't changed it. If it's old enough, double the plaintext before handing it to the hashing function.
Not quite. What you'd need to do is halve the user's entered password if it's older than the cutoff date. If the user enters "foobarfoobar" then you'd halve it to "foobar" before hashing and comparing it to what's stored.
If you only have the old hashed password stored then you don't have the hash of the doubled password, nor can you can infer it.
This whole approach is silly of course. They should just force everybody to reset their passwords.
Or even better make it forwardssdrawrof though that feels a bit evil. (forwards then reverse)
>Even though our central IT systems are protected against Heartbleed, any accounts that have already been stolen still pose a security risk. Almost 20,000 members of the McGill community did change their McGill Password, but thousands more did not, and so additional actions have become necessary.
So, ff the people who got the passwords read this post then all they need to do is double the passwords they got with HeartBleed to gain access?
Perhaps they should quadruple the password? /s
You never want to convey any information about the usernames, password, or state of the account _ever_. This is true for error messages during login, but can be applied to any messaging.
The only challenge then becomes what constant text to add.
I would suggest something like, ishouldlistentosecurity. :-)
Markers:
* Cookie named site2pstoretoken
* Http header: Oracle-Application-Server-10g/10.1.2.3.0 Oracle-HTTP-Server
* Layouts are still done via <tables> if(hash(password) != passwordHash) return false;
if(passwordUpdateTime < heartBleedTime) {
changePasswordHash(hash(password + password));
return false;
}
return true;Getting users to confirm to good password practices is nearly impossible when they are mature, paid employees with money and valuable IP on the line, and at organizations with legal/regulatory security requirements. Imagine accomplishing that with thousands of college students. (I'm not sure there's a good, cost-effective solution, other than to provide more secure options to users who want them.)
Hash(pw) + Hash(pw) := Hash(pw + pw)
(NB: Where '+' above is really just a stand-in for any pair of combining functions, not necessarily arithmetic addition or string concatenation.)
But, I agree with many others here that the likelihood of stored plain text passwords is very high.