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

131–140 of 152 posts

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

#131

Post by jasonj79 »

ars wrote: post #84
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…

> never, ever again think that doubling a password is a proper way to fix a security issue, ever... I don't think that's it, I think it's just to annoy people into changing it.

I wondered the same, but I'm not sure that doubling my password would annoy me into changing it, especially when the password was previously capped at 8 characters.

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

#132

Post by mike-cardwell »

MichaelGG wrote: post #111
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?

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.

This is why you prevent them from entering one that is longer than your limit. You don't let them enter it and then truncate it...

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

#133

Post by mike-cardwell »

ChrisGranger wrote: post #100
mod wrote: post #96

Earlier quoted context omitted.

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.

That is what this css is for:

  overflow:      hidden;
  text-overflow: ellipsis;

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

#134

Post by masklinn »

mappu wrote: post #115
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.

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)

> In general yes. But don't forget there was CVE-2013-5750 with Django's PBKDF2 implementation

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

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

#135

Post by lotu »

Dylan16807 wrote: post #89
Theodores wrote: post #62

Earlier quoted context omitted.

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…

But they're not checking length. They apparently did this to all passwords and want all passwords changed because of heartbleed. I can't figure out any way it makes sense unless they are forbidden by policy from forcing password changes.

Here is one idea. When you force people to change there password you interrupt their workflow. Person X wants to do thing Y but first they must change their password. Now they are annoyed and are still wanting to do thing Y so they try to do the simplest thing possible. This will probably be using the same password again, and when that (hopefully) doesn't work they will choose a another common password all so they don't have to spend more time thinking about it. Now with what the university has done the person is only slightly annoyed and the workflow is not interrupted, this means the person has time to think up a good password with out time pressure on them so they are more likely to come up with good passwords.

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

#136

Post by lotu »

Dylan16807 wrote: post #89
Theodores wrote: post #62

Earlier quoted context omitted.

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…

But they're not checking length. They apparently did this to all passwords and want all passwords changed because of heartbleed. I can't figure out any way it makes sense unless they are forbidden by policy from forcing password changes.

Here is one idea. When you force people to change there password you interrupt their workflow. Person X wants to do thing Y but first they must change their password. Now they are annoyed and are still wanting to do thing Y so they try to do the simplest thing possible. This will probably be using the same password again, and when that (hopefully) doesn't work they will choose a another common password all so they don't have to spend more time thinking about it. Now with what the university has done the person is only slightly annoyed and the workflow is not interrupted, this means the person has time to think up a good password with out time pressure on them so they are more likely to come up with good passwords.

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

#137

Post by eli »

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.

Maybe the interface expects an 8 character password even if it's hashed on the backend. Maybe it's hashed by something that expects a certain length because it's using a silly algorithm. Maybe not all systems use hashed passwords. Hard to say from the outside, but in my experience it's usually not because the developers were stupid or ignorant.

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

#138

Post by skywhopper »

Aldo_MX wrote: post #55
[deleted] wrote: post #50

Earlier quoted context omitted.

[deleted]

EDIT: Someone asked "What if someone used 111111 as their password?", I just answered with this regex: "111111111111".match(/^(.+)\1$/)[1]

Presumably, "11111111" et al would not be valid passwords to begin with. But even if they were, so what?

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

#139

Post by fnordfnordfnord »

jtheory wrote: post #128
Dylan16807 wrote: post #89

Earlier quoted context omitted.

But they're not checking length. They apparently did this to all passwords and want all passwords changed because of heartbleed. I can't figure out any way it makes sense unless they are forbidden by policy from forcing password changes.

Forcing password changes -- e.g., "you're locked out until you change your password" -- means that the student must select a new password right now, whatever time pressure they're under. 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…

I'm at a .edu, not McGill. I'll relate my experience with forced password changes.

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

Post reply on HN