Playing with more user-friendly methods for multi-factor authentication | Hacker News Reader

Playing with more user-friendly methods for multi-factor authentication

tesseral.com

79 pointsnoleary82 comments

> When I tell people I work on authentication software, I nearly always hear some version of the same story: I hate multifactor authentication. No, really. People hate this stuff.

I hate all of the half-cooked non-TOTP MFA methods that I'm forced to use. Just let me use my freaking authenticator app. If you believe that your users prefer (or maybe it's just you?) more databroker-friendly methods, then fine, but please at least provide TOTP as an option.

I wish that banks would offer TOTP. SMS is famously insecure and poorly suited for something that’s a load-bearing pillar in most of our lives, and TOTP is probably the most reasonable replacement. Unfortunately only a tiny handful of US banks offer non-SMS 2FA of any kind, and to my knowledge the one that does (Scwhab I think?) requires the use of a hardware gadget even though it’s standard TOTP (which people have written python scripts to extract the necessary bits of info from).

Fidelity offers TOTP standard support, works with the native Apple Password app/keychain.

Only recently. They used to require Symantec's authenticator.

To this day I'm just amazed that World of Warcraft tried to mandate security tokens in a time when E*Trade barely supported them.

Why is a video game embarrassing fintech?

World of Warcraft was supporting tens of thousands poor teenagers in developing countries, who would farm high value items in the game and then sell the account /items to rich people who didn't want to put in the hard work.

There was (maybe still is) lots of money to be made by hacking accounts and selling them.

WoW was fintech!

>WoW was fintech!

WOW was teaching kids how free market capitalism works early on.

Schwab supports Symantec VIP but there's a python package to emulate it, which will give you a regular TOTP setup code.

At least in Germany all the SMS 2FA has been shut off, but replaced with tons of custom 2FA apps. The security argument is certainly that they can check for 'insecure' devices. But I wonder what the empirical evidence here is and how often (compared to phishing/social engineering) a TOTP token was actually stolen. Worst thing is IMHO Microsoft now which seem to have also shut off the TOTP option and use some other propriatary 2FA scheme now. IMHO banks should simply use FIDO2 HW tokens, but with all that passkey bullshit it becomes unlikely...

No it hasn't. How can you make a statement so confident, when obviously you couldn't objectively know?

Evidence to the contrary?

For my German banks, this is true. Stupid custom apps and proprietary reader hardware that read coloured moving QR codes everywhere.

It's your responsibility to provide evidence for your claims, not everyone else's to prove yours wrong...

You say "no" to the poster saying "in Germany all the SMS 2FA has been shut off".

It makes sense to ask you for evicence: You'd just have to name a bank that provides SMS 2FA.

A failure scenario I found is when mitm antivirus decrypts traffic (or something similar), so a proprietary 2fa scheme doesn't work, because it can't get through network.

A passkey is far better than TOTP for security to the point that TOTP should probably be deprecated already.

TOTP still seems good enough for most things

It's like picking WEP for your wifi

https://www.cisa.gov/sites/default/files/publications/fact-s...

At best WPA2. WEP is broken in ways that don't need human fault.

The only downside of TOTP to FIDO and friends (from a security perspective) is phishing resistance

That's a pretty major downside to OTP's and certainly not one that can be offhandedly dismissed.

It is for general population. I don't think HN users for instance are particularly concerned about phishing sites.

Zero days exist, and something like tapjacking can be used to obscure and capture those TOTPs.

Don't use TOTPs if you have an option to use Passkeys/WebAuthN

Short video example: https://taptrap.click/

Python users (pypi.org) just got hit that were using TOTP.

"If the user had enrolled a Security Device for PyPI second factor authentication, the attacker would not have been able to use the second factor, as the WebAuthn protocol requires the user to physically interact with a hardware security key, or use a browser-based implementation, which would not be possible if the user was not on the legitimate PyPI.org website (Relying Party Identifier)."

https://blog.pypi.org/posts/2025-07-31-incident-report-phish...

Because of how humans work TOTP can give false confidence to the user which is a further downside.

Grandma goes to fakesite.com not realising it isn't her real site. It asks her for the TOTP code, she provides her TOTP code and it works. She is reassured - if this wasn't her real site why would the code work?

Now, in theory a neutral security assessor can see that's not reassuring, but that's not how humans work, the fact there was a challenge-response feels like security even though for all they know if was accepting any inputs.

Phishing sites generally have a milder version of this effect. I have vanity mail, so I own the "mail provider" handling my email and yet of course I get those phishing mails saying as the "Administrators" of my vanity domain they need me to type in my password. But they don't know my password of course, so filling in their form with crap "works" the same as anything else, fuckyouscammers, sure that's a reasonable password.

These schemes can't work if you don't rely on stupid shared human secrets ("Passwords") everywhere, but we did and it seems many people are really enthusiastic to keep doing that, so I doubt we'll escape from this self-imposed status. I wanted to make a web site that mimics the famous reusable Onion article but I've never gotten around to it. "No way to prevent this"

Find me a grandma using TOTP. It would confuse them too much.

Huh? We're not asking random grandparents to implement TOTP, only to use it, and that's necessary for a lot of basic remote work and so on these days.

I clearly said "using" not "implementing".

Hence my "Huh". Everybody working in my team uses TOTP if they don't have their own Yubikey which most do not. Most of them aren't close to as old as I am, but some are indeed grandparents, it's like if you were astonished anybody over age 40 can type.

Passkeys don't replace all use-cases for TOTP

Yes, for the love of god and all that is holy, just let me use TOTP for MFA. I absolutely HATE that some banks use SMS as a method of MFA. Sometimes it's a mix of 8 character numeric password with SMS as MFA.

totp is still terrible, still phishable, more annoying to enter or use. it's only tolerable because it's better than the other methods you might see (email, sms, custom app), but imo it also falls into the half baked category behind things like passkeys.

The problem with multi-factor authentication is its overuse. I would also hate physical keys if every single door I came across required me to unlock it.

When you already have so many logins that you start using a password manager, your passwords are already high entropy enough that they don't get brute forced and a leak doesn't compromise your other accounts. TOTP adds challenge response to this, so it is actually a bit better than a password since an interception cannot be reused, but they are both still shared secret and in both cases need to be stored in some other device (password manager vs TOTP code manager). For most logins that don't require real security I just use my password manager for both so it is just a disjoint shared secret approach. Nevertheless, TOTP "increases security" for websites (but not my security specifically) because the shared secret is generated by the website owner so is definitely unique and not reused unlike many other user's passwords.

I expect the majority of people are storing their TOTP secrets on the device they are logging in from (their mobile device) and so have single points of vulnerability. So multifactor auth is typically just a disjoint shared secret with a partial challenge. The extra security is just created because the website forces true random shared secret. We could have all this with a single factor.

Why couldn't we combine the two? Make TOTP based on a higher-entropy secret with longer generated codes the only factor. This would prevent replay attacks of entered passwords, thus protecting against phishing, and ensure users have safe secrets (since the site generates the secret).

That's my preference. For some things I would be willing to have the increased security of a genuinely separate device.

Quite funny. Amusingly, the self-portrait method is effectively the signatures we considered acceptable for financial and legal transactions for many decades - make up a scribble and compare it to a scribble you do previously - if it's close enough and you _seem_ to be the guy, we're good.

> make up a scribble and compare it to a scribble you do previously

I'll take "Lies that your parents told you about how the world works" for 500, Alex.

Serious question though, I thought the whole signature thing was more of a legally binding thing for the signer asserting themselves as X, sort of like checking the "I'm over 18" box. Sort of a "Well we asked you the question, it's not our fault if you lied" type thing.

I remember opening a bank account and having to sign a specific card that the bank would keep solely to verify my signature on checks.

When I got my first credit card, circa mid-90s, no one told me I had to sign the bank. Took my brand new card with my brand new girlfriend to a shop and bought something.

Handed the clerk my card during payment, she looked at it and said it is not signed so she is not allowed to accept it. I took it back, she gave me a pen, I signed it and gave it back to her.

She ran the transaction, got an approved slip, gave me the slip to sign, I signed it and gave it back.

She compared the signature on the slip to the signature on the back of the car, and Lo And Behold, They Matched!

Like logging in after a password reset.

I personally don't mind this because I've been burned too many times by services that mangle a new password in some invisible way, for example silent truncation, so I like the opportunity to log in just to make sure that the update has worked, the value in my password manager is correct, etc.

I always do a random scribble. If I want to later deny signing something good luck proving its me, won't match any of my other signatures. At least that's the theory, this is mostly a joke to me and I don't care if it works.

"lies that your American parents told you about how the world works"

i went to Germany as an exchange student, scribbled out my random scribble for my travellers check, and they denied me because my signature wasn't close enough to their record. heard a similar story from a friend who visited Japan

And in India when you need lots of cash from your own account, you need to sign a withdrawal slip, and signatures on that need to match exactly the original signatures on their file.

Signatures are the tip of the iceberg. Plenty of other forms of bs forensics live on in the legal system in some shape or form. e.g., fingerprint analysis, polygraphs, field sobriety tests, devices that literally do nothing, trainings on reading facial expressions, and so on. If you can take a two week course on it, then chances are there is some cop somewhere using it to detain people.

fingerprints seem pretty solid?

On a good day, with an excellent print and the best people doing the matching you can be pretty sure if this print is from this person, but crime scenes are not that perfect scenario and the actual crime scene investigator might be less than great at the matching or influenced to some extent by what their boss wants.

There's a big difference between "This thumbprint in blood was on the recovered murder weapon and it's a perfect match" and "This smudge of half a finger on a paper bag found near the scene was arguably a match" but the jury isn't necessarily told about this and where on that scale the evidence they've been told about would lie.

Standards vary wildly on what constitutes a fingerprint match. There can be well over 100 ridge characteristics in a fingerprint, but some US jurisdictions only require as few as 12 of them to match, and it all comes down to an investigator's subjective determination anyways. It is not scientific.

A fingerprint locked NFC Yubikey seems to be the preferred with all ages at work. Everyone likes it as long as it is once per login to the computer (which basically means we have to use Edge for everything which is fine).

Everyone universally hates passkeys because they never work right.

It sounds like you're talking about passkeys though? (FIDO2) Or are you using PIV on all of those keys?

Fido2

whisper that Yubikey is holding the passkey data ;)

I still don't know what a passkey is, but since Microsoft pushes for it, I assume I'll probably hate it

Everybody is pushing for it, Microsoft is just being dragged along.

I’m referring to the browser based ‘passkey’ everyone is pushing right now

Except for those whose fingerprints don't work (climbing wears away fingerprints). I have even heard of people struggling to renew their passports because of difficulties getting their fingerprints read.

Many manual jobs wear away fingerprints. I renewed my ID card after renovating my home and the fingerprint reader could not read anything meaningful. They told me that sometimes the state accepts those messy fingerprints anyway and yes, the request got approved. There is some jumbled fingerprint on my record now.

I would much prefer to have a pin on the yubikey itself with little keys or something but since that isn’t an option, fingerprint it is.

You can set a yubikey to require a pin entered on the host.

It’s a shitty user experience though, as loads of websites turn into “username+password+yubikey+pin+key button press”

Yep... which is why we use the biometrics one. End users refused to use the app as it was a pain.

> Everyone universally hates passkeys because they never work right.

I’m considering a passkey deployment. What sort of issues did you encounter?

Tied to the browser and did not travel with the user across devices and apps. It's that way by design.

An authenticator device is agnostic, transportable and can be backed up (or a secondary added)... sometimes. Implementations can suck (looking at you, my bank that only allows one key)

Poker hands would pretty cool for encoding things that you have to recognize quickly; e.g., key fingerprints. If there are 2.5M unique hands then encoding 256 bits of information requires 12(ish) poker hands.

One aspect I find puzzling is why most two-factor authentication (2FA) applications restrict authentication to only a single valid code at any given time. This constraint inevitably creates a window during which it is inconvenient or impractical to copy the code to another device. Allowing the previous code to remain briefly valid would eliminate this unnecessary delay, enhancing usability without significantly compromising security.

Ente Auth displays the current code and the next code so you can choose whichever best meets the time remaining until the changeover. It’s a nice usability feature.

FWIW 2FAS starts to show you the next code near the end of the window, this is very handy https://2fas.com/

Have you actually tried writing a code close to the expiry window? I've definitely submitted codes a few seconds after the expiry and had them still be accepted

Some users clocks are a minute or two out, so sensible TOTP implementations will actually accept about 5 codes to account for clock error.

Since totp codes are time based and there is no guarantee that time of the generating device, and the verifying device are exactly identical they usually allow some room for error. You'll probably be fine entering the code before or after for example.

See RFC-6238: https://www.rfc-editor.org/rfc/rfc6238

This is all in the standard, most places have implemented one of the options. I've implemented all of the options at least once. It's configurable based on how lax/secure you want to be.

Most places I've dealt with allow the previous and next code to also be used, so instead of a 30s window you actually have a 1.5m window.

I believe every single 2fa system I've used accepts either the current code or the one directly prior.

Pedantry warning: I'm not convinced that some of these methods qualify as a second factor of authentication, based on the "something you know, something you have, something you are" model. They're both "something you know", right?

That is actually multifactor. Second factor is just any additional factor.

I know that the article is a joke, but the last one is (or was?) actually used by Facebook as a forced mfa when it suspected a correct login to be "suspicious".

Of course, it's also a way to force users to tag their contact's photos and train Facebook's face detector by holding your account hostage until you comply, similar to those CAPTCHA street view challenges.

Besides, it only works if the attacker is a stranger, if it's an acquaintance (or a very dedicated stalker) then it doesn't work so well anymore.

I would want X.509 client authentication. You can use a passworded private key if wanted (and the server will not need to know your password), and there are other benefits with security and other stuff, compared with the more common 2FA and cookies and that stuff. It also ensures better that the client and server are communicating with each other that they want to rather than someone else that they don't want, then merely using X.509 server authentication only.

> It's incredibly easy to remember your hand. Just ask any of your friends that play poker -- they can surely remember a bad beat. And it's pretty much impossible for an attacker to guess.

There's an implication here that users would pick a random hand. I'm sure a set containing all flushes, straights, full houses and four of a kind would account for most of the used passwords.

These are such terrible ideas that I expect someone already has one of them on github.

Please, non of these. Just a QR code with an authenticator app of my choice.

It’s a joke

The only 2FA I'm using is the one of my bank, because I must (there are regulations.)

I stopped logging in into GitHub since they enforced 2FA on my account. Luckily no current customer of mine is using GitHub. They are on Bitbucket and it does not require 2FA yet.

A number of services that I use ask me to enable 2FA. I skip the offer everytime.

The worst 2FAs are SMS based: not because of the (in)security of SMSes but because I don't receive SMSes when I'm outside of my country.

>because I don't receive SMSes when I'm outside of my country

What?! I've never had that issue.

I never received a SMS from Italy when I was on vacation in Australia in 2019. Apparently my phone contract would allow them but either the phone company did not honor its terms or banks didn't send SMSes to roaming customers. I ended up using Italian payment services that either had their own app or other methods to perform 2FA. I also had an Australian SIM but there were no chances to associate it to my accounts. I guess that it's fair, because a foreign number all of a sudden is a red flag for a stolen account.

And nobody sent SMS to me, everybody used WhatsApp or similar services.

Why do we like entropy in auth factors?

Imagine two different password strength standards:

1. Just a 4 digit numeric PIN like `1981`

2. A 20 character upper/lower/numeric/special-character password like `qmd1tkf7mwa.PQB0qrz$`

The PIN has lower entropy and is therefore a lot easier to brute force.

I haven't calculated this stuff myself -- I just used Wolfram Alpha -- but it looks like the PIN would take <1 second to brute force, while the 20 character password would take 7.6 * 10^25 years. [1] [2]

[1] https://www.wolframalpha.com/input?i=password+strength+qmd1t...

[2] https://www.wolframalpha.com/input?i=password+strength+1981

Reply on news.ycombinator.com