Feature #117

Two factor auth for https://panel.bitfolk.com/

Added by halleck over 11 years ago. Updated over 8 years ago.

Status:Closed Start:2014-01-12
Priority:Normal Due date:
Assigned to:- % Done:

0%

Category:-
Target version:-
Votes: 4

Description

It would be a good thing to have the option of making ones https://panel.bitfolk.com/ login two-factor, by also requiring a Yubikey.

History

Updated by admin about 11 years ago

  • Subject changed from Yubikey auth for https://panel.bitfolk.com/ to Two factor auth for https://panel.bitfolk.com/

Updated by admin about 11 years ago

Would people consider the Google two factor auth mobile app in TOTP mode good enough for this?

Updated by halleck about 11 years ago

Yeah, I guess Google Auth style TOTP is a more realistic option, and a clear improvement.

Personally I'd be happy with that solution too.

Updated by halleck about 11 years ago

(That is, a clear improvement to just having a regular password login.)

Updated by robert about 9 years ago

I just wanted to register my support for this. TOTP is now a widely deployed, mature technology and given that gaining access to the panel is enough for a complete compromise of a customers VPS my view is that MFA is essential. Certainly when I am evaluating new services for running infrastructure, MFA is now a hard requirement.

Updated by admin about 9 years ago

I assume use of optional 2FA should be incompatible with any form of automated email password reset, yes?

Updated by robert about 9 years ago

Definitely, I think it's fair to say that someone prepared to enable MFA is accepting responsibility for not losing their password under any circumstances - and would probably want a very stringent process to get it unlocked if something goes bad (e.g. GPG, two forms of id, etc.). Most services I use that support MFA offer text message as a fallback, which is useful as a mobile number can be recovered if you lose access to the device that has all your MFA accounts attached to it.

Updated by admin about 9 years ago

We are also going to need to either use the same 2FA for SSH to Xen Shell, or else allow it to be made key-only. As it stands you can't actually do anything destructive via web panel, but you certainly can from Xen Shell.

Updated by admin about 9 years ago

Is it actually justified to disable email password resets just because two-factor authentication is enabled?

If 2FA is enabled then obtaining a new password by email still doesn't give an attacker access to anything.

Is it not the case that it's only the 2FA part that shouldn't be able to be reset/disabled by email?

Updated by admin about 9 years ago

I've implemented TOTP 2FA on the panel test site and would appreciate some user testing of it to check it is fit for purpose.

You can log in at https://testpanel.bitfolk.com/ with your real credentials. It is currently connected to the real customer database so changes you make will be real. However, there is no 2FA on the real panel site yet so you can't lock yourself out of the real site. I will purge any TOTP keys and set everyone back to TOTP disabled before deploying it to live.

So please could you have a look at it and see if it works how you want/expect?

Updated by robert about 9 years ago

I've just set up MFA on the test panel and it works perfectly!

Updated by halleck about 9 years ago

Ok, I have now done some quick testing at enabling 2FA at https://testpanel.bitfolk.com/, and it logging in appear to succeed when it's supposed like, as well as failing when it's not supposed to.

I would suggest requiring that the user enters a valid TOTP code during the 2FA setup process.

Updated by admin about 9 years ago

robert wrote:

I've just set up MFA on the test panel and it works perfectly!

Good to hear. Are you happy with how it is set up, things like…

  • being able to see the QR code, key and three valid tokens at any time from the security page
  • disabling of email password reset when MFA is enabled
  • always show input box for MFA token on same page as user/password inputs regardless of whether it will actually be checked

etc?

Updated by halleck about 9 years ago

halleck wrote:

...logging in appear to succeed when it's supposed like, as well as failing when it's not supposed to.

Ok, that part about the failing might have turned out a big ambiguous. What I meant is that the login is failing in situations where the login ought to fail, hence the failing being the desired result.

In short, it's all good.

Updated by admin about 9 years ago

halleck wrote:

I would suggest requiring that the user enters a valid TOTP code during the 2FA setup process.

Ah good idea, so like, it asks you to put a token in and only enables 2FA if you get that right?

Updated by halleck about 9 years ago

admin wrote:

Ah good idea, so like, it asks you to put a token in and only enables 2FA if you get that right?

Yepp.

Updated by robert about 9 years ago

admin wrote:

robert wrote:

I've just set up MFA on the test panel and it works perfectly!

Good to hear. Are you happy with how it is set up, things like…

  • being able to see the QR code, key and three valid tokens at any time from the security page

Without knowing enough about how TOTP works behind the scenes, it seems disclosing these pieces of information is akin to having a way for someone to see their current password. If the user wants to set up a new authentication device, I think the correct thing would be for them to regenerate a new key and invalidate the old one.

  • disabling of email password reset when MFA is enabled

That makes sense.

  • always show input box for MFA token on same page as user/password inputs regardless of whether it will actually be checked

Most sites I use ask for the digits on a subsequent page once you have entered your password, others have it under a show/hide box.

Updated by heavy-lifting about 9 years ago

I've just added 2FA and configured it using 1Password and it seems to work fine. Even without really known what I was doing - the TOTP feature on 1Password was news to me - it was easy to set up.

Updated by admin about 9 years ago

heavy-lifting wrote:

the TOTP feature on 1Password was news to me - it was easy to set up.

Thanks, good to know that one works nicely. I've only tried Google Authenticator myself so far.

Updated by admin about 9 years ago

There's a report that the key can't be added using Google Authenticator on iPhone 5s. The error message is:

The barcode 'otpauth://totp/BitFolk Panel (XXX)?secret=…' is not a valid authentication token barcode.

I don't have an iPhone I can test this with. Is anyone successfully using this with Google Authenticator on iPhone?

Personally I am using Google Authenticator on Android.

Updated by admin about 9 years ago

robert wrote:

admin wrote:

  • being able to see the QR code, key and three valid tokens at any time from the security page

Without knowing enough about how TOTP works behind the scenes, it seems disclosing these pieces of information is akin to having a way for someone to see their current password. If the user wants to set up a new authentication device, I think the correct thing would be for them to regenerate a new key and invalidate the old one.

Point taken, I will remove these.

  • disabling of email password reset when MFA is enabled

That makes sense.

But does it? Why? If MFA is enabled then even if you take over someone's email account you still can't gain access. Is there a reason to link enabling MFA with disabling email password reset? So far all I have seen is "if you've enabled MFA you're probably security-conscious enough to not want email password reset." In which case you could just disable that.

You might be shocked at how many BitFolk customers apparently do not keep any track of their account password and just reset it every time they want to use it. I am worried that forcing password reset to be disabled will reduce the number of people willing to enable MFA.

  • always show input box for MFA token on same page as user/password inputs regardless of whether it will actually be checked

Most sites I use ask for the digits on a subsequent page once you have entered your password, others have it under a show/hide box.

I use two sites that have it up front on the login page, and I copied that design because it means not having to wait for another form to load before logging in. I rejected the idea of having the token input field initially hidden for the same reason: so people don't have to click some UI element to show the token input field.

Is it better/necessary to not show the token input field by default?

I suppose something I could do is have it initially hidden but the first time someone displays it, a cookie is set that makes it always be displayed for them in future. That might be stretching my JS skills though, and that's probably not a good reason to delay deployment.

Updated by admin about 9 years ago

admin wrote:

There's a report that the key can't be added using Google Authenticator on iPhone 5s. The error message is:

The barcode 'otpauth://totp/BitFolk Panel (XXX)?secret=…' is not a valid authentication token barcode.

I don't have an iPhone I can test this with. Is anyone successfully using this with Google Authenticator on iPhone?

Personally I am using Google Authenticator on Android.

Something to investigate:

16:11:18 <+Tolien> I get that error with the iOS Google auth app too. looks like it expects the name in the QR code to not have spaces in it

16:11:54 <+Tolien> if you change the "Bitfolk Panel (x)" to "BitfolkPanel(x)" it scans correctly

16:18:42 <@grifferz> interesting. I have existing keys for other web sites that have spaces in. but I will change it to underscores and see if it helps the original reporter. thanks!

Updated by sarah-jane about 9 years ago

So I logged in to testpanel in Chrome, with TOTP enabled. I mistyped by OTP and got "Epic Fail". I typed the code in correctly and logged in.

I then opened up MS Edge (IE on Win10), went to the login page and was able to login with the SAME 6-digit OTP for Panel(448).

I had never been to the site before on MSIE as I only use this software when Chrome can't cope (i.e. very rarely) or if I want to keep it out my browsing history (ahem!)
Both connections are proxies by my EL5 Squid in Bitfolk.

Updated by sarah-jane about 9 years ago

I can confirm that removing the spaces made Google Authenticator on iPhone work.

I can also confirm that replacing the spaces with %20 made it work, and showing the CORRECT authentication OTP's.

QR's generated at: http://dan.hersam.com/tools/gen-qr-code.html

It would be nice if you could also add to the URL: &issuer=Bitfolk%20Panel - to have a nice label at the top of the OTP as I have several codes in my authenticator now.

Updated by admin about 9 years ago

So I logged in to testpanel in Chrome, with TOTP enabled. I mistyped by OTP and got "Epic Fail". I typed the code in correctly and logged in.

I then opened up MS Edge (IE on Win10), went to the login page and was able to login with the SAME 6-digit OTP for Panel(448).

Yes, this will happen because each token is valid for 30 seconds. Also to allow for clock skew the previous and next tokens are also considered. So a potential worst case is that a used token is still valid for almost 90 seconds.

I have access to 3 other services that use TOTP and all of them allow this reuse within the time period. It would be possible to avoid it by keeping track of last used token per user, which would also prevent yourself from logging in twice within 30 seconds. I'm not convinced this is really necessary, but if people are bothered by the possible reuse then I would be happy to work on it as a post-deployment improvement. I really don't want to make it a per-user option as that just starts to offer too many options.

The scenario that's being protected against here is something like a keylogger that gets all your credentials. They would then have up to 90 seconds to log in as you before the token expired.

So, expiry of token upon use - necessary or not?

Updated by admin about 9 years ago

I can also confirm that replacing the spaces with %20 made it work, and showing the CORRECT authentication OTP's.

Okay so rather than replacing with underscores I will try URI-encoding it.

It would be nice if you could also add to the URL: &issuer=Bitfolk%20Panel - to have a nice label at the top of the OTP as I have several codes in my authenticator now.

Hmm, it already has a "label=BitFolk Panel (uid)" which shows as the title in Google Authenticator on Android. What are you using that also needs "issuer="? Is this GA in iPhone again?

Updated by admin about 9 years ago

Okay, so based on your feedback I've…

  • Made it require the input of a valid token before 2FA is enabled for real
  • Removed the ability to see the QR code and key
  • Added a button to delete the key (which disables 2FA as well)
  • URI-escaped the label ("BitFolk: UID %u") part of the otpauth URI
  • Added an issuer of "BitFolk" as recommended by https://github.com/google/google-authenticator/wiki/Key-Uri-Format

I haven't yet…

  • Done anything to address token reuse as I'm waiting for feedback
  • Actually deployed the SSH part
  • Changed anything regarding the automatic disabling of email password reset, as no one yet seems to disagree with it

Please could you test deleting your 2FA key and adding a new one again, especially on iPhone?

Updated by robert about 9 years ago

I've tested that, works great for me (Google Authenticator on Android).

Updated by ra about 9 years ago

Works for me adding a new 2FA key with Google Authenticator for iPhone.

When you successfully enter a valid token to confirm, is it worth highlighting the "Congratulations, …" text? When I hit submit, it didn't seem like anything had happened until I noticed that block of text.

Updated by sarah-jane about 9 years ago

I invalidated TOTP for UID 448 and then re-added to Google for iPhone using the latest barcode. Successfully added and verified. Looking good!

TBH I'm not too concerned about re-use, but RFC 6238 is clear that it MUST NOT be accepted. However, as you have discovered, very few implementations enforce this.

But because a successful login generates a very long-lived session cookie, if login's been replayed then the account could be compromised for a long time (I might raise this as a separate issue :)

Updated by admin about 9 years ago

Okay, I will make it keep track of the last successful token and not accept it again.

Updated by admin almost 10 years ago

When you successfully enter a valid token to confirm, is it worth highlighting the "Congratulations, …" text? When I hit submit, it didn't seem like anything had happened until I noticed that block of text.

I've now added cheesy SVG warning / tick mark icons and made the page scroll to the correct place. Is that sufficient?

Ideally it would be done by a pop-over dialog that prompts you through each stage but that is beyond my web skills I'm afraid.

Okay, I will make it keep track of the last successful token and not accept it again.

That's now done.

So as far as I am aware the only outstanding thing is to make it enable / disable 2FA on SSH to Xen Shell.

Updated by admin almost 10 years ago

  • Status changed from New to Feedback

I've now put this live, including 2FA for SSH to Xen Shell. Please give it a bit more testing!

I've disabled 2FA for all of you so it doesn't affect your ability to connect to your Xen Shell, so you'll just need to re-enable it (keys will stay the same).

Updated by robert almost 10 years ago

Thanks Andy.

Updated by admin over 8 years ago

  • Status changed from Feedback to Closed

People seem happy with this now.

Also available in: Atom PDF