I Hate MFA | Hacker News Reader

I Hate MFA

alexmolas.com

47 pointsalexmolas97 comments

Open articleView on HN

> it distracts me

It would be faster if a password manager is used with browser plug-in.

> It forces me to have a smart phone

Not if we're talking about TOTP. The information for that can be stored in a password manager.

> Or couples online with offline

Not if you use a password manager.

> it can be replaced with other solutions

TOTP + password manager is more convenient (and more online) than yubikey, in my opinion. Especially convenient with a browser plugin.

My chosen pm is KeePassXC, would highly recommend.

One caveat: I hate non-TOTP MFA. It's either proprietary lock-in or less secure.

> One caveat: I hate non-TOTP MFA. It's either proprietary lock-in or less secure.

Agreed. A particular pain point for me is Apple's proprietary (or SMS-based, even worse) iCloud 2FA, it's just awful. I would use TOTP/HOTP for it in a heartbeat if given the option.

They support standard hardware keys now, which have worked pretty well for me. Just can’t use them if you have devices which aren’t on one of the later OS updates since the OS won’t support signing in with a yubikey.

without a browser plugin or something better than human eyes to verify domain matches, password + totp are phishable / mitm-able in an online attack

A fact that becomes important in some contexts. Nevertheless I still feel it is the best compromise between convenience and security available to us.

IMO you don't have MFA if your codes are generated by your password manager.

Does someone who has phone-based MFA and a phone-based password manager lack MFA?

Does it matter if they're in the same app?

Yes, very much, you can have different passwords on the two separate applications.

This is also reductive because it doesn't take into account password managers used on a non-mobile device, where the benefits become obvious in that if one of your devices is comprised it's unlikely that the other is too.

> Does someone who has phone-based MFA and a phone-based password manager lack MFA?

Yes. Call that say 1.25 factors. It is of greater than zero value.

1Password covered this very well:

https://blog.1password.com/1password-2fa-passwords-codes-tog...

They tackled the subject for sure, but my takeaway from that blog posting is not that storing your TOTP tokens in 1Password is “as good as” having separate hardware devices for password storage management and TOTP management, but rather that storing your TOTP tokens in 1Password (or any password manager) is better than not using OTP at all. This of course is definitely true, and a definite improvement in security. I think a sibling referred to it as “1,25x” as secure, which feels about right (on some non-linear scale where 2.0 represents two unique factors).

I don’t use a KeePass or similar device, and I do have my TOTP tokens on my phone (using the great OTP Auth app, no affiliation), but I do most of my work on a computer so I toyed with completely removing password management from my phone and just having the OTP app there. I haven’t committed to that that yet though. Another option is to use a cheap device such as an iPod Touch for OTP, though those are probably more expensive than a dedicated OTP device (I just happen to have one lying around unused).

Agree, non-TOPT MFA is a scourge.

It's criminal that Google requires you to set up a phone-based or proprietary MFA before you can switch to TOPT.

Your phone number isn't something you "have" - it's something you're renting from another big company, and their security has obvious reset holes made to cope with unsophisticated users, therefore is worse than a password managers.

The only workaround I've found that is non-distracting is to have a dedicated phone-to-web/email system... Google Voice works for this if you're US based.

I greatly prefer SMS auth(At least for personal stuff, I see the value of TOTP for work) because of exactly those reset holes. For low value targets it's not really much of an issue, and makes it much harder to get locked out of your account, which would be almost as much of a problem as getting hacked.

Unfortunately, in my experience, there is lots of MFA out there that doesn't support TOTP (many providers probably don't even know it exists).

> TOTP + password manager is more convenient (and more online) than yubikey, in my opinion. Especially convenient with a browser plugin.

More convenient than yubikey webauthn, or just yubikey TOTP? Personally I find tapping my yubikey much easier than any 'enter the code' 2FA.

Also it should be noted that storing your TOTP secret in the same place as your password means you're one malware attack away from losing access to that account. While this risk may be acceptable for many accounts, it should at least be considered.

The security implications are indeed a debate, but really any attack on the password manager is a huge security problem anyway so you might as well store the TOTP information there. One way to mitigate this is to use offline password managers such as keepassXC (which I use) and non-proprietary sync stuff such as syncthing (but I just use a cloud drive provider).

Entering a code is easy because of the password manager plug in. I don't have to find the Key with my finger, I just have to click with the mouse. Much easier.

If your password manager is hacked, but your TOTP info is offline, how is this not better that having TOTP info in your password manager? Also not sure how syncing through a cloud drive is any better than a cloud password manager.

> Also not sure how syncing through a cloud drive is any better than a cloud password manager.

The private keys stay on your machine

Not if you're using a commercial cloud drive

Your point about separating TOTP being more secure is a good one and I acknowledge it. I simply find storing the TOTP together with the password manager to be a reasonable compromise between security and convenience.

Sinking through a cloud drive is better because it diffuses the value proposition of hacking the cloud drive. If someone hacks The cloud provider they are likely to find a bunch of ripped videos and pictures of children and cats, with the occasional sensitive file here and there. Thus it makes less sense as a hacking target while still having lots of the same protections and professional oversight as any other cloud provider.

The value proposition of hacking a password manager SaaS is much higher so it becomes much more worth someone's time to hit.

It's like the difference between storing gold in a lock box in a bank and storing gold in a lockbox in a storage rental facility. Storage rental still has guards and locks and cameras, but will not attract the attention of dedicated, organize efforts to extract value like the bank will.

Good points. I keep Auth backups in my pw manager for convenience also, just because I don't know of a better way other than printing the qr code and stuffing in my desk.

I'm not worried about a general cloud beach as much as I am a personal attack if someone gets hold of my phone and manages to unlock it. Then they have 2 of the 3 keys: the cloud drive, and the Auth app. All they need to do is hack the pw manager, which if they have the vault file from the cloud drive, they can brute force until the cows come home.

WebAuthn is more secure, easier to use, and is not proprietary.

Did the one you hate include Duo? That’s the only one I’m using that is not TOTP based. But eventually I find a way to get the secret and generate the 2-factor myself.

I agree with you about using a password manager to solve these kind of problems. One thing people don’t understand is we have collaborators that need to deploy to a Chile desert where the environment is so bad that your mobile phone would likely die there. (It’s not recommended to bring one anyway.) So all these solutions requiring a 2nd device, usually a mobile phone, is very annoying. The most annoying part is that these security policy is enforced by central university who don’t care about the requirements of a research project.

But frankly, even if there’s a way to do it with a password manager (using site computing for example so no mobile is necessary), this is not presented as the way to use MFA, and some would consider it a breach of security.

SMS MFA is ridiculous and should not be a thing. Phones are very unreliable (between trying to daily drive a PinePhone in the past for a while, and AT&T's device whitelist after the 3G shutdown, I've been through a lot of crap).

TOTP seems fine to me. Can run it on various devices without a SIM, including just using a password manager like keepassxc on your computer that lets you copy paste the code. Sadly this all gets dumbed down and obscured so most people don't realize what TOTP is or that standard things are being used. We get told to download Google Authenticator or Microsoft Authenticator and keep it on our personal phone against our wishes forever. Hating MFA is quite understandable when it takes this form. Plus some of these TOTP apps make it hard to back up the data for use on another device, making a lost or broken phone rather catastrophic.

Tip, when presented with the setup QR code on a site, decode it and just put the secret into your password manager instead of a phone app (in keepassxc right click an entry and it has a TOTP submenu). Can also be handy to save an image of the QR for later (do at your own risk of course, this is sensitive data) in case you need to set up TOTP again.

People will probably argue this is less secure than letting it all live on your phone, but it still saves you from the most likely threat: websites being hacked and leaking your password. Also it's still protected by your password manager password, which should be unique and only accessible locally.

It's even worse than that: if you're using a local password manager like KeepassXC (I do), you already have some form of MFA: something you know to unlock your password database, and something you have (in the form of the password database itself).

GitHub recently forced me to use TOTP (not quite the only choice I hear, but bear with me). Well, so I've added my TOTP secret into KeepassXC, and now instead of copying my password from it, I copy the TOTP time code.

I believe the increase in security, if any, is negligible.

Using a local password manager isn’t MFA. How is that verifiable to the authentication service?

And storing my TOTP code in the same password manager I use to store my GitHub password is not more of an MFA than using the password alone. They may hope I'm using my phone, but they can't know. And they shouldn't. My security, my business.

Overall there are 2 cases to consider: one where a compromised users screws the user, and one where a compromised user screws the service.

In the first case, which is most online services, the only reason the service cares about the security of an account is to protect the user. They have no business policing how said user handles their own security. Propose and nudge, sure, but verify? That goes one step too far.

In the second case, which would be most enterprise networks, I would recommend that the company issues a security key to each employee, and ensures (with some form of remote attestation if need be) that employees log in with that key.

In scenario 1, I can see the reasoning if we’re talking a low value account e.g. pseudo-anonymous account that holds no personal/financial info. In this case the service isn’t worried about you but the platform as a whole where a person or group can control many accounts

Scenario 1.5 is non enterprise but with a financial or something of value aspect e.g. rewards/loyalty programs. The service has to protect against fraud

Scenario 2: if we’re having this discussion about the need for MFA, how it ties us to devices and all the other reasons mentioned already, then using a security key with remote attestation is even more difficult for the end user. I don’t see how this is an improvement. It is in fact MFA itself, just with a different, more cumbersome, type of factor

How exactly in scenario 1 would the service protect itself against sock-puppets? How can they make sure that two different accounts are tied to two different users? How do they prune "false" accounts? We see that kind of stuff being done by Facebook for instance (real name policy), and it has basically nothing to do with MFA.

In scenario 1.5 the service has to make sure users are protected. I believe it is counter productive there to force users beyond some reasonable step. For instance, it would be unacceptably discriminatory for a bank to require users to have an Android or iOS phone application to be able to make payments online. (Flip phone users should not be second class citizens.)

Scenario 2 is almost exclusively about employees. Issuing hardware to employees is not difficult. I have 2 company-issued laptops, one from my company, one from my client. If my client wanted to increase security, it would be trivial for them to just give me a USB security key, and it would be trivial for me to just plug that key and touch it whenever there's a pop-up saying I should touch it. I don't see the difficulty here.

In fact, given the choice of installing Okta on my personal phone, or using a security dongle, I would take the security dongle every time. Not only does it better separate work stuff from personal stuff, it's actually more convenient.

> And storing my TOTP code in the same password manager I use to store my GitHub password is not more of an MFA than using the password alone.

Of course it is. Unlocking your passwords in KeepassXC isn't MFA in this context because it's completely orthogonal to phishing, brute force attacks, and data breaches. OTPs are far from great but help with all three, no matter where you store them.

Oh yeah? How does that help exactly?

If the password database leaks, the TOTP shared secret can be used by attackers (one can't hash the TOTP shared secret like we do passwords). Phishing? They can just take my TOTP code and redirect it to the legitimate service. I may be able to stop them by asking the service to end the session (if I even find how to do that), but as long as the session is up they can do pretty much whatever they want. At best they'll be barred from doing important operations like changing the password, if the service asks for the TOTP code for such things.

The only thing TOTP really mitigates is brute force attacks, and they do so only for people who use weak passwords. Since I'm using randomly generated passwords with over 120 bits of entropy, I'm basically immune to brute force to begin with.

We have much better than TOTP to stop those attacks.

> If the password database leaks, the TOTP shared secret can be used by attackers (one can't hash the TOTP shared secret like we do passwords)

OTP secrets are stored encrypted, not in plaintext.

> they'll be barred from doing important operations like changing the password, if the service asks for the TOTP code for such things.

Yes, that's what "help" means here. OTPs limit the access lifetime and rights of the session. They help. They're strictly better than a password alone, whereas you claimed they're "not more of an MFA than using the password alone".

To reiterate:

1. The password to unlock a password manager isn't MFA for the services the password manager protects because it's part of the authentication flow of your local system, not of those services. This is also why it does nothing to combat phishing, brute force attacks, or data breaches.

2. Where OTP secrets are stored, on the other hand, is irrelevant for those same threat models. Their value, limited as it is, is the same either way. In fact, if you use a password manager with OTP autofill and never type codes in by hand, you're basically doing as well against phishing as people using FIDO. But again, U2F and FIDO2 are strictly better.

> OTP secrets are stored encrypted, not in plaintext.

Then so are password hashes. I mean, it would be pretty stupid to make the effort to encrypt part of the login information, and then fail to encrypt the other part.

> Yes, that's what "help" means here. OTPs limit the access lifetime and rights of the session. They help.

Yeah, yeah, they do. How much? "Hardly" In my opinion.

Here’s the thing with TOTP: it’s time based, and therefore remains valid for a couple dozen seconds. Unless the service took special steps to make sure TOTP codes aren’t reused, the MitM can reuse your first TOTP code to change your email & password behind your back, close the session, and lock you out forever. They’d have to be fast, but machines are pretty fast these days. And even if the service does take such precautions, nothing prevents the MitM to ask you for a second TOTP once you make a less than important operation, and if you’re tired enough you’ll just grumble and give it to them.

Point being, there are ways to do long term damage even in the face of TOTP, which are only barely harder than password-only attack.

So sure, TOTP does help. They even help me, by a negligible little bit. But honestly it’s zero vs epsilon as far as I am concerned.

> 1. The password to unlock a password manager isn't MFA for the services—

Irrelevant.

MFA means multiple factors are required to log in. If I’m putting a password in my password manager, I need something I know (master password), and something I have (my password database). That’s 2 factors no matter how you cut it. Whether the service I’m using knows about those 2 factors is immaterial.

> 2. Where OTP secrets are stored, on the other hand, is irrelevant for those same threat models. Their value, limited as it is, is the same either way.

Agreed.

> In fact, if you use a password manager with OTP autofill and never type codes in by hand, you're basically doing as well against phishing as people using FIDO.

Indeed.

> But again, U2F and FIDO2 are strictly better.

They are, if only because the service can be more confident this translate to decent security practices from the user (or at least the user’s machine). And they can be quite non-intrusive, which I like.

I’m wary however of the temptation to use those new credential mechanisms to lock users in. Require FIDO2 if you want, but do not require me to buy a security key from a specific brand (even if it’s the TPM), or store my credential database in some Apple Cloud Shit.

Google’s Titan security key supports Passkeys if you don’t want a smartphone. Very reasonably priced. I have a handful for users who need secure auth but don’t have a smartphone.

I do not permit anything but passkeys or secure hardware tokens to be issued in our org’s identity providers (no sms, email, totp otps).

https://store.google.com/us/product/titan_security_key?hl=en...

Is that Google's Yubico?

they are fido2 keys like yubikeys, though the added feature set is a bit different: titan does more resident keys / passkeys, but no extra features like the yubikey 5 series

good: they support 250! passkeys (vs 25 for yubikeys)

bad: most sites still don't support passkeys so you can't use it yet

Agree lots of sites still don’t support passkeys, but we’re getting there slowly but surely.

In a corp setting, just your idp for SSO requires it. Azure/Entra (Microsoft idp) will support next month. Okta supports today. For those who use Auth0, it’s two checkboxes in your tenant config to enable.

https://passkeys.directory

https://passkeys.2fa.directory/us/

https://janbakker.tech/prepare-for-passkeys-in-entra-id/

https://www.okta.com/press-room/press-releases/okta-launches...

https://auth0.com/blog/activate-passkeys-let-users-log-in-wi...

https://news.ycombinator.com/item?id=38521663

Yeah, damn. The killer feature for me for my YubiKey is TOTP stored on it + passkeys, but the latter is (as you noted) quite limited. The former is too but I’m yet to hit that limit. Having both is super useful I find

I found Titan keys to be redundant and less convenient than all of the various features YK possess. Also, I don't trust Google to hold all aspects of my A3E.

> It couples online and offline

That's kinda the point, as it makes it more difficult for account theft.

Online only solutions are either:

* knowledge based (and problematic for many people due to data breaches and common passwords, though perhaps not for OP)

* public/private key based and not widely supported

> It can be replaced with other solutions

I love my password manager and think it is a great solution for me. But I'm a tech person and know other people who a password manager would be horrible for. Even 1password, what I'd consider to be the leading password manager for "normal" folks has only millions of users[0].

Let's be generous and suppose they have 9M and all in the USA. That's only 2.7% market penetration. Not exactly a mass market solution.

0: https://www.businesswire.com/news/home/20230919527858/en/1Pa...

Preach. Passwords + password manager are the more secure ideal.

Yes and no. Many online services still have silly rules about password construction and length that preclude the random generated passwords that many password generators create. I often have to remove/substitute disallowed characters or shorten the generated passwords because the service has an arbitrary limit on the length of a password.

So yes, they are better but they are still often inconvenient at least when adding a new service.

Can’t stand this. I want to challenge the CTO of my bank to a public debate about password best practices.

And a double pox on those sites that disallow "paste" in their passwords fields.

Blowing my own horn a little, I have a Perl script that generates random passwords, with options to, for example, generate a 16-character password with lowercase letters, but with one uppercase letter, one digit, and one punctuation mark, all chosen randomly and placed at a random position:

    $ gen-password -len 16 -lower -1upper -1digit -1punct
    e$hmvcel9nyghAyw

Another script in the same project generates XKCD-style random passphrases.

https://github.com/Keith-S-Thompson/random-passwords

I have MFA on for everything and I've about had enough. I'd rather have super non-memorable passwords for everything and have one MFA code for the password manager vault.

Passkeys should not require MFA either. I see a good enough future for me and it's:

1. Bitwarden with vault password and MFA

2. Everything else within, passkey

I'm completely unconvinced MFA is necessary if the "password manager at top + passkeys for services" mentality is ingrained in everyone. If you offer a service where I sign in with a passkey and also require MFA you better publish an extremely convincing security paper why, or have an infrastructure critical service that burns the world down if someone unauthorized gets in. There is no other justification for that level of security other than to be an asshole.

Password manager + MFA is a lot more secure. Password managers aren't impervious to attacks.

Everything I've seen to replace or "fix" the problems with passwords just makes things worse.

My requirements are:

1. Nothing tied to a specific device, especially one that can be easily lost/stolen/broken like a cell phone or USB drive

2. No biometrics

3. It shouldn't permit anyone, outside the website I'm logging into, to know if, when, and/or how often I log into that site.

I'm pretty sure using passwords with an offline password manager is the only thing that satisfies that, but if someone comes up with something better that meets all my requirements I'd be all for it.

Other than a few awful providers such as AWS, 2FA isn't limited to a single device. Put it on your cell phone and your old phone you upgraded, or a cheap old phone, or multiple yubikeys, etc.

If one is lost you grab a second device.

yubikeys are interesting, basically not much different than a password manager in the case they get lost/stolen, but I worry about the privacy aspect. I assume using the app, or the use of yubicloud would allow yubico to know which sites I use, and perhaps when.

Why would you assume that? You don’t need to use their app.

It looks like it might be possible to avoid leaking a list of the sites you use with yubikeys, but I need to look closer at how they work on the website's end to make sure they aren't using YubiCloud or some other third party service for validation or key management, and to make sure nothing is trackable through it. It looks like Yubico OTP requires Yubicloud and using yubico-pam might use Yubicloud.

I deal with #1 by having two YubiKeys, and registering both

sqrl, but no one is using it because the big boys can't own it or sell it or use it for any sort of lock in or stickiness, and also probably because it's actually correct, which means there is no way to fix user F-ups

Yep. It's often users' magical thinking combined with charlatans trying to sell them a panacea.

1. Can't be tied to just one device - Must have backup codes or multiple devices that can act as the same to prevent lockout and aid legitimate recovery.

2. No biometrics - Doesn't survive rubber-hose cryptanalysis. Easily impersonated.

I would add the following:

4. Unable to operate without my interactive, explicit permission.

5. Not a device left online 24/7. Preferably detachable.

6. Not an NFC.

Congratulations, we've just reinvented the emperor's new clothes with very long CSHWRNG-generated passwords or key files, password managers, FIDO2 hardware devices, and backup codes.

> 2. No biometrics - Doesn't survive rubber-hose cryptanalysis. Easily impersonated.

Also, biometrics generally can't be revoked. Not nearly enough attention is paid to that, and it's very important, IMO.

In the extreme case, let's say you're using actual DNA. On the surface, that looks impregnable to anyone but maybe your identical twin (barring the "rubber hose" thing, of course).

In practice, anyone who's hacked a genealogy site (as happened quite recently with 23andMe, IIRC), or who's managed to grab your used coffee cup or cigarette butt pwns you forever.

Client side ssl certificates satisfy all your requirements and are phishing resistant.

False dichotomy and less secure. Very long passwords + password managers + separate FIDO2 hardware. The point of MFA is that even with a compromised password manager or compromised password, that extra factor is required. The more damaging the loss of credentials would be, the greater the user costs of actual security (more factors) should be allowed to protect them in order to multiply the costs and trouble to potential attackers.

There is a couple of things I wouldn’t agree with. SMS as authentication factor is certainly bad idea, but it’s not MFA problem. Many services support OTP and modern password manager is expected to support it too.

Unique 25 character password is much easier to steal than your biometric information. All hackers need is a successful MITM attack (key logger?) or a database dump containing unhashed passwords. They could be some script kiddies from Russia or India running an automated attack on some old version of WordPress. For biometric information they would need to get access to it first and hacking your device (or getting physical access to you) if you protect it properly may not be feasible for majority of them.

Author should try Bitwarden - it can generate TOTP codes along with remembering your password. It even autocopies your TOTP code when you autofill password, so you can log in without mousing around menus and losing flow.

Nullifies most of the benefit of MFA though so maybe keep your critical stuff like email logins out of it.

Bitwarden (as well as Vaultwarden) supports Passkeys as well now. You can even export the keys!

> it can generate TOTP codes along with remembering your password

Absolutely correct, if you pay. Which is their right, but I'd argue you shouldn't have to to get such a basic convenience in the digital age as "just works when I want to log in".

You expect them to host your secrets, protect your secrets, maintain multiple extensions and clients, and provide you with a low friction flow for free?

If it's a budget thing, self hosted bitwarden/vaultwarden with premium features has been a thing for a while now.

I don't expect Bitwarden to - the comment was meant to be an indirect dig at the industry in general. Why do I need to pay for secure login convenience? It should just work.

1Password does allow you to set it up as an authenticator for sites with 2FA so you don't need a smartphone.

The author seems to not have heard of hardware tokens to store your MFA.

It’s not linked to a single device (you can get your codes on a computer, phone or tablet), it doesn’t require you to be “online”, and you use them for OTP, passkeys and whatnot.

I use Aegis authenticator on my phone which supports export, I import them into gnome authenticator from where it is incredibly fast and easy to get the code into a web application login:

* Press "windows" key * Type the first letter or couple of letters of the name of the code, press enter to copy (which also closes the expose style view and returns to the previous application) * Paste

Very smooth, with this setup I have no issue using 2fa with codes.

Not sure if it can be simplified to this extent on other operating systems / window managers

The thing that annoys me most is that there's no reason MFA needs to be tied to your mobile device, and I have to pull it out every time I'm signing in somewhere on my computer.

Just let me have an MFA program like Authy on my laptop, or even make it a Chrome extension. It would be so much more convenient.

MFA is not generally trying to stop the use case where someone steals your laptop while it's open, it's trying to prevent the case of someone stealing your password remotely.

I used to use Lastpass with MFA, only for them to leak my vault and completely obviate 2FA. It irks me to think of the cumulative hours I lost on entering those codes, though I still think 2FA(+) has value. You can do something relatively painless like 1Password, where my device stores my secret (I only use the odd 2-3 devices after all).

Lastpass is in and of itself a solid argument against the infallibility of a password-manager-only approach.

Just use a password manager that stores your TOTP token along with the password and never care again. I use Bitwarden.

Say no to proprietary hardware enclosures that deny you access to your own keys. Only use them as secondary auth of convenience, store all your passkeys in a software vault you control.

“I believe MFA commits a deathly sin against the commandment “Thou shall code against interfaces, not implementations.’”

I don’t disagree with the sentiment, but I’ve certainly never heard of this commandment - at least, not until the author conveniently declared it one to make the point.

I wish everything would work with my yubikey as-is.

Instead it’s the Microsoft Authenticator and it’s different MFA styles:

- sometimes faceID is enough

- sometimes I need to select a matching number in a list of 3

- sometimes I need to type the number myself

- sometimes I need to type a TOTP from my phone to my computer (much worse)

And isn't it ominous how it's "Multi" and not just "Two"...

"Two" is a magic number that conflates the concept with implementation. Two-factor authentication is not useful because of 2, it's useful because of >1. "Multi-factor" lets us generalize to 0 factors (anonymous), 1 factor (weakly authenticated), and many factors (strongly authenticated).

I find anything that doesn't support U2F keys annoying. It doesn't add any friction when the computer just says "push the USB key", since it's a yubikey nano that's always plugged into the computer.

What REALLY annoys me though is places that do support U2F keys, but only one. Last I checked AWS was broken in this regard. And honestly that adds enough friction that I'd rather do experiments on GCP, which doesn't have this bug.

Not that my experiments affect AWS's bottom line. But it does mean that I learn GCP better, and maybe will recommend it in a work context. Not recommend it because MFA, but because I will better be able to say what GCP product can and can't do, than AWS, because of this.

AWS supports multiple U2F keys, I have two on my accounts. The UI is a bit clunky, though.

PayPal, on the other hand, only allows a single U2F token.

As another commenter pointed out, AWS only started supporting multiple MFAs last year.

Ugh, but yeah Paypal… that's why I'm still on SMS (SIM hijackable) and TOTP (phishable) with them.

AWS started supporting multiple keys last year.

That's great news. Thanks!

Magical thinking and bitching because you can't get something (good security) for nothing (absolutely painless). Authentication is based on something you have or something you know.

FIDO passkeys are the way to go now. It's saved to your password manager and just needs one click to authorize your login.

> So when my brain is at 200% CPU usage and I log into some service and they ask me to authenticate with my phone, my attention receives a right hook that directly knocks it out. When this happens it means that half of my morning productivity gets destroyed

The author deserves to have a way to work that fits their needs, but really they need to realize that this is an extreme neurodivergence. This is honestly shocking to hear.

I think it might also have to do with the content of their work. I'm rarely doing anything that needs deep focus, I'm making glorified CRUD screens and doing tech support.

When I do more physical things like counting objects or putting away groceries I have far more trouble, dealing with multiple physical objects at once is a lot more overwhelming than writing the same boring code I should probably just pay for Copilot for...

I don't mind additional factors. It's the disablement of things like paste and similar that I despise.

“For example, I’ve been using a password manager for the last two years, and now all my passwords have been generated automatically. This means that if you steal my password you’ll only have access to one of my accounts.”

At risk of stating the obvious, this misses the point of MFA.

Password managers are not an alternative to MFA. Also, how do you enforce the usage of a password manager such that you can confidently remove the requirement for MFA?

The whole idea is to protect the one account. If you “only” lose one account that’s still a bad day. Service1 has no ability to protect Service2, so protecting all of your accounts is not something MFA tries to solve

It blows my mind how prevalent smartphone-based MFA has become. People should be far less willing to comply with vendors' demands for mobile numbers under the guise of improved security. SMS 2FA generally worsens your security posture by opening up new and more convenient vectors for taking over your account[0].

What's especially shocking is when I encounter employers insisting that I setup MFA using a smartphone. Even employers that should clearly know better, working in security-sensitive areas where employees are developers with commit rights to cloud software/operating system code, making lucrative targets. There's a lot of cargo-cult negligence out there.

Fortunately there are better approaches to MFA. MFA is not the problem, smartphones and cell carriers are just raging dumpster fires.

[0] https://en.wikipedia.org/wiki/SIM_swap_scam

we all do. but it works.

So do password managers.

Websites concerned about password use should provide an option to use a randomly-generated password (generated by the website, not the user) in leu of MFA. This guarantees the password is unique and complex, and practically ensures that the user has a password manager.

I agree in spirit but not in practice. I don't think a website should be trusted to generate a random password - leave that to browser infrastructure (which includes extensions).

The idea is that by generating a unique password for the user, the website guarantees that it really is a unique password. How else can you do that?

How is this different from the way we handle e.g. api keys?

still vulnerable to password db leaks

Only if you don't hash and salt

I've never had any of my accounts hacked and my password practices are not great. And for most accounts I don't really care that much if somebody does.

I loathe MFA and all this security theatre that makes everything janky.

Mfa isn’t for us. It’s for everyone else.

But I will admit, as someone working professionally as a specialist in the cyber domain, that mfa saved my ass more than once.

Until it works too well.

I've been consulting with a business on their website, many people have left the company before I got involved..

Godaddy MFA - can't change DNS to new server, no way to renew domain name. What a process to get documents and things together to bypass that -

Cloudflare MFA - if I'm at another IP location I can't clear a cache without getting an email to another person and getting codes.

I like MFA for bank account type stuff.. and I'm serious about security.

However for many things, I would prefer a multi-message that a login has occurred (Send me three emails to different addys and an SMS text) - send me a message that a change has been made, log the ip and changes made.

I feel that an sms and email sent to all known things would help with sim swap issues even more than MFA to swap one..

I mean for some things do both - but many things MFA is a drag, especially domain name related stuff that is easy to reverse if a change is detected.

Copy mfa code on iphone, paste to mac. Makes it bearable.

Reply on news.ycombinator.com