TOTP without a smartphone, afterword

After the article “TOTP without a smartphone” was published, it received many interesting and useful comments. I decided to wait until the discussion died down and work on the comments and thoughts expressed.

Since the volume of work turned out to be quite large, I formatted it in the form of a separate publication-afterword.

Philosophical questions (knowledge or possession factor?)

In an ideal model M.F.A. the first factor is assumed to be the knowledge factor (password), and the second is the possession factor (here like mine phone number for SMS, or smartphone with a code generator, or hardware key).

A fascinating discussion ensued over what could be considered knowledge and what could be considered possession; how one can flow into another; what can be copied and what can be lost/taken away. Many thanks to dear @splitfire, @aborouhin, @inkelyad as the creators of this thread!

Separate storage of different FAs

Although the presence of 2FA itself increases the security of the service compared to just a password (there are no threats of password leakage, banal spied or more complex options, such as keylogger / keyboard sound analysis etc) – ideologically it would be correct to store 2FA separately, in a way that eliminates the possibility of simultaneous disclosure of both the password and TOTP.

So I stopped using KeePass to store TOTP secrets (even though it seemed very convenient, security is usually inversely proportional to convenience, and vice versa). Yes, you can use a separate password database for 2FA, but this will no longer be convenient; and storing them safely in GPG encrypted form has already been implemented.

Using 2FA on a separate device

Thanks to dear @xSVPx for the idea:

The meaning of two-factor verification is that both “passwords” are also stored or obtained in ways that do not have common places. Those. To compromise, two devices must be hacked, not one.

Indeed, even with separate storage of different FAs on the same device (for example, a work desktop), there is a threat of disclosure of all FAs if it is completely compromised. So I store 2FA on a separate Linux machine accessible via SSH. To be more reliable, you can access it not from your main desktop, but from your work laptop.

And yes, that's why the copying TOTP to clipboard options should be considered a potential security weakness. It’s not for nothing that TOTP is made digital and short, so that even a busy person can keep it in RAM for the few seconds it takes to enter.

2FA and Microsoft

I didn't fully understand the intricacies of 2FA at Microsoft when I wrote:

does not work with MicroSoft, since they traditionally did not limit themselves to standard TOTP

Thanks to dear @aborouhin and @CaptainFlint for bringing this to my attention and encouraging me to once again go through the not-so-obvious MicroSoft account security settings.

As it turns out, when you enable 2FA, you can select the option another authenticator program, then instead of a proprietary connection with the Microsoft Authenticator application on the phone, a QR code will be generated (for example, Google Authenticator is normally perceived); and with the option I can't scan QR you can get the treasured TOTP secret in base32 format. After which it works without problems mytotp.sh (with the same default six digits and SHA-1 hash).

Extracting TOTP parameters from Google Authenticator

Dear @adrozhzhov shared a method for retrieving TOTP parameters already entered into Google Authenticator. We need to initiate Transfer Accounts in the application, select the one we need from the list, receive a QR code, take a screenshot of the screen and click Cancel.

For further work you need a program zbarimg for decoding QR code (package zbar-tools in Debian and derivatives, zbar in RedHat and derivatives) and a script for parsing the otpauth-migration line (Python3 with two dependencies, installed from GitHub)

 $ sudo apt install zbar-tools
 $ cd ~/wrk && git clone https://github.com/qistoph/otp_export
 $ cd otp_export && pip install -r requirements.txt
 $ ./parse.py "$(zbarimg -q --raw  /path/to/qr-auth.png)"
 [...]
  secret: b'ABCD1234EFGH5678IJKL2345MNOP6789'
  name: myname@service
  issuer: 
  algorithm: SHA1
  digits: SIX
  type: TOTP

New version of the script (fork on GitHub)

Thought be in fashion and posting your trivial script on GitHub turned out to be successful: the repository was forked twice, and in second case modified to be used as BASH functions mytotp(), mytotpadd() And mytotplist() for loading into the environment and subsequent calling. Moreover, dear yuriq I submitted a pull request to include changes in my repository, everything is like adults!

Now I’m thinking about what’s best to do – on the one hand, the changes are useful; on the other hand, I’m quite old-fashioned and try not to bloat the BASH environment, so I should leave the original version with the script. All that remains is to study the manuals for git(1) as well as best practices on GitHub to do everything correctly and beautifully.

U2F hardware token

Dear @kasiopei asked a question about U2F devices:

Why is almost no one implementing U2F? Do they not know about him or is the defense weak?

Since my knowledge of this issue was purely theoretical, I decided to part with a small amount of money and looked for a device available for purchase right now that supports FIDO 2UF formats (CTAP1) / FIDO2 (CTAP2).

Yubikey devices seemed a little expensive to me, plus the sign The FIDO U2F PIN I was puzzled by the wealth of options – I took a simpler USB device. And this is what I want to say:

This is the best solution to the “TOTP without a smartphone” problem!

Works with all my services (I think in 2024 most web services support CTAP); for Windows (7 / 10), MacOS (10.13+), Linux (Mint 21); with current versions of FireFox and Safari (I'm sure it will work with Chrome too). If you do not set your PIN to a token (pure ownership factor), then you don’t need to do anything with it other than:

• Registration: go to the service, select the 2FA setting, hardware key; when asked, touch the button on the key

• Usage: went to the service, saw an invitation to touch the button on the key, touched it – authentication completed

Among the disadvantages (except for the need to pay real money): if the token breaks / disappears, we are left without 2FA. Apple even suggests using 2FA when activating two different tokens; but it is quite possible to get by with the “token + TOTP” scheme, which is what I used.

Conclusion

So, I have now solved the indicated problem in two ways: perfect (but can’t be copied for money) and a little simpler (but free and subject to backup).

I would like to thank all the panelists who were not mentioned above for your opinions and comments; as well as the dear @Exosphere for patiently answering my newbie questions when preparing the publication.