2

Are there ("not insignificant") security implications to using the same OTP secret across multiple servers?

On my network, I'm running gitlab-ce, nextcloud, and LTB self-service password among a few other services. GL and NC both support 2FA via TOTP, but as individual add-ons and not via a central auth (such as LDAP) or some other shared way.

I'm working on a PR to SSP to enable 2FA for the password-change, but then I wonder if it'd be possible to have GL use the same LDAP-stored OTP secret. I want to suggest supporting this to GL, but only if it does not weaken the system.

The consequence of not centralizing it is not huge: each app/server will store its own 2FA secrets, so the user must manage them all individually. Unlike passwords which don't technically require a password-manager, I don't know of anybody who is able to remember their OTP secret and generate codes in their head, so users are forced to use a managing app (such as Google Authenticator or FreeOTP Authenticator). Reducing from a list of multiple secrets to one is mostly just convenience.

Similarly, besides convenience, are there known advantages to centralizing OTP secret storage?

r2evans
  • 125
  • 8
  • My first instinct is that using the same secret on multiple servers would make your setup vulnerable to replay attacks, but I can't immediately substantiate that. :) – HBruijn Nov 07 '16 at 19:05
  • I hadn't considered mathematical weakening, that's very interesting (and will be sufficient if true), thanks! – r2evans Nov 07 '16 at 19:06

1 Answers1

3

The problem is that as @HBruijn pointed out, that the TOTP value you used to login to one service can be used by the attacker to login to another service. And this within a time windows from maybe two minutes. Although your timestep might only be 30sec, the RFC specifies that the validating service should search the OTP value back and forth in time. This is recommended due to the drift of the clock. https://www.rfc-editor.org/rfc/rfc6238#section-6

The other point is, that your whole system is only as secure as the weekest part. If any of the systems/databases looses the OTP secret, all systems are compromized.

As you finished your question you should think about using a centralized system, which stores the secrets and performs the validation. This way there is no possibility of replay attacks and you only have to secure the OTP secret in one place.

You might want to take a look at privacyIDEA, which exactly does this. It is an authentication system, which manages authentication devices like TOTP tokens or Apps for users centrally. All applications authenticate against this service. (Disclaimer: I am core developer of privacyIDEA)

The problem with this is, that all connected applications need to be connected, i.e. each application must be able to talk to privacyIDEA. For this the application must be able to either act as a RADIUS client or talk to the authentication REST API. There are several plugins out the for many different applications like OTRS, ownCloud, Wordpress, dokuwiki, Typo3...

Community
  • 1
cornelinux
  • 229
  • 1
  • 7
  • I hadn't run across privacyIDEA before, thanks for the recommendation (and plug). (Any chance you'll update the docker image of it?) – r2evans Nov 09 '16 at 04:19
  • It looks like the ownCloud client authenticates solely with the user password or solely with the OTP, never with both. If I missed something, the docs are a bit misleading. If this is true, however, how is this 2FA and not just OTP 1FA? (Plus I could not find the `user_privacyidea` directory to copy to owncloud, it's not under `authmodules`.) – r2evans Nov 09 '16 at 06:09
  • The ownCloud client (desktop client) can do real 2FA. This is a matter of the limited authentication protocol, which owncloud uses. – cornelinux Nov 09 '16 at 21:09