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.

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.

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

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

EDIT: Someone asked "What if someone used 111111 as their password?", I just answered with this regex:

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

Presumably, "11111111" et al would not be valid passwords to begin with. But even if they were, so what?

the point being "111111" already appears doubled for example

could just have the doubling check after the hash check though

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.