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.
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.
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.
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.
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.
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 ️.
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.
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").
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:
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.
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.
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.
> 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.
[+] [-] spectralblu|7 years ago|reply
[+] [-] StavrosK|7 years ago|reply
We need WebAuthn yesterday.
[+] [-] w8rbt|7 years ago|reply
[+] [-] paxy|7 years ago|reply
[+] [-] mrmattyboy|7 years ago|reply
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|7 years ago|reply
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|7 years ago|reply
[+] [-] Deadsunrise|7 years ago|reply
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.
[+] [-] rusbus|7 years ago|reply
[+] [-] techntoke|7 years ago|reply
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
[+] [-] philsnow|7 years ago|reply
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`).
[+] [-] jacekm|7 years ago|reply
https://bitbucket.org/devinmartin/keeotp/wiki/Home
https://sourceforge.net/projects/traytotp-kp2/
[+] [-] elagost|7 years ago|reply
[+] [-] tptacek|7 years ago|reply
[+] [-] ptoomey3|7 years ago|reply
[+] [-] umurkontaci|7 years ago|reply
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|7 years ago|reply
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.
[+] [-] jwilk|7 years ago|reply
Who does that? And why would anyone do that?
[+] [-] smugworth|7 years ago|reply
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|7 years ago|reply
[+] [-] jlv2|7 years ago|reply
[+] [-] w8rbt|7 years ago|reply
https://github.com/w8rbt/oathgen
https://github.com/w8rbt/goathgen
[+] [-] franky47|7 years ago|reply
[+] [-] elagost|7 years ago|reply
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/
[+] [-] badideaprojects|7 years ago|reply
[+] [-] sametmax|7 years ago|reply
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.
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] Can_Not|7 years ago|reply
https://otp.codebro.org
[+] [-] Leace|7 years ago|reply
Yubico provides a Python and C library for this: https://developers.yubico.com/Software_Projects/FIDO_U2F/U2F...
[+] [-] YjSe2GMQ|7 years ago|reply
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|7 years ago|reply
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.
[+] [-] dragonwriter|7 years ago|reply
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.
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] Jach|7 years ago|reply
[+] [-] slaymaker1907|7 years ago|reply