Gnome Authenticator is still a little early and buggy (mainly performance issues when you have lots of tokens), but it can import and export Aegis format (and a few others). It's been downright luxurious having my seeds on my phone and my laptop and desktop.
[3] I think (I hope) that Gnome Authenticator will be distributed as part of Gnome at some point in the future, but it isn't yet
[4] It's also super easy to build and run from source using Gnome Builder[5]. Just open Builder and clone the source from gitlab, and click the "Build" button and it will do its thing
If I had to guess, which currently I do as GP has not provided an answer, I would guess it has to do with the the ease with which the flatpak can be updated maliciously compared to a traditional OS package that usually goes through a separate maintainer. Thus, if the project was hacked or the owner of the flatpak turned evil, they could reap a pretty major bounty with no blocks in the way.
If this were my concern, I would just build from source as it is quite easy to do with this project.
> It's been downright luxurious having my seeds on my phone and my laptop and desktop.
The same is possible for my iOS tool of choice (called "OTP auth"). It can also synchronize to iCloud (passphrase encrypted) and make use of that on macOS.
I've resisted the temptation of that comfort so far (and of just putting the TOTP seeds into Bitwarden or 1Password), because it does seem a lot like collapsing what's now definitely two or maybe three factors into two or sometimes only one.
Indeed, I went through a very similar philosophical dilemma as well. I eventually decided that the convenience outweighed the security reduction, in part because the security reduction feels fairly minimal as they still live only on local devices and not on a device accessible to anyone besides me.
I still can't bring myself to put them into bitwarden, though. I suspect that will be a line I refuse to cross for quite some time, even though the convenience and luxury of doing so is tempting. Having my seeds in the cloud to me definitely reduces a factor
Just thanking you for your tips. I was looking for something after Authy's decision to discontinue the desktop version. This sounds like a great option.
I'm going to probably gnome authenticator on top of WSL2, because I like monstrosities.
Yes, very much agree. I am uncomfortable with the idea of putting them into a cloud service such as bitwarden, not because of a distrust for bitwarden, but rather having them on the cloud and/or in the same place as the passwords feels like big reduction in security. Simply having them on an additional local device does not feel like much of a change to me.
To each their own though, and everyone has a different level of risk, and a different level of risk tolerance. With all security, it comes down to an evaluation of that. I know some people in a very safe area who don't even lock their car or their house. They have not had any issues, and it can be very convenient not to have locks. That security posture is not for me, but it works for them.
You do not have the same problem, though. Sandboxing on mobile OSes is much more severe. No app can just magically access the rendering context of other application without elaborative million dollar exploits.
Bitwarden and KeePassXC also provide free, secure, and open-source 2FA in addition to password management. I keep my TOTP secret keys separate from my passwords simply by storing them in separate vaults. I don't know why anyone would use anything else (although I'd love for someone to comment and tell me).
Yes, if your vault is hacked, your 2fa will become 1fa, but:
- 2fa is still good for stopping someone who steals your password but not your whole vault
- 2fa blocks people from guessing your password (through brute force etc)
The whole concept of yubikeys bothers me. If it is lost, broken, or stolen, access to everything it protected is effectively gone. Same for SMS if you have an eSIM and your phone is lost or destroyed (as happened to me recently, and was a nightmare). TOTP synchronized to multiple devices seems to be the only way to have MFA while protecting oneself from getting locked out. I'm open to being convinced otherwise.
... The posession factor is the encrypted file that stores your secrets. It is in fact the same factor that Aegis uses, because it also uses an encrypted file to store your secrets. I'm not sure what you're expecting Aegis to do that is different from storing TOTP secrets in an encrypted file.
You missed the bit where I mentioned keeping my TOTP secret keys separate from my passwords by storing them in separate vaults, each of which is separately encrypted on-device with a different password. Cloud synchronization is optional.
The goal is to protect your data from brute force not from yourself, it’s perfectly reasonable to have 2fa in your password manager, saying it’s 1fa is just fud
2FA traditionally means relying on one thing you know (i.e. a password) plus one thing you have, or one thing you are (biometrics).
Every single one of my passwords is unique and randomly generated and at least 32 characters, none of them are getting brute forced unless there is a sudden gigantic leap in quantum computing. And if that happens, the world has bigger problems than my passwords.
Having a separate identity factor, something that I own, is not to save me from myself. It's to save me if someone steals my phone or laptop and is able to get into it.
Now we all face different threat models and if your threat model doesn't call for having a totally separate identity factor, great! There's nothing wrong with that. But we don't all face your threat model, and some of us do indeed need a second identity factor that's not stored in the same place as the password.
> Having a separate identity factor, something that I own, is not to save me from myself. It's to save me if someone steals my phone or laptop and is able to get into it.
What if that second factor is physical and stolen along with the things it was supposed to protect? What if your biometrics are cloned in some way?
Having TOTP synchronized across devices, but protected by passwords mitigates those risks as well as the risk that you lock yourself out by loss of a physical token.
> Every single one of my passwords is unique and randomly generated and at least 32 characters, none of them are getting brute forced unless there is a sudden gigantic leap in quantum computing.
One of the threat models that I consider is there being a bug in the particular RNG/encryption algorithm implementation used to get that encrypted password. In that case, my password can possibly be brute forced much faster than purely random guessing.
The main downside for me with using Bitwarden for 2FA TOTP is that I can't add more than one TOTP to a password. At work we use Active Directory so I can access a lot of sites with the same account, but all those sites have a different TOTP. I can only store one in Bitwarden and I am forced to store the rest on my phone in a regular authenticator app. I don't want to create duplicate accounts in Bitwarden just for the TOTP.
I'm a veteran developer, but really more of a "normal" than the type of developer who is commenting on this story. I admit I find this stuff really, really, really confusing. I hate dealing with any of this stuff, I don't do it voluntarily for the same reasons I don't (for example) use pretty good privacy for email (I just use web gmail like a regular person).
Anyway, I do (involuntarily) use 2FA for two services, and managed to set myself up with Google Authenticator on my Android phone. Both services that onboarded me for this explained it really poorly, but at least got me hooked up and I now routinely (and reluctantly) login to those services this way. Reading this I suddenly realised, whoaaa, if I lose my phone do I lose access to those (important) services? Well no, I hope not at least, when I look at the Authenticator app it has the green "your codes are being saved to your google account" cloud icon. That's kind of reassuring. I suppose.
I'm not really sure what my point is, other than online security is an ever more important issue, it's a swamp and even many technical people who might know everything there is to know about some arcane corner of the technology universe don't necessarily properly understand it. Although I suspect most would not be prepared to admit it like I just did. Actual normal people (like my wife for example) have absolutely no chance of getting on top of the details and navigating their way to a best practice solution. I hope Google (or Apple) don't either give up on this or go full evil, that would be really bad.
I think I will check out whether my two services can give me recovery codes. I am confident I can manage vital username/password combinations and recovery codes, that's the level of sophistication (or not) I'm comfortable with in this space.
For my personal threat model, most 2FA flows decrease my security. Historically, the loss of my phone is a more likelier event than a compromise of my credentials and the damage to me and the businesses holding my accounts from loss of my credentials is much less than the denial of service from loss of access. This flips with some access from my employer and my bank, but I don't associate any of my personal devices with my employer's account in any way.
It is a shame how the industry seems to think that security is some single dimension along which things are more or less secure. Denial of service for personal accounts is often times more damning and common than account compromise. 2FA makes me less secure in some cases.
I absolutely get your point but I think at least some of that is on you, or on those services. There are supposed to be safeguards that remove (or at least mitigate) the risk of denial of service caused by loss of the secondary device. One-time-use codes or some other method for emergency access are common ones I can think of.
True, but you are missing the point. A system is secure that acts in its user's best interests. In the case above, 2FA is not in the user's best interest, as defined by the user.
The current state of technology seems frightening indeed. This 2FA is a miracle. It is free and independent of the big tech companies. I'd put it on the same level of importance as Mozilla products. In the future, we will see more proof-of-personality applications for security reasons. But recovery codes won't be going out of fashion any time soon. Unless, of course, AI-enabled developers are gifted with long-term memory in the next few years.
It makes me nervous for sure, not super happy about it. I think I'll be fine if I lose my phone. My last phone died so completely it may as well have been lost but I could still hook the new one up to my Google account. Actually maybe I was already using the Google Authenticator app then.
Well, that's exactly why I started using Aegis and swear by it, its backup capability. I keep it encrypted and backed up on two separate locations, so my phone can blow up safely and I'll still be able to 2FA under my own terms.
Since we're here: Anyone else dealing with the stupid thing where your organization won't let you have your generating token thing and instead force you into e.g. Duo?
I have only one, and its frustrating. I know it's probably breakable with rooted Android or something but haven't had much time to look into it (or fight it)
Duo lets you use a physical security key, I then use bitwarden to store that as a passkey. Not quite a full replacement but good enough for me (you can also self host bitwarden [0])
Some organizations disable totp entirely. Instead, everytime there's a login attempt a pop-up notification with "allow" & "deny" options is pushed to the registered device.
TOTPs are inherently less secure than many of these proprietary solutions (they don't offer control over where people store them and whether they create backups of them, for one thing), so I do somewhat understand companies preferring those.
I agree that "TOTP with user held keys offer relatively more control to the user than to the organization," but I would never call this "inherently less secure."
Aegis should really be more well-known IMO. I installed it on an old phone that didn't have enough storage for Google Authenticator and was really pleased with the app. The fact that it's a community project is also a nice bonus.
> The fact that it's a community project is also a nice bonus.
It is more than a bonus. This is the only kind of project you know that tomorrow, the day after or a year from now there wouldn't have profit incentives or a pending IPO to completely abuse your experience as a user and extract as much profit as possible.
I hope others don't follow Microsoft Authenticators footsteps in creating their own Authenticator, saying others are insecure, and not allowing Authenticators like Aegis.
Can you do an encrypted backup on demand (protected with a password you supply)? Is there any desktop app such backup can be opened/read with (or even eg. read with something like sqlite db browser)? Can the app be configured to save an encrypted copy to eg. Dropbox whenever changes are made?
Is it recommended to install from Play store, or the APK off GitHub?
I use Aegis as my main app for 2FA so I can answer these questions:
> Can you do an encrypted backup on demand (protected with a password you supply)?
Yes!
> Is there any desktop app such backup can be opened/read with (or even eg. read with something like sqlite db browser)?
It's just plain JSON once decrypted, so it's always readable; I do know the GNOME Circle app "Authenticator" can natively import Aegis backups as well, since it's what I use on my desktop machine, but I don't know what other apps exist.
> Can the app be configured to save an encrypted copy to eg. Dropbox whenever changes are made?
It does have some facilities for automatic and cloud backups judging from the settings page, but I've never tried them
> Is it recommended to install from Play store, or the APK off GitHub?
If you do the latter you'd lose automatic updates. I used F-Droid.
>If you do the latter you'd lose automatic updates.
Obtainium[1] will give you automatic updates from most sources, including Github/Gitlab/Codeberg and F-Droid repos. Especially relevant to this discussion, since Aegis 3.0 hasn't hit F-Droid yet, as at the writing of this comment.
I really like it that more and more apps start using Material 3/You.
Apples UI design was never my cup of tea, but I love the consistency of UI design in most iOS apps, compared to the wild UI inconsistencies on Android.
I'd take a more diverse UI experience on Android any day over a more polished yet heavily opinionated experience at iOS.
That being said, I feel like the main complaint about Android apps design is the fact that a lot of apps are just horrible half-assed implementations of old Material UI slapped together on a drag and drop editor like the Android Studio widget system. Offering an incentive for people to build anything and make money off data collection and ads without the corporate tyranny of Apple results in just that. So apps that are on FOSS repositories such as F-Droid are usually much cleaner to use, despite their UI/UX being just as diverse.
Agreed I've never owned an iPhone, so I'm kind of used to the android experience and don't mind that much, but I'm just happy that it gets more and more consistent, at least the apps I use.
Though I only use FOSS apps so I can't speak for the playstore apps.
I've been using Aegis for a number of years, and have found nothing I don't like about it. It's a perfectly functional app, and I'm looking forward to trying out the new update!
It’s why I was a bit scared when reading the title (though the screenshot makes it look like I’ll be fine), I’ve had two open source apps make their UI/UX vastly worse recently with major updates (granted, I’m assuming some people like the changes), one was Gajim (XMPP messenger) on Desktop, and another Breathly (guided breathing) on mobile.
I'm currently a happy user of 2FAS[1], any idea how Aegis compares to it? A quick search suggests that Aegis doesn't support multiple devices and is not available on desktop.
I have being using andOTP for years but the development seems to halt, also it's no longer available from f-droid. The feature that backup with gpg encryption is broken.
I hope it's possible to import my otps from andotp into aegis. Also the backup encryption with gpg (openkeychain) is welcomed.
I have been a happy long-time user of andOTP since migrating to it from FreeOTP (iirc) and was unaware that it was no longer maintained. Some quick digging shows that the Github repo links to this XDA post[0] where the author announced he was ceasing development. :(
The good news is that migrating to Aegis is quite simple. Export from andOTP, in Aegis go to Settings -> Import & Export -> Import from File, & choose andOTP. Pick your file and away you go.
It doesn't seem to have a database of icons like andOTP does though; none of my imported items show an icon though several did in andOTP. (Could this be because of the method they were added?)
Long ago, I used Google Authenticator to store 2FA tokens without giving it much thought.
When I lost the app data to a phone reset, I also lost my 2FA tokens. Got lucky I didn't have many tokens saved at the time and was able to restore all the important accounts despite losing the tokens. Even though it was my fault for not reading the T&C of the Google Authenticator app, I cursed Google for creating an inferior product on an OS they controlled. What was the use of requiring login with a Google account on the Android device if you are not going to persist this kind of data.
Then I moved to Authy which syncs and stores your tokens online to their cloud, allaying all the fears I had from previous experience. Incidentally another phone reset happened.
Now Authy allows you to access your tokens "locally" to any device that can install their app or browser extension. Using more than one "device" locally gives you data redundancy.
I cannot just trust a browser extension with my 2FA tokens (yikes), so at the time I only had my Android device with the tokens locally. When this "trusted device" (read app data) was lost I had to request support for a reset to gain back my data from Authy. That process takes 48 hours after initiating the reset.
(The app data counts as a device, not the other way around; this is the crux of my problem with 2FA application design.)
As soon as I got my tokens back I moved to Aegis and never looked back. I can export backups, save them encrypted on any location and import them anytime without fear of losing app data aka device.
Great app that does the job! The kind I don't mind installing on my phone.
I use it for nextcloud, github and my microsoft account (it was really buried in the settings but it is possible to avoid using MS auth something app).
Here's a utility to convert exported Aegis JSON to a Keepass 2 or KeepassXC database if anyone's interested
https://github.com/GeKorm/atk (binaries in the releases page)
I use Bitwarden for passwords and 2FA (browser plugin, Android app for mobile). Definitely not recommended by anyone security focused, but these 2fa are forced onto me by different platforms and not something I chose/care.
There should be desktop authenticator software. If I can have one on Linux I'm sure all the other desktop OSs have at least 1.
I would say that the "generic desktop app" approach is to be avoided. The reason is that there is a strictly better alternative that targets almost the same audience. By implementing a TOTP generator as a desktop browser extension instead, one gets visibility into which site the user visits, and can show only the relevant code, or, if there is none, a phishing warning.
The users that are left behind in the browser extension approach are those who need TOTP for non-web things like SSH.
I use KeePass. It's a little bit cryptic to set up the OTP - you have to create an advanced field called TimeOtp-Secret-Base32 with the seed in it - but after that you just Ctrl-T to get the latest code.
Aegis is really great. So nice not to use proprietary authenticators. And it can do import and export.
Does anyone know the history of this project? It seems legit but an authenticator is a pretty sensitive application so making sure this app is trustworthy is a little more important than for other apps.
I happened upon this app recently when I was frantically searching for a Google replacement. Couldn't believe something this polished was lurking. I used another open source app several years ago but it got discontinued (FreeTOTP or something).
Just use Bitwarden. The UI is clunkier, but the UX is better. After it fills in the username and password, it puts the OTP in the clipboard, so you can just paste and go without opening an app and manually copying it into the login form.
I'm hard opposed to storing my second factor codes alongside my first factors. Part of the reason why I use 2FA is because if my password store is compromised, the accounts in it that are compromised do not contain all of the credentials necessary to log into the accounts protected by 2FA. I also do not store my emergency removal codes in the same secret store as my passwords for this reason.
It is no different from Passkeys in that regard, yet we're fine with that. If you want extra security, you would have your password manager and your OTP generator on different devices, but only a small fraction of people do that. Storing your OTP generator secrets and your passwords in the same app provides a reasonable trade-off between security and convenience for most people.
Etrade (probably some other companies?) uses Symantec VIP, which is a proprietary TOTP client. I was really glad to have found a project that allows me top stop using it and instead utilize other standard TOTP clients.
I used it until I switched to KeePassXC for all of my secret management means, but it's still a great app to fall back to, and allows for simple information exchange when moving to another app.
On F-Droid there is still version 2.2.2 (last updated 6 month ago). If I try to install the app from Github releases I get a version conflict with my current version from F-Droid. Any tips?
Authy has no official backup-solution, it's vendor lockin. They discontinued their desktop-app last week, are owned by a company, and so you never know when they might charge money or discontinue the app as a whole.
There are unofficial solutions for backup, but who knows when those will stop working.
Truly open-source, available on f-droid, works on everything including low-end android hardware with everything except microsoft (because microsoft). What's not to like.
This looks very nice. Had I not just moved all my 2FA to keepass, I would give it a go. My setup: mac desktop, linux desktops, android with syncthing to tie it all together.
Can we just get a 2FA app that's cross-platform and synchronized? I understand the security implications of that but I don't care, I would rather have my social media hacked and have it convenient than just have to go grab my phone whenever I want to login into something.
Last year Google Authenticator started syncing secrets to the cloud[0] which means that those secrets can now be accessed in new ways outside of the user's control[1], which resulted in a huge breach at a startup called Retool[2].
From then on I started moving my company's team and contractors (as well as family and friends) off of Google Auth and onto Aegis.
The app is clean, easy to use, open source, has all the options we could dream off.
(and its privacy policy isn't tens-of-pages-long like some other apps, where privacy seemed to be part of the marketing strategy but not the product itself)
> I started moving my company's team and contractors (as well as family and friends) ... onto Aegis
An important question on this, if you don't mind:
If the phone, where Aegis was installed, is dead/lost/stolen, which options are available to make sure that access to the accounts linked to that phone wouldn't be lost either?
Every service I've used with TOTP codes (12 at current count) has given me some sort of randomised backup token at the same time to use if I lose my 2FA app. I store those somewhere separate. I'm not going to argue that this is user-friendly but AFAIK there's no reason you're obliged to use cloud backups today.
This is actually a pattern I really don't like: Why do I mostly get these thrown at me for TOTP, but not other 2FA methods? What am I supposed to do with these "backup codes"? Store them all in my password manager?
At that point, I might as well store the TOTP seed there and rely on its multifactor authentication – which is probably fair for many use cases, but suffers from the problem outlined by GP.
I think sites should treat TOTPs effectively equivalent to Passkeys, i.e. as maybe synced, maybe backed up, but maybe neither – and then the user needs an alternative login method, just like for all 2FA methods.
Personally, I use Bitwarden for passwords and store my 2FA seeds in a Keepass database on my PC and backed up to my cloud. It isn't perfect by any means but at least if my Bitwarden gets compromised, my 2FA tokens are safe and vice versa. If I lose control of both, welp, it's gonna be a bad time I guess.
Choosing 2FA segregates users into two buckets. Most people are satisfied with the risk of allowing password reset emails and social engineering attacks. They don't pick 2FA.
The rest are generally more sophisticated users, and are willing to risk loss of the entire account if they lose their credentials. That's the price for an overall increase in account security. From this perspective, it makes sense to provide backup codes as another tool in the DIY account-management toolbox.
These buckets oversimplify the situation, but they help explain why backup codes are offered as last-ditch authentication for 2FA.
I write the backup codes in a small paper notebook, kept in a drawer at home. I've had to use it maybe once in the past decade. It's very unlikely that I'll lose both my phone and the notebook at the same time. It's extremely unlikely that anyone who breaks into my house and finds this notebook, can do anything with it.
You can copy an encrypted backup file to a usb drive and then either copy that to a few other secure places or just put it in a safe depending on how much redundancy you need. I use Aegis these days as a backup MFA option for a yubikey. You can password protect access to open Aegis with its own unique password which I like (no cloud dependency or access), but it's kind of inconvenient if you have a decently sized password so I prefer it as the backup option if the yubikey goes missing.
You can optionally backup your encrypted data using Android's built-in backup utility tied to your Google account. It can, then, automatically restore codes when you sign in on a new device.
Does that back up TOTP seeds in Google Authenticator? I thought apps had to opt in to this type of backup and would assume that Authenticator doesn't, but Google has changed the Android backup mechanism so many times, I lost track.
It backs up TOTP seeds. You need to enable this manually. As a part of Android Device backup, Google does backup certain things automatically[1] but non-Google apps require explicit opt-in.
Interesting, thank you! I would have expected Google Authenticator to somehow tangle the encryption keys used to the device it’s running on, but apparently it doesn’t if this works.
Point of order: Retool got hit by an SMS phishing attack, and while they made a big deal out of Google syncing TOTP seeds, the real moral of their story is to stop using TOTP altogether; it's not phishing-resistant. Rather than cutting a whole team from one TOTP app to another, it would probably be a better idea to shift the whole team to an IdP that forces FIDO2. TOTP is obsolete.
It was not in my case. I found out about this feature when I saw the green cloud icon and pressed it to find out what it meant. At that time I was made aware the my data was saved in my Google account.
It's likely your company's administrator forced this default behavior. Cloud sync was an opt-in on my account too, fwiw. It would have been a huge story had it been opt-out.
TLDR: From what I can tell, the "consent" to cloud backup from Google Authenticator was misleading at best and blocked access to the tool until it was given. IMHO this is another example of Google forcing decisions on customers in order to extract even more data. Thumbs down!
It looks like Google didn't make clear what was happening... There are almost no settings in Authenticator and there is no place to turn "cloud backup" on or off. I found this article that described the feature when it rolled out.
If the screenshot is accurate, they blocked access to the tool until "consent" was given to backup codes to Google. The text itself is clear in retrospect but, in my opinion, implies that there will be a choice to backup to Google and that choice was never presented.
"Google Authenticator is Upgrading... You can now sign into your Google Account and backup your Google Authenticator codes to the cloud."
A button is presented labeled "Get Started" and, if you click it, Authenticator will backup all of your codes to the cloud.
I don't remember being presented with this screen but I don't remember a lot of things. I suspect I needed to get a code and simply clicked the button to get to the list of codes. If I read it, I likely thought there was a new setting and I could manage this "backing up" from there. Clearly this was not the case and I "consented" to let Google have all of by 2FA codes.
It's opt-in, yes, but via a dark pattern of "hey, cool new thing, say yes quickly?" as far as I remember it.
I remember getting tripped up by this, because I also have work credentials in there that by policy I'm not supposed to store in a synchronizing TOTP client, and Google Authenticator didn't even allow reviewing the TOTP seeds for the longest time, so this seemed like quite the departure from their previous security stance.
That sounded scary, but after reading into the Retool breach (thanks for pointing it out), it doesn't sound like Google Authenticator is completely to blame.
Retool points out the "attacker was able to navigate through multiple layers of security" [0], i.e.:
1. "through a SMS-based phishing attack" on "Several employees"
2. "one employee logged into the [SMS phishing] link", "logging into the fake portal"
3. "attacker called the [phished] employee" "and deepfaked our [IT team] employee’s actual voice"
4. "the [phished] employee grew more and more suspicious, but unfortunately did provide the attacker one ... (MFA) code" (over the call)
5. "The additional OTP token shared over the call was critical, because it allowed the attacker to add their own personal device to the employee’s Okta account, which allowed them to produce their own Okta MFA from that point forward."
6. "This enabled them to have an active GSuite session on that device." With "Google Authenticator synchronization feature that syncs MFA codes to the cloud", "if your Google account is compromised, so now are your MFA codes".
By #5, I'm thinking GA sync is about as blameworthy as Okta for allowing a device to be added with just a single additional OTP token shared over a phone call?
Here's a different perspective (tptacek) [1]:
>> We use OTPs extensively at Retool: it’s how we authenticate into [Google, Okta, internal VPN and Retool]
> They should stop using OTPs. OTPs are obsolete. For the past decade, the industry has been migrating from OTPs to phishing-proof authenticators: U2F, then WebAuthn, and now Passkeys†. The entire motivation for these new 2FA schemes is that OTPs are susceptible to phishing, and it is practically impossible to prevent phishing attacks with real user populations
> TOTP is dead. SMS is whatever "past dead" is. Whatever your system of record is for authentication (Okta, Google, what have you), it needs to require phishing-resistant authentication.
> My only concern is the present tense in this post about OTPs, and the diagnosis of the problem this post reached. The problem here isn't software custody of secrets. It's authenticators that only authenticate one way, from the user to the service.
I only started reading into the Retool case because there was the claim above that sounded serious and scary:
> Google Authenticator started syncing secrets to the cloud[0] which means that those secrets can now be accessed in new ways outside of the user's control[1], which resulted in a huge breach at a startup called Retool[2].
This is the fear I went back to Authy from Raivo (iirc they didn’t sync back then; besides I have never trusted iCloud sync) and Tofu. I lost access to two accounts that I would have wanted to avoid.
By the way, a few days back Twitter simply decided to stop accepting my 2FA keys. Luckily I was logged-in in another browser as well where I could disable 2FA. And no it didn’t accept backup code either.
So that’s another risk with 2FAs. What I am trying to say is — 2FA synced or not synced are problematic either way.
I am also wary of passkeys! What happens if my Apple (for example) account is disabled or I am locked out of it?
I love Aegis but I can't help but think that it's sad we ended up in this place with regards to 2FA. When all these temporary codes started they were sent over SMS, which was insecure but at least all I needed to do was to pick up my phone. Nowadays I open Aegis and I have > 20 services there, and trying to look for my code between all the running numbers is a pain.
It would have been so much more comfortable if we flipped this around a little - the website would present a QR code, you would open the phone and scan the code, the phone would make a request signed with your key to a URL, and the website would authenticate you because by making this signed request you proved that "something you have" part is done.
It feels like when the 2FA thing started no one considered that sooner or later all services will require it, and the UX will be terrible.
I almost^ missed a train recently because I tried to book my ticket and for the first time ever (and actually not since either) Amex wanted to send me a verification code. They support only SMS & email, but you can't change it for the current one and it was set to SMS, and I don't have email on my phone anyway & was at the station. Anyway - SMS didn't arrive. Had the same thing recently with them from a bank, it's the network blocking them, suspected spam or whatever.
There's plenty of other reasons not to use SMS 2FA, but it might suddenly not work one day right when you need it, and totally out of your control, is perhaps the most universally compelling?
I'm totally not advocating for 2FA over SMS. It's also just not secure enough.
What if the website presented a QR you can scan with Aegis and then Aegis would make a request with your one time code? You could still type it manually - there would be an input and a QR code next to it.
Fortunately, SMS-OTP isn't considered SCA/PSD2 compliant anymore (by itself, since it's only a single factor – and the card number doesn't count) by the regulator in the EU (not sure about the UK), so hopefully we'll be seeing less of that going forward.
Had this crap happen to me the other day with a banking app. Luckily I eventually managed to find a way to get them to call my phone with the code instead.
I used to quite like the hack that LastPass authenticator had to make it easier.
If you ever encountered a TOTP form in your browser that the LastPass browser extension recognised it would send a push notification to the aunthenticator app on your phone which if approved would send the TOTP code to your browser and submit the form on your behalf.
Unfortunately it only ever worked on the handful of websites Lastpass had implemented bespoke support for, but it was magic when it worked. It would be nice to have a universal standard for push notification 2FA.
> the website would present a QR code, you would open the phone and scan the code, the phone would make a request signed with your key to a URL, and the website would authenticate you because by making this signed request you proved that "something you have" part is done.
WebAuthN essentially gives you that behavior, with the addition of making it MITM-resistant (which TOTP isn't). It even works cross-platform these days (I think both devices need Bluetooth as a proof-of-proximity, to make sure an adversary isn't relaying you a QR code).
Unfortunately both iOS and Android absolutely insist on syncing these credentials to the cloud, but both now have APIs that would allow a third party to provide a local-only backend.
I agree this kind of sucks (I have about 40 tokens on there), but it's relatively well mitigated with the search functionality and typing the first few characters of the service. This works for all that I've tried except the root MFA token from AWS, and I could easily fix that by exporting and changing the name and re-importing if I wanted to.
This has two things about it that make me actively not want it:
1. Does not work offline (requires an internet connection to work). The current design for TOTP is super flexible as they only require time syncronization, which doesn't require an internet connection.
2. It means I have to install an app for each service, which I absoulutely do not want to do. I would prefer to only use native apps for things that actually need to be native. PWAs and web UIs are strongly preferred for me. A comprehensive and robust way to manage permissions would mitigate my dislike for native apps somewhat, but this is getting harder and harder (though praise be unto GrapheneOS for their efforts!)
From an engineering perspective, it also feels like unnecesary bloat/complexity and coupling.
I agree regarding the offline ability, though literally all the things I'm using 2FA for are online, as they are about logging-in to services.
As for the 2nd point - I definitely don't think it has to be a separate app for each service. Why would it? Imagine an app that holds a private key, the website showing a QR code, you scan it with the app, the app sends the public key to the service using a URL provided in the QR code, and the service stores your public key. From now on, every time you want to login you're asked to scan a QR code, which makes the app send a signed request to the a URL encoded in it. The service gets the request and proceeds with the login. One app, all services.
> Nowadays I open Aegis and I have > 20 services there, and trying to look for my code between all the running numbers is a pain.
exactly :(
I wish passkeys get rolled out quickly across all sites, most people use just 2 or 3 trusted devices 99% of the time.
for those edge cases where you are working on an untrusted device, the passkey on your trusted mobile can help with authentication via Bluetooth or some QR code etc,...
If you do that in your own app, you might as well just show a QR code which the user scans and opens up the app for approval. Code as backup. Having to type in an alphanumeric code (talking about Steam Guard, not standard TOTP) when the app is already involved is quite outdated.
I believe Steam Guard already added the scan QR code flow a while ago?
You raise a good point: It seems like this should be possible to integrate into WebAuthN somehow, but currently it isn't.
Passkeys could be coupled with Web Push somehow, for a "confirm action x" type of experience pushed to your (networked) authenticator even when you're not at the website of the relying party that owns it.
Steam uses "standard" TOTP but displays the code in a non-standard format. You used to be able to extract the secret and use e.g. KeePass to provide the code in the Steam Guard format.
Couple things no one's mentioned yet. In Aegis you can add icons to token slots, and manually sort them (alphabetically). This, plus searching, helps a lot in finding tokens quickly. They have pre-existing icons for most of the common sites.
I use Aegis only as backup because the workflow is cumbersome as you say (the app itself is flawless in my book), my primary TOTP authenticator is KeePass. I use the exact same KeePass setup on Linux, Windows and MacOS and copying a TOTP token is only a hotkey away. My KeePass also acts as SSH agent which also works with Cygwin, MSYS and WSL. On Android I use KeePassDX which also supports TOTP. I almost never ever open Aegis and when I do it's mostly to check that I can remember the password. I sync my KeePass databases across all devices and OSes with Syncthing.
At least with aegis I can create groups. So I can separate email, work stuff, etc and only see a few tokens in each group.
Sure the ui isn't great. And it takes a couple extra clicks to the groups. But given the stupid shit that sites do like disabling paste for two factor codes or passwords, i just would never trust them to not fuck up a more streamlined solution. I like a bit more manual control sometimes, at the expense of convenience.
And it also runs and is backed up completely offline, which is nice.
> Nowadays I open Aegis and I have > 20 services there, and trying to look for my code between all the running numbers is a pain.
I just click search and type 2-3 characters and most of the time I can see what I need right away. I'm using way over 20 services with 2FA and that's really the least of my concern.
And I actually don't use search that much since Aegis also has a feature of sorting by the usage so whatever I'm using regularly are already at the top for me.
if you run safari and store all your passwords using icloud “passwords”, safari will automatically prefill the 2fa code. i assume this is the case for other browsers as well?
I'm using Bitwarden, for passwords, but I always felt uncomfortable with the idea of having my 2FA on my laptop too. It feels a little silly - if Bitwarden has both my password and my 2FA code, it's enough to hack my Bitwarden and all this "multi-factor authentication" isn't very "multi" anymore...
But then it's barely better than 2FA vault & 1FA app. ('Barely' because it's like a bit of depth, and breadth into a few specific attacks revolving around the app's poor handling of your password.)
Theoretically that's true, but practically, Bitwarden (and any other browser-based extension capable of autofill) runs in a much less secure environment than e.g. Aegis or Google Authenticator on a smartphone, and people often keep it unlocked (or at least not requiring 2FA for every password access).
If you use Aegis on Android and use a Gnome-based Linux distro, I highly recommend complementing with Gnome Authenticator[1][2][3][4].
Gnome Authenticator is still a little early and buggy (mainly performance issues when you have lots of tokens), but it can import and export Aegis format (and a few others). It's been downright luxurious having my seeds on my phone and my laptop and desktop.[1] https://gitlab.gnome.org/World/Authenticator
[2] https://flathub.org/apps/com.belmoussaoui.Authenticator
[3] I think (I hope) that Gnome Authenticator will be distributed as part of Gnome at some point in the future, but it isn't yet
[4] It's also super easy to build and run from source using Gnome Builder[5]. Just open Builder and clone the source from gitlab, and click the "Build" button and it will do its thing
[5] https://wiki.gnome.org/Newcomers/BuildProject