61–70 of 152 posts
Earlier quoted context omitted.
How is that helpful for mitigating security issues though?
Because it annoys the holdout users into changing their passwords.
This approach is just a dumb prank.
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…
They can put a flag on the database and check that the cleartext you send them when logging in is doubled before hashing half of it. I can't count how many times I've seen something that could easily be done at login time and people conclude that the service must be storing plaintext or multiple hashes. This isn't even a direct security measure in the first place. This is to annoy people into updating their passwords…
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 anoth…
I think it probably has something to do with this.
https://www.mcgill.ca/it/channels/news/email-subject-interna...
Earlier quoted context omitted.
There are several ways this can be done without that. Easiest is if they store the date of the last password change or otherwise know you haven't changed it. If it's old enough, double the plaintext before handing it to the hashing function.
>> Seemed like a good idea until it dawned on me that this means the passwords are stored as plaintext. >There are several ways this can be done without that. >Easiest is if they store the date of the last password change or otherwise know you haven't changed it. If it's old enough, double the plaintext before handing it to the hashing function. Not quite. What you'd need to do is halve the user's entered password if…
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 anoth…
> 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-interna...
http://www.mcgill.ca/it/news/phishing-attack-mcgill-email-11...
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.
I think that the goal here is not to increase password strength, but to make typing your old, short password so annoying that you pick a different one (that complies with the current password strength rules). That is, this isn't aimed at attackers; it's aimed at users. If so, it's pretty clever.
Then why not just force them to change the password on login?
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 also don't use very many of the computing facilities, and may just use a few legacy systems.
Earlier quoted context omitted.
Theoretically, they could have HAD the password in plaintext, then doubled it, salted it and hashed it in the new DB.
this makes sense, as they also doubled(+2) the min password lengths. 18 char would be rather annoying to me though.
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…
I'm not sure, but there may be some hash functions for which H(concat(a, a)) = F(H(a)). I'd worry a little about their security in some contexts - particularly if that generalized beyond just duplication, it seems likely vulnerable to length extension attacks if used for HMAC, &c - but for password hashing it might be fine and would clearly be better than plain text. It's not impossible they were already using a hash…
If H is secure then F is not computable. If they can do a trick like this then their hashing is no good.
Another possibility would be
Yeah, you can approach it like a puzzle and figure out what crazy set up they could have, but Occam's Razor has to apply at some point. I'm betting they did the dumb thing, not the strange thing that is mostly pointless.
Getting users to confirm to good password practices is nearly impossible when they are mature, paid employees with money and valuable IP on the line, and at organizations with legal/regulatory security requirements. Imagine accomplishing that with thousands of college students. (I'm not sure there's a good, cost-effective solution, other than to provide more secure options to users who want them.)