8 ms·
The fact that they're able to "double your password" is a bad sign. Here's what this implies to me: * McGill had a database of everyone's password in plaintext
by rspeer 12y ago
The fact that they're able to "double your password" is a bad sign. Here's what this implies to me:
* 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.
- Nogwater 12y agoI don't think that's necessarily true. Let's say they have all of the passwords stored as bcrypt hashes, and they also know the last time you changed your password. They could just update the application logic to check that your password is of the form <pw><pw> if your last change date is before X. Then to check the password, they just take the first half and check that against the hash.
- pwr22 12y agoOh God...
- deleted 12y ago[deleted]
- Dylan16807 12y agoDoubling doesn't provide a benefit, no matter how well they hash or don't hash.
- Aldo_MX 12y agoWhether it provides a benefit or not is unrelated to the fact that they don't need to know your plaintext password to use something like the regex I wrote to detect a string duplicated twice and extract the first match prior to hashing/checking against the DB.
- danudey 12y agoIt annoys people into updating their password, for one.
- shit_parade 12y agoWhich they could of accomplished with a password reset via email.
- fnordfnordfnord 12y agoIt's a .edu. The password you just reset is the same as the password for their email.
- Aldo_MX 12y ago"password123password123".match(/^(.+)\1$/)[1]
- deleted 12y ago[deleted]
- oxryly1 12y agoSo, in other words, this is an elaborate prank?
- tlrobinson 12y agoIt's a moderately aggressive way to get people to change their passwords (more aggressive than an email or prompt, less aggressive than forcing upon login)
- oxryly1 12y agoIf that happened to me I'd just keep the doubled password. It seems more secure (it's not), and I already remember it. This approach just seems dumb.
- StavrosK 12y agoThis would break passwords like "foofoo", since they'd think it was already doubled, they'd check "foo" against the hash and it would fail. Then again, you can get around that with doubling it again after checking, so I don't know.
- azernik 12y agoWhy is this a problem? If your password is "foofoo" and was set after the cutoff, then it won't be halved; if it is "foofoo" and was set before the cutoff, it will be halved, and then not match the password in the database, as intended.
- rafekett 12y agothis, i'm not sure why it is hard to see that this is easy to implement without storing passwords in plaintext.
- StavrosK 12y agoYou have to have stored the last password change date, which many systems don't do.
- jtheory 12y agoIf they didn't before, they can start storing it to implement this.
- semanticist 12y agoPasswords prior to the doubling were a fixed length, so they could always assume the first eight characters of a 16 character password (which hasn't been changed manually) is the original password. Of course, anyone who has a leak of the original passwords can equally just send a a double of it, so I'm not sure what benefit this is supposed to be offering.
- cheez 12y agoYep, basically: if(userHasUpdatedPw) { checkPw(hash(pw)) } else{ checkPw(hash(pw+pw)) }
- primitivesuave 12y agoIt's quite easy to come up with a scheme to manipulate the password client-side. I'd assume an organization with any technology credence whatsoever knows not to store unencrypted passwords by now.
- zackify 12y agotake a look at pearson's blackboard, they store passwords in plain text.
- steve-howard 12y agoI'd really rather not. Blackboard has a reputation among students and faculty alike for being nigh-impossible to understand.
- username 12y agoPearson does this in all of their services.
- zackify 12y agoi know, mymathlab as well.
- deleted 12y ago[deleted]
- jszymborski 12y agoThe problem is that these passwords are used on everything from printer services to cisco vpn access to federated network ("eduroam") where "client-side" isn't somethin McGill controls. McGill does some beautiful IT admin stuff. And then it does some scary-ass shit like this.
- dllthomas 12y agoI'm not sure, but there may be some hash functions for which H(concat(a, a)) = F(H(a)). I'd worry a little about their security in some contexts - particularly if that generalized beyond just duplication, it seems likely vulnerable to length extension attacks if used for HMAC, &c - but for password hashing it might be fine and would clearly be better than plain text. It's not impossible they were already using a hash for which that's true - just unlikely. 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.
- bmm6o 12y agothere may be some hash functions for which H(concat(a, a)) = F(H(a)) 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.
- dllthomas 12y ago"If H is secure then F is not computable. If they can do a trick like this then their hashing is no good." Can you point to something more than assertion, here? "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." It's mostly pointless, but it's increasingly common knowledge that the dumb thing is dumb. It's more subtle that the pointless thing is pointless. If I had to bet, I'd also bet that they did the dumb thing, I just think it's marginally less conclusive than had been implied.
- okbake 12y ago> there may be some hash functions for which H(concat(a, a)) = F(H(a)) I'll give a shot at why this implies that H is not a secure hash function, though I could be wrong. The outputs of a secure hash function should be randomly distributed across the set of all possible outputs. If H is a secure hash function that outputs a value in the set {0,1}^128 (a 128 bit output), then H(a) and H(a+a) should both be 128 bit outputs whose mapping are indistinguishable from values chosen truly at random from this set. Although there is a discernable pattern in the two inputs to H (the concatenation), there should be no discernable pattern in the two outputs of H that you could use to reliably map H(a) to H(a+a) for any given a.
- temuze 12y agoTheoretically, they could have HAD the password in plaintext, then doubled it, salted it and hashed it in the new DB.
- bengali3 12y agothis makes sense, as they also doubled(+2) the min password lengths. 18 char would be rather annoying to me though.
- kngspook 12y agoIMHO: It's not too annoying having a long password if you make it a sentence. It's when people try to get a single "word" up to 18 chars that it becomes annoying to type. A sentence is also nice because it's not too hard to work in a capital letter, lower case, and a symbol into the passphrase.
- Dylan16807 12y agoThey can put a flag on the database and check that the cleartext you send them when logging in is doubled before hashing half of it. 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.
- deleted 12y ago[deleted]
- Aldo_MX 12y agoEDIT: Someone asked "What if someone used 111111 as their password?", I just answered with this regex: "111111111111".match(/^(.+)\1$/)[1]
- skywhopper 12y agoPresumably, "11111111" et al would not be valid passwords to begin with. But even if they were, so what?
- RubyPinch 12y agothe point being "111111" already appears doubled for example could just have the doubling check after the hash check though
- Theodores 12y agoYou are correct - for UX reasons you don't want to be causing people to change password unnecessarily, so a check at login for length is the obvious way to do it, informing people on an as needed basis that their password is too short. I just don't think they want short passwords on their system any more. Hence there is nothing sinister about what they are doing and how they are storing passwords. The evidence fits the scenario that they say it is.
- overgard 12y agoThere's also the "exactly 8" limit increased to "8 to 18". Why even have those limits? If you're hashing it there's no reason to have a limit at all.
- kngspook 12y agoI've always wondered this... So many organizations do this.
- eli 12y agoTypically compatibility with legacy systems
- nemanja 12y agoThat shouldn't be a factor if passwords are hashed, right? In other words, you don't have plain-text to pass on to the legacy system.
- akjsdfh 12y agoI was once told it was to prevent DoS-ing the back end of the system by submitting gigabytes to hash... the check was an HTML input limit and there was no backend limit... I was sad.
- eli 12y agoMaybe the interface expects an 8 character password even if it's hashed on the backend. Maybe it's hashed by something that expects a certain length because it's using a silly algorithm. Maybe not all systems use hashed passwords. Hard to say from the outside, but in my experience it's usually not because the developers were stupid or ignorant.
- deleted 12y ago[deleted]
- nemanja 12y agoI always thought that the max is there to discourage users from setting passwords so long they can't remember them (and instead write them down on a post-it that's right on the monitor).
- jasonj79 12y agoA better way to do this would have been: * 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...
- ars 12y ago> never, ever again think that doubling a password is a proper way to fix a security issue, ever... I don't think that's it, I think it's just to annoy people into changing it.
- jasonj79 12y agoI wondered the same, but I'm not sure that doubling my password would annoy me into changing it, especially when the password was previously capped at 8 characters.
- lukifer 12y ago> ensure fair complexity of the incoming password 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.)
- reitanqild 12y agoPlease don't enforce it. The moment you have a "sufficiently large wordset" in English you'd already added a whole lot of words that are hard to spell not only for non-native speakers. Why not try to generate semi random pronounceable passwords? There's a clear decrease in entropy but brute force cracking against all pronounceable strings less than 20 chars will still be hard. (Of course your definition of pronounceability might differ.)
- pyre 12y agoIn pseudo-code: 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
- burke 12y agoNo, they quite clearly did this: if password_requires_rotation() p1, p2 = split_in_half(password) fail unless p1 == p2 verify(p1, ciphertext) else verify(password, ciphertext)
- chias 12y agoAs Dylan stated, an example of a way to do this on login without storing passwords in plaintext: 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 Done. That said, the security of this is a joke: anyone who wants to compromise McGill accounts and (a) has a valid (old) username and password and (b) has seen this public press release is simply going to double all of their compromised passwords. But still, typing a double-password is annoying if you don't want to do it. So this is really just a way to "force" people to change their passwords without forcing a password reset.
- eridius 12y agoThe security of this is a joke because this isn't a security move. It's not designed to make the users secure after the Heartbleed vulnerability. It's purely designed to make logging in annoying for the users, so they finally change the password they should have changed a while ago. Seems a heck of a lot better than force-expiring passwords like I'd expect any other company to do.
- jtheory 12y agoExactly; I like it, personally. Blocking login until they've changed their password is too harsh, and it's counter-productive. A college student who needs to choose a new password now but is under time pressure is definitely not going to take recommended steps like "go install a password manager that'll generate a secure random password for you." They may not even have a piece of paper on hand right now, so they will choose a password that they can remember. Like -- their previous password, but "2" instead of "1" at the end.... Whereas if you just give them a nudge like this, they will bear the annoyance of typing it twice if they're in a rush, then when time permits they can choose a decent replacement.