Neat! I should try this. Been using pass since forever. Does it support autofill on Android?
GNU Pass is a great example of Unix-y interoperability for me. I sync the .password-store folder over to my phone with Syncthing, where the Password Store android app reads it. Password Store in turn talks to OpenKeychain for my encryption key with biometrics support. Changes are also synced back to my other devices. Each piece of the puzzle can focus on doing one thing and doing it well, even on Android!
Thing is, I often create or update passwords from my phone. I have yet to find a good UX for committing and pushing those changes from Android. Though I would be interested in that, because I have little protection against accidental deletion now.
With syncthing it's just instantly everywhere whenever I add an account, no action required. That's particularly useful when I create an account on my computer, then have to scan an OTP QR code with my phone. By the time my phone's out of my pocket the fresh account is already in the store to save the OTP code into.
But both Android [1] and iOS [2] clients have git functionality built-in. You just swipe it up (for iOS) or press sync (and swipe too, don’t remember if it works on Android) and it syncs.
A couple of iOS notes:
- The iOS app has a nasty bug, when you have not the latest repo on your iPhone, it cannot merge changes. So I recommend syncing your repo first, and then add new passwords from your mobile. IIRC, Android has no issues with that, but I’m not sure here.
- If you have a complicated ssh key (I have gpg-key for that) the iOS client doesn’t work properly. Could also have issues with other keys. IIRC, it’s the iOS issue. So I use a very special iPhone-only key that I added to my GitLab repo, where my passwords are stored. I generated the key with `ssh-keygen -t rsa -b 4096 -m PEM -f /tmp/id_rsa` and transferred it to my iPhone via iTunes, to ‘pass for iOS’ application.
I myself never add passwords from my mobile, but I use mobile for adding 2FA (scanning QR-code), so my workflow as follows: I make sure I pushed the changes from my laptop/desktop with `pass git push`, then I swipe up on my iPhone, and only then I add 2FA code by scanning the QR-code. Then I push changes back, `pass git pull` from my laptop/desktop and add 2FA one-time codes manually. That may sound weird, but actually that’s quite simple for me.
Syncthing may just work here, but for me, I don’t run Syncthing all the time, only when I need to sync some changes, which is infrequent for me. As well as my passwords, actually. I don’t care too much with my mobile, as I try to limit my smartphone usage and pick laptop whenever possible, so to avoid over-consumption of media (which is easier on a modern smartphone). But that’s just another story.
I used gopass for a while and regret it. They kept messing with the contents of passwords, sometimes in ways that it itself couldn't read. Adding `GOPASS-1.0` etc. I feel like it also did way too many encrypts/decrypts for each password (I'd have to press my hardware button 4 times just to rename a password I think). Slowly fixing all my passwords having moved back to pass.
I'm no fan of bash or pass's rather anemic built in structure but I don't feel like gopass were the right stewards.
I think browserpass ff+chromium plugin supports otp as well. A nice thing is it's a native plugin so you can manage it with your system package manager (rather than the extension store).
I wrote a CLI password manager as a personal project a few years ago and it would only clear the clipboard if the hash of the contents matched the hash of what was originally copied. I presume `pass` does something similar.
Hash? Why would you do any hashing? The domain is only so large so it's meaningless even if you cared about keeping the original bytes in RAM (which you don't).
This is the same concept behind the fact that it typically makes little to no sense to hash phone numbers or credit card numbers.
The way my clipboard-clearer worked would have exposed* the plaintext secret if it wasn't hashed. Surely this would be generally true; however, in my case, it would have been particularly trivial to exfiltrate.
(* The clipboard exposure was more limited...although probably only in a "security by obscurity" sense :P)
KeePassXC[1] password manager supports TOTP and I use it for that purpose in addition to storing passwords. It never made sense to me to use an app like Authy.
I suspect most people make the assumption that an Authenticator app is something special that needs to talk to the service that issued the QR code/secret string.
It's nothing more than a SHA1 hash of a secret string and an adjusted current time.
The keepassxc CLI reopens the database separately; it's actually possible to use git-credential-keepassxc† to do the scripting instead because it acts more like a browser (so it interacts with the already running instance of KeepassXC).
For me it’s separation of secrets. If my vault is exposed they won’t be able to log in without the codes. Putting it all in one place is a bad idea, some may think.
1Password wrote a blog post stating something similar. Basically it comes down to if you're using TOTP as a true second factor. If you are it really shouldn't even be accessible from the same device.
I suspect most people aren't though. Most people are just being forced or nudged to using it. The main purpose for platform providers to push TOTP is probably consumers reusing passwords leading to account compromise, but if you are using a password manager, you can generate high entropy single-use passwords which don't really have that problem.
What if you lost or somehow broke the phone? You'll be locked out your stuff faster than you'd expect. If you back it up to a cloud service, are you sure you can recover it without the TOTP? If you are backing it up to your computer, then it's already on your computer and will probably be compromised when your vault is, so you might as well use your vault anyways.
I load my TOTP tokens into two phones, one that stays at home fully charged. If I lose them, I can easily reset my TOTP with any reasonable provider - I have the account login and password, and can authenticate with my email/provide proof of identity.
The conflict between single point of authentication and single point of failure is intractable. Just pick a poison based on which is less likely to fuck you over.
I only use KeePassXC for TOTPs now. Note it can work on Android too. There is often no good way to back up phone authentication apps without a cloud service, which is a problem if I ever lost or broke my phone, and it requires me to use a separate device when using my computer, which I'd rather not do.
Autofill can save you a lot of time if you prefer to usually stay logged out of websites (auto-deleting cookies, for example) but need to log in sometimes.
Several comments here suggesting that using password managers for TOTP defeats the purpose of TOTP as a second factor. I don't agree.
I strongly prefer other factors (U2F/FIDO(2)/WebAuthn/Passkeys/whatever) but unfortunately TOTP is still extremely prevalent. Worse is when only a single secondary factor can be registered, in which case even if something other than SMS or TOTP is available, I slightly bias away from hardware security tokens in order to have a clear recovery path. I can at least back up most TOTP keys.
I agree that having a second vault for TOTP seems superior but from a UX and recovery perspective it's not so clear. Are both vaults available on all devices? Are they usually unlocked simultaneously? Is it likely that one vault but not the other would be stolen? Or you have a separate device or air-gap and now the usability adds friction. It seems like diminishing returns.
Conversely a single vault still offers significant protection from many attack vectors, including keyloggers and phishing. Even if access is obtained via MITM'ing a TOTP, the blast radius is often limited to a single session. Many services have poor session security, once established, but many do not. And in my experience it's still nearly impossible to get rid of SMS 2FA.
TOTP is almost always strictly better than SMS 2FA, and storing your TOTP keys alongside your passwords doesn't really diminish the effectiveness of TOTP very much at all. Unless you have the keys themselves exposed, they're still closer to "something you have" than "something you know", at least from where I'm sitting.
Their main weakness is that they can be backed up or copied at all, as well as MITM'd. How I securely store them doesn't have much impact.
> Their main weakness is that they can be backed up or copied at all
Which is also a major strength. I've had the experience of a phone app losing all of my TOTP information, and spending a long while having to use the recovery paths of various websites. After that experience, I want my second factor to be something I can back up and restore.
That'll continue to be true until either all websites reliably accept multiple 2FA devices (e.g. register multiple hardware keys) or I can buy multiple redundant hardware devices that produce the same TOTP codes so I can register "one" device with a site and still have a backup.
I wish the Firefox password manager had builtin TOTP support.
Most of the security benefits of TOTP is really for the service providers. Service providers get blamed when users are hacked because they used the same weak password across multiple websites. With TOTP service provider chooses the key the codes are derrived from, so user cannot choose a stupid one.
Most of the other threats that people talk about TOTP fixing are movie plot threats and not ones that happen in the real world to ordinary people. The only major exception is that webauthn prevents phishing, but TOTP cannot help with that.
Arguably storing TOTP tokens in your password manager does provide a level of protection against phishing.
You might fool me with that phishing page, but you won't fool my password manager's autofill. It would have to be full on MITM or DNS poisoning for that to work, which is already more of a movie plot.
1. using password managers for TOTP defeats the purpose of TOTP as a second factor
2. using password managers for TOTP is useful
Both can be true simultaneously.
The point of "something you have" is that it is "literally infeasible" to compromise your account without physically robbing you of your yubikey-equivalent. That automatically excludes >99% of the population that aren't within X miles of you from being able to potentially attack you.
Using this definition, both SMS and TOTP already fail, but at least one can approximate it by storing the TOTP on a physical device in a way that blocks casual export.
If you store it in a (non-local/backed up) password manager, you completely give up the pretense that "it is impossible to compromise your account without physically robbing you of your yubikey-equivalent". Someone from across the world can now compromise you without leaving their room.
Now again, just because it doesn't meet the "2FA threshold", doesn't make it useless. But it is also true that it doesn't provide the level of security that 2FA is supposed to provide.
Unless you were using LastPass and their Authenticator app. When they admitted that there had been unauthorized access to their storage and databases that had users vaults, what they failed to mention publicly (but which they finally told me after persistent questioning) was that the TOTP seeds were also part of the breach.
TOTP codes acceptable to Github etc. can be generated via
oathtool - Open AuTHentication (OATH) one-time password tool
OATH Toolkit provide components to build one-time password
authentication systems. It contains shared C libraries, command line
tools and a PAM module. Supported technologies include the
event-based HOTP algorithm (RFC 4226), the time-based TOTP algorithm
(RFC 6238), and Portable Symmetric Key Container (PSKC, RFC 6030) to
manage secret key data. OATH stands for Open AuTHentication, which is
the organization that specify the algorithms.
PSA: Authy Desktop is being killed off this year, which could mean the last opportunity to export your tokens out of Authy (for migration, or for external backup)
There are a few gists floating around regarding how to export by remote chrome debugging an older version of Authy desktop app, which still worked for me recently. This page explains too:
I wrote once many years ago, showing me all my TOTP codes in a terminal. I'd run it on a text-only offline/airgapped Raspberry Pi (an old one, with not even WiFi capabilities).
I was also pissed off by the clock issue, so I'd show both the previous, present and next code to come: because it's really a PITA when you see 213987 but you've got only two seconds left before it rolls. So I may as well start entering the next code (what the server accept is something not in my control).
And I always, always, always have a known, public, 2FA which I can use to double-check that everything is smooth (for example by entering it on some online computer and verifying that I get the same tokens generated).
I just reused whatever 2FA/TOTP Java library I found and wrapped that in a little CLI utility.
My secrets were unlocked by entering a password when I'd start the app.
You don't need to use the previous, present, and next code. Most decently implemented TOTP servers take time-sync-issues into account and accept codes a few seconds here and there. They do this also bec the time for a packet to move around the earth can also sometimes take a couple seconds.
Your setup on raspberry Pi sounds complicated. Mine was simpler. Just a CLI showing totp. Less secure but more convenient.
I like 1Password `op run` which works without copying. You put environment variables in your code, and when run with `op run` these variables are replaced on runtime with the actual credentials:
I use aegis (previously i used andotp) and backup to a folder shared via syncthing.
This allows me to usw OT via andotp -cli in emergency vor to use it in a new phone. For some i also use keepassxc (my credential/information store.) but the important ones.
I prefer yubikeys, but keep totp AS a backup mechanism when i can add two methods.
For me it comes down to trust. I'm already trusting Bitwarden with the desktop/mobile apps and the browser extension. Using rbw would require me to trust someone else with arguably my most important digital data.
As for the cost, it's both reasonable at the yearly rate and I want to support them so they can continue improving the software (still waiting for Passkeys on mobile for example).
I can't really speak to the node part, but it seems to perform well enough in my experience.
Just be careful not to use the same account/database/vault for OTPs and passwords, when using a manager like Bitwarden or KeePass, otherwise they no longer contribute a second factor to your authentication.
To be honest, password managers that support TOTPs should always come with a very clear disclaimier that keeping all your eggs in the same basket is a detriment to your safety, and that you should either use a different software for these codes or a separate account.
I don't believe they do, but correct me if I'm wrong.
I've thought about this a lot, and I feel that it's not really as big a detriment to safety as you might expect. It's not exactly the same as an air gapped token generator, obviously, but:
- It's still something you have, and don't know: the TOTP secret. What you transmit is a short term generated code, but unlike your password, you don't send the secret key at any point.
- The downside of air gapped tokens is that when they break or are lost or stolen, you have to somehow re-enroll with a new device. The security properties of this process are deeply variable between authorities, and there's always the risk of just total loss of access. If you have the TOTP secrets backed up in Bitwarden, you can avoid this.
- Vault software can keep all of these secrets encrypted using keys protected by biometrics on a phone, or an external device like a Yubikey, that are only unwrapped by a particular physical interaction. Usually the vault software does a better job than the average person of determining whether you're looking at a legitimate authentication prompt or a phishing site, and I suspect it's less likely to automatically enter your TOTP code into the wrong than a person is when transcribing it by hand or copy pasting.
Beware: That shell function will use the secret on a command line, leaking the secret to the process list, available to every user on the system. The oathtool manual page even warns about this.
Python includes libraries that match up with the needs well, so a python TOTP generator can be pretty small, 30 lines in this case...and not too golfed:
Frankly, I'm glad Authy Desktop is dead. It didn't allow exporting of TOTP secrets, so migrating off of it was a pain. I've been much, much happier with a tiny shell alias to oathtool and gpg.
For extra benefit, bind a keyboard shortcut and use xsel (Linux) or pbcopy (Mac) to drop the TOTP code into the clipboard. Now entering a frequent TOTP code is as simple as two keyboard chords.
(I only do this because my employer offers very limited options for MFA and I don't have a smartphone. I'd much rather use the Yubikeys I already have...)
It is actually doable to export secrets from authy desktop, but it involves starting it in debug mode and connecting chrome to it (it's an electron app). It was the solution I found to extract the secrets back when I set up https://pypi.org/project/totp/
[0]: https://www.passwordstore.org/
[1]: https://github.com/tadfisher/pass-otp