Earlier quoted context omitted.
It annoys people into updating their password, for one.
Which they could of accomplished with a password reset via email.
It's a .edu. The password you just reset is the same as the password for their email.
McGill will double your password if you don’t do it first
141–150 of 152 posts
Re: McGill will double your password if you don’t do it first
#142Earlier 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 reason to inconvenience rather than force is users in a rush will pick the worst passwords, even as paid employees where their password is the thing between the outside world and highly confidential stuff.
Re: McGill will double your password if you don’t do it first
#143Earlier quoted context omitted.
That is simply not true. I used to think the same but real world experience showed me that a lot of websites hash the passwords but they still set a limit to password length. You should read this : https://www.reddit.com/r/gfycat/comments/2m7ddd/how_does_gfy...
makes sense... hopefully this is their reason instead of the former.
it doesn't actually... limit to 1k chars or something, not 20 if you worry about stuff like that.
Re: McGill will double your password if you don’t do it first
#144Earlier quoted context omitted.
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?
the point being "111111" already appears doubled for example
could just have the doubling check after the hash check though
Re: McGill will double your password if you don’t do it first
#145Re: McGill will double your password if you don’t do it first
#146No, It does not mean that the password is stored as plaintext. Simply keep a flag for "UpdatedRecently?", if the flag is false, then not only should the first half of the input correctly match the hash, but the first half the input should match the second half.
Do you consider this likely?
I'd probably flip a coin.
Re: McGill will double your password if you don’t do it first
#147Earlier 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?
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…
[deleted]
Re: McGill will double your password if you don’t do it first
#148Earlier quoted context omitted.
So, in other words, this is an elaborate prank?
It's a moderately aggressive way to get people to change their passwords (more aggressive than an email or prompt, less aggressive than forcing upon login)
If that happened to me I'd just keep the doubled password. It seems more secure (it's not), and I already remember it.
This approach just seems dumb.
Re: McGill will double your password if you don’t do it first
#149Earlier quoted context omitted.
"If H is secure then F is not computable. If they can do a trick like this then their hashing is no good." Can you point to something more than assertion, here? "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." It's mostly pointless, but it's incr…
> there may be some hash functions for which H(concat(a, a)) = F(H(a)) I'll give a shot at why this implies that H is not a secure hash function, though I could be wrong. The outputs of a secure hash function should be randomly distributed across the set of all possible outputs. If H is a secure hash function that outputs a value in the set {0,1}^128 (a 128 bit output), then H(a) and H(a+a) should both be 128 bit out…
I don't think this follows. "Random output" is an idealized model that no actual, specific hash function achieves. I already said that having such an F would worry me, but "if F is computable, H is not secure" is a strong statement and I'm wondering whether it's backed up by math, not-quite-math-but-good-reasoning, or handwavy bluster. Please don't take this as an attack, though - I appreciate the attempt!
Re: McGill will double your password if you don’t do it first
#150Earlier quoted context omitted.
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.
This would break passwords like "foofoo", since they'd think it was already doubled, they'd check "foo" against the hash and it would fail. Then again, you can get around that with doubling it again after checking, so I don't know.
Passwords prior to the doubling were a fixed length, so they could always assume the first eight characters of a 16 character password (which hasn't been changed manually) is the original password.
Of course, anyone who has a leak of the original passwords can equally just send a a double of it, so I'm not sure what benefit this is supposed to be offering.