TOTP Codes in the Terminal | Hacker News Reader

TOTP Codes in the Terminal

jpmens.net

103 pointssea-gold72 comments

A pass[0] extension called pass-otp[1] can produce otp codes from the command line

    > pass edit git/hub
    [... put in your totp ...]
    otpauth://totp/GitHub/...

then you can

    > pass otp -c git/hub
    Copied OTP code for git/hub to clipboard. Will clear in 45 seconds.

pass-otp is also compatible with the passff firefox plugin; not sure beyond that.

[0]: https://www.passwordstore.org/

[1]: https://github.com/tadfisher/pass-otp

If you copy something else to the clipboard afterwards does it know not to clear it?

I wrote a CLI password manager as a personal project a few years ago and it would only clear the clipboard if the hash of the contents matched the hash of what was originally copied. I presume `pass` does something similar.

I don't think it does, it looks like it clears the clipboard and then restores the previous clipboard item. Your suggestion seems better.

https://git.zx2c4.com/password-store/tree/src/password-store...

Hash? Why would you do any hashing? The domain is only so large so it's meaningless even if you cared about keeping the original bytes in RAM (which you don't).

This is the same concept behind the fact that it typically makes little to no sense to hash phone numbers or credit card numbers.

It makes sense if your password is something like hc0z3kjwedngwh4hgwct0-hunter2.

The way my clipboard-clearer worked would have exposed* the plaintext secret if it wasn't hashed. Surely this would be generally true; however, in my case, it would have been particularly trivial to exfiltrate.

(* The clipboard exposure was more limited...although probably only in a "security by obscurity" sense :P)

I use it almost every single day, it's pretty simple and neat, haven't had the need for anything fancier.

Neat! I should try this. Been using pass since forever. Does it support autofill on Android?

GNU Pass is a great example of Unix-y interoperability for me. I sync the .password-store folder over to my phone with Syncthing, where the Password Store android app reads it. Password Store in turn talks to OpenKeychain for my encryption key with biometrics support. Changes are also synced back to my other devices. Each piece of the puzzle can focus on doing one thing and doing it well, even on Android!

Password store for android: https://f-droid.org/packages/dev.msfjarvis.aps/ Openkeychain: https://f-droid.org/packages/org.sufficientlysecure.keychain...

Why not sync it via git? It’s way better, imo.

Thing is, I often create or update passwords from my phone. I have yet to find a good UX for committing and pushing those changes from Android. Though I would be interested in that, because I have little protection against accidental deletion now.

With syncthing it's just instantly everywhere whenever I add an account, no action required. That's particularly useful when I create an account on my computer, then have to scan an OTP QR code with my phone. By the time my phone's out of my pocket the fresh account is already in the store to save the OTP code into.

But both Android [1] and iOS [2] clients have git functionality built-in. You just swipe it up (for iOS) or press sync (and swipe too, don’t remember if it works on Android) and it syncs.

A couple of iOS notes:

- The iOS app has a nasty bug, when you have not the latest repo on your iPhone, it cannot merge changes. So I recommend syncing your repo first, and then add new passwords from your mobile. IIRC, Android has no issues with that, but I’m not sure here.

- If you have a complicated ssh key (I have gpg-key for that) the iOS client doesn’t work properly. Could also have issues with other keys. IIRC, it’s the iOS issue. So I use a very special iPhone-only key that I added to my GitLab repo, where my passwords are stored. I generated the key with `ssh-keygen -t rsa -b 4096 -m PEM -f /tmp/id_rsa` and transferred it to my iPhone via iTunes, to ‘pass for iOS’ application.

----

[1]: GitHub: https://github.com/android-password-store/Android-Password-S... + Website: https://passwordstore.app/ + Play Store: https://play.google.com/store/apps/details?id=dev.msfjarvis.... + F-Droid https://f-droid.org/packages/dev.msfjarvis.aps/

[2]: GitHub: https://github.com/mssun/passforios + AppStore: https://apps.apple.com/us/app/pass-password-store/id12058205...

I myself never add passwords from my mobile, but I use mobile for adding 2FA (scanning QR-code), so my workflow as follows: I make sure I pushed the changes from my laptop/desktop with `pass git push`, then I swipe up on my iPhone, and only then I add 2FA code by scanning the QR-code. Then I push changes back, `pass git pull` from my laptop/desktop and add 2FA one-time codes manually. That may sound weird, but actually that’s quite simple for me.

Syncthing may just work here, but for me, I don’t run Syncthing all the time, only when I need to sync some changes, which is infrequent for me. As well as my passwords, actually. I don’t care too much with my mobile, as I try to limit my smartphone usage and pick laptop whenever possible, so to avoid over-consumption of media (which is easier on a modern smartphone). But that’s just another story.

Thanks for pointing this out! This functionality has been right under my nose for ages without me noticing.

Also worth looking at gopass[0], the Go re-implementation. It supports OPT out of the box.

[0]: https://github.com/gopasspw/gopass

I used gopass for a while and regret it. They kept messing with the contents of passwords, sometimes in ways that it itself couldn't read. Adding `GOPASS-1.0` etc. I feel like it also did way too many encrypts/decrypts for each password (I'd have to press my hardware button 4 times just to rename a password I think). Slowly fixing all my passwords having moved back to pass.

I'm no fan of bash or pass's rather anemic built in structure but I don't feel like gopass were the right stewards.

I think browserpass ff+chromium plugin supports otp as well. A nice thing is it's a native plugin so you can manage it with your system package manager (rather than the extension store).

KeePassXC[1] password manager supports TOTP and I use it for that purpose in addition to storing passwords. It never made sense to me to use an app like Authy.

I suspect most people make the assumption that an Authenticator app is something special that needs to talk to the service that issued the QR code/secret string.

It's nothing more than a SHA1 hash of a secret string and an adjusted current time.

[1] <https://keepassxc.org>

For me it’s separation of secrets. If my vault is exposed they won’t be able to log in without the codes. Putting it all in one place is a bad idea, some may think.

You can have one database for passwords and another for OTP.

What if you lost or somehow broke the phone? You'll be locked out your stuff faster than you'd expect. If you back it up to a cloud service, are you sure you can recover it without the TOTP? If you are backing it up to your computer, then it's already on your computer and will probably be compromised when your vault is, so you might as well use your vault anyways.

I load my TOTP tokens into two phones, one that stays at home fully charged. If I lose them, I can easily reset my TOTP with any reasonable provider - I have the account login and password, and can authenticate with my email/provide proof of identity.

1Password wrote a blog post stating something similar. Basically it comes down to if you're using TOTP as a true second factor. If you are it really shouldn't even be accessible from the same device.

https://blog.1password.com/totp-and-1password/

I suspect most people aren't though. Most people are just being forced or nudged to using it. The main purpose for platform providers to push TOTP is probably consumers reusing passwords leading to account compromise, but if you are using a password manager, you can generate high entropy single-use passwords which don't really have that problem.

A TOTP protects you against a replay of your password after it's typed into a compromised computer.

Yeah, that's why I also don't use the OTP features in Bitwarden (Premium), despite using the software as my password manager.

On my computer, I also use a distinct password to protect my pass-otp secrets.

The conflict between single point of authentication and single point of failure is intractable. Just pick a poison based on which is less likely to fuck you over.

I only use KeePassXC for TOTPs now. Note it can work on Android too. There is often no good way to back up phone authentication apps without a cloud service, which is a problem if I ever lost or broke my phone, and it requires me to use a separate device when using my computer, which I'd rather not do.

Autofill can save you a lot of time if you prefer to usually stay logged out of websites (auto-deleting cookies, for example) but need to log in sometimes.

KeePassXC also has a cli interface suitably named keepassxc-cli, so for TOTP in the terminal its something like:

   keepassxc-cli show -q "$KEEPASS_DB_FILE" "$ENTRY_NAME" --totp
   <type password>
   <prints totp>

edit: doubly so specifically regarding Authy since theyre discontinuing it on the desktop in a few months.

They are discontinuing Authy Desktop in 3 weeks (March 19th), brought forward (!) from August. https://help.twilio.com/articles/19753631228315

The keepassxc CLI reopens the database separately; it's actually possible to use git-credential-keepassxc† to do the scripting instead because it acts more like a browser (so it interacts with the already running instance of KeepassXC).

† https://github.com/frederick888/git-credential-keepassxc

for anyone new keepassxc, do check out the auto-type feature. you can trigger it (through keyboard shortcut) to type TOTP digits.

Several comments here suggesting that using password managers for TOTP defeats the purpose of TOTP as a second factor. I don't agree.

I strongly prefer other factors (U2F/FIDO(2)/WebAuthn/Passkeys/whatever) but unfortunately TOTP is still extremely prevalent. Worse is when only a single secondary factor can be registered, in which case even if something other than SMS or TOTP is available, I slightly bias away from hardware security tokens in order to have a clear recovery path. I can at least back up most TOTP keys.

I agree that having a second vault for TOTP seems superior but from a UX and recovery perspective it's not so clear. Are both vaults available on all devices? Are they usually unlocked simultaneously? Is it likely that one vault but not the other would be stolen? Or you have a separate device or air-gap and now the usability adds friction. It seems like diminishing returns.

Conversely a single vault still offers significant protection from many attack vectors, including keyloggers and phishing. Even if access is obtained via MITM'ing a TOTP, the blast radius is often limited to a single session. Many services have poor session security, once established, but many do not. And in my experience it's still nearly impossible to get rid of SMS 2FA.

TOTP is almost always strictly better than SMS 2FA, and storing your TOTP keys alongside your passwords doesn't really diminish the effectiveness of TOTP very much at all. Unless you have the keys themselves exposed, they're still closer to "something you have" than "something you know", at least from where I'm sitting.

Their main weakness is that they can be backed up or copied at all, as well as MITM'd. How I securely store them doesn't have much impact.

Unless you were using LastPass and their Authenticator app. When they admitted that there had been unauthorized access to their storage and databases that had users vaults, what they failed to mention publicly (but which they finally told me after persistent questioning) was that the TOTP seeds were also part of the breach.

Most of the security benefits of TOTP is really for the service providers. Service providers get blamed when users are hacked because they used the same weak password across multiple websites. With TOTP service provider chooses the key the codes are derrived from, so user cannot choose a stupid one.

Most of the other threats that people talk about TOTP fixing are movie plot threats and not ones that happen in the real world to ordinary people. The only major exception is that webauthn prevents phishing, but TOTP cannot help with that.

Arguably storing TOTP tokens in your password manager does provide a level of protection against phishing.

You might fool me with that phishing page, but you won't fool my password manager's autofill. It would have to be full on MITM or DNS poisoning for that to work, which is already more of a movie plot.

Sure, but that is true of your normal password as well. It doesn't add any additional security.

> Their main weakness is that they can be backed up or copied at all

Which is also a major strength. I've had the experience of a phone app losing all of my TOTP information, and spending a long while having to use the recovery paths of various websites. After that experience, I want my second factor to be something I can back up and restore.

That'll continue to be true until either all websites reliably accept multiple 2FA devices (e.g. register multiple hardware keys) or I can buy multiple redundant hardware devices that produce the same TOTP codes so I can register "one" device with a site and still have a backup.

I wish the Firefox password manager had builtin TOTP support.

1. using password managers for TOTP defeats the purpose of TOTP as a second factor

2. using password managers for TOTP is useful

Both can be true simultaneously.

The point of "something you have" is that it is "literally infeasible" to compromise your account without physically robbing you of your yubikey-equivalent. That automatically excludes >99% of the population that aren't within X miles of you from being able to potentially attack you.

Using this definition, both SMS and TOTP already fail, but at least one can approximate it by storing the TOTP on a physical device in a way that blocks casual export.

If you store it in a (non-local/backed up) password manager, you completely give up the pretense that "it is impossible to compromise your account without physically robbing you of your yubikey-equivalent". Someone from across the world can now compromise you without leaving their room.

Now again, just because it doesn't meet the "2FA threshold", doesn't make it useless. But it is also true that it doesn't provide the level of security that 2FA is supposed to provide.

TOTP codes acceptable to Github etc. can be generated via

    oathtool - Open AuTHentication (OATH) one-time password tool

     OATH Toolkit provide components to build one-time password
     authentication systems.  It contains shared C libraries, command line
     tools and a PAM module.  Supported technologies include the
     event-based HOTP algorithm (RFC 4226), the time-based TOTP algorithm
     (RFC 6238), and Portable Symmetric Key Container (PSKC, RFC 6030) to
     manage secret key data.  OATH stands for Open AuTHentication, which is
     the organization that specify the algorithms.

I use an alias to oathtool to generate OTPs.

It seems like this method at least keeps the secret key inside 2FAS backups, so it's probably slightly better opsec.

PSA: Authy Desktop is being killed off this year, which could mean the last opportunity to export your tokens out of Authy (for migration, or for external backup)

There are a few gists floating around regarding how to export by remote chrome debugging an older version of Authy desktop app, which still worked for me recently. This page explains too:

https://jaketrent.com/post/export-authy-desktop-data/

If you have a M1/2/3 Mac you can install the iPad version of Authy which works as a replacement.

i used this tool https://github.com/token2/authy-migration and it worked as expected.

you just need to generate their html and on it, you will see a bunch of QR codes -- just use them to add a new TOTP to whatever tool you use.

Nice! That's a good find

I wrote once many years ago, showing me all my TOTP codes in a terminal. I'd run it on a text-only offline/airgapped Raspberry Pi (an old one, with not even WiFi capabilities).

I was also pissed off by the clock issue, so I'd show both the previous, present and next code to come: because it's really a PITA when you see 213987 but you've got only two seconds left before it rolls. So I may as well start entering the next code (what the server accept is something not in my control).

And I always, always, always have a known, public, 2FA which I can use to double-check that everything is smooth (for example by entering it on some online computer and verifying that I get the same tokens generated).

I just reused whatever 2FA/TOTP Java library I found and wrapped that in a little CLI utility.

My secrets were unlocked by entering a password when I'd start the app.

You don't need to use the previous, present, and next code. Most decently implemented TOTP servers take time-sync-issues into account and accept codes a few seconds here and there. They do this also bec the time for a packet to move around the earth can also sometimes take a couple seconds.

Your setup on raspberry Pi sounds complicated. Mine was simpler. Just a CLI showing totp. Less secure but more convenient.

For people storing One-Time Passwords in 1Password, you can access them in the terminal too:

    op item get <item_name> --otp

To copy to clipboard just use pbcopy or xclip:

    op item get <item_name> --otp | pbcopy        # MacOS
    op item get <item_name> --otp | xclip -sel c  # Linux

I like 1Password `op run` which works without copying. You put environment variables in your code, and when run with `op run` these variables are replaced on runtime with the actual credentials:

https://developer.1password.com/docs/cli/secret-references/#...

Implementing TOTP is a fun exercise to learn crypto. But key storage is a bit more interesting as it has so many different approaches and trade offs.

Yeah, seems like a small enough thing to get your hands dirty. Might give it a shot soon, thank you for the suggestion!

I use aegis (previously i used andotp) and backup to a folder shared via syncthing. This allows me to usw OT via andotp -cli in emergency vor to use it in a new phone. For some i also use keepassxc (my credential/information store.) but the important ones. I prefer yubikeys, but keep totp AS a backup mechanism when i can add two methods.

I don't like having TOTP codes available on any connected devices so I got one of these little offline authenticators.

https://shop.reiner-sct.com/authenticator/reiner-sct-authent...

A few years back, on a limb, as a quick experiment a coworker of mine (github.com/jkirsteins) wrote `twofa`.

Surprisingly usable for a few day's worth of hacking around!

https://github.com/sqreen/twofa

rbw (a terminal client for Bitwarden) can also generate totp codes.

And the official CLI client for Bitwarden is here: https://bitwarden.com/help/cli/

Yeah, it's nice and all, but it's a node application and requires premium for TOTP.

rbw is written in Rust and doesn't need premium for TOTP.

For me it comes down to trust. I'm already trusting Bitwarden with the desktop/mobile apps and the browser extension. Using rbw would require me to trust someone else with arguably my most important digital data.

As for the cost, it's both reasonable at the yearly rate and I want to support them so they can continue improving the software (still waiting for Passkeys on mobile for example).

I can't really speak to the node part, but it seems to perform well enough in my experience.

Just be careful not to use the same account/database/vault for OTPs and passwords, when using a manager like Bitwarden or KeePass, otherwise they no longer contribute a second factor to your authentication.

To be honest, password managers that support TOTPs should always come with a very clear disclaimier that keeping all your eggs in the same basket is a detriment to your safety, and that you should either use a different software for these codes or a separate account. I don't believe they do, but correct me if I'm wrong.

I've thought about this a lot, and I feel that it's not really as big a detriment to safety as you might expect. It's not exactly the same as an air gapped token generator, obviously, but:

- It's still something you have, and don't know: the TOTP secret. What you transmit is a short term generated code, but unlike your password, you don't send the secret key at any point.

- The downside of air gapped tokens is that when they break or are lost or stolen, you have to somehow re-enroll with a new device. The security properties of this process are deeply variable between authorities, and there's always the risk of just total loss of access. If you have the TOTP secrets backed up in Bitwarden, you can avoid this.

- Vault software can keep all of these secrets encrypted using keys protected by biometrics on a phone, or an external device like a Yubikey, that are only unwrapped by a particular physical interaction. Usually the vault software does a better job than the average person of determining whether you're looking at a legitimate authentication prompt or a phishing site, and I suspect it's less likely to automatically enter your TOTP code into the wrong than a person is when transcribing it by hand or copy pasting.

YubiKeys support cli access with the benefit of being hardware backed, and optionally requiring a physical touch:

  $ ykman oath accounts code <slot>
  Touch your YubiKey...

I store my TOTP secrets in the Gnome Keyring

      totp() {
        TOKEN=$(keyring get totp $1)
        oathtool -b --totp $TOKEN | xclip
      }

and my TOTP secrets are saved via ansible-vault

    - name: set TOTP in keyring
      with_items: "{{ TOTP }}"
      community.general.keyring:
        service: totp
        username: "{{ item }}"
        password: "{{ TOTP[item] }}"
        keyring_password: "{{ keyring_password }}"

Beware: That shell function will use the secret on a command line, leaking the secret to the process list, available to every user on the system. The oathtool manual page even warns about this.

I would instead recommend something like:

  totp() {
    oathtool --base32 --totp -- @<(keyring get totp "$1") | xclip
  }

(Bash required.)

Python includes libraries that match up with the needs well, so a python TOTP generator can be pretty small, 30 lines in this case...and not too golfed:

https://github.com/susam/mintotp/blob/main/mintotp.py

I've written a similar tool for the Aegis backup file that lets you fuzzy find entries, auto generation of codes and includes clipboard support.

https://github.com/Granddave/aegis-rs

Frankly, I'm glad Authy Desktop is dead. It didn't allow exporting of TOTP secrets, so migrating off of it was a pain. I've been much, much happier with a tiny shell alias to oathtool and gpg.

For extra benefit, bind a keyboard shortcut and use xsel (Linux) or pbcopy (Mac) to drop the TOTP code into the clipboard. Now entering a frequent TOTP code is as simple as two keyboard chords.

(I only do this because my employer offers very limited options for MFA and I don't have a smartphone. I'd much rather use the Yubikeys I already have...)

It is actually doable to export secrets from authy desktop, but it involves starting it in debug mode and connecting chrome to it (it's an electron app). It was the solution I found to extract the secrets back when I set up https://pypi.org/project/totp/

Users of 1Password with Dropbox sync can get TOTP in a terminal window with GitHub.com/jeffallen/1pw

It is a crude hack, but it works for me.

Sadly nothing to do with Top Of The Pops

TOTP will forever mean Top Of The Pops[0] for me first. I'm reassured that I'm not the only one. Thursday nights have never been the same.

[0] https://en.wikipedia.org/wiki/Top_of_the_Pops

I scrolled down hoping to see this mentioned.

If it wasn’t I was going to bring it up, faith in lip synced music telly reconfirmed.

tetripin does that too, but you have to pip install it.

Reply on news.ycombinator.com