TOTP tokens on my wrist with the smartest dumb watch
blog.singleton.io
blog.singleton.io
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.)
If anything under $100 is too much to secure your account, just use SMS 2FA, or disable 2FA entirely.
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.
https://www.cloudflare.com/products/zero-trust/phishing-resi...
Related thread: https://news.ycombinator.com/item?id=33020078
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.
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.
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.
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.
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.
Does this make Google stop asking for my phone number?
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.
If you’ve got a strong and unique password then your primary concern should be phishing, which is the same for sms and totp.
That's a big assumption and one that is far from generally true.
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.
https://github.com/google/google-authenticator/wiki/Key-Uri-...
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.
[edit] https://www.crowdsupply.com/oddly-specific-objects/sensor-wa...
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?
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
But if you want the simplest cli thing, you can probably can use this golang ( https://github.com/yitsushi/totp-cli ) or this python ( https://github.com/WhyNotHugo/totp-cli ) implementations.
Unlike the other ones posted here, this one just takes secrets as arguments:
> python -mtotp DGLTPWEUERUUDCEC SWPKQCKEWRXPCRXE
628502
674329
https://pastebin.com/apNKxMBFFurther, 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.
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 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.
Alternatively, gopass[2], which re-implements pass in golang, has this functionality built in[3].
[0] https://github.com/tadfisher/pass-otp
[1] https://www.passwordstore.org/
[3] https://github.com/gopasspw/gopass/blob/master/docs/commands...
It allows export import feature of keys
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.)
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.
You can also use python's pyotp.totp.now()
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.
FYI, Authy was bought and is now owned by Twilio
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.
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...
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?
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.
Great!
(Side note: Authy backups are encrypted client-side with the user's backup password. They're not unprotected on a third-party server; Authy has no ability to decrypt them. https://authy.com/blog/how-the-authy-two-factor-backups-work...)
Also to be totally honest, each device should have their own TOTP key and while backups are fine*, key sharing isn't.
of course, they're not open source, so I'm not really going to bat for them here, but am I missing something?
https://authy.com/blog/how-the-authy-two-factor-backups-work...
https://www.ghacks.net/2022/08/10/twilio-the-company-behind-...
etc.
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.
https://github.com/joeycastillo/Sensor-Watch/pull/95
This is the reason I bought the board. It makes me happy not having to use my phone for this.
So this is certainly useful for some people.
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.)
I log out of everything every day.
https://www.crowdsupply.com/oddly-specific-objects/sensor-wa...
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!
I’m quite excited at the idea of taking one my old ones and giving it new functionality.
For InfiniTime (the PineTime firmware), here is the issue/discussion about it: https://github.com/InfiniTimeOrg/InfiniTime/issues/310
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 four number code IS the added security already.