
McGill will double your password if you don’t do it first - isbadawi
http://www.mcgill.ca/it/channels/news/faculty-and-staff-mcgill-will-double-your-password-if-you-don%E2%80%99t-do-it-first-238834
======
rspeer
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 database of everyone's password in plaintext. Oh, and a large proportion of them are still the possibly-compromised ones.

* They're comfortable announcing this fact to the Web, for some reason.

I really hope the first thing they do after doubling the password is put it
into a password-hashing function and throw away the plaintext, and then make
those users change them anyway, because the doubled passwords are still
compromised. It sounds unlikely.

~~~
Nogwater
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 <pw><pw> 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.

~~~
StavrosK
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.

~~~
azernik
Why is this a problem? If your password is "foofoo" and was set after the
cutoff, then it won't be halved; if it is "foofoo" and was set before the
cutoff, it will be halved, and then not match the password in the database, as
intended.

~~~
StavrosK
You have to have stored the last password change date, which many systems
don't do.

~~~
jtheory
If they didn't before, they can start storing it to implement this.

------
eksith

      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.

~~~
cgriswald
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.

~~~
jschwartzi
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?

~~~
reberhardt
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.

~~~
desas
I think mysql is the only database that auto truncates varchars isn't it?

------
Cerium
No, 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.

~~~
ChristianBundy
How is that helpful for mitigating security issues though?

~~~
tempestn
Because it annoys the holdout users into changing their passwords.

~~~
oxryly1
Back in my day ( _old man grumble_ ) the system would force you to change your
password on next login. Simple, effective.

This approach is just a dumb prank.

~~~
jarek
I dislike being forced to change password without notice, I need some time to
come up with a secure, typeable one. Change on next login just results in me
reusing an old password or adding a "2" to the current one.

------
omgitstom
Everyone is guessing if they are storing in plaintext or not. But that isn't
the actual issue to learn from their mistake. They have publicly asserted what
they are doing (which is great information for a hacker), and chose a bad way
to attempt to force users to reset their passwords because of a compromise. I
would feel better if it was an email directly to mcgill faculty / staff. If
you are building out a user management system, you need a way to disable
accounts and force a password reset.

You never want to convey any information about the usernames, password, or
state of the account _ever_. This is true for error messages during login, but
can be applied to any messaging.

------
btilly
Doubling the password is cute, but it would be even more effective to change
the password for you by appending constant text to it.

The only challenge then becomes what constant text to add.

I would suggest something like, _ishouldlistentosecurity_. :-)

------
comboy
This must be some security joke. I would worry more about passwords not being
hashed than the fact that some users didn't change them.

------
Nogwater
After all of this effort, they're still limiting passwords to 18 characters?
Why would they do that?

~~~
jasonj79
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.

~~~
simlevesque
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...](https://www.reddit.com/r/gfycat/comments/2m7ddd/how_does_gfycat_stores_the_passwords_of_its_users/)

~~~
jasonj79
makes sense... hopefully this is their reason instead of the former.

~~~
tmmm
it doesn't actually... limit to 1k chars or something, not 20 if you worry
about stuff like that.

------
achille2
Looking at a (failed) login flow, it looks like they are using Oracle SSO

    
    
        Markers:  
        * Cookie named site2pstoretoken
        * Http header: Oracle-Application-Server-10g/10.1.2.3.0 Oracle-HTTP-Server
        * Layouts are still done via <tables>

------
deckar01
This strange rule could coexist with hashed passwords:

    
    
      if(hash(password) != passwordHash) return false;
      if(passwordUpdateTime < heartBleedTime) {
        changePasswordHash(hash(password + password));
        return false;
      }
      return true;

------
hackuser
I'm not sure it improves security significantly, but the weak link is using
passwords as security in an environment like a university.

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.)

------
alfredxing
Here at UBC all accounts (students, faculty, staff) must have their passwords
updated every year. They force you to do it with 3 "skips" available (for if
you really don't have time).

------
cm2187
Am I the only one alarmed by the general inability of websites to protect
sensitive information? There isn't almost a day without a major service
leaking passwords or personal details. If we don't get a LOT better at this
there will be some major reaction sooner or later, either legislative or in
term of public behaviour. Like the government establishing a system of
licenses to have the right to handle personal data, or with regular costly
audit. But we can't continue at the current pace.

------
vitamen
Is this effective at stopping attacks (given that it is public knowledge), or
is it mostly a measure to annoy users into updating their passwords to
something less cumbersome?

~~~
Cerium
I think this is to annoy the users.

------
zackify
This is the same thing as blackboard, they store every password in plain text,
nobody seems to care. I've been trying to bring attention to it.

------
geofft
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.

~~~
abritishguy
Then why not just force them to change the password on login?

~~~
geofft
One possible answer: Because tenured faculty can call up the helpdesk and get
policies reversed, because they're tenured and the helpdesk isn't.

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.

~~~
gohrt
what's tenure got to do with it? if tenured dinosaur faculty leave, that's a
huge win for the budget.

------
mazlix
this is in no way more secure.... there's a bijection... any password that an
attack wants to try they just double so instead of bruteforcing [aab, aac,aad]
just [aabaab, aacaac, aadaad] the only reason this makes sense to do is to
annoy users into changing their password

------
yAnonymous
Unacceptable. They should have AT LEAST trippled the passwords.

~~~
MrSourz
That's maybe the next step to prompt the user to change!

Or even better make it forwardssdrawrof though that feels a bit evil.
(forwards then reverse)

------
smlacy
Although highly suspect and troubling, this does not necessarily require that
they have all users original passwords stored in plain text. If they had
originally used a hashing function that obeyed the following:

Hash(pw) + Hash(pw) := Hash(pw + pw)

(NB: Where '+' above is really just a stand-in for any pair of combining
functions, not necessarily arithmetic addition or string concatenation.)

But, I agree with many others here that the likelihood of stored plain text
passwords is very high.

------
abritishguy
They need to hire some competent IT people

------
scottydelta
How can they double the password using the hashes? Are they storing password
in plaintext? :O

------
wfjackson
>The need to change passwords arose in April, when the Heartbleed
vulnerability was revealed. Heartbleed makes systems vulnerable to data theft
since attackers can use it to gain access to systems and then proceed to
access and steal information without leaving a trace.

>Even though our central IT systems are protected against Heartbleed, any
accounts that have already been stolen still pose a security risk. Almost
20,000 members of the McGill community did change their McGill Password, but
thousands more did not, and so additional actions have become necessary.

So, ff the people who got the passwords read this post then all they need to
do is double the passwords they got with HeartBleed to gain access?

Perhaps they should quadruple the password? /s

~~~
pcthrowaway
The point isn't to make their system more secure, it's to annoy the users into
changing their password.

------
zackify
what the actual fuck

~~~
simlevesque
this is hilarious

------
okonomiyaki3000
RIP Security.

------
cannedbass
Seemed like a good idea until it dawned on me that this means the passwords
are stored as plaintext.

~~~
hga
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.

~~~
sehrope
>> 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
it's older than the cutoff date. If the user enters "foobarfoobar" then you'd
halve it to "foobar" before hashing and comparing it to what's stored.

If you only have the old hashed password stored then you don't have the hash
of the doubled password, nor can you can infer it.

This whole approach is silly of course. They should just force everybody to
reset their passwords.

~~~
MrSourz
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.

