
2FA on the command line - mbushey
https://www.sendthemtomir.com/blog/cli-2-factor-authentication
======
spectralblu
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...](https://support.yubico.com/support/solutions/articles/15000012643-yubikey-
manager-cli-ykman-user-manual#ykman_oathwicpwc)) 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.

~~~
StavrosK
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.

~~~
feistypharit
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.

~~~
jorvi
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.

~~~
Spivak
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?

~~~
jorvi
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.

------
mrmattyboy
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!

------
deathanatos
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.

~~~
agwa
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.

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

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

Even works with Browserpass and the Pass Android client:

[https://github.com/browserpass/browserpass](https://github.com/browserpass/browserpass)

[https://github.com/zeapo/Android-Password-
Store](https://github.com/zeapo/Android-Password-Store)

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

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

[https://qtpass.org/](https://qtpass.org/)

------
tptacek
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.

~~~
ptoomey3
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 ️.

------
umurkontaci
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.

~~~
clinta
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.

~~~
ihattendorf
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.

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

------
smugworth
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.

------
colemickens
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").

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

------
w8rbt
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/oathgen)

[https://github.com/w8rbt/goathgen](https://github.com/w8rbt/goathgen)

------
franky47
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

------
elagost
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](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/](https://www.clockworkpi.com/)

------
badideaprojects
Here’s a PHP library to achieve the same
[https://www.idontplaydarts.com/2011/07/google-totp-two-
facto...](https://www.idontplaydarts.com/2011/07/google-totp-two-factor-
authentication-for-php/)

------
sametmax
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.

------
Can_Not
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](https://otp.codebro.org)

------
Leace
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...](https://developers.yubico.com/Software_Projects/FIDO_U2F/U2F_Host_Libraries/)

------
YjSe2GMQ
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?

~~~
lukeschlather
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.

~~~
YjSe2GMQ
What's a TPM? Is it this?
[https://en.m.wikipedia.org/wiki/Trusted_Platform_Module](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.

~~~
lukeschlather
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.)

------
Jach

        #!/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...)

------
slaymaker1907
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.

------
throwayaw
> 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

------
miguelmota
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](https://github.com/rsc/2fa)

------
fxfan
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.

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

------
leowoo91
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.

------
rexysmexy
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

------
shurcooL
Russ Cos wrote another excellent one:

[https://godoc.org/rsc.io/2fa](https://godoc.org/rsc.io/2fa)

------
aaronarduino
Looks like the comments on that site need 2FA.

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

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

~~~
mbushey
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.

~~~
null_content
> 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.

