Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

mcgill.ca

Post reply on HN
Print view View original

91–100 of 152 posts

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

#91

Post by burke »

rspeer wrote: post #9

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 databa…

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)

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

#92

Post by dragonwriter »

Theodores wrote: post #62
Dylan16807 wrote: post #34

Earlier quoted context omitted.

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 t…

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

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

#93

Post by WallWextra »

Cerium wrote: post #13

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.

Do you consider this likely?

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

#94

Post by azernik »

StavrosK wrote: post #83
Nogwater wrote: post #19

Earlier quoted context omitted.

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

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.

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

#95

Post by jschwartzi »

cgriswald wrote: post #87
eksith wrote: post #47

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 anoth…

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.

I have an auto loan with a company which truncates the username. It's bizarre because they'll happily let you key in the entire username when you go to log in, but it truncates when you first set your account up.

Why on earth would you ever need to truncate a username?

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

#96

Post by mod »

jschwartzi wrote: post #95
cgriswald wrote: post #87

Earlier quoted context omitted.

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.

I have an auto loan with a company which truncates the username. It's bizarre because they'll happily let you key in the entire username when you go to log in, but it truncates when you first set your account up. Why on earth would you ever need to truncate a username?

To keep username from ruining the front-end.

If I had a 2,000 character username, this page would look really stupid.

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

#97

Post by okbake »

dllthomas wrote: post #72
bmm6o wrote: post #69

Earlier quoted context omitted.

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 pointle…

"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 incr…

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

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

#98

Post by rafekett »

azernik wrote: post #94
StavrosK wrote: post #83

Earlier quoted context omitted.

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.

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

#99

Post by andrewstuart2 »

cgriswald wrote: post #87
eksith wrote: post #47

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 anoth…

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.

It's a pet peeve of mine when a site puts a max length on characters (which is dumb itself) and then they don't put a max length on the password input later. Nothing but a regular workout for your 'forgot my password' feature.

It bothers me less now that I use a good password generator/safe, but still bothers me nonetheless.

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

#100

Post by ChrisGranger »

mod wrote: post #96
jschwartzi wrote: post #95

Earlier quoted context omitted.

I have an auto loan with a company which truncates the username. It's bizarre because they'll happily let you key in the entire username when you go to log in, but it truncates when you first set your account up. Why on earth would you ever need to truncate a username?

To keep username from ruining the front-end. If I had a 2,000 character username, this page would look really stupid.

I saw an example of that on a JavaScript-related site recently, where a guy's username was aaa...aaa several hundred characters long, causing a ludicrous horizontal scroll bar. You'd think it would be easy enough to say upfront during account creation that both usernames and passwords are limited to x characters.
Post reply on HN