McGill will double your password if you don’t do it first

The fact that they&#x27;re <i>able</i> to &quot;double your password&quot; is a bad sign. Here&#x27;s what this implies to me:<p>* McGill had a database of everyone&#x27;s password in plaintext at the time of Heartbleed<p>* 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<p>* Despite this concern, McGill <i>still</i> has a database of everyone&#x27;s password in plaintext. Oh, and a large proportion of them are still the possibly-compromised ones.<p>* They&#x27;re comfortable announcing this fact to the Web, for some reason.<p>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.

<p><pre><code> The McGill Password length has also been increased from exactly eight characters to a variable length of eight to 18 characters. </code></pre> So they&#x27;re not using bcrypt (usable length 72). Even PBKDF2 would have been acceptable, but my guess is that they were sold a &quot;layer over&quot; on their stack with this. I can already tell this is a hacky patch.<p><pre><code> Every year, about 1,200 to 1,500 McGill accounts are compromised in one way or another. </code></pre> 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.<p>If every site properly salted and hashed passwords, reuse isn&#x27;t even a problem. But as we know :<p><pre><code> - Most people choose crappy passwords. - Most sites use crappy hashing schemes (if they hash at all) </code></pre> When other sites are compromised, there&#x27;s an easy list of ready passwords to try against other potential targets.<p>McGill&#x27;s problem isn&#x27;t Heartbleed.

No, It does not mean that the password is stored as plaintext. Simply keep a flag for &quot;UpdatedRecently?&quot;, 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.

Everyone is guessing if they are storing in plaintext or not. But that isn&#x27;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 &#x2F; staff. If you are building out a user management system, you need a way to disable accounts and force a password reset.<p>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.

Doubling the password is cute, but it would be even more effective to change the password for you by appending constant text to it.<p>The only challenge then becomes what constant text to add.<p>I would suggest something like, <i>ishouldlistentosecurity</i>. :-)

This must be some security joke. I would worry more about passwords not being hashed than the fact that some users didn&#x27;t change them.

After all of this effort, they&#x27;re still limiting passwords to 18 characters? Why would they do that?

Looking at a (failed) login flow, it looks like they are using Oracle SSO<p><pre><code> Markers: * Cookie named site2pstoretoken * Http header: Oracle-Application-Server-10g&#x2F;10.1.2.3.0 Oracle-HTTP-Server * Layouts are still done via &lt;tables&gt;</code></pre>

This strange rule could coexist with hashed passwords:<p><pre><code> if(hash(password) != passwordHash) return false; if(passwordUpdateTime &lt; heartBleedTime) { changePasswordHash(hash(password + password)); return false; } return true;</code></pre>

I&#x27;m not sure it improves security significantly, but the weak link is using passwords as security in an environment like a university.<p>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&#x2F;regulatory security requirements. Imagine accomplishing that with thousands of college students. (I&#x27;m not sure there&#x27;s a good, cost-effective solution, other than to provide more secure options to users who want them.)

Here at UBC all accounts (students, faculty, staff) must have their passwords updated every year. They force you to do it with 3 &quot;skips&quot; available (for if you really don&#x27;t have time).

Am I the only one alarmed by the general inability of websites to protect sensitive information? There isn&#x27;t almost a day without a major service leaking passwords or personal details. If we don&#x27;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&#x27;t continue at the current pace.

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?

This is the same thing as blackboard, they store every password in plain text, nobody seems to care. I&#x27;ve been trying to bring attention to it.

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&#x27;t aimed at attackers; it&#x27;s aimed at users.<p>If so, it&#x27;s pretty clever.

this is in no way more secure.... there&#x27;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

Unacceptable. They should have AT LEAST trippled the passwords.

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:<p>Hash(pw) + Hash(pw) := Hash(pw + pw)<p>(NB: Where &#x27;+&#x27; above is really just a stand-in for any pair of combining functions, not necessarily arithmetic addition or string concatenation.)<p>But, I agree with many others here that the likelihood of stored plain text passwords is very high.

They need to hire some competent IT people

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

&gt;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.<p>&gt;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.<p>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?<p>Perhaps they should quadruple the password? &#x2F;s

what the actual fuck

RIP Security.

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