McGill will double your password if you don’t do it first

[rspeer]

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.

[Dylan16807]

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.

[Nogwater]

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.

[chias]

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.

[overgard]

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.

[burke]

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)

[pyre]

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

[jasonj79]

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

[primitivesuave]

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.

[temuze]

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

[dllthomas]

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.

[eksith]

  The McGill Password length has also been increased from exactly eight 
  characters to a variable length of eight to 18 characters.

So they're not using bcrypt (usable length 72). Even PBKDF2 would have been acceptable, but my guess is that they were sold a "layer over" on their stack with this. I can already tell this is a hacky patch.

  Every year, about 1,200 to 1,500 McGill accounts are compromised in 
  one way or another.

Phishing + guessing. I know someone who gets about 2-3 emails a week asking to enter their login info into some site in Brazil or the Czech Republic.

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)

When other sites are compromised, there's an easy list of ready passwords to try against other potential targets.

McGill's problem isn't Heartbleed.

[danudey]

They may be artificially limiting the password length because other services which authenticate (e.g. VPNs, mail systems, older UNIX logins, administrative software, payroll, etc.) may have limits on password input fields.

[cgriswald]

On the plus side, they're telling people about the limit. I visit so many websites that will happily take passwords of arbitrary length without complaint... until you try to log in and your password doesn't work because the password you entered was too long and it truncated it.

[fabulist]

> Phishing + guessing. I know someone who gets about 2-3 emails a week asking to enter their login info into some site in Brazil or the Czech Republic.

I think it probably has something to do with this.

https://www.mcgill.ca/it/channels/news/email-subject-interna...

[baby]

> So they're not using bcrypt

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

[Cerium]

No, It does not mean that the password is stored as plaintext. Simply keep a flag for "UpdatedRecently?", if the flag is false, then not only should the first half of the input correctly match the hash, but the first half the input should match the second half.

[ChristianBundy]

How is that helpful for mitigating security issues though?

[WallWextra]

Do you consider this likely?

[omgitstom]

Everyone is guessing if they are storing in plaintext or not. But that isn't the actual issue to learn from their mistake. They have publicly asserted what they are doing (which is great information for a hacker), and chose a bad way to attempt to force users to reset their passwords because of a compromise. I would feel better if it was an email directly to mcgill faculty / staff. If you are building out a user management system, you need a way to disable accounts and force a password reset.

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.

[btilly]

Doubling the password is cute, but it would be even more effective to change the password for you by appending constant text to it.

The only challenge then becomes what constant text to add.

I would suggest something like, ishouldlistentosecurity. :-)

[comboy]

This must be some security joke. I would worry more about passwords not being hashed than the fact that some users didn't change them.

[Nogwater]

After all of this effort, they're still limiting passwords to 18 characters? Why would they do that?

[jasonj79]

I't because they are still storing passwords in cleartext... If they were hashing passwords (which is the correct way to do it) there would be no limit.

[achille2]

Looking at a (failed) login flow, it looks like they are using Oracle SSO

    Markers:  
    * Cookie named site2pstoretoken
    * Http header: Oracle-Application-Server-10g/10.1.2.3.0 Oracle-HTTP-Server
    * Layouts are still done via <tables>

[deckar01]

This strange rule could coexist with hashed passwords:

  if(hash(password) != passwordHash) return false;
  if(passwordUpdateTime < heartBleedTime) {
    changePasswordHash(hash(password + password));
    return false;
  }
  return true;

[hackuser]

I'm not sure it improves security significantly, but the weak link is using passwords as security in an environment like a university.

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

[alfredxing]

Here at UBC all accounts (students, faculty, staff) must have their passwords updated every year. They force you to do it with 3 "skips" available (for if you really don't have time).

[cm2187]

Am I the only one alarmed by the general inability of websites to protect sensitive information? There isn't almost a day without a major service leaking passwords or personal details. If we don't get a LOT better at this there will be some major reaction sooner or later, either legislative or in term of public behaviour. Like the government establishing a system of licenses to have the right to handle personal data, or with regular costly audit. But we can't continue at the current pace.

[vitamen]

Is this effective at stopping attacks (given that it is public knowledge), or is it mostly a measure to annoy users into updating their passwords to something less cumbersome?

[Cerium]

I think this is to annoy the users.

[zackify]

This is the same thing as blackboard, they store every password in plain text, nobody seems to care. I've been trying to bring attention to it.

[geofft]

I think that the goal here is not to increase password strength, but to make typing your old, short password so annoying that you pick a different one (that complies with the current password strength rules). That is, this isn't aimed at attackers; it's aimed at users.

If so, it's pretty clever.

[abritishguy]

Then why not just force them to change the password on login?

[mazlix]

this is in no way more secure.... there's a bijection... any password that an attack wants to try they just double so instead of bruteforcing [aab, aac,aad] just [aabaab, aacaac, aadaad] the only reason this makes sense to do is to annoy users into changing their password

[yAnonymous]

Unacceptable. They should have AT LEAST trippled the passwords.

[MrSourz]

That's maybe the next step to prompt the user to change!

Or even better make it forwardssdrawrof though that feels a bit evil. (forwards then reverse)

[smlacy]

Although highly suspect and troubling, this does not necessarily require that they have all users original passwords stored in plain text. If they had originally used a hashing function that obeyed the following:

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.