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.

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

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.

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

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.

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

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

could just have the doubling check after the hash check though

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

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.

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.

This approach just seems dumb.

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.

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

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

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

    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

Seems a heck of a lot better than force-expiring passwords like I'd expect any other company to do.

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.

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

the check was an HTML input limit and there was no backend limit...

I was sad.

    if password_requires_rotation()
      p1, p2 = split_in_half(password)
      fail unless p1 == p2
      verify(p1, ciphertext)
    else
      verify(password, ciphertext)

  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

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

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

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

I don't think that's it, I think it's just to annoy people into changing it.

McGill does some beautiful IT admin stuff. And then it does some scary-ass shit like this.

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.

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.

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.

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.