4 ms·
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
by eksith 12y ago
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.
McGill's problem isn't Heartbleed.
- danudey 12y agoThey 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.
- eksith 12y agoThis 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.
- fabulist 12y ago> 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. https://www.mcgill.ca/it/channels/news/email-subject-internal-only-contains-malware-attachment-240148 https://www.mcgill.ca/it/channels/news/email-subject-interna...
- eksith 12y agoThat'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 : http://www.mcgill.ca/it/news/phishing-attack-mcgill-email-115751 http://www.mcgill.ca/it/news/phishing-attack-mcgill-email-11...
- cgriswald 12y agoOn 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.
- jschwartzi 12y agoI 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?
- mod 12y agoTo keep username from ruining the front-end. If I had a 2,000 character username, this page would look really stupid.
- ChrisGranger 12y agoI 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.
- mike-cardwell 12y agoThat is what this css is for: overflow: hidden; text-overflow: ellipsis;
- reberhardt 12y agoIn 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.
- baby 12y ago> So they're not using bcrypt 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: http://stackoverflow.com/questions/2772014/is-sha-1-secure-for-password-storage http://stackoverflow.com/questions/2772014/is-sha-1-secure-f...