> 2. People don't have their phone on them all the time (and some don't even have a smartphone).
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.
I have a common name, so a ton of people think they have my email address when logging into things. I suspect this triggers 2FA much more than normal as I am constantly logged out of things and have to use 2FA to log back in. Lately I had a pretty funny series of events.
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 in a similar boat. Not so much service, but I move around internationally and change sims a lot. I dont even have a sim most of the time, I'm on wifi 99% of the time.
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.
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?
Can't you find a cheap prepaid provider that has roaming access? Since you're not going to be making calls, the balance drain should be minimial, although you still have to top up a certain amount (depends on the carrier) to keep the sim active.
I have a dumbphone. Until recently I could not care less about losing it. But I realised that since it's not PIN protected (I could but don't want to do it), losing is a security issue. People can find my phone, match my phone number to my email address using leaked data, try these credentials on different services and wait until they get a reset password SMS.
So by forcing me to add my phone number some services actually decrease the security of my account.
>I have a dumbphone. Until recently I could not care less about losing it. But I realised that since it's not PIN protected (I could but don't want to do it), losing is a security issue.
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.
> pop out the sim and if it isn't password protected (most aren't IME), they'll have full access to your phone number.
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.
While what you described is theoretically possible, I've never seen any mobile provider implement it. The reason is fairly simple: if you cared about the security of your sim, you'd set a sim pin. If you don't, you don't set a pin. Requiring reauthentication every time your IMEI is going to cause a massive increase in support calls for very little security gain.
Yes, but as I moved between countries and bought SIM cards from many carriers all carrier employees offered me to disable the pin "for convenience". Let's say your phone died, and you put it on a charger. A phone would eventually turn itself back on, but if your sim is locked you. wouldn't be able to accept incoming calls until you unlock the phone and unlock the phone. Without a sim pin once your phone turns on you become available again. People like that.
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.
Nearly every sim I've seen don't have one set by default, and I can't imagine the average smartphone user digging through their smartphone settings to add one.
Interesting... i usually buy prepaid sim cards outside of EU (due to "fuck-you" roaming prices), and every time I bought one, in multiple countries, I had to scratch off the silver "paint" to get to the random pin written on the sim card (the large plastic part, the one that you break of the mini/micro/nano sim from).
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.
>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.
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.
For some weird reason, when im travelling with wifi calling, receiving sms messages is a crap shoot. I basically dont get them if theyre sent by a gov agency, bank, etc.
I do still get them from android phones. Its weird, i have no idea why.
SMS 2FA often blacklist VOIP and similar systems to avoid abuse. Try receiving SMS 2FA at a Twilio number, for instance – it’s super unreliable. There are virtually no providers where you can reliable receive 2FA via SMS programmatically, with the exception of a handful of companies who use large banks of real SIM cards.
> If you have an android phone yourself, maybe it's not actually SMS and it's actually RCS[1]?
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.
Sure, I was just pointing out a clarification for GP since a lot of people aren’t actually aware that you can use 2FA without an internet-connected device. Maybe they already knew it, maybe not.
Unfortunately this point is a bit of FUD about Passkeys (or just off topic). Passkeys themselves don't require internet access. Syncing them across devices might require internet access in the same way that password managers might require internet access to sync across devices.
Living on a boat last year, I had a similar problem: we had internet access, but no phone service. Getting into my bank account, or any financial account, became a righteous nuisance; I had to drive inland until I found cell service, use my phone as a hotspot, attempt to log in, then wait for the SMS. Realize after getting home that there was another bill to pay? Oops, guess you're driving back into town again!
FWIW, ChatGPT asks for your number just as an "are you a human" method. It never uses it for 2FA (at least never for me), so as long as you have service the one time your signing up, you'll never get another OTP challenge.
If you don’t have a smartphone, or your phone cannot connect to a service, why is authentication a problem? If you don’t network access you lose access to the network, this isn’t exactly a surprise.
> If you don’t have a smartphone, or your phone cannot connect to a service, why is authentication a problem? If you don’t network access you lose access to the network
It might seem surprising these days, but the parent poster might have network access through means other than a phone.
The only reason I have a smartphone is because many services (especially government services, like tax and the NHS) require a mobile phone so you can receive SMS. It's like how the government used to produce documents as MS Office files; they were forcing the public to go along with their choice of software company.
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.
In rural areas you can be in an area where you have a gigabit fiber connection and no cell service at all. Wi-Fi calling being added to the main carriers has been a game changer for rural access.
Every company's customer base is going to look different. This requires research, and developer empathy and life experience cannot substitute for research.
> it seems like a dangerous crutch than a useful technology
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.
> 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 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.
What I find more annoying is the aggressive insistence of bigcorps to do everything possible with 2FA except actually just use the damn 2FA code I already have set up in my password manager. SMS, emails, pushing codes to random devices I'm logged in on, whatever.
I recently got a pair of yubikeys… they have been around about ten years already and support industry standards. Guess how many services I use support them? A smaller fraction than I’d like.
My employer had a program where you could put in a request and get a free yubikey. Turns out they basically only work with Chrome (no Firefox, no terminal-based auth), so none of my team actually ever uses theirs because it's not really more convenient.
When was that? I use a pair of cheap FIDO2 keys with both Firefox and the Linux PAM module. It's hell of a lot more convenient than typing in passwords to unlock LUKS volumes or sign in to web services, that's for sure. I use mini keys though, they barely stick out of USB ports.
I think this article misses the mark in a pretty big way.
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.
What I find increasingly annoying is third parties (i.e. those whose primary service isn't to provide authentication or MFA, specifically) trying to route me through their mobile apps for a second factor.
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 use 2FA for GitHub with KeePassXC, on my desktop. I don't have a GitHub app on my phone. You can setup a TOTP app for GitHub without their mobile app.
The argument that passwords are acceptable as long as everyone practices good "hygiene" strikes me as having many parallels with the argument that C code is memory safe as long as it is written properly.
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.
> 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.
Not really, to some extent some amount of collateral damage is necessary for a free and open society. I don't want to live in a nanny state that decides everything for me.
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?
You can always use a FIDO2.1 key as a passkey, they're not tied to the big tech. I don't even have a smartphone and have been using them on the couple of sites that support passkeys just fine.
We will also have at least one open software implementation when this gets merged:
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).
What part of Passkeys is "centralization of passwords into corporate controlled infrastructure"?
"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.
Because users who lost account because of lack of 2FA usually require attention and support resources. It’s easier to require more security than to figure out if this is a legitimate user who is trying to get access.
> they just sweep the problem under a corporate rug and ignore that people will still use them inappropriately.
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.
From a certain perspective, passkeys are a lot like using "Sign in with Google/Apple/Microsoft account"
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.
> 98% of passkeys will be stored in cloud accounts with those providers.
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.
> 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.
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.
If your passkey is issued by Google on your Android device, and Google decides to revoke your account for violating some arcane term of service, how long until you lose access to services with those passkeys? At the very least, I imagine you lose it if you get a new device?
Of course passwords are fine. What's not fine is getting billions of people to change their behavior and switch to and use a password manager (that's not chrome).
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.
Not the parent but the problem is that Chrome (sub. Firefox and Safari, these are problems with pretty much all browsers) isn't a password manager, its a password autofiller.
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.
It's a full-featured password manager, accessible via passwords.google.com . Also has great android app integration. I use it on Android, Linux, and Windows. The only thing it's missing is the marketing; I often wonder why they don't market it and crush 1password et al.
This isn't a great answer, but I've never liked Chrome password manager because I feel like a password manager is something I want to pay a company for, not a service I want to be given for free. Somehow, it being a free feature that's bundled with my browser makes me not trust it. (Again, not claiming this is a great reason not to use it)
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.
Yes, pass is 800 lines of relatively straightforward bash and I am qualified to review bash. Now, granted, it uses GnuPG and git but in those cases I think the risk of problems is minimal.
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.
Not sure if it is what the GPP is referring to, but I prefer to keep a larger gap between my browser and password manager to reduce the potential spread of difficulties if the browser falls foul of a security vulnerability. The risk of this happening is of course small, it would require significant bugs in a couple of different places, but the potential damage is high. Firefox's password manager, or those built into any other web UAs, I'd be wary of for the same reason rather than it being specifically an anti-chrome thing.
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.
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.
But MFA is not supposed to replace your password. It’s in addition to it, and if it’s implemented correctly, only on new devices.
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).
In reality, the vast majority of services ignore that principle and MFA is a never-ending daily nightmare. It feels like I can't even take a leak without the phone now.
There's absolutely no reason why you'd need a phone for most services. TOTP generators exist for every device and every platform. Some password managers even automatically copy a TOTP code after autofilling a password field.
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.
Realistically speaking, the vast majority of the security benefit of TOTP in the wild is "the user doesn't get to choose a weak password", followed by "the persistent secret isn't getting sent over the wire"; being an additional "factor" is faaaar in the distance.
I think the advantage is that users suck at picking passwords, refuse to learn how to use a password manager, so TOTP is there to make sure that even if people set Welcome2023 as their password, some credential stuffer can't log in to their remote desktop because they need an extra six digits to log in.
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.
In my opinion 2FA is one of the best use cases for a smart watch, and at least Authy supports that use case, it's so much better than to look where I put my phone...
I don't despise all inconvenient things. I don't mind carrying house keys. It's just a question of whether you value the security enough to make it worthwhile.
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.
You can have a very secure facility that only uses a "house key"-style entry flow for the user. The key will look really weird (see Medeco and Evva for examples) and the building will have some design compromises - few entry points, no openable windows, etc.
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.
MFA has some sort of calculated irritation built into it.
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.
Security is inconvenience, therefore the role of security is to find where is the limit. Because afterwards users will start to search for shortcuts, which usually makes the systems even less secure.
> 2. People don't have their phone on them all the time (and some don't even have a smartphone).
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.
“Passwords are fine” only in a theoretical world where everyone uses passwords “correctly” and securely. But in the real world people don’t, so passkeys are a much better and easier method.
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.
- 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)
you either can remember all your passwords and then you are fucked or you use a pass manager
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
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?
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
It is 100% fine to have adversaries know your public key. Asymmetric key crypto is not the same as "already hashed private keys." You can happily use a 4096 bit RSA key if 112 bits of effective security isn't enough for you.
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
fishing is another topic we did not talk about passwords vs. passkeys
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
> I'm old. What's the difference between a pass word and a pass key ?
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?
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
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 want whatever solution that my parents, wife and coworkers will actually use so I don’t have to help them.
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.
International SMS delivery is unreliable. Unreliable is not strong enough word. It more often doesn't work that it does. Or it works with enough of a delay to cause a timeout on the site where you want to login.
Where do you travel? Because I've gotten international text in dozens of countries in different continents with no problem. Delays I've seen (but also sometimes I also see them in my home country). Usually trying 1-2 times more it gets in time.
In the EU I get an EU cell plan because it's orders of magnitude cheaper than roaming from North America when travelling for a month.
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.
With a password manager you're putting all the eggs in the same basked. Why I'm I the only one who see this?
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.
You are not the only one that sees this. Everybody sees this. But we can compare things.
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.
"I guess the point I'm trying to make here is that the problem with passwords is password hygiene, not with the method itself"
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.
It doesn't sound like you actually use 2FA, it sounds like you use 1FA plus a formality-password, where the "second factor" is the only one that matters. so it's 1FA.
Can you please elaborate on SMS 2FA being intercepted or snooped?
(Disclosure: working on a product to prevent exactly that and really curious to hear about those hijacking cases.)
I used to control the passwords manually, but now I just rely on the Firefox password manager. I have it on my notebooks and in my smartphone, it syncs all the passwords, generates them and that's basically all I need. It completely abstracted the password handling away from me, and I have not types a password manually for quite some time. I hope that it's safe.
> 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.
On many Israeli sites, like insurance providers and credit cards, 2FA texts are used for authentication without a password. i.e. instead of typing in a password, you type in your phone number and then type the 6-number code you got as an SMS message to your phone. I hate it so much.
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.
Strange article I must admit. They describe common pitfalls as:
1. People don't have their phone on them all the time (some don't have a smartphone)
2. New users don't understand these methods of authentication
3. General much more complicated than a basic email/password combo
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.
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?
this is very often so the service can choose if you have a regular password or need to be redirected to an external SSO service (though i guess it's not the only case)
Why not just let everyone use their preferred method for authentication and not forcing a particular doing-it-the-right-way on people?
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.
This is also something I feel strongly about. I absolutley disdain any product or vendor that promotes "passwordless" (like bitwarden!). For typical web auth, you can't do better than passphrase+FIDO2.
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.
I just "lost access" to passkeys.io while trying out passkeys. My phones Bluetooth was switched off, and by the time my phone created and saved a passkey, it timed out on the computer. So now I can't login with that passkey and it only fails. Seems like I'm locked out now...
They missed the point that users with passwords are often extremely prone to phishing; especially with certain popular MiTM frameworks. We have the technology available to combat that, so, please yes, let’s move away from open sesame authentication.
For a layperson, the passwords are easy to understand and provide enough ways to shoot themselves in the foot. Unless you are an expert, password hygiene can rarely be accomplished.
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.
Support for passwordless flows via WebAuth was only added to browsers very recently. And it was only with the introduction of Passkeys that the user experience became good enough for regular people to use. Now the keys will auto-sync between devices and can be shared with other people via Bluetooth, etc. It’s too early to say it won’t be well understood or adopted.
> 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 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.