Enhance the GoogleAuthenticator.authorise() to support scratchCodes?

[xhh11]

This will require that the interface ICredentialRepository to include a method: String getScratchCodes(String userName)

It is natural to have save and get in the same class/interface.

Alternatively, we can add a method GoogleAuthenticator.authoriseWithScratchCodes() and keep authorise() unchanged.

[senthilkumarkj]

Would it be safe to treat scratch codes like passwords? Instead of getScratchCodes(String userName), we can say, verifyScratchCode(userName, inputScratchCode). That way you can store the scratch codes in hashed form and need not do encryption that we need to do for secretKey.

[senthilkumarkj]

I had a requirement, where I got to list the scratch codes, later sometime. Had to store it encrypted. :|

[emcrisostomo]

Hi @xhh11, we'll think about it.

[emcrisostomo]

Hi @senthilkumar-kj, scratch codes come directly from random material: once you get them, it's up to you to safely store them somewhere, there's no way to "verify" them as you verify a TOTP password. TOTP passwords are completely different in nature: they are not random at all, they are the result of a calculation which takes the private key as one of the parameter.

In fact, scratch codes are better compared with the secret key: once you generate it, it's up to you to safely store it somewhere and use it when necessary.

If you need to store the scratch codes encrypted, then why don't you just encrypt them and store them in your repository of choice?

However: scratch codes are not a feature specified by the TOTP RFC: it's a provider-specific "safety net". I added it because Google's implementation does it, but in retrospect I think it's not a benefit, but a liability: a TOTP library such as this should not worry about scratch codes at all.

Scratch codes support, in fact, it's barely sufficient as is. For example: what happens when you run out of scratch codes? This library offers no way to generate new ones. Let alone application-specific policies such as scratch codes expiration, scratch codes maximum number of use, etc.

[senthilkumarkj]

Hi @emcrisostomo, I agree with you and I understand. 😊 The verify part will be part of the application. I initially thought it will be same as verifying password, so I had it stored hashed. Then there was a requirement to list the scratch codes for the user later. So I had to change my impl to save it encrypted.

I didn't want anyone to read my first comment and save it hashed. So I thought I would correct it. Hence the second comment.

[yidongnan]

I also want to enhance the GoogleAuthenticator.authorise() to support scratchCodes

[emcrisostomo]

Hi @yidongnan, I understand the interest in this feature but I sincerely believe it does not fit into this library. Besides scratch codes not being part of the TOTP RFC, the only way to `integrate' this feature that I devise would be providing a callback for library methods to call during the authentication phase. Here, the problems I see are many:

• I would keep TOTP password verification completely separate from scratch code verification: I would not allow scratch codes to be passed and treated as a password. Rather, I would expect an application to provide a separate login form where users explicitly declare they've lost their shared key, or they have no access to their token generator, or whatever. This approach is what I currently see on Google, GitHub, etc. On the contrary, would you like this library to invoke your backend to check whether each and every password is either a valid TOTP password or a valid scratch code? I wouldn't want it to.
• Assuming this callback is available, you should provide its full implementation. At this point, what is the advantage of having the library call into your implementation? Wouldn't it be better to keep TOTP password and scratch validation separate and satisfy the previous point?