81–90 of 152 posts
Earlier quoted context omitted.
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…
Even if they 'check that the cleartext you send them when logging in is doubled before hashing half of it' and calculate hash of the doubled string, what will they check it against? They don't have the hash of double the string until and unless they were storing the plain-text.
They just check if the entered password is doubled identically, then compare half of it to the hash.
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 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.
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…
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…
I don't think that's it, I think it's just to annoy people into changing it.
what the actual fuck
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 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.
if(userHasUpdatedPw) { checkPw(hash(pw)) }
else{ checkPw(hash(pw+pw)) }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…
After all of this effort, they're still limiting passwords to 18 characters? Why would they do that?
I't because they are still storing passwords in cleartext... If they were hashing passwords (which is the correct way to do it) there would be no limit.
Earlier quoted context omitted.
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…
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…
I can't figure out any way it makes sense unless they are forbidden by policy from forcing password changes.
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…
if not check_password(submitted_password) then
HTTP 401
else if password_last_changed