7

We have a public website for employees which has access to some sensitive company information. To make the login process more secure we want to implement TOTP. The setup and implementation has been quite straight forward. What I'm not clear on is the best way to store the seed for each user.

It obviously can't be salted and hashed as you need it to generate the time based code. MD5 type encryption seems a bit pointless given how quickly it can be decrypted, so my question is what is the best way to store the seed, and is it ok to store it in the same table as the username and password?

Improve this question

3 Answers 3

Reset to default
1

MD5 type encryption seems a bit pointless given how quickly it can be decrypted,

Don't get your terminology mixed up. MD5 is a hash algorithm, not an encryption algorithm. There is a world of a difference between the two.

To answer your question, I don't see an issue with storing the seed unencrypted together with the username and password in a database. A TOTP seed is easy enough to reset if you ever get compromised. You need the seed in cleartext for the algorithm to work anyway.

Improve this answer
5
  • 2
    Resetting the seed when using Google Authenticator as TOTP provider may be easy but will be impossible when using a hardware token with the seed 'burnt in'.
    – Jeff
    Commented Sep 23, 2013 at 18:24
  • @Jeff You are right of course. I did not consider that scenario.
    – user10211
    Commented Sep 24, 2013 at 0:48
  • @Jeff, not a problem for us in the case as we're using mobile phone applications, but I see your point
    – Greg
    Commented Sep 25, 2013 at 2:45
  • @greg may I suggest that you consider marking my answer as "correct" so as not to confuse newcomers. As has been pointed out, having hardware tokens makes it expensive to recycle the TOTP seeds. If your clear text seed table is compromised, you would need to redistribute seeds to all users. Also consider that setting the TOTP seed in a software token is a delicate process that you should not perform too often.
    – Emil
    Commented Jun 11, 2018 at 21:01
  • Passwords are also easy enough to reset if compromised, too. Your reasoning does not make sense.
    – schroeder ♦
    Commented Feb 21, 2022 at 8:30
7

According to RFC 6238, the RFC concerning TOTP, you should store your keys securely by encrypting them with tamper-resistant hardware encryption, expose them only when required, and limit time in the RAM as unencrypted keys.

https://datatracker.ietf.org/doc/html/rfc6238#section-5

Improve this answer
2

I would highly recommending encrypting the seed. However easy it may be to re-distribute seeds for your TOTP applications, a compromise would mean that an adversary is capable of instantly computing the second factor of your 2FA login.

Improve this answer
2
  • @Emil - if compromised, would you still consider the seed secure even if it was encrypted? Is the hope just that they will not see the value in finding the key? Or is it that you can replace the seed for all users before the 2nd factor is decrypted?
    – Greg
    Commented Jun 12, 2018 at 1:50
  • If the seeds are properly encrypted, the seeds will remain secure for practical purposes as long as the encryption key is not compromised of course. Since the seeds themselves are random, an attacker will have to resort to brute force in order to decrypt the data. To be able to validate a successful decryption, the attacker would need to reproduce a valid OTP (which has either been intercepted or produced by an actual token). Together, this renders an offline attack on the database table impractical.
    – Emil
    Commented Jun 13, 2018 at 8:39

You must log in to answer this question.

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