Live data from Hacker News

TOTP Codes in the Terminal

jpmens.net

41–50 of 73 posts

Re: TOTP Codes in the Terminal

#42

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 h…

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.

Re: TOTP Codes in the Terminal

#44

Earlier quoted context omitted.

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.

Re: TOTP Codes in the Terminal

#46

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://ke…

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.

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.

Re: TOTP Codes in the Terminal

#48
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 }}"

Re: TOTP Codes in the Terminal

#49

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 -- @
(Bash required.)
Post reply on HN