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