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

101–110 of 152 posts

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

#101

Post by reberhardt »

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?

In addition to the frontend issue mod mentioned, it often happens accidentally without any errors or warnings when using a VARCHAR in a relational database, which have a maximum length. If the username field is VARCHAR(20), the application ignores database truncation warnings, and the developer didn't think to check the username length before storing it in the database, it'll truncate a 21-character username without you knowing. This comes down to the devs using sensible field lengths and handling edge cases.

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

#104

Post by TimSchumann »

ars wrote: post #82
scottydelta wrote: post #75

Earlier quoted context omitted.

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.

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

#105

Post by chias »

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…

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.

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

#106

Post by akjsdfh »

nemanja wrote: post #81
eli wrote: post #76

Earlier quoted context omitted.

Typically compatibility with legacy systems

That shouldn't be a factor if passwords are hashed, right? In other words, you don't have plain-text to pass on to the legacy system.

I was once told it was to prevent DoS-ing the back end of the system by submitting gigabytes to hash...

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

I was sad.

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

#108

Post by eridius »

chias wrote: post #105
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…

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…

The security of this is a joke because this isn't a security move. It's not designed to make the users secure after the Heartbleed vulnerability. It's purely designed to make logging in annoying for the users, so they finally change the password they should have changed a while ago.

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

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

#109

Post by lukifer »

jasonj79 wrote: post #73
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…

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…

> ensure fair complexity of the incoming password

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

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

#110

Post by ars »

TimSchumann wrote: post #104
ars wrote: post #82

Earlier quoted context omitted.

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…

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

Post reply on HN