Hotfix deployed to address website issue

[Pann 8,689]

Earlier today, we were made aware of an issue where password recovery emails were not expiring properly. This caused some users to become alarmed that their security may have been compromised. Your account security is important to us, so we want to assure you that no accounts were compromised. We identified the cause and applied a hotfix to correct it so that the links provided in password recovery emails will expire after one hour. In a future update, we will implement tokens that are immediately destroyed after use.

 

 

As part of the deployment process for the hotfix, all active sessions on the Crowfall website and forum have been expired. We recommend that all users close all open browsers and log back into the website.  

 

If you haven’t already, we urge you to set up two-factor authentication on your account today. Another layer of protection is always a good thing when it comes to protecting your online empire. 

[hamopeche 778]

What about the password recovery links not being password recovery links, but instead security bypass links?

[Jihan 5,468]

The fix did NOT address the issue which causes logins to fail. I am still not able to login without using the password bypass mechanism.

[FenrisDDevil 3,473]

Agreed with jihan and hamo above. Additionally:

 

I am not sure the recovery button is supposed to send emails with new tokens each time you click on it.

I received 10 mails in a matter of seconds because it didn't respond at first and I kept clicking.

It should only send the email once..

Edited July 10, 2015 by Fenris DDevil

[Jihan 5,468]

Also, previously sent bypass tokens were NOT expired. I just logged in with one.

[Jihan 5,468]

OK, old bypass tokens have now been expired. The original problem of being unable to login without a bypass token still remains, however.

[Jihan 5,468]

It looks like all 2FA users are unable to login without using a bypass token.

[Pann 8,689]

Yes, that will be addressed in a future update. 

[Jihan 5,468]

Also, I hope that the described end state ("tokens that are immediately destroyed after use") will not preserve the current functionality of permitting login without a 2FA code. Once 2FA is implemented on an account it should not be possible to log into that account without a 2FA code by any means, short of having a live conversation with ACE support and removing the 2FA security level.

 

There's no point in locking all your doors but one.

[hamopeche 778]

Yes, that will be addressed in a future update. 

 

I'm not convinced the weight of the situation is landing with full force.

 

1) The only way to login is with a security bypass link, which is a serious security vulnerability.

2) Every single user has had existing privileged sessions invalidated, so every single user is now required to login.

 

Your team has just forced every single one of your users into the security vulnerability.

[FenrisDDevil 3,473]

^^^

 

except users that haven't activated 2FA yet

Edited July 10, 2015 by Fenris DDevil

[hamopeche 778]

^^^

 

except users that haven't activated 2FA yet

 

Ahh, I didn't realize non-2FA users don't have an authentication issue. They've still forced their vulnerability pool to be much larger than it otherwise would have been. Reflexive reactions to security issues almost always make the situation worse.

[Jihan 5,468]

2fa users are able to log in normally now.

[Mox 1,284]

I hope everything's going be fixed asap, cheers .

[Tyrant 6,553]

Hopefully everyone understands that your email is how we communicate with you about your account. (so it should be under 2FA)  And if your email is compromised, then you are going to have security issues that go way beyond Crowfall.

 

As Pann noted, we'll have more code updates coming for this, including later today.

[budkin 110]

As part of ensuring self-help/change password session tokens were invalidated after one hour, the tests for a valid 2FA value were also strengthened causing a comparison failure - in more technical terms - we were loosely comparing a string and an integer and changed to correctly comparing an integer with an integer - this has been updated to ensure an integer is being processed on both sides of the comparison and so 2FA is working once more during login.

[hamopeche 778]

Hopefully everyone understands that your email is how we communicate with you about your account. (so it should be under 2FA)  And if your email is compromised, then you are going to have security issues that go way beyond Crowfall.

 

As Pann noted, we'll have more code updates coming for this, including later today.

 

Here's a pretty decent read on what considerations going into the design of an access recovery feature, with exploration of the security concerns:

Everything you ever wanted to know about building a secure password reset feature

 

Notably, this writeup, while extensive, does not directly address the authentication bypass concern present with crowfall.com's current not-actually-a-password-reset feature. That concern, for those not following along, is that the link sent in the ostensible password reset email is not a link to reset the password, but a link to bypass authentication entirely and grant anyone with the link privileged access to the account tied to the email address the link was sent to.

 

It may seem that, once we are willing to send privileged functionality to an email account, anything we then send is roughly equivalent to anything else we might send. This is outright false.

 

There are, broadly speaking, two categories of privileged functionality we might send to an email account in an access recovery scenario: temporary functionality, and persistent functionality. Examples of temporary functionality are single-use passwords and password reset links. Examples of persistent functionality are multi-use (typically, non-expiring) passwords and authentication bypass links.

• Temporary functionality gives the recipient (who may or may not be the requestor; and, importantly, may or may not be the account holder) the ability to change the authentication details of the account, once (ideally) or for a very limited time. Whether a reset link (dramatically preferable) or a temporary password, the consequence of using the temporary functionality is that there will be a change to the authentication details of the account before any of the account's privileges can be leveraged.
• Persistent functionality gives the recipient (see qualifications cited above) the ability to leverage the account's privileges with no change of the authentication details, effectively in perpetuity.

 

The difference, here, is whether leveraging the functionality sent to an email account results in a change of the account's authentication details.

 

Obviously, if a person forgot their password, an authentication bypass link doesn't help them beyond the short term, because they still don't know their password and therefore can't change it, so they have to generate new links every time they want to login. At this point, there might as well not be an authentication system beyond sending an emailed link.

 

The primary security issue, however, is that when there is no requirement to change the authentication details, it enables a variant of the Man-in-the-Middle Attack. An eavesdropper with access†, even temporary, to the account holder's email can leverage persistent functionality to gain ongoing access to the account's privileges, without anyone ever knowing. When the authentication details are required to be changed before account privileges are available, in order for the attacker to misappropriate those privileges they must make a change which will lock out the account holder. This alerts the account holder, at next login attempt, to an errant situation, which gives the account holder the opportunity at least to remove the attacker's access (by resetting the authentication details themselves), and gives an attentive account holder indication that an attack has occurred. When account privileges are available without changing authentication details, the attacker can misappropriate those privileges in perpetuity without detection.

 

Authentication bypass is a gaping security hole, no matter the good intentions of the system.

 

 

† Discovering a person's password, encountering an unlocked laptop, finding an unsecured phone, using a shared email account, etc.

[Jihan 5,468]

Shorter hamopeche: Tyrant's response indicates, to those who understand information security, that either ACE does not understand security or is not serious about security.

 

There's no shame in the first if you're willing to accept feedback from experts and correct the issues raised. I have confidence that it's not the second.