CODEWITHSUNDEEP
securityhmacsha1
Shashank
Shashank

Reputation: 471

TOTP : Changing secret upon every session

I have such requirement about changing the users secret for every session for generating OTP. We decided to use TOTP as our algorithm to do so. We are sending OTP in SMS to the user for authorization verification (no need to generate OTP at client side). 

TOTP = HOTP(WhereSessionCalculate(SecretKey), TC)

So, Is it good practice to change the secret of an user session wise. If not then what are the consequence that can possibly arise. Please explain and let me know if more information needed.

Upvotes: 0

Views: 1258

Answers (1)

David Williamson
David Williamson

Reputation: 487

The basic premise of two-factor (or multi-factor, to be more accurate) authentication is to supplement the normal username/password combination - these are things you know - with one or more additional factors of a different type. Most commonly used are what you have (e.g. your cellphone, with a Google Authenticator app or an RSA, Gemalto etc. token) or something about what you are (biometric data such as iris, fingerprint etc.)

Someone can learn a username and password from shoulder-surfing (easy if the password is short), even sniff it from an insecure network connection (hope you're using SSL with AES256 or somesuch to encrypt the sessions to your app!) but the addition of 2FA stops that.

So let me some back to your question and whether your approach is accretive to the security of authenticating your users . Once the user's OTP key is set and stored in the user's record in the database, and that key is used to seed the TOTP generator, what would having the user re-seed with a new key accomplish? Yes, generating a OTP code and sending by SMS verifies that the person logging on has their phone with them at that very moment, but then so would using Google Authenticator; moreover, and I betray my Apple fanboi bias here (!) incoming SMSes are displayed on the lock screen of my iPhone, which would also therefore display your OTP, whereas to access the Google Authenticator app I have to unlock my phone with my PIN.

Also bear in mind that most systems are compromised at a network or system level and whole databases of usernames and passwords stolen to be cracked - compromising a single user's access isn't generally worth the trouble, unless you have a very high value asset attracting the attention of state actors!

Having explored the issues here for my own app I've gone with a username and password initial login (minimum length 20 characters to perplex rainbow tables, but with no stipulation on complexity or frequent changing), maximum number of attempts before locking the account for an increasing amount of time for failed logins, and a secondary login using Google Authenticator (as it's free, runs on iOS, Android and BB10, and is pretty easy to use). To improve on this I would consider biometrics but my application is commercial not military etc. so what I have is quite enough for my assessment of the risk.

I hope that helps you work out the best approach for your application.

Upvotes: 2

Related Questions