Page MenuHomePhabricator

Enable optional two-factor authentication for OTRS
Open, MediumPublic

Assigned To
None
Authored By
Ireas
Dec 22 2015, 5:14 PM
Tokens
"The World Burns" token, awarded by Framawiki."Piece of Eight" token, awarded by Effeietsanders."The World Burns" token, awarded by OldUser02."The World Burns" token, awarded by Steinsplitter."Like" token, awarded by Thibaut120094.

Description

Once OTRS 5 is deployed (T74109), we should consider enabling optional two-factor authentication for OTRS agents (2FA, see the release notes for OTRS 5 Beta 2, What’s New, section 3). It does not seem to be difficult to enable it, and it would allow agents who are familiar with 2FA to increase the security of their accounts.

The background for this request is that the WMF Security Team will be working on two-factor authentication for Wikimedia projects in the next quarter (cf. their schedule on meta). OTRS access should be protected with reasonable security mechanisms too.

Event Timeline

Ireas created this task.Dec 22 2015, 5:14 PM
Ireas raised the priority of this task from to Needs Triage.
Ireas updated the task description. (Show Details)
Ireas added a project: OTRS.
Ireas added a subscriber: Ireas.
Restricted Application added subscribers: StudiesWorld, Matthewrbowker, Rjd0060 and 2 others. · View Herald TranscriptDec 22 2015, 5:14 PM
Krenair added a subscriber: Krenair.

In my opinion, access to OTRS is even more sensitive than access to MediaWiki accounts.

Uhh... That depends on which MediaWiki accounts.

Ireas updated the task description. (Show Details)Dec 22 2015, 5:31 PM
Ireas set Security to None.
Ireas added a comment.Dec 22 2015, 5:34 PM

In my opinion, access to OTRS is even more sensitive than access to MediaWiki accounts.

Uhh... That depends on which MediaWiki accounts.

You are right. I was only considering the private information available to most users / agents. I removed that sentence from the task description.

Steinsplitter moved this task from Incoming to Backlog on the OTRS board.Jan 20 2016, 5:19 PM
Restricted Application added a subscriber: TerraCodes. · View Herald TranscriptNov 12 2016, 5:11 PM
Thibaut120094 triaged this task as High priority.Nov 12 2016, 5:11 PM
revi added a subscriber: revi.Nov 12 2016, 5:11 PM
FDMS added a subscriber: FDMS.Nov 12 2016, 5:13 PM
OldUser02 added a subscriber: OldUser02.

Note: 2FA is now available for admin on wikimedia wikis and on OTRS Wiki. Likely this should be priority as well.

DatGuy added a subscriber: DatGuy.Nov 13 2016, 12:17 PM
DC added a subscriber: DC.Jan 20 2018, 2:22 PM
OldUser02 awarded a token.
OldUser02 added a comment.EditedFeb 19 2018, 1:08 PM

Is there a way to push this ticket? OTRS contains very sensitive information (especially in oversighter queues) and security should be a priority.

Last week, someone tried to access my account using password reset on my email account + OTRS account...

In T122220#3983280, @Scoopfinder wrote:

Is there a way to push this ticket? OTRS contains very sensitive information (especially in oversighter queues) and security should be a priority.

You just did. I 've enabled Frontend::Agent::Auth::TwoFactor::AuthTwoFactorModule. The only valid value is GoogleAuthenticator and only the time based part (TOTP, see RFC 6238). It's set as optional so users that don't want to enable it right now are not force to, but it is possible to do so. The login page has changed already a bit and allows entering that.

Now enabling 2FA for one's account is a bit weird. Unlike the usual services where a QR code is displayed, the user is required to enter a key in the AgentPreferences screen in the Change Password section under "2 Factor Token" (confusingly this seems to be the key, not a token). One does need to also enter the Current password (and looks like also a new password, but it can be the same as the current one). That key then is to be entered as well in the creation of a new entry in the Google Authenticator app. The entry should be configured to be time based (which is the default). This is not a very friendly user interface overall and I fear it is going to limit the adoption.

Let's keep it enabled for some time and see what kind of feedback we get and reevaluate.

Last week, someone tried to access my account using password reset on my email account + OTRS account...

Ouch. Looks like indeed you need 2FA.

Josve05a added a comment.EditedFeb 21 2018, 12:24 PM

Works for me (unless it would have accepted anything at all. Just logged in with 2FA and AI got logged in.) :D the key needed to be 16 letters GoogleAuth

Hello @akosiaris and thank you for responding to my cry for help. :-)

Now enabling 2FA for one's account is a bit weird. Unlike the usual services where a QR code is displayed, the user is required to enter a key in the AgentPreferences screen in the Change Password section under "2 Factor Token" (confusingly this seems to be the key, not a token). One does need to also enter the Current password (and looks like also a new password, but it can be the same as the current one). That key then is to be entered as well in the creation of a new entry in the Google Authenticator app. The entry should be configured to be time based (which is the default). This is not a very friendly user interface overall and I fear it is going to limit the adoption.

Unfortunately, I couldn't make it work yet. I will try again later in the day when I have more time.

If I got it to work

Step 1. Go to OTRS user settings
Step 2. Enter your old password and your ‘new’ (or same password)
Step 3. Enter a 16 (lower capital?) letter-key of your choice
Step 4. Press change password
Step 5. Create a new 2FA in Google authenticator
Step 6. Enter your 16-char key and an account name
Step 7. Choose timer based tokens
Done

@Josve05a : I did as mentioned, but still can login without 2FA or with a random 2FA. Did you try to check this too? (maybe I am the one doing sth wrong)

In T122220#3988921, @Scoopfinder wrote:

@Josve05a : I did as mentioned, but still can login without 2FA or with a random 2FA. Did you try to check this too? (maybe I am the one doing sth wrong)

No, I didn’t failcheck it, only checked if I could get in. Hmm...

In T122220#3988921, @Scoopfinder wrote:

@Josve05a : I did as mentioned, but still can login without 2FA or with a random 2FA. Did you try to check this too? (maybe I am the one doing sth wrong)

Same here, The shared secret is getting ignored.

Looking at the code it does look like the "2 Factor Token" in AgentPrerefences is checked when updating one's password. As an extra security precaution that is. So my initial assertion was wrong and what 've been testing a moot point. I 've yet to find where in the web interface an Agent is meant to set the key and no documentation exists

Reading the code more I 've managed to find the following setting PreferencesGroups###GoogleAuthenticatorSecretKey that needs to be enabled for a panel to show up in AgentPreferences allowing to enter the shared key. Unfortunately there seems to be some bug in the code and I get in the logs

[Notice][Kernel::System::Auth::TwoFactor::GoogleAuthenticator::Auth] User: Alexandros Kosiaris two factor authentication failed (non-matching otp).

I triple checked the key in my app and OTRS but they are the same. The file responsible for the authentication part seems to have had quite a few changes and at least 1 fixed bug related to timezones. https://github.com/OTRS/otrs/commits/master/Kernel/System/Auth/TwoFactor/GoogleAuthenticator.pm. Unfortunately that fix does not apply directly to our codebase and many of the above changes have not been ported to OTRS 5 but are rather OTRS 6 related.

Given all of the above I am thinking about disabling this once more and wait at least for the upgrade to OTRS 6 before reenabling it. That is however going to take quite a while from the looks of it and is going to be a major upgrade.

Keegan added a subscriber: Keegan.Feb 21 2018, 6:45 PM

Given all of the above I am thinking about disabling this once more and wait at least for the upgrade to OTRS 6 before reenabling it. That is however going to take quite a while from the looks of it and is going to be a major upgrade.

I'd rather have it disabled than turned on and broken.

Josve05a added a comment.EditedFeb 21 2018, 7:13 PM

I'd rather have it disabled than turned on and broken.

Well, security theater (real thing) might be a good deterrent against so called hackers trying to gain access by force testing passwords.

akosiaris changed the task status from Open to Stalled.Feb 22 2018, 7:27 PM
akosiaris lowered the priority of this task from High to Medium.

I 've disabled the functionality. I 've conducted multiple tests and never got it to work. I am setting this to stalled, we should revisit when we have upgraded to 6.x.x (or if some patches about this land in 5.0.26+)

RP88 added a subscriber: RP88.Oct 1 2018, 1:20 PM
Restricted Application added a subscriber: Krd. · View Herald TranscriptMar 10 2019, 9:41 AM
Meno25 added a subscriber: Meno25.May 31 2019, 12:22 PM

Now that we've upgraded to OTRS 6, I'm happy to be a volunteer to test this.

Ditto, happy to test.

ElHef added a subscriber: ElHef.Wed, Sep 16, 4:06 PM

As would I, just say the word

Kb03 added a subscriber: Kb03.Wed, Sep 16, 4:11 PM

Got another lab rat here, just say when

+1 to the lab rat queue, I'd love to test this.

AntiCompositeNumber changed the task status from Stalled to Open.Wed, Sep 16, 5:56 PM

❤️ to all of you.

I 've enabled the 2 settings required (the global on/off and small dialog in the preferences to enter the TOTP secret). I must say that the user experience has definitely improved in this version. There is now no need to generate the TOTP secret on your own, but there is a GENERATE button that creates one. There isn't unfortunately a QR code or something similar that would make it really easy to enter it in e.g. GoogleAuthenticator, so it requires some manual work to set it up in an app, but it's rather straight forward. No docs however exist for it, so it might make sense to create some (I guess in OTRS wiki?).

There is now a 2 factor field when logging in. If a user has created a TOTP secret in their prefs a TOTP token is required, otherwise it can be left blank (this might make sense to document and communicate as well).

There is also a 2 factor field when changing one's password. Same thing as above applies.

Please give it a try.

I was able to set it up in Google Authenticator without issue and it seems to be behaving. (Wouldn't let me log in with a blank or wrong code, and did let me log in with the right one.) It is somewhat confusing and fairly easy to mess up though. Agree with previous comment about documenting and communicating about the blank 2FA field when logging in. Manual entry of the shared secret seems like it would be fairly easy to accidentally brick your account, especially since I'm not seeing anywhere that it generates scratch codes.

Manual entry of the shared secret seems like it would be fairly easy to accidentally brick your account, especially since I'm not seeing anywhere that it generates scratch codes.

Which just made me realize that we need some documented process (that multiple people can run) to allow resetting/removing the 2FA secret of a user that has e.g.

  • Messed up the process by mistake
  • Lost their phone/store where codes are
  • Delete by mistake the app from their phone
  • Something else that current eludes me and leaves the user without access to a valid 2fa token generator.
Kb03 added a comment.EditedThu, Sep 17, 2:08 PM

Possibly PGP signing (preferred for me) or committed identity like enwiki to verify identity (see en.wikipedia.org/wiki/User:Kb03 for an example)

I have also enabled 2FA on my account. It's a bit of a scary process currently - I'm used to being asked that 2FA is set up correctly by inputting a code. Instead, the interface just assumes that you're set up correctly, which makes it easy to lock your account.

Manual entry of the shared secret seems like it would be fairly easy to accidentally brick your account, especially since I'm not seeing anywhere that it generates scratch codes.

Which just made me realize that we need some documented process (that multiple people can run) to allow resetting/removing the 2FA secret of a user that has e.g.

  • Messed up the process by mistake
  • Lost their phone/store where codes are
  • Delete by mistake the app from their phone
  • Something else that current eludes me and leaves the user without access to a valid 2fa token generator.

Interestingly, the OTRS Admins have access to the shared secret. Which is an immense oversight (and all the more reason to require 2FA for admins), but would allow us to remove 2FA from the account as far as I can tell. More testing would be needed, but I was able to confirm that I could see Alexandros' secret (sorry mate!)

I have also enabled 2FA on my account. It's a bit of a scary process currently - I'm used to being asked that 2FA is set up correctly by inputting a code. Instead, the interface just assumes that you're set up correctly, which makes it easy to lock your account.

Manual entry of the shared secret seems like it would be fairly easy to accidentally brick your account, especially since I'm not seeing anywhere that it generates scratch codes.

Which just made me realize that we need some documented process (that multiple people can run) to allow resetting/removing the 2FA secret of a user that has e.g.

  • Messed up the process by mistake
  • Lost their phone/store where codes are
  • Delete by mistake the app from their phone
  • Something else that current eludes me and leaves the user without access to a valid 2fa token generator.

Interestingly, the OTRS Admins have access to the shared secret. Which is an immense oversight (and all the more reason to require 2FA for admins), but would allow us to remove 2FA from the account as far as I can tell. More testing would be needed, but I was able to confirm that I could see Alexandros' secret (sorry mate!)

Ahahaha. Ok it makes sense that they would be able to remove it as I 'd expect OTRS admins to do the action outlined above but see it? that's golden...

Krd added a comment.Thu, Sep 17, 4:04 PM

I appreciate that we have that feature now and do test it, but I second akosiaris' statement above that we don't have any process yet to recover an account. I guess if anybody locks out themselves at the moment we could be unable to recover the account. Please consider that OTRS admins may not have enough resources for assistance at the moment.
If 2fa forces us to rely on anything not verifyable during account recovery, it perhaps doesn't add much additional security.

Steinsplitter added a comment.EditedThu, Sep 17, 4:44 PM

Please consider that OTRS admins may not have enough resources for assistance at the moment.

I had to search this bug in order to check if 2FA is ready for production on OTRS. There is some kind of danger that OTRS agents are not looking into this bug and therefore sooner or later there will be requests like "Lost key, can't login".

Likely it should be noted somewhere (OTRS Wiki)?

I appreciate that we have that feature now and do test it, but I second akosiaris' statement above that we don't have any process yet to recover an account. I guess if anybody locks out themselves at the moment we could be unable to recover the account. Please consider that OTRS admins may not have enough resources for assistance at the moment.
If 2fa forces us to rely on anything not verifyable during account recovery, it perhaps doesn't add much additional security.

This is my biggest concern as well. My feeling, at least for the trial period, would be to require a post to [[AR]] on OTRS wiki. But, if we have to remove their 2FA token we also scramble their password and force them to reset it.

Long-term, we need a better solution (like a committed identity that enwiki has) - but all of that is taking more time from an already stretched thin admin team.

Another question/idea would be: How hard are OTRS modules to build? We could theoretically build an enhanced version of the built-in 2FA module, which allowed for scratch codes and hide the generator token.

I appreciate that we have that feature now and do test it, but I second akosiaris' statement above that we don't have any process yet to recover an account. I guess if anybody locks out themselves at the moment we could be unable to recover the account. Please consider that OTRS admins may not have enough resources for assistance at the moment.
If 2fa forces us to rely on anything not verifyable during account recovery, it perhaps doesn't add much additional security.

This is my biggest concern as well. My feeling, at least for the trial period, would be to require a post to [[AR]] on OTRS wiki. But, if we have to remove their 2FA token we also scramble their password and force them to reset it.

Long-term, we need a better solution (like a committed identity that enwiki has) - but all of that is taking more time from an already stretched thin admin team.

Another question/idea would be: How hard are OTRS modules to build? We could theoretically build an enhanced version of the built-in 2FA module, which allowed for scratch codes and hide the generator token.

A more suitable question would be "How costly are OTRS modules to maintain?" as I my experience up to now with OTRS modules is that most of their cost goes into maintenance and not building them. And since we would be probably patching the current implementation, it would be considerable. We would need to find someone to do build it and maintain it down the road.

I appreciate that we have that feature now and do test it, but I second akosiaris' statement above that we don't have any process yet to recover an account. I guess if anybody locks out themselves at the moment we could be unable to recover the account. Please consider that OTRS admins may not have enough resources for assistance at the moment.
If 2fa forces us to rely on anything not verifyable during account recovery, it perhaps doesn't add much additional security.

This is my biggest concern as well. My feeling, at least for the trial period, would be to require a post to [[AR]] on OTRS wiki. But, if we have to remove their 2FA token we also scramble their password and force them to reset it.

Long-term, we need a better solution (like a committed identity that enwiki has) - but all of that is taking more time from an already stretched thin admin team.

Another question/idea would be: How hard are OTRS modules to build? We could theoretically build an enhanced version of the built-in 2FA module, which allowed for scratch codes and hide the generator token.

A more suitable question would be "How costly are OTRS modules to maintain?" as I my experience up to now with OTRS modules is that most of their cost goes into maintenance and not building them. And since we would be probably patching the current implementation, it would be considerable. We would need to find someone to do build it and maintain it down the road.

Would... this be a bad time to mention that I know Perl? While I could maintain it, I don't know how to build an OTRS module, so it might take a bit to build.

ElHef added a comment.Fri, Sep 18, 7:10 PM

As another issue I see with this, the shared secret stays openly viewable in my preferences after being set. It's right below the password change fields, which ask for a 2FA token (presumably as a security check). Rather defeats the purpose of asking for that if you can just grab the secret and generate a code...