2FA on the command line | Hacker News Reader

2FA on the command line

sendthemtomir.com

177 pointsmbushey79 comments

I would caution against this approach. This fundamentally changes the 2FA from a "something you have" to "something you know", which is the type of factor your password is. If you do want 2FA functionality on the command line, look into Yubikeys with their ykman CLI tool. (https://support.yubico.com/support/solutions/articles/150000...) You're able to store a TOTP secret on the Yubikey itself (maintaining it as a "something you have" factor), as well as optionally requiring the yubikey be touched before the TOTP is emitted.

2nd factor is still "something you have", just that it is now your laptop rather than your phone.

No, because possession factors are not copyable, but files in laptop definitely are.

Yup. It's arguable whether TOTP secrets stored in Google Authenticator are a true "something you have" factor, but this came at a tradeoff because not everybody wants to pay for a RSA token generator and carry that around. Assuming the Android system is secure (big assumption, bear with me here), this is closer to a "something you have" factor because its difficult, if not impossible for users to retrieve the secrets from the GA app.

TOTP is a second factor so long as you store the information to generate it on a second device.

I think 2FA objective is to protect mainly from password leaks. If an attacker has access to the files on your laptop aren't they able to intercept 2FA codes too even if they are generated on another device? Such attacks are not purely theoretical we could observe them in real world.

Apart from that I believe that TOTP keys should be encrypted and that is actually my main issue with the described tool - it stores the keys in plain, in a config file.

2FA is to mitigate risk after the password is compromised, not to prevent password compromise in the first place.

That doesn't change the necessity of protecting TOTP keys, session keys, bearer tokens, etc., it's just that your second factor is supposed to be a parallel factor, not an extra lock around your password.

To expand on what you're saying:

TOTP as a "something you have" approach to 2FA is entirely dependent on how well the device secures the secrets.

An RSA key's private key is (nearly?) impossible to retrieve. The Google Authenticator's TOTP keys are a bit easier. A file on a laptop is even easier.

I believe iPhones now come with on-board TPM's? So in theory you could actually generate the private key on the TPM, and then your phone becomes the "thing you have" to a higher degree of security than authenticator apps.

Not sure about any apps that take advantage of that yet, but the hardware seems to be there.

Not sure about any apps that take advantage of that yet

All iOS apps essentially do, if they store things in the keychain or even the filesystem.

TPMs have been in phones for years actually, both iPhones and Android phones. The iPhone chips have become a lot better the last year or two though. Some apps, like government or banking apps, actually have been using ARM TrustZone (and probably Apple's T2 chip) for secret storage already.

If you use krypt.co, you can store ssh and GPG keys on your phone's TPM, as well as a secret key for use with a browser addon to facilitate WebAuthn. So, you can already use your phone as the "thing you have".

Well, Android devices do have "Trustzone"s, where keys are bound to the hardware, and user's identification (pin/password) Sadly, Google Authenticator doesn't seem to be using that. AndOTP does have Android KeyStore backend, which is using Trustzone.

Depending on how the original OTP key is stored on your phone, it's not much better than having it on your laptop. The key is still just stored there, somewhere, inside our phone. On the laptop at least you know where and how it's stored.

This might seem intuitive but it's wrong unless your phone is really old and unpatched. Modern phones sandbox everything, often encrypted per-application (standard on iOS for many years, becoming common on Android), and they have storage classes which will not be included in backups or easily copied to a computer.

You could start to approach that on a laptop — make sure you have FDE enabled, use the operating system's sandboxing features pervasively, store secrets using the TPM, etc. but that's a huge amount of work and the attack surface for apps on your laptop is enormous, especially for developers: how many people using a system like the one described are one unlucky npm install away from sending their TOTP seed to an attacker? The equivalent attack requires a system compromise on a phone (which tend to have 7+ figure USD bounties on iOS).

> unless your phone is really old and unpatched

The rate of CVEs an android, combined with the sheer number of manufacturers who are slow about updates or just never deliver any, means that unpatched devices are nothing like the rarity that this statement suggests.

I was trying to avoid an iOS vs. Android flamewar but feel free to read that as “buy an iPhone 3GS or later unless you want to carefully check this”.

> > This might seem intuitive but it's wrong unless your phone is really old and unpatched

> feel free to read that as “buy an iPhone 3GS or later..."

iPhone 3GS stopped getting patches 5 years ago (https://en.wikipedia.org/wiki/IOS_6). I think it qualifies as really old and unpatched.

We do know how and where it is stored, a database file in /data/data/com.google.android.apps.authenticator2/databases/databases. I regularly copy it and back up in case my phone needs resetting.

So are the keys on your phone's 2fa app

Indeed. Doing this with the OS TPM or secure enclave might have been worthwhile, but without that it's basically a fancy way of writing a password on a post it.

For my threat model (and I suspect for most people's), access to copy files on my laptop implies access to install active malware on my browser sessions, i.e., it's already game over. If you don't have that access, then a file on my laptop is in fact something I have.

(I have a few things I intend to be survivable across a total laptop compromise, but they're special-case things like credentials that can upload code that will be run by a few thousand people. They're not protected by regular website 2FA. For regular websites, a browser compromise would almost always let you wait until I'm logged in, then disable 2FA and change both the email address and password on the account, at which point it's irrecoverable.)

This is just assuming that your phone is more secure than your laptop. Which is possibly the case but files on a phone are still copyable the same way files on a laptop are.

Store your TOTP secrets PGP or NaCL encrypted. I have done this for years. You'd have to get my private key (off of a smartcard) and get my private key password (out of my head) to decrypt my TOTP secrets before you could use my TOTP generated codes. I have much more faith in this approach than I do Android apps.

    $ gpg -d encrypted-secret.txt | goathgen

Or have the ability to run code on your computer, in which case they’d just wait until you enter the private key password and then steal all your TOTP secrets.

Having your TOTP secrets on a unique device means that an attacker in that scenario (access to your endpoint) could steal a single TOTP code for the single site, but wouldn’t be able to steal the seed secret itself.

I 100% agree with you, but I recently started putting my TOTP tokens in my password manager, and it's so much more convenient to just have the token pasted in while you log in, instead of having to find the phone, turn it on, launch the 2FA app, find the code from a huge list and type it in, that I'm willing to take the security hit.

We need WebAuthn yesterday.

Agreed, I hesitated for years to not put 2FA in 1password. But, after a few phone upgrades and resetting each and every account, it's worth it. It can take nearly 10 minutes per account to reset 2FA. Spending a few hours every few years doing that was just too much.

Putting your 2FA in 1Password sort of reduces your security back to 1 compromise (breach 1Password and you're screwed). I would recommend putting your TOTPs in Authy. Easy to restore and even in multi-device mode waaaay safer than storing all your TOTP next to your passwords.

While this is true I think if anyone had control of my password database they could remove the 2FA from most of my accounts without much issue.

Also where is the password to your Authy account?

And where are your 2FA backup codes?

You just give Authy a relatively simple password, and don't save it anywhere. If you don't have Authy in multi-device mode it will be impossible to activate another session, and if you do activate another session while in multi-device mode Authy will check if any other devices are active and if so will ping those devices with a verification request. It checks for an active device so that if you have only one device active and do a reinstall you can still activate. I have my 2FA backup codes in Dropbox, which itself is behind 2FA.

In essence someone has to both get my 1Password password, 1Password secret key and either compromise my phone (for Authy) or my phone number (to recover 2FA backup codes via Dropbox SMS recovery), or my computer (for direct Dropbox access). But very few organisations have that amount of capability and I have nothing stored in my accounts that is worth that capability. If I had, I would store it behind GPG and a password that is only in my mind.

Also, to lose access I'd need to lose my 1Password secret key or forget Authy password + get logged out of all my Dropbox devices simultaneously. The chances of that are rather slim.

I take the secret from the initial signup (2d-barcode/hex string) and encrypt it with my public keys (private keys are on 2 different Yubikeys) and then distribute them to 3 different computers. Overkill, especially given that encrypted local iPhone backups store the GoogleAuthenticator secrets, but it means I won't lose my 2FA secrets if I lose my phone.

I'm no security expect (and a bit of alcohol is helping write this), but I do honestly feel like people are shooting themselves a bit, especially to the point of using pass-otp, which is presumably ALSO where you're storing your passwords... It really feels like you've got two keys to a safe that two seperate people look after. But then decide to go for a beer together and one holds the other's key whilst they get another drink...

Sometimes conveniece definitely comes at a cost, and getting to the point of having an application to 'remember' your passwords (ignoring the fact the passwords can then be completely unique and more secure) and then duplicating the OTP keys (that are meant to be kept on an independent device) into the same application seems like a step to far.. at least for me! Think I'd prefer the inconvenience :/ No offense to anyone else's comments intended!

I was really hoping this was integrating 2FA into command line utils; e.g., doing SSH with 2FA. :/ I would strongly caution against the article's advice.

The scenarios I feel like most corporations want to protect against are:

1. Accidental password disclosure, e.g., c/p password to someone who should not know it.

2. Laptop compromised, e.g., with a trojan, keylogger, etc.

3. Laptop physically compromised, e.g., stolen, or opportunistically available (e.g., locked, but sitting on a desk).

It's #2 that's the problem here, and the reason why you want your OTP on a separate device, or hardware designed for it like a Yubikey. In the case of #2, if your OTP secret is on your laptop, and protected by only your laptop password, someone with remote access only needs to log your activity until they have your password, and then they have both your password and OTP.

Were your OTP instead on a separate device, they would also need to compromise that device; with things like a hardware key, this is by design exceedingly difficult, given that it's a separate device designed to never give up the secret, whereas a filesystem can't really tell the difference. That's the point: it should compromising both factors, separately.

But if you're just keeping your OTP secret on disk, and ignoring #2? You're really only covering #1, and a good password manager will make accidental disclosures rather difficult to do anyways, so it seems like little benefit.

If your laptop's compromised the attacker can just steal your cookies and it doesn't matter how you're doing 2FA. In general, an actively compromised device is not a threat you can effectively defend against.

FWIW if you want 2-factor SSH you can do that. Just add the PAM module.

You can use a trezor and https://github.com/romanz/trezor-agent

The cool thing is that the key is derived from the trezor's seed, so you can have several backup devices. And you need pin+passphrase not just the yubikey.

Been doing this for a while. There is a great extension for Pass:

https://github.com/tadfisher/pass-otp

Even works with Browserpass and the Pass Android client:

https://github.com/browserpass/browserpass

https://github.com/zeapo/Android-Password-Store

Seems like this is the appropriate way to do this - build it into a good existing system based on encryption. Thanks for sharing it!

Sure thing. If you're looking for GUI clients too, QtPass supports it too:

https://qtpass.org/

While not a command line tool, it's worth mentioning that KeePass also has plugins for generating TOTP codes:

https://bitbucket.org/devinmartin/keeotp/wiki/Home

https://sourceforge.net/projects/traytotp-kp2/

I don't use pass-otp but I do keep the private GPG key for `pass` in my yubikey and use touch-to-whatever, so whenever I get a password out of it I have to tap my yubikey.

The magic incantation to get the latter set up is something like `ykman openpgp touch aut on` (though I can't recall if it's `aut` or `sig` or `enc`).

We would sternly warn our clients against using anything like this. If you're really going to do this, just use a serious password manager like 1Password, and set random passwords. Desktop-based TOTP is pretty much just theater past that.

I mostly agree, though I still think adding 2fa to whatever password manager you do use is vaguely worthwhile. Long term creds can get checked into repos, accidentally pasted somewhere, etc. May as well have 2fa to mitigate this edge case ️.

This is less secure than not having 2fa at all.

2FA means two factor authentication. It's a guarantee that even if someone hacks your password or steals your computer, if they don't also have physical access to the secondary device (phone, yubikey etc), they won't be able to gain access to your account.

If you put the secrets of 2FA into the same computer, you are back to 1FA.

However, you end up being less secure than not enabling 2FA in the first place. This is because when you enable 2FA, they can disable the regular checks that they have for 1FA accounts. It will also be incredibly difficult to regain access to the account if you don't have access to 2FA devices.

2FA is protection against a lost password. It was never protection against a lost password combined with a stolen device.

Think about this scenario. You use Google authenticator on your phone, and have your banking app on your phone. A thief knows your banking password and steals your phone.

Now replace "phone" with "computer". I don't see how changing the underlying 2FA device changes security.

The only real danger is if that 2FA db on your computer is not encrypted. But again, the same danger exists if you use an unencrypted phone.

Assuming they know the passphrase/PIN for the phone. It's also much easier for rogue software to steal the 2FA token from the laptop than the phone.

Please enlighten me how is it easier to decrypt my 1password on my laptop than it is on my phone ?

> It was never protection against a lost password combined with a stolen device.

I don’t know where you’ve worked but almost every time I’ve been in a discussion that’s an explicit goal. The most common situation being where someone loses a laptop but not a token or phone.

Even in the case where someone gets the phone, note that phones have fairly strong protection against reading private data directly and 3/5 of my auth apps and my password manager have require both the device and a passcode or Touch ID authentication to open so its non-trivial to get either codes or passwords out of a device. On iOS at least it’s been many years since “an unencrypted phone” existed so there aren’t simple ways to get around this which don’t just devolve to some form of “if the CIA/Mossad/etc. target you but inexplicably choose not to hold a gun to your head until you unlock the account”.

In the hairy world of Android things are much less certain. Encryption is optional, and root access is available which can be leveraged to backup the unecrypted contents of any app, including Google authenticator. I'll agree, an iPhone is a very good secure second factor. But I don't see anyone getting as passionate about not using an android for second factor as people get over using a computer. Which to me seems totally unjustified.

Especially since most enterprises own their employee's laptops, but not their phones. The administrator can manage and mandate full disk encryption on the PC. But if the employer offers TOTP for a second factor, they have no control over what device holds those TOTP codes.

> when you enable 2FA, they can disable the regular checks that they have for 1FA accounts

Who does that? And why would anyone do that?

It always seems to me like security solutions rarely take into account usability and user experience. Even something which should be simple like configuring a client to use SSL over plaintext can block productivity for a multitude of reasons until you finally put all the pieces together correctly.

Maybe it's out of necessity, because convenience features would be less secure. Maybe there's not much overlap between those concerned with security and those concerned with ease-of-use, except for cases where companies can develop tools that encourage good security practices while exposing the end user to other risks (e.g. password vaults with one entrypoint).

So what you end up with is people gravitating towards bad security practices and using shortcuts because it's a PITA to maintain the good ones. Let's skip using SSL because we need to get work done instead of troubleshooting the dozen possible misconfigurations. I'll use a really short password for my AppleTV account because it's too hard to type the damn thing with the on-screen remote. I'm tired of getting a 2FA code 50 times a day to get work done, so I'll implement a hot key to generate it from the command line.

Seems like ease-of-use for security solutions should be almost as much of a priority as the security implementation itself in some cases.

Alternative: Use `gopass` which will generate OTP codes and can be used in conjunction with a Yubikey or other OpenPGP smartcard to keep the "something you have" factor in play. I made a PR that sees those codes available through the gopass browser extension, as well. It's pretty painless and is code and a security model that can be understood in an afternoon (though not my favorite and begs for a "RIIR").

The best non-spam comment: "Hi, I'd suggest to encrypt the ~/.otpkeys file with pgp :-)"

If you like oathtool, you may like oathgen and goathgen too (I wrote them years ago). They take stdin so you can store your secrets PGP or NaCL encrypted, etc. and pipe them:

https://github.com/w8rbt/oathgen

https://github.com/w8rbt/goathgen

I use Bitwarden for TOTP generation, this is how I use it for command line TOTP code generation, with NPM's 2FA as an example:

  npm publish . --otp $(bw get totp npm)

Note: it requires the Bitwarden vault to be unlocked for the current shell, as such:

  export BW_SESSION=$(bw unlock --raw) && echo $BW_SESSION

I built something like this (a bash script wrapper around oathtool) but ended up outputting the text to a picture with ImageMagick. This is much more polished, though. Using a proprietary program for two-factor (Google authenticator or Authy) is something I like to avoid and oathtool fits the bill. However, it's not something I'd recommend without caveats: Encrypt your tokens using GPG or something like that. Failing that, at least keep these on an encrypted hard drive, and don't put them on external media. Keep it on as few devices as you can, and not on a shared machine.

Edit: Suppose I should add the link. https://gitlab.com/elagost/linux-2fa

I build it for the clockworkpi device, so there were more constrains than a normal desktop system. https://www.clockworkpi.com/

Here’s a PHP library to achieve the same https://www.idontplaydarts.com/2011/07/google-totp-two-facto...

I see a lot of hate here, but this concept fits my use case nicely.

I'm really not worried about my computer being stolen or pwned. I'm more worried about somebody trying to access some service from elsewhere in the world, with a password they would have obtains from another mean.

In which case, OTP on my laptop is sufficient, and it also has the nice property of being a backup of the seeds on my phone, which I can loose.

Here's a OTP client (Google authenticator compatible) that's also an HTML5 PWA. Obviously you shouldn't assume it's secure or production ready. I found it useful for testing 2FA when adding it to another app. Also be careful, not all OTP clients you find online are GA compatible.

https://otp.codebro.org

A better idea would be to utilize U2F just like in browsers and use a hardware token like Yubikey.

Yubico provides a Python and C library for this: https://developers.yubico.com/Software_Projects/FIDO_U2F/U2F...

The controversy of this tool vs Google Authenticator essentially boils down to how secure your laptop/workstation is vs how secure your phone is.

Without being purely "conservative", i.e. it was first done on phones therefore it should stay on phones, what are the actual arguments for one vs the other? What do phones have that laptops don't, and vice versa?

In theory, the phone stores the TOTP secret on a TPM that can't be backed up. So the TOTP secret is fundamentally tied to that specific phone. You can't back up the secret, and somebody with brief access to your phone cannot copy it. Even with unlimited access to your phone, it's unlikely anyone can copy the secret.

This solution stores the secret in your home directory, which is easily readable by any process that has access to your hard drive. Anyone with brief access to your laptop/workstation can easily copy the secret. If you back up your home directory, anybody with access to your backups has access to the secret.

What's a TPM? Is it this? https://en.m.wikipedia.org/wiki/Trusted_Platform_Module

Again, forgive my ignorance, but do smartphones routinely include TPM chips that Google Authenticator utilizes? Never heard of that before.

Yes, a "Trusted Platform Module." Now that I'm looking around it doesn't look like Google Authenticator actually does this, but it does make it more difficult to copy the TOTP secrets than this 2FA on the command line thing.

Though it could and probably should. (Really, this 2FA CLI app could probably do so as well, most modern laptops probably have a TPM.)

> Without being purely "conservative", i.e. it was first done on phones therefore it should stay on phones, what are the actual arguments for one vs the other? What do phones have that laptops don't, and vice versa?

People are away from their laptops and exposed to risk of then being stolen without immediate knowledge of that fact more often than the same is true of smartphones, which makes laptops somewhat more of a security risk.

Though, I thought that now TOTP in general, on any platform, is at best a second choice after U2F hardware tokens.

    #!/bin/sh
    # expects keyboard shortcut to be super+2
    twof=`oathtool --totp mysecret`
    xset r off
    xdotool keyup --window 0 2 type --clearmodifiers --window 0 "$twof"
    xset r on
    sleep 0.3 && xdotool key 'Super' &

Shhh... (By the way real 2FA devices like yubikeys are great...)

Can anyone explain to me why you would ever want to do this instead of proper public key encryption? A huge advantage of public key encryption is that it doesn’t rely upon having well synchronized clocks like many 2FA solutions. Also, you can easily insert a “something you know” by putting a password on your private key.

> Copy/Paste is easier than typing digits displayed on your phone

i'd say that if your main concern is having to type digits on your computer keyboard and you'd like to copy/paste it, KDEConnect can store an TOTP generated on your phone to your computer clipboard, as in 1- generate OTP on your phone 2- C-v on the computer 3- done

Pretty cool. I've been using this 2FA tool written in Go which is easy to understand and works great:

https://github.com/rsc/2fa

I will make a separate submission but since a lot of security minded people here- I want to ask- how does everybody manage their pins? I tend to forget them but password manager seems like an overkill.

I did the same thing in Python a while ago. Our security team didn't like it. https://pastebin.com/9CLhPiff

Make sure you use that from an another computer, or this is essentially an anti-pattern for 2FA. Reason would be, it's no different than entering password at the same machine.

I wouldn't expose your private keys for 2FA in plain text on your laptop. At least encrypt the file with GPG key to not expose it and read it in the script

Russ Cos wrote another excellent one:

https://godoc.org/rsc.io/2fa

Looks like the comments on that site need 2FA.

I just use JIT SSH connections, which is practically a 2FA solution.

This would be better if the key did not show up in the process list.

I agree with you, however I'm the only user on my laptop so for the few milliseconds that oathtool is running it's not a problem for my use case.

$ time otp aws

otp aws 0.00s user 0.01s system 98% cpu 0.015 total

Even back in the 90's Mysql was able to hide the CLI supplied password from the process list. It would be cool if oathtool was able to do the same.

> Even back in the 90's Mysql was able to hide the CLI supplied password from the process list. It would be cool if oathtool was able to do the same.

This has always been a brittle and not easily portable approach.

And doesn't protect you from an attacker doing something much simpler: reading your .bash_history file.

Passing passwords as arguments has always been a bad idea.

This bug in oath-toolkit was reported a few years ago:

https://bugs.debian.org/839278

(Debian maintainer and upstream maintainer are the same person.)

Reply on news.ycombinator.com