A security reminder to anyone who is in the target audience here: if you're clever enough to have TOTP 2FA enabled on your Google account, get some cheap USB security keys and enable Advanced Protection, which completely disables non-hardware 2FA. It requires two different tokens (and you should really get one for each computer you have/use, plus at least one offsite backup) because once enabled it actually and completely locks anyone out of the account that does not possess one of the enrolled tokens.
TOTP is not much better than SMS-based 2FA. It's still vulnerable to phishing, local device malware (that attacks your TOTP in your password manager), etc. It's best to use hardware tokens everywhere that support them, and both Google and GitHub do. (And Google supports a special hardware token only mode which I wish more sites would adopt.)
> TOTP is not much better than SMS-based 2FA. It's still vulnerable to phishing, local device malware (that attacks your TOTP in your password manager), etc. It's best to use hardware tokens everywhere that support them, and both Google and GitHub do. (And Google supports a special hardware token only mode which I wish more sites would adopt.)
Since this device doesn't actually have network connectivity he might have this problem potentially when someone is watching his watch with a camera, or if someone is able to do something in his close proximity, which means it absolutely is better than SMS-based 2FA and the phishing attack vector is different and if a person has access to him in close proximity anyway the cheap USB security doesn't offer anything(well not completely true, but almost) over this particular TOTP use case.
Security is kinda cool these days and everyone is a security expert, but just reiterating trained responses without actually thinking about the attack vectors is getting a bit annoying. It's as if it is cool to say the most secure use case people can think of without even considering what and who it is that is actually protected and from whom.
Yeah, sure, but then again a watch on your wrist is harder to take away than a hardware key on your physical keychain that you don't pay attention to.
EDIT: yes, lol, thank you for explaining what phishing is jgrahamc. We didn't know. I get that a lot of Americans and some Germans guard their car keys like an internal organ, but for a lot of people in the world a keychain is something you toss in an insecure place most of the time of the day.
Phishing doesn't require stealing the watch. It just requires me to type in a TOTP token on a phishing website. Very different threat model than physical access.
It may be easier to steal, but it should have some kind of minimal protection. It should lock out after a low number of failed pins, for example. The YubiKeys do this.
stealing watches is pretty trivial if you practice. but also TOTP is just more inconvenient than, say, the Microsoft authenticator with biometric confirm and server push, or a token you just press that's near your computer or phone. the fact that these can also help defeat phishing is just one more benefit.
Well if you want to look at specific attack vectors this one may have remote access issues based on what and where you store the source code. I'd guess OP knows what he's doing, but someone trying this with an accidentally open repo or comprised machine are possibly bigger risks here then with most other TOTP solutions.
Equally it has the hardware key flaw of being able to be physically stolen, but with no option of an additional lock, and more likely then most systems that you might leave the totp running so a camera exploit is a little easier then with an app maybe.
Not to say I think any of this is likely, and with the exception of a public repo mistake, it's probably a lot harder then an SMS exploit.
While I agree with your points regarding the security of TOTP / SMS, and I do push for hardware keys at work, I think a case could be made for a mixed use for "regular people".
Maintaining two hardware keys is an absolute PITA, especially if you go down the route of storing one off-site, hence not having it with you to enroll when you get a new account.
What I do, is use the hardware token as the "main" factor and use the TOTP if for some reason I don't have the token (I may sometimes forget it at home when I'm at my parents' house).
The point is that, since I usually have my key, if I'm presented with a Google or whatever prompt for a TOTP, I know something's fishy. I don't normally use that, so I'll investigate why that happens and won't just go ahead and type my code in there.
This needs to be repeated too. And developers need to be reminded that anything they secure with hardware keys absolutely needs to accept multiple hardware keys in order to mitigate loss or destruction of the first key.
Not so sure, for me I am going to forget to have the hardware device. I will probably lose it. I will forget to take it with me and then can't access things mobile. Or will take it out with me and lose it. Have enough stuff to keep track of! I would use hardware for some occasional use logins though.
Why is TOTP not much better than SMS? Someone can take over your phone contract to get those SMS messages by sweet talking your telco, but for TOTP they need to get hold of my device or get some malware onto my phone.
> TOTP is not much better than SMS-based 2FA. It's still vulnerable to phishing, local device malware (that attacks your TOTP in your password manager), etc.
It's still massively better than SMS-bases 2FA. Those vulnerabilities you list are all things that involve you or your device. You can take care to avoid them.
With SMS there are also vulnerabilities that don't involve you or your device, such as someone convincing your carrier to transfer your phone number to them.
SIM swap is real but rare, since it cannot be automated. It is also largely defeated by having a strong and unique password, assuming that your provider doesn’t use SMS as a single factor password reset option.
If you’ve got a strong and unique password then your primary concern should be phishing, which is the same for sms and totp.
I have a $50 yubikey nano plugged into each of my multiple-thousand-dollar computers, protecting my accounts containing/accessing client data worth millions.
If anything under $100 is too much to secure your account, just use SMS 2FA, or disable 2FA entirely.
Fwiw big players regularly give free keys to e.g. OSS maintainers. Dunno if it’s still active but Pypy has a program for maintainers of crates flagged as sensitive (or something like that), you can get two Titan keys courtesy of google.
I also have a pair of github-branded yubikeys from a long time ago but I don’t remember what that program was.
> cost has been prohibitive.
A titan is 35 or so, hardly prohibitive. And if you have access to anything important your company ought be glad to get you one or two, or yubis.
I was a backer of the V2 and I think my order is now a year overdue. I don't really back things on kickstarter because I don't like to gamble, but this seemed like a sure bet. Turns out it wasn't.
I got mine (and it randomly died so they sent me a second one). You still haven't received your first one? That sucks, they're generally very good devices (minus them randomly dying, I guess).
I just wanted to call out how cool it is to replace the guts of a 1980s-era wristwatch with a ARM Cortex M0+ microcontroller, while reusing the original display and buttons.
One of my long-term hacker project goals is to replace the guts of an analog watch with a microcontroller and turn it into a "smartwatch-lite". There's a surprising amount of information and features you can display with three pointers (and a small numeric window): temperature, heartrate and other body sensors, NFC to replace payment or access cards, etc.
Yeah, I had a Withings semismart watch, one of their cheaper models without a screen. It integrated a pedometer, and had a dial had that would show steps taken, it moved from 0 to 100% of your goal. One had to pair it to the Withings Android app to set not just the goal for number of steps/day, but even for setting the time.
I sold it after a few months, realizing how much I missed a second hand and a glow-in-the-dark face. Also, the app had a ton of telemetry going back to Withings.
Building your own you would be in full control of the data.
Yep there are plenty of watches like that (for example Fossil I think), but I'd really like to take a nice vintage watch and build a hackable watch platform myself.
How accurate does the time have to be for TOTP to work? If the watch drifts a bit, will it no longer work? Compared to your phone which is synced with an NTP server.
I wish all implementations would at least accept one previous generation. It sucks having to either wait for the next code or try to input before the timeout if it is close.
I'm not sure I've ran into an implementation that doesn't.
I used to wait for the code to rollover before entering it but honestly if you're not sure if the implementation accepts a previous code or now just use that time to try it and if it fails you still have like 45s to enter the current code.
Is there some Unix-ish tool to generate these TOTPs on a laptop? I don't like to keep the 2nd factor on a small mobile device that is easy to lose. So I ask about a laptop tool.
By Unix-ish I mean something that is small and does one thing well. Like pipe in a secret to it and it gives me a TOTP? Pipe in multiple secrets and it gives me multiple TOTPs? Then I don't have to remain beholden to a custom encryption format. I can encrypt my secrets with other Unix-ish tools, decrypt it, pipe it to this tool and get my TOTPs. Recommendations?
I just cooked up something in Python if you have it installed on your system, quite straightforward to use. If there's interest, I can prepare a compiled version.
Unlike the other ones posted here, this one just takes secrets as arguments:
I believe it is worth mentioning here that reading secrets from command line arguments exposes the secrets in shell history (e.g., ~/.bash_history, ~/.zsh_history, etc.), thus writing the secrets in cleartext to the filesystem. If command line auditing is enabled on a system, any secrets in command line arguments would be exposed in such audit logs too.
Further, if multiple users are logged into the same system (perhaps an unlikely scenario for most people), then secrets in command line arguments would expose the secrets in the output of ps -ef too thereby exposing the secrets to other users.
By the way, I have a similar script at https://github.com/susam/mintotp but it reads secrets from the standard input (as opposed to reading from command line arguments), one secret per line, and outputs TOTP values, one per line. Most of what this script does can be done with oathtool too and there is a section titled "Alternative: OATH Toolkit" in the README that documents this in detail.
fun fact: you can teach your shell to ignore commands that begin with a space character. in bash $HISTCONTROL needs to be ignorespace or ignoreboth, in zsh you must setopt HIST_IGNORE_SPACE
> reading secrets from command line arguments exposes the secrets in shell history
Yes, and process arguments (such as from command line) can also be accessible in process list data that's accessible to other processes and users.
Even if the process only lives for an instant, or normally no other processes could access the data, good practice is to nevertheless keep secrets out of any process arguments.
I should indeed have mentioned that. On the other hand, this is not a concern if you do not execute the it outside your shell (e.g. in another script that reads TOTP secrets from elsewhere).
This is secure because the secret never leaves the hardware key.
This is convenient because you launch a tool with a global keyboard shortcut and copy/paste the code. I use `yubikey-oath-dmenu` to allow me to quickly filter to the TOTP code I need.
Not exactly the same, but if you're using Bitwarden (which is compatible with generating TOTP tokens) to manage your passwords, you can use their bitwarden-cli tool to request tokens from the cli: https://bitwarden.com/help/cli/#get
> Is there some Unix-ish tool to generate these TOTPs on a laptop? I don't like to keep the 2nd factor on a small mobile device that is easy to lose.
I know that this is not really answering your question, but most open-source TOTP apps (like andOTP and Aegis) can export all the TOTP in an encrypted file that you can save. So if you lose your main TOTP device you can restore all of them quite easily.
It relies on file permissions so is not exactly robustly secure (no idea about RAM vulnerabilities etc).
As per the author, I consider my laptop the fundamental point of vulnerability. If someone else gets access to it, I'll know and I'll hit the metaphorical panic button :)
Edit: I recently set up a new laptop, and copied my OTP seeds from Aegis into gauth without a hitch. Another step closer to me moving away from Authy.
This means your laptop itself would be your hardware device, the TOTP secret would be stored in the TPM and theoretically impossible to steal/copy. Of course this means you will probably want a mobile device (possibly a second laptop also) as a backup.)
Note that tpm2-totp is specifically meant to authenticate your laptop's state (TPM PCR values) to you, not you to some third system. But you could adapt tpm2-totp for the purpose of authenticating you to other systems.
If you are not that a hacker but already own a Smartwatch such as the Apple Watch, Authy[1] is a pretty rock solid option. I use Authy for a few key credentials, and I have used my watch for the keys.
Authy gets recommended often here but got turned off of them because they require a phone number to set up the app on iOS. There's no phone number requirement for TOTP implementations so I eventually found Duo Mobile. This was before they got bought by Cisco.
The phone number gets used during account recovery; when I reset my iPhone once without a second Authy device to activate it, I was locked out for 24h while it bombarded my number with calls and texts about the impending restore. I appreciated that safety measure.
And I don't appreciate being forced into a "feature" that specifically subverts the entire god damn point of 2FA codes and leaves them in an unprotected state on some third party server.
I apologize for getting that wrong and also want to acknowledge that choice IS good, and I do agree that informed users can reasonably make that decision. I get a bit too "there's one best/right answer" on this topic, thanks for checking me a bit.
The TOTP secrets are encrypted with a passprhase locally. You need the phone number to download the encrypted secrets but then need to use your passphrase to decrypt the restored backup locally.
AndOTP is great. Especially if you compare it with all the iOS options.
iOS TOTP apps all suck, it's amazingly bad. I installed like ~15 different ones. After the fifth try, I just had to know if it was just my poor initial selection or a general problem.
Each and every iOS TOTP app has at least one crucial problem - requiring a subscription, mandatory sync to a proprietary cloud, having no export-import, not having a watch companion, being from an unknown/generic developer, no support for longer TOTP codes (worse, some display it truncated!) or they're simply very buggy.
I settled on Step Two because it was like all the others, but not an eyesore...
iOS's security makes a self-hosted/non-third party backup/sync super difficult IIRC. (Unless you use Apple's product) I think unless the app has it built in, it's not easily doable. Android can use syncthing, but even Google is making that more and more difficult with each release.
Is there a standard app developers can use to securely sync/backup to for self-hosters? Is there a 'nice' UX/flow to connect apps to s3-style storage (enabling folks to use AWS/DO/Backblaze/whatever?) or would that be too raw?
You're most likely correct about automatic synchronisation from filesystem like that. That though doesn't mean there can't be any built-in integration with Next/OwnCloud or simply manual export-import.
Yes. It had no import functionality, no Apple Watch companion, and a relatively convoluted setup process that adds a point of failure without reasonable reduction in any risk.
One would have to set a password that they then store in a password manager, that is then accessed using the same 2FA protected by the password. Plus a mandatory PIN, with the same caveats. Cyclical or duplicate authentication is simply not good design.
Aegis is another open-source option. It can import the andOTP format and can also export the keys, but has the advantage of being able to use fingerprint unlock.
Ah yes, Twilio, the company that activated 2FA, forced users to activate it during login, and somehow forced it to be SMS auth (aka, completely jamming my account because I dared to login).
Had to manually contact them to resolve and then close the account because FUCK THAT, and fuck SendGrid too, which did the exact same thing after Twilio acquired them.
Sorry, I don't buy for a second that that was an accident or negligence. I'm sick of watching people play ball with companies that pull such moves. (Edit: you want to KYC me to prevent abuse? Fine. Don't make my startup insecure to achieve it.)
Authy is just not a good suggestion here when there are standard, non-needlessly-tied-to-sms options.
That's what I use as well. Nice apps, fair pricing (One-time payment) and no data collection.
Started using it only because of its feature to sync between devices with iCloud - so no more stress if my phone breaks.
Unfortunately it has no import/export functionality and truncates eight/ten-digit TOTP codes. As I mentioned in an another comment, even then it is better than most alternatives on iOS.
No. They aren't. This thread is seriously upsetting to read. So many people clearly haven't even remotely begun to think about what they're doing or the implications thereof.
Another user here pointed out that Authy uses a user provided password to encrypt the 2fa secrets on the server. That's definitely more secure than I had said, that's my mistake. (I still have my reservations, but that's getting too pedantic to matter here)
Key sharing isnt fine but how many web services will let me enroll multiple totp tokens simultaneously? I havent encountered any, personally. yall designed this reality, now you have to live in it.
This is very cool, I just recently ordered a light phone 2 (a dumb phone) - and one of the things I am currently trying to solve is how I am going to access my google authentication codes for various work and personal project related accounts. Something like this would be very awesome, but also this post really demystifies how this type of auth works.
If you're a bit weirded out by the website secret pasting, I made a PR which lets the sensor watch load TOTP secrets from an Aegis export (essentially just a bunch of TOTP URIs):
This is super cool but do folks really need their google and GitHub 2FA codes often enough to justify this? Browser sessions are pretty durable it seems. The one thing I could think of is GitHub admin type actions that prompt for a credential to enter “sudo” mode or whatever they call it. However in that case they’ll take your password as well (or a webauthn key in my case)
It saved me a trip back to my desk a few times when I had to sign in to an account protected by 2FA on another computer and I forgot to bring my phone along.
I always thought that the benefit of the physical device was that it was decoupled from the main device. If someone steals my laptop, for example, they won't be able to access my MFA secured accounts unless they ALSO steal my phone (and are unable to lock it).
Sure, but if your threat model is that the attacker has enough access to your machine to extract your password manager's database, they can also just copy your session cookies from your existing browser session. Even in the case of password leaks, if someone breaches the password database of a website they can just as easily dump the TOTP table.
Personally my view is that (if you're using a password manager with a unique password per-site) 2FA primarily protects you when you have to input your password on an untrusted system that may have a keylogger. In that case it doesn't really matter where you store the TOTP key (presumably you're not going to unlock your password database on that machine).
To be fair, in the case of a security bug in the password manager (such as the few previous LastPass bugs in this vein), you are slightly more protected. But I use KeePassXC which has a far more segregated design so I'm not as worried about this as I would be if I was using a password manager entirely integrated into the browser (either built-in or an extension).
(Though these days I primarily use U2F/WebAuthn if the site supports it.)
The concept of programming a dumb watch is rather appealing; this project looks like one that's both practical and quite fun to work on.
It would be rather neat to have a dumb watch that can take in custom embedded code (say Lua) for people who enjoy hacking but are terrible at hardware. I'd buy one day one!
It is pretty trivial to put this board in a Casio watch; I'm not even sure I'd call it tinkering unless you decided you want to connect the buzzer (requires soldering one bit of metal).
There needs to be a button based passcode to view TOTP instead of just pressing one button once. That would add a layer of security. A combination of buttons and number of presses should still be somewhat added security.
What's the threat model here? The TOTP code is worthless without the password. You would need to get my password and physically obtain the watch; what threat does a button code protect against?
Someone who steals the watch from my house doesn't have the password.
Someone who phishes the password doesn't have access to the watch.
The government agent who has exerted enough physical force or legal coercion to get me to cough up the password can demand the TOTP code at the same time.
The only added security I can think of on a two factor authentication thing is a fingerprint reader on a physical hardware key, and even that's more of a gimmick than anything. And maybe TOTP codes generated from a password manager, but IMO that already defeats the purpose of two-factor because if your one device with password manager is compromised, they have both password and the second factor.
The four number code IS the added security already.
A security reminder to anyone who is in the target audience here: if you're clever enough to have TOTP 2FA enabled on your Google account, get some cheap USB security keys and enable Advanced Protection, which completely disables non-hardware 2FA. It requires two different tokens (and you should really get one for each computer you have/use, plus at least one offsite backup) because once enabled it actually and completely locks anyone out of the account that does not possess one of the enrolled tokens.
https://landing.google.com/advancedprotection/
TOTP is not much better than SMS-based 2FA. It's still vulnerable to phishing, local device malware (that attacks your TOTP in your password manager), etc. It's best to use hardware tokens everywhere that support them, and both Google and GitHub do. (And Google supports a special hardware token only mode which I wish more sites would adopt.)