Passwords Are Fine
herman.bearblog.dev
herman.bearblog.dev
I live in rural Western Australia with almost zero phone coverage, and this is a huge problem. I'm terrified of all these services wanting my phone number, or bugging me to turn on phone 2FA, because the moment that happens, I lose access to that service.
ChatGPT that everyone is spamming on every discussion? I can't even sign up for it (I'm not really bothered about that; it seems like a dangerous crutch than a useful technology).
The problem is the developers have smartphones, their friends have smartphones, their bosses have smartphones and their clients have smartphones. Everyone they know have smartphones and live in places with reception. So they don't or can't imagine something different.
You can even have the authentication app on your laptop so you don’t need to switch devices (1Password at least supports this).
Yeah, I share my 2fa with every device and defy the purpose. I know. But if you have access to any of my devices I sm already compromised.
E.g., ING in Australia.
Not to sidetrack, but could you expound further? I struggle to reach the blanket conclusion of “not useful”.
I don’t really see how it’s a crutch, more than any other assistance tool like Google, StackOverflow, code-completion or actual docs. Hallucination is a separate problem, which is solved by using fine-tuned models.
They won't solve the main cause of hallucination: prompt has zero connection to generated text other than probability.
ChatGPT do not generate answers, it comes up with something that looks like an answer. There is a good chance it is the answer, but you can't guarantee it.
I believe this particular problem won't be solved, unless researchers teach machines how to reason. But then we would have greater concerns than hallucinations.
I don’t need 100% truth, because reading multiple docs myself and piecing things together has tons of potential pitfalls too.
I frankly am baffled by the allure ... of letting opaque computational systems perform intellectual tasks for them. ...when it comes to using language in a sensitive manner and talking about real-life situations where the distinction between truth and falsity and between genuineness and fakeness is absolutely crucial, to me it makes no sense whatsoever to let the artificial voice of a chatbot, chatting randomly away at dazzling speed, replace the far slower but authentic and reflective voice of a thinking, living human being.
https://www.theatlantic.com/ideas/archive/2023/07/godel-esch...
It might seem surprising these days, but the parent poster might have network access through means other than a phone.
Most government docs are now PDFs, happily. But forcing people to choose between Android and iPhone (or forgoing service) is pretty nasty - these devices are expensive.
So by forcing me to add my phone number some services actually decrease the security of my account.
Making phone numbers required for signing up was only nominally to improve security. Overall, it’s a net negative for privacy and security, and only benefits the service provider by allowing them to track you (they can buy data on that phone number and create a profile on you) + reducing the number of people calling/emailing them because the user is locked out of their account.
This really isn't a dumb phone specific issue. Even for smartphones if someone stole it they could pop out the sim and if it isn't password protected (most aren't IME), they'll have full access to your phone number.
Also, even if you want to keep the pin on many people would set it to something convenient like 1111 or 9999. In fact, one of the carriers I used had 1111 s a default pin code for all their SIM cards.
So, while security is there in theory, in practice it's rarely in place.
Can they do this without connecting to a cell tower? Otherwise, the carrier would notice the pairing of your SIM to the new IMEI, and further security steps would be possible.
Have you tried enabling Wi-Fi calling or switching to a carrier that supports it? At least for my carrier and iOS, you can send/receive SMS messages (yes, the green bubbles) through Wi-Fi.
I do still get them from android phones. Its weird, i have no idea why.
If you have an android phone yourself, maybe it's not actually SMS and it's actually RCS[1]?
[1] https://en.wikipedia.org/wiki/Rich_Communication_Services
And, in my experience, Android pushes you heavily to enable RCS; every time you open its messages app, there's a chance that it will randomly ask you to enable it, with a large button to enable and a small link to dismiss the dialog without enabling. I never tried, but I expect that once enabled, it'll never ask again, so it might have been enabled by accident sometime in the past.
Don't want to pay outrageous fees for Google FI or the like, as literally all I need it for is to get into online banking (who have decided sms 2fa is now compulsory, without offering any other options like an authenticator app). I'm currently locked out of my bank, will have to fork out $50+ just to call them, then hope I can convince them I am who I say I am. Then do the dance again next year when they do it again.
Can we all just do authenticator apps?
Last I checked, they were asking for $20 / month for unlimited calling and texting. Do you consider that outrageous?
As an alternative, Google Voice will host your phone number for free. It works with every WiFi connection and even while traveling internationally. Have you considered that?
It's pretty outrageous if you already have a local sim, so you're basically paying google $20/month to only receive SMS messages.
But yeah re:Google Fi, $240/y to recieve maybe 3 sms is pretty bad imo. And unlimited is only within US.
I kept the number from the last country I lived in solely for 2FA of accounts from that country and after almost a year I've managed to change over most things but not all. A week ago I decided to change that physical sim to an esim as I only need to enable it occasionally. I did the process for this, and at the end I got a link to last country's app store. The only way to install the esim is to use this app and it is only in last country's app store. I haven't logged into that for a while so it needed email confirmation. I haven't logged into the associated gmail address for a while so that needed 2FA confirmation by SMS. So I'm now locked out of an email address, apple id, and phone number.
I’m sure there’s a joke in here to be made about dating apps.
It starts off by saying the problem with WebAuthn is lack of widespread support, which is fair now, but not a fundamental unsolvable problem. WebAuthn/Passkeys are pretty new - essentially less than 12 months old (since iOS 16 GA). Google.com added support this year, and Apple.com is adding support this year. iOS 17 adds support to the system frameworks to let third party apps (like 1Password) store and sync Passkeys.
But my biggest objection is with saying all problems of passwords are "solved by fairly simple password hygiene". Apart from the "if everyone just did the correct thing we wouldn't have any problems" declaration, IMHO the main advantage of Passkeys is that they eliminate phishing as a possibility due to the public/private key cryptography.
Passkeys just entirely eliminate classes of problems with passwords by shifting the burden of security from the user to the tech itself.
I remain skeptical that Passkeys will end up with widespread support, and I think it's too early to tell how it'll go, but all signs are pretty promising. I hope Passkeys work out.
For example, GitHub and Google (via their Gmail mobile app) are constantly nagging me to open their apps for certain actions such as modifying security settings on a GitHub repository or even just logging in to Google Workspace.
While certainly more secure than SMS, I'd like to use an authenticator app of my own choosing for that process (e.g., 1Password or Authy). While that's still possible, UX-wise that requires an additional step and possibly also brings about the risk of being flagged by some internal fraud detection system.
To me, this feels like they're trying to promote their apps and increase user retention and interaction by means of what superficially looks like a beneficial security feature.
I'd rather just have memory safety built in to the language I'm using—I'm not sure exactly what the equivalent is for passwords, but I don't think I would oppose it.
It's a hard problem. I don't think passkeys really are the solution long term, they just sweep the problem under a corporate rug and ignore that people will still use them inappropriately.
But somehow the same people arguing for ultimate freedom and OSS are also arguing for centralization of passwords into corporate controlled infrastructure.
I'm somewhat at a loss on how to argue on these issues. You want to hand over control over your key infrastructure to big tech and you want the average population to do that as well? Go ahead. Most people on iPhones already use sign in with Apple with apples 2FA system anyway it won't matter to them.
But why encroach on me and force me to use it to protect me from myself?
"Big Tech" does not control Passkeys beyond the work on the underlying WebAuthn spec https://www.w3.org/TR/webauthn-2/, and that they develop implementations of that spec.
We will also have at least one open software implementation when this gets merged:
https://github.com/keepassxreboot/keepassxc/pull/8825
There are braindead implementations like PayPal's:
https://www.paypal.com/us/cshelp/article/what-are-paypal-pas...
that force you to use Android or iOS, but it's nothing new, they manage to fuck up everything they touch (for example, U2F 2FA only supports registering one hardware key and it has been that way for years).
Can you expand on these 2 points? I'm still trying to wrap my head around passkeys and these are some of the arguments I see around but never quite explained.
Because if this passkey stuff takes off with normal people, 98% of passkeys will be stored in cloud accounts with those providers.
The weakest link in the security chain is the procedure for when the user forgets their password / loses their phone / gets a rootkit / gets phished / has their e-mail compromised. You can transfer that problem from your site to a cloud provider and hope they do a good job - but the problem doesn't go away.
They will also (and primarily) be stored in the individual devices, and don't need cloud access to the providers in order to be used.
In this sense, it solves one of the main issues with third-party sign-in, i.e. that if the provider decides to lock your account, you get locked out of any linked services.
> You can transfer that problem from your site to a cloud provider
With passkeys? How so? Are passkeys not just cryptographic key pairs? If your service associates a certain account to a certain public key, there's nothing an external cloud provider can do to solve the issue you describe.
It's possible I've missed something, like I said before I'm still wrapping my head around the whole thing.
Without passkeys, if one of my users lost their "second factor" (e.g. lost phone) I had to provide a flow for them to get into their account despite that, while remaining secure.
With passkeys, users can restore their "second factor" from a cloud backup, so long as they can get access to that cloud backup. Hence, my lost-second-factor flow is outsourced to the user's cloud provider.
You could even argue passwords are better than passkeys for those with strong password hygiene. However when it to the masses, the convenience-security tradeoff of something like passkeys is always going to be better. And for the nerds and geeks, passwords are not going to disappear anytime soon.
I use pass as my password manager on all my Linux boxes (with a yubikey to store GPG keys and Password Store + OpenKeychain on android).
I basically refuse to use any password manager with an implementation I can't see or audit.
I can't imagine trusting any company to handle my passwords correctly.
The only proprietary component is the yubikey which is basically incapable of misbehaving in a way which would cause me to lose control over my passwords unless I lose control over the yubikey itself.
That's a fair point. I certainly haven't.
But the great virtue of pass is that it runs locally, which means that it's much more difficult to attack than a SaS password manager.
I haven’t in all honesty read the Password Store android application (nor OpenKeychain) source code but I trust my phone sandbox capabilities enough for it not to do anything nefarious like send my passwords somewhere. Its also not so large that it would be hard to read it.
The point is, the operating principles behind how Pass works are simple enough that its relatively easy to verify the core of any implentation and relatively difficult to smuggle in nefarious behavior.
Maybe you haven't heard of pass[1], but it's an open source project, and it's easy to build from source[2].
---
An air gap would be preferable still, as that would protect from similar issues at the OS level, but that is another step or few into less practical (well, significantly more inconvenient) territory. I at least have my master password on a USB device (and backed up by other physical means in case that dies) which is only plugged in when needed, that is effectively an air gap when I don't leave the password manager unlocked between uses.
The result is that what should be crucial things like "how do we ensure permanency of the passwords file" are treated as very second rank - profile corruption usually is met with "remove the entire profile", which also ditches the password database. Literally every other password manager has some sort of tool available that makes it very clear where your data is stored and emergency backup options.
Chrome also doesn't like it if the login form doesn't look like most other login forms (and because this is the internet, you're gonna at some point run into weird login forms). It also can behave really funny if the site combines the user registration form with the user login form (which a lot of webshops do) by putting the autofill information in the registration form instead of the login form.
Add to that a very subpar experience in manually filling the right fields and "why not Chrome" should have a very clear answer.
As a user I just despise MFA. I hate having to keep my phone with me while I work. I hate the disruption in flow logging into everyday services like AWS.
Passwords are so much better.
House keys are a minimal inconvenience because the lock on your front door also affords minimal security. Just ask the Lock Picking Lawyer how long it would take a determined intruder to get into your home, whether by picking, force, or finding a weakness such as open window.
If your home had high security, I can guarantee that you'd feel the inconvenience.
A password, in theory, could work the same way. Except that the normal password UX involves people remembering the password, which entails a huge security compromise.
Yep, I'd call that a significant inconvenience (for a home that someone like me lives in).
MFA irritates me because usually it isn't my choice.
Part of it consists in the incredibly varied ways it can manifest. I could receive an SMS code, an email code, I could generate a TOTP code (choice of two Yubikeys), I could use U2F/FIDO (choice of 3 Yubikeys), I could get a Magic Link, I could use Sign in with Google, I could punt and use a code on my emergency backup paper. Don't forget to pass a CAPTCHA, and your password probably expired while you were away, as well.
Of course this all transpires after I've unlocked my password manager's vault, which has its own style of 2FA security, its own timeouts, and its own UI/UX quirks.
So you can see the sheer dizzying possible mutations of the MFA flow. Sometimes you don't even know what they'll hit you with until you try to log in!
What amuses me is "We sent a code to your email. This message will self-destruct in 10 minutes." when email used to arrive on the scale of 5-7 days if the server was overloaded or busy. Oftentimes I find myself racing multiple timeouts to run the gauntlet of MFA in whatever way has been mandated.
— Frankmin BenjalinAt least my password isn't changing anymore but I never understood that policy if you made a strong password. It was overkill.
Some websites still require it though, and that's nonsensical and annoying. Just randomly generate one and keep it in a password manager.
Once you’ve done the second factor dance on a new device once, and assuming the MFA setup has been done well, you shouldn’t need to reach for the MFA code again (at least, not often).
Of course, you'd lose most security benefits of TOTP, but if all you want is to ignore security concerns and log in without a phone, there are tons of ways to accomplish this. Just set up authy or krypt.co and be on your way.
IMO the MFA codes aren't even the problem. The fact that you need to reauthenticate multiple times per week is the real issue. Session tokens valid for longer than four hours seem to be considered a sin in most big tech companies for some obscure reason.
You'll get the best security if you don't have the TOTP secret on a device that also contains your passwords, just in case you get hacked, but even with TOTP on-device it provides a little bonus security.
And for services (like AWS) that don't (yet) support passkeys, a hardware token like a YubiKey is also an option.
I use a desktop app for most time based authentication tokens, there are plenty that sync up across mobile and desktop.
Even if people have their phones all the time there's always a possibility that components on the device might suddenly fail.
The charging port in my iPhone stopped working on one May morning and thus device died. I temporarily lost access to most of the apps incl. 2FA code generators for about a month. Luckily one of service centers was able to find component and replace it cheaply.
I fail to understand how educating billions (?) of people about proper password hygiene is faster or simpler than moving all authentication to a “tap this button to magically log in” method.
I'm old. What's the difference between a pass word and a pass key ?
> tap this button to magically log in” method.
And how exactly is "this button" authenticated ?
isnt public key a bad wording suggesting it should or can be public?
I would call it verification key and keep it secret on the server
only thing it need not to be hashed, it is already "hashed" meaning if it leaks it has 128 bit security or so
if I get it well, the private key can be guessed from the public key from huge alien resources so it is actualyl like an already computer intensive hashed 128 random password from a 2^128 domain?
I do not think the public key is to be posted on twitter or should not be guarded at all... it is just not the signing key and it is 128 bit strong away from it
i compare password hashing on server with passkeys where you store the public key on the server... we are told to hash computer intensive preparing for the worst that the server is breached and an attacker has the stored hashed (salted, peppered) password... then with brute force if you hashed computer intensive and the password was not weak, it can be i dont know 60,80,120 bit strong?
well you can actually get the password from the hash but if everything ok, infeasible... i guess it is the same with getting the private key from the public key, it is possible but with ecdsa256 i read 128 bit strong or so
i dont want more security i just find it interesting that nobody says the hashes are not a secret... ok it is more problematic since weak passwords remain much weaker hashed or not
i would still say if possible keep your verification key to yourself... and if it leaks, no problem
i would call them secret key (private) and verification key (public)
but i dont know much about this and i guess by digital signatures they are really public? but hey may be even stronger
You can use the terms you want. Other people will use normal terms.
we talked about whether a public key is actually a similar secret than a well managed (hashed) password
well it is not up to you to decide what terms are normal the language, concepts evolve
if you want to understan things better than you do know, sometimes you go 1-2 levels deeper and think for yourself
a public key has a security strength, lets say 128 bit a computer intensive hashed strong password can level this if you generate unique very strong passwords for each site with your pass manager and(!) they hash it well, it can be compared to giving a public key to the site
in this sense your argument which you just copy from other people is false
a good argument would be that a public key that we give the sites has 100% strong security and the password will not travel from the client to the server, whereas plenty of domain service provider implement security bad so you have to rely on them
in addition, computer intensive hashing on the server is more electricity and cpu|memory usage
please try to talk about the actual topic and dont try to derail the conversation like it was about whether passkeys are better or not... hiding behind something you declare normal is also bad practice...
just debate the only thing I said: actually, you do give a kind of well guarded secret to the server and it is not like a public key should be advertised
I do think it is a very intersting thought
and, of course, if a password comes from a weak domain, you can hash minutes, it will never be as strong as a public key
pass manager is needed and that is one of the key differences
it is good but also a challenge for some people, especially if the 3 bigs cannot sync because normal people without pass manager begin to use Apple, Google, Microsoft pass management... if they have all 3 devices, all of them...
what I do not understand, what the heck is the goal, one passkey per service and total sync or a domain (server) has to create and manage 4 passkeys for 4 operating system providers if user does not use a total syncing pass manager?
that is the problem since those who use pass managers are normally ok but those who dont, and wont register/trust/pay for one, begin to use A/G/M/L pass managers and 4 pass manager accounts must be secured?
and then you begin creating 4 passkeys for each website?
you start a process by pressing the button and authenticate via having the device and using your os account biometrics/passcode
then your pass manager signs a challenge with the passkey proving that you come from a trusted device (you are logged in to your pass manager) where you are the os account owner
Password: You have to choose a good one using your brain or a password manager of your choice, and you have to remember it using your brain or a password manager of your choice.
Passkey: Your device generates it for you, whether or not it is sufficiently random, and long enough is not up to you. You don't even have to worry about it. Your device stores it for you. You don't have to remember it in your brain, you don't have a choice if you want to use a password manager or not. The passkey is stored in something which is functionally equivalent to a password manager.
> how exactly is "this button" authenticated ?
What are you asking? How is it authenticated between the server and the client? Or how is it authenticated that the person pressing the button is the right person on the client side?
Disagree. This isn't possible with passkeys:
- logging into a service with email and brain-stored password from any device
With passkeys, your phone becomes your password, so don't break it, lose it, let it die, forget it in the car, become too old, let your kids use it, etc
> “tap this button to magically log in” method
That only works if the device you tap it on is the same device with the key, while that's not always the way for many people (sync may or may not be set up or active)
passkeys will be stored in a pass manager and they can be recovered with device pin and master pass, I think they will be exportable too
so yes, you can log in with brain stored stuff
I guess you need a device to log in? then you log in to your pass manager and you can log in to anywhere
only this way you have to remember a passcode and a master pass, not 1000 passwords and you need your master pass 5x/10 years and your passcode every other day and you log in with your device and your biometrics
passkeys have issues but what you are saying is pure shit
Thing is, most people don't understand passkeys. If you want to be secure, then you want to understand why and how you're secure; a pinky-promise that you're secure doesn't cut the mustard.
I do have some understanding of this kind of technology, having written for myself an OAuth server back in the day. I gave up on the server, because the services I wanted it for (bank, tax, medical) didn't accept OAuth, and because it was much too hard to understand.
Passkeys involves more third parties, and is even harder to understand.
I try to explain that if they’d just commit to using a password manager, they just won’t have to think about it anymore, but it’s like pulling teeth.
I’m sure one day we’ll have some sort of standard that replaces passwords (maybe it’ll be passkey) but until then I’m prepared for the continued death by a thousand cuts of password related IT.
EU citizen here. Do you... not have roaming?
Plus, you know, SMS hijacking and all that.
So to log into my bank I have to load the website on my device, enter my username / password, have it send the SMS 2FA, switch to my home SIM card, wait to receive the text message, switch back to my EU SIM card, ensure internet works, then submit the 2FA code to finally log in.
That assumes I haven't forgotten something to poke the SIM card out with. I couldn't find eSIM last time I went to Portugal.
More analyticalally: the probability_of_an_account_getting_hacked times damage is constant. More unrelated accounts you have, hack more probable, less damage on a single hack. With one password manager account, everything you have is at stake.
There is no way around it. You can't manage this risk.
People who don't use a password manager observably reuse passwords and use weak passwords. In huge quantity. People who use passwords managers do not reuse passwords or use weak passwords at anything resembling this scale.
Thefts of password vaults appear to be rare and it is much much easier to train people to use one good password for their vault, meaning that even with something like the LastPass breach, many people can be will protected.
Yes, if you are a unicorn and can happily generate and recall 100+ strong and unique passwords for your various services then a password manager reduces your security posture. But almost nobody does this.
Password managers also provide some small resistance to phishing, since they can help you notice a page that doesn't match the origin used to register a password.
Clearly this guy has never got his password sniffed before, or even heard about it.
It's always painful to see someone who doesn't understand something talking about it, and worse, badmouthing it.
And,
"Notice that all of these problems are solved by fairly simple password hygiene"
Clearly this guy has never heard about various fiascos of various password manager software.
=====
Passkey doesn't need you connected to the internet.
Google Auth too.
Actually weak password is fine, when you have 2FA. I have some accounts which has weak password, some even already in haveibeenpwned; but no problem for years because it got 2FA as well.
Password alone without 2FA is okay, as long you can ensure no malware/keylogger enter your system. Which is a risk.
Forcing your users to change their password routinely is bad policy, it motivates your users to use weak password and/or store it insecurely, and other unexpected behaviours.
SMS 2FS sucks because it can be intercepted and/or snooped - no, this is not just a theory, this happens rather routinely in my country.
Etc etc
https://www.stavros.io/posts/clearing-up-some-passkeys-misco...
To answer the article's points:
> While the tech is great, the problem is that nothing supports these new-fangled methods of authentication.
Should we never switch to anything else, then, because nothing will support it until everything does?
> Multi-devicing for authentication is a poor user experience. Even having to go click a link in your mailbox sucks.
WebAuthn doesn't require multi-devicing.
> People don't have their phone on them all the time (and some don't even have a smartphone).
WebAuthn doesn't require a phone.
> New users don't understand these methods of authentication.
New users don't understand how to safely use passwords either. If we're going with max usability, we might as well get rid of passwords and just use usernames for authentication. Otherwise, we should compare like to like, and the usability of passwords is not worth how insecure they are.
> They're generally much more complicated to implement than a basic email/password combo.
Yes, it's much easier to implement something insecure than something secure. This sentence is disingenuously omitting all the impossibility around actually making passwords secure, ie using a different password for each site, 2FA, password length restrictions, etc.
When it comes down to it, Passkeys are orders of magnitudes more secure for a small usability cost over completely insecure passwords. To say anything else is hostile to security.
my user agent should do otp on my behalf with clean, hassle free and reliable ux. my secrets should auto-rotate on a regular schedule and i should be able to force a rotation at any time in the event of a compromise. the existence of a relationship between myself and any party i wish to authenticate with, or knowledge of authentication events shall remain private between myself and that party exclusively. in the event of a catastrophic loss of control over my digital identity, i should be able to work with a partner to quickly prove my physical identity and regain access to my digital one.
However, recommendations were to use Apple's authentication methods that are not device manufacturer agnostic, download and use a password manager (complicated) or use 2FA apps.
All of these require a smartphone and are additional methods of authentication.
Overall, you need MFA and try not to use SMS MFA.
For me it works basically the same way.
But then you get all people who don’t care or are so technically inept that at first occasion will lock themselves out of password manager.
As myself and as a user I could use passwords, no problem.
As a service provider that is entirely different ball game. If I could skip sending out emails or smses it will be cheaper to have web authn, then not having to store passwords only public keys is such a great thing.
In the end if webauthn takes over as end user I will never have to see login screen ever again. I would beet to register once and then maybe rotate key once in a while.
I really hate all these other trends I keep seeing. Log ins only using Magic Links in emails, which is an ENORMOUS pain in the ass, and now I often have to log in to another service as well.
Or this weird thing sites are doing lately, where the log in page just asks for a username, then loads a second page with the password box. Like WTF is that even accomplishing besides sometimes confusing my password manager. Why do we need this weird intermediate step at all?
(not that i like it.)
Also, how many accounts and passwords people tend to have which are pets rather than cattle? Bank and email can cause major headaches and probably everyone has 1-2 more accounts which they value and would cause significant setbacks if compromised. Passwords are plenty fine.
Device secrer only methods like passkeys and anything biometric+tpm without non-pin knowledge factor if auth are cancer. Skip thid bandwagon if you can help it.
For a layperson, passkeys are difficult to understand, but provide out-of-the-box hygiene and security.
Passwords are not fine. What we need is better explanation/education of passkeys.
Why? Aren’t built-in password managers such as iCloud Keychain (which also auto-generates secure passwords) enough?
> Multi-devicing for authentication is a poor user experience. Even having to go click a link in your mailbox sucks.
Agreed. Passkeys reduce this friction quite a bit since you won’t need to multi-device if you’re already signed in to your platform account. But if you’re borrowing someone else’s computer, then yeah you need to get a key from another device that already has it. If this use case happens to you a lot, I would recommend using a USB security key to store your credentials.
> People don't have their phone on them all the time (and some don't even have a smartphone).
WebAuthn doesn’t require a phone. It only requires you to be using or have handy some device that holds your keys. It can be a laptop or a USB security key. Again, I would recommend a USB security key for people who don’t own a phone or computer. These things are cheap enough for charities to give them out in large numbers and small enough to go anywhere. Keep one on your keychain. If that’s still too much of a problem, then keep your keys in your platform account and see if you can temporarily sign in to your platform account on the device where you are a guest. Just be sure to sign out afterward.
> New users don't understand these methods of authentication.
An old dog can learn new tricks, but it takes time. We’re in a phase where most of the writing on this topic is geared towards developers. That will change. A lot of people seem to prefer native UIs to web based UIs and WebAuthn makes a large part of the sign in process native, so maybe people will find it easier. I certainly do with the implementations I’ve built, though that may be a given.
> They're generally much more complicated to implement than a basic email/password combo.
Agreed and I think this is mostly the fault of the spec. For example, some of the data the client and server have to send to each other can’t be easily serialized to JSON and for some reason, apparently no one thought that was a problem. There are some ways to do it but they are hacky and the auth libraries barely even paper over this problem.
Also, the spec wants a signature counter to be implemented to prevent replay attacks. But Apple’s implementation of Passkeys always reports 0 for the signature count, which I think may be to preserve privacy. I don’t particularly like having to store the signature count either, nor does it seem like a reliable detection method, so Apple’s approach seems ok to me. But then how do I prevent replay attacks? There’s very little information on this subject, let alone guidance on how to handle it.
There’s lots of jargon in the spec that you have to memorize and the libraries that exist today tend to embrace the same jargon.
I think a lot of these wrinkles will be ironed out in time. The momentum is clearly there and the tech has gotten to a point where you can build some really low friction sign in flows. You may bang your head against the wall dealing with some of the wrinkles I mentioned, but the end result can be great. One of my favorite features is that you can build the sign in flow in such a way where the native UI presents the accounts that are available. That means not only does the user not need to type a password, but they don’t need to type their email either. Literally no more typos possible, even for people who don’t use autofill.
I guess the point I'm trying to make here is that the problem with obesity is just amount of food consumed, not the food itself.