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

111–120 of 152 posts

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

#111

Post by MichaelGG »

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?

Well, you have to have some limit. Otherwise a user could register with a 1GB username. This might break all sorts of things that assume they can display or work with usernames.

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

#112

Post by pcthrowaway »

wfjackson wrote: post #11

>The need to change passwords arose in April, when the Heartbleed vulnerability was revealed. Heartbleed makes systems vulnerable to data theft since attackers can use it to gain access to systems and then proceed to access and steal information without leaving a trace. >Even though our central IT systems are protected against Heartbleed, any accounts that have already been stolen still pose a security risk. Almost 2…

The point isn't to make their system more secure, it's to annoy the users into changing their password.

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

#113

Post by saifelse »

cheez wrote: post #86
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.

Yep, basically: if(userHasUpdatedPw) { checkPw(hash(pw)) } else{ checkPw(hash(pw+pw)) }

More like:

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

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

#114

Post by gohrt »

nemanja wrote: post #79
overgard wrote: post #53

Earlier quoted context omitted.

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.

I always thought that the max is there to discourage users from setting passwords so long they can't remember them (and instead write them down on a post-it that's right on the monitor).

better to put the pw in a physical token than have some short guessable pw

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

#115

Post by mappu »

overgard wrote: post #53
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…

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.

In general yes. But don't forget there was CVE-2013-5750 with Django's PBKDF2 implementation, where arbitrary-length passwords could DoS the server. An upper bound is probably a safe thing to have (but 18 is too low)

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

#116

Post by gohrt »

geofft wrote: post #67
abritishguy wrote: post #45

Earlier quoted context omitted.

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

One possible answer: Because tenured faculty can call up the helpdesk and get policies reversed, because they're tenured and the helpdesk isn't. Another possible answer: Many systems can't prompt for password changes, and will just continue to log you in (because, especially for remote-access systems, that's better than denying access and hoping you find another way to get logged in). Probably the lazier of the users…

what's tenure got to do with it? if tenured dinosaur faculty leave, that's a huge win for the budget.

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

#117

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

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

#118

Post by reitanqild »

lukifer wrote: post #109
jasonj79 wrote: post #73

Earlier quoted context omitted.

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…

Please don't enforce it. The moment you have a "sufficiently large wordset" in English you'd already added a whole lot of words that are hard to spell not only for non-native speakers.

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

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

#119

Post by jarek »

oxryly1 wrote: post #61
tempestn wrote: post #39

Earlier quoted context omitted.

Because it annoys the holdout users into changing their passwords.

Back in my day ( old man grumble ) the system would force you to change your password on next login. Simple, effective. This approach is just a dumb prank.

I dislike being forced to change password without notice, I need some time to come up with a secure, typeable one. Change on next login just results in me reusing an old password or adding a "2" to the current one.

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

#120

Post by desas »

reberhardt wrote: post #101
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?

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…

I think mysql is the only database that auto truncates varchars isn't it?
Post reply on HN