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 another.
Phishing + guessing. I know someone who gets about 2-3 emails a week asking to enter their login info into some site in Brazil or the Czech Republic.
If every site properly salted and hashed passwords, reuse isn't even a problem. But as we know :
- Most people choose crappy passwords.
- Most sites use crappy hashing schemes (if they hash at all)
When other sites are compromised, there's an easy list of ready passwords to try against other potential targets.
They may be artificially limiting the password length because other services which authenticate (e.g. VPNs, mail systems, older UNIX logins, administrative software, payroll, etc.) may have limits on password input fields.
This is why PBKDF2 would have made more sense then. They can centrally authenticate, derive a secondary token from the original pass while specifying the max limit for each of those services. Best of all, this means the mail, UNIX login etc... need not have the same login token.
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.
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.
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.
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.
> Phishing + guessing. I know someone who gets about 2-3 emails a week asking to enter their login info into some site in Brazil or the Czech Republic.
I think it probably has something to do with this.
That's pretty bad. I think those get filtered before it gets to the inbox most of the time, but the phishing continues too. This one from 2010 is pretty similar :
Bcrypt is not the ONLY secure solution to securely store passwords (contrarily to what everyone is trying to tell you). See Thomas Pornin's answer on SO:
If every site properly salted and hashed passwords, reuse isn't even a problem. But as we know :
When other sites are compromised, there's an easy list of ready passwords to try against other potential targets.McGill's problem isn't Heartbleed.