Hacker News Reader

Comment by rspeer | Hacker News Reader

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.

View on HN

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

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

But they're not checking length. They apparently did this to all passwords and want all passwords changed because of heartbleed.

I can't figure out any way it makes sense unless they are forbidden by policy from forcing password changes.

> But they're not checking length.

Yeah, for that you'd need to know more about the password than we'd like them to know. I imagine they are simply setting the policy to "double" the password if it is older than X days.

Forcing password changes -- e.g., "you're locked out until you change your password" -- means that the student must select a new password right now, whatever time pressure they're under.

Most people in a rush aren't going to do a good job choosing a secure new password; they aren't going to read McGill's recommendations about password managers or whatever; they're not even going to take 30 seconds to think about how to come up with a reasonably secure but memorable password.

They're just going to use their old password with a "1" on the end.

So -- McGill came up with a way to keep nudging students into updating their passwords, without forcing the specific moment they need to do it.

I'm at a .edu, not McGill. I'll relate my experience with forced password changes.

>Most people in a rush aren't going to do a good job choosing a secure new password;

Yup. This happens once per year without fail, and more often if there is some security problem. Often enough, it happens during a busy time of the semester (beginning or end).

>they aren't going to read McGill's recommendations about password managers or whatever; they're not even going to take 30 seconds to think about how to come up with a reasonably secure but memorable password.

My employer's IT department's password advice is... vintage, to be kind. It took a shaming in front of the college president to get them to stop threatening people for writing passwords down. The clunky password rules are at least partly responsible for the typically weak passwords. Another factor is the practice of configuration of machines with timeouts in the 10 to 30 minute range, forcing people to constantly enter their passwords. Yet another is the number of disparate IT systems with different password databases, and different password rules.

Here is one idea. When you force people to change there password you interrupt their workflow. Person X wants to do thing Y but first they must change their password. Now they are annoyed and are still wanting to do thing Y so they try to do the simplest thing possible. This will probably be using the same password again, and when that (hopefully) doesn't work they will choose a another common password all so they don't have to spend more time thinking about it. Now with what the university has done the person is only slightly annoyed and the workflow is not interrupted, this means the person has time to think up a good password with out time pressure on them so they are more likely to come up with good passwords.

> You are correct - for UX reasons you don't want to be causing people to change password unnecessarily,

If there is an identified potential compromise, then the password change isn't unnecessary.

Even if they 'check that the cleartext you send them when logging in is doubled before hashing half of it' and calculate hash of the doubled string, what will they check it against? They don't have the hash of double the string until and unless they were storing the plain-text.

They have the hash of the original password.

They just check if the entered password is doubled identically, then compare half of it to the hash.

Correct me if i'm wrong here, but to do what you're saying they could/should do here we basically have three options...

1) Storing the password in plaintext. 2) Sending the password over the wire in plaintext. 3) Computing two hashes on the same system (presumably) via the same function, with a known relationship between their inputs.

I guess the fourth option is they have a securely stored hash of the password, but that still wouldn't allow them to compute the 2x hash server side so we're looking at another round trip and/or number three above.

Not confidence inspiring.

> Correct me if i'm wrong here

Yes, you are wrong.

> we basically have three options

Or sending the plaintext password over the wire using SSL?

You are aware that to use a hash the server needs the plain text password right? And not just them, every server needs this?

You are acting like getting the plaintext password is something strange. It's not.

You can send the password encrypted or not, it has nothing to do with the hash on the server.

> but that still wouldn't allow them to compute the 2x hash

As I have said already, they are not computing the 2x hash.

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

Oh God...

  "password123password123".match(/^(.+)\1$/)[1]

So, in other words, this is an elaborate prank?

It'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)

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

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

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

this, i'm not sure why it is hard to see that this is easy to implement without storing passwords in plaintext.

You have to have stored the last password change date, which many systems don't do.

If they didn't before, they can start storing it to implement this.

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

Yep, basically:

    if(userHasUpdatedPw) { checkPw(hash(pw)) }
    else{ checkPw(hash(pw+pw)) }

More like:

    if(userHasUpdatedPw) { checkPw(hash(pw)) }
    else{ checkPw(hash(assertDoubledAndTakeHalf(pw)))}

Probably

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

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

Exactly; 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.

There'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.

I've always wondered this... So many organizations do this.

Typically compatibility with legacy systems

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

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

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

I 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).

better to put the pw in a physical token than have some short guessable pw

I believe old versions of mailman fall on their face when using pw more than 8 chars.

In general yes. But don't forget there was CVE-2013-5750 with Django's PBKDF2 implementation, where arbitrary-length passwords could DoS the server. An upper bound is probably a safe thing to have (but 18 is too low)

> In general yes. But don't forget there was CVE-2013-5750 with Django's PBKDF2 implementation

CVE-2013-5750 is a Symfony vulnerability, the Django one is CVE-2013-1443.

And of course it was fixed by limiting passwords to 4096 bytes, not 18.

An easy alternative (which has to be applied if you're using bcrypt since it's limited ~50 bytes of input) is applying length reduction through a regular cryptographic hash before applying the KDF[0]. Of course the cryptographic hash might still be DOS'd, but they tend to have a throughput of 100~300MB/s on commodity hardware so that's less likely.

[0] HMAC actually does that internally: if the key (password) is bigger than BLOCKSIZE — 64B for hmac-md5 and hmac-sha1, it will pass it through the hash function once then pad it to BLOCKSIZE before doing its thing.

The pkbdf2 DOS is because PBKDF2-HMAC calls HMAC once per round, so (on passwords longer than BLOCKSIZE) it performs length reduction once per round, and the total input data for length reduction alone is thus rounds * pw_length.

Given pbkdf2 tends to have round counts in the tens of thousands or hundreds of thousands these days, the amount of data going through the hash function literally increases by several orders of magnitude… and for nothing since it's the exact same operation each round.

Thus running e.g. SHA-384 on a password before handing it off to a KDF is probably a good idea in any case

No, 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)

In 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

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

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

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

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

Please 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.)

It'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.

take a look at pearson's blackboard, they store passwords in plain text.

I'd really rather not. Blackboard has a reputation among students and faculty alike for being nigh-impossible to understand.

Pearson does this in all of their services.

i know, mymathlab as well.

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

Theoretically, they could have HAD the password in plaintext, then doubled it, salted it and hashed it in the new DB.

this makes sense, as they also doubled(+2) the min password lengths. 18 char would be rather annoying to me though.

IMHO: 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.

I'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.

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

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

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

I don't think this follows. "Random output" is an idealized model that no actual, specific hash function achieves. I already said that having such an F would worry me, but "if F is computable, H is not secure" is a strong statement and I'm wondering whether it's backed up by math, not-quite-math-but-good-reasoning, or handwavy bluster. Please don't take this as an attack, though - I appreciate the attempt!

I don't think I'm able to make a much more rigorous argument, but I will note that you seem to be applying two different criteria here. If you want to criticize modeling a hash function as a PRF as too idealized, then you aren't going to get a mathematical answer (since it will start with "let H be a PRF").

A maximally strong mathematical answer is showing that given that F and H(a), we can reconstruct too much about a, for any H and corresponding F. There are probably other similarly strong forms of argument - I'm not saying that's the only one - but you can see how it differs from "Well, it's just not random."

Reply on news.ycombinator.com