2

We are running a web application using a client's identity federation to authenticate users. A new requirement is to use 2FA, we have decided to use an OTP algorithm using Java, similar to this one featured on GitHub.

As per the OTP algorithm, we need to provide a shared secret key for every user to authenticate the OTP code with. In our use case is it a valid/good practice to store a mapping between the secret key and related user(s) in the in-app database so we can later validate the OTP code.

I am new to 2FA, so I am not sure if the above approach is allowed or this is not allowed in web identity federation.

2
  • What is your question? Apr 4, 2018 at 0:21
  • Is it a valid / good practice to store mapping between secret key and related user in app database to validate OTP code although we are using client identity federation
    – K.Pil
    Apr 4, 2018 at 1:19

2 Answers 2

0

This depends on the Identity Provider (IdP) you are using for this purpose.

Case 1 : IdP supports validating TOTP
If your IdP supports validating the TOTP, then you can directly call the api and don't need to store any secret key in your app db.

Case 2 : IdP doesn't support 2FA
In this case, you will have to store the secret key for each user and validate the TOTP in your app itself.

Example : In Shibboleth you can use this with Shibboleth-IdP3-TOTP-Auth extension, whereas some IdPs only supports SMS-based 2-factor authentication.
Baiscally, You have to go with the IdP specification, unless you can choose the IdP. If you have a choice, go for those which supports various kind of multi-factor authentication (TOTP, SMS, Hardware tokens, etc)

0

Yes, you need to store a mapping between the user and the key material, that represents the second factor.

This is also recommended in RFC4226.

You should take care of two things:

  1. Store the key material in an encrypted manner. Of course the encryption key and the key material might be located on the same server. But this at least protects you against sql injections and maybe losses of database backups ;-)

  2. You should implement an 1:n mapping or maybe even a n:m mapping. A user could have more than one second factor. Also a second factor could be used by more than one user.

Having said this all, I am wondering if you really want to implement your own 2FA management system! ;-)

There are a lot solutions out there that are doing a great job. You would probably only have to enhance your login code and not worry about enrolling 2FA, storing encrypted keys and mapping...

Take a look at privacyIDEA, which is a project of mine (disclaimer). In this case, if a user would need to authenticate with a second factor, it boils down to calling the REST API

POST https://yourserver/validate/check
user=fred
pass=128930

Done. You may take a look at the REST API documentation.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .