[HN Gopher] Microsoft Confirms Password Deletion for 1B Users
___________________________________________________________________
Microsoft Confirms Password Deletion for 1B Users
Author : elorant
Score : 171 points
Date : 2024-12-14 00:18 UTC (3 days ago)
(HTM) web link (www.forbes.com)
(TXT) w3m dump (www.forbes.com)
| atonse wrote:
| I'm all for alternatives to passwords but what is the pathway for
| "I lost passkey"
|
| Is it sending a reset to a recovery email?
| zsjkadj wrote:
| multiple passkeys
| vbezhenar wrote:
| It is outside of passkey scope. Most services will use email to
| recover access.
| nottorp wrote:
| > It is outside of passkey scope.
|
| Yeah right, pass along responsability to someone else. And
| you wonder why people don't trust this "security" solution.
| vbezhenar wrote:
| There's no reason not to trust it. It's strictly better
| than passwords in almost every regard. Of course if you
| manage your passwords well, you don't get more security
| with passkeys, because your account is already safe enough.
| But for someone, who used to write his universal
| "Johny1987" password on a sticker at his display, passkey
| provides security and usability benefits.
|
| Passkey is just not supposed to solve all the problems in
| the world. It's supposed to replace login and password and
| that's about it. Authentication.
| nottorp wrote:
| That would be fine if it didn't introduce device
| dependency and vendor lock in.
|
| How do I get my keys out of Apple's wallet again? Or out
| of a Yubikey for that matter.
|
| They are no longer under my control and I depend on
| Apple's or Yubikey's benevolence to access my services.
| bigfatkitten wrote:
| > Or out of a Yubikey for that matter.
|
| You don't, and neither does an adversary. That is
| literally the whole point of paying $50 for a Yubikey.
| nottorp wrote:
| So I need to pay for the privilege of having a single
| point of failure for my credentials :)
|
| Oh no I forgot, I could pay even more to have backups.
| Scion9066 wrote:
| Basically the same as if you had lost a physical key:
|
| You either have an extra set up or you work around the problem
| through some kind of recovery method.
| AstroJetson wrote:
| If I install all my private-passkeys onto my phone, then I have a
| new problem of Lost, Stolen, Broken to deal with. I'm device
| agnostic, I want to get to my account from my phone, tablet,
| laptop, desktop, all I'm doing is spreading the exposure out by
| needing to install passkeys everywhere.
| jwrallie wrote:
| Microsoft will probably tell you that the Microsoft
| Authenticator supports syncing, so you should set it up on a
| backup device.
|
| This has several problems though, one of them being that they
| assume you have at least two mobile devices (let's say a phone
| and a tablet) and another that they assume the OS you run on
| both your devices is the same. They do not support migrating
| you passwords between Android and iOS for example!
| ashleyn wrote:
| I do not and never will trust cloud storage of credentials.
| WorldMaker wrote:
| Microsoft's interesting approach here with Authenticator is
| that they don't expect you to trust one cloud with all your
| credentials, they are hoping that you can trust two clouds
| with partial information. They've (allegedly) got some
| variant of Shamir's Sharing where some of the data is
| encrypted in OneDrive and some of it is encrypted in iCloud
| or Google Drive depending on which phone you use. That's
| (supposed to be) why there is that "phone-type lock-in" on
| the automatic backups/transfers because the cloud with the
| most phone-native/device-specific encryption is phone-
| vendor dependent today.
| UltraSane wrote:
| Do you trust VPNs? Because they are the same idea with a
| slight twist. VPNs encrypt data before it leaves your
| computer and decrypts it when it arrives at the
| destination.
|
| 1Password and the like encrypt data before it leaves your
| computer, stores it for however long you want, and then
| decrypts it when it the data is copied to your computer.
| recursive wrote:
| VPNs use (I think) some kind of synchronous key-exchange
| handshake. That doesn't work with storage part in the
| middle.
| FireBeyond wrote:
| I love that the "big guys" get to support syncing passkeys
| between devices... but others don't (wasn't it KeePas who had
| issues where they were threatened by being blocked from
| supporting that - https://github.com/keepassxreboot/keepassxc
| /issues/10407#iss... )
| eikenberry wrote:
| Nice how he whipped out the attestation threat when
| contradicted. Shows their authoritarian leanings.
| arielcostas wrote:
| I mean, same with passwords, right? If you enter your password
| on a compromised device or you forget it, you are screwed.
| Which is what password managers (or passkey managers, or
| perhaps we could use a new term like "credential managers")
| help you with. Syncing, preventing unauthorised access (for
| example requiring your biometrics, main password or similar),
| backing up...
| luismedel wrote:
| Honest question: Can I have a paper backup of passkeys? How
| can I pass them to tech-illiterate relatives?
| dboreham wrote:
| No and you can't. These are features.
| UltraSane wrote:
| No and that is actually a key advantage that makes them
| almost impossible to be stolen or phished.
| oefrha wrote:
| You can write down your password anywhere and copy it to any
| other piece of paper at any time. You don't need certain
| brands of paper blessed by a consortium, or have restrictions
| even when copying to a blessed brand of paper.
| growse wrote:
| The only reason you care about copying your password is
| because it's usually (always?) the _only_ credentials you
| have for a service.
|
| This isn't true of webauthn/passkeys. The number of use
| cases where you need to "make a copy of " or "backup" your
| passkeys is _zero_. I get that some providers let you do
| this for some level of convenience, but you can opt out of
| this and just enrol multiple distinct credentials with each
| service.
| philjohn wrote:
| Another option is to use a password manager that supports
| passkeys, such as BitWarden. You can even host it locally,
| behind a VPN, if you don't trust the threat modelling of their
| hosted version.
|
| Then, it's a case of installing BitWarden on any devices you
| want to use to login, protected with a strong password and 2FA.
| TheSpiceIsLife wrote:
| I don't understand the benefit of using passkeys in a
| password manager.
|
| If the password manager is unlocked, I get logged in
| automatically anyways.
| ahofmann wrote:
| 1. Passkeys are unique, so no more password stuffing
| attacks.
|
| 2. Passkeys can't be to short, in contrast to passwords
|
| Passkeys essentially remove almost all risks for websites
| and moves them to the user (lost passkey, attacks on their
| password managers). It is not perfect, but it removes a lot
| of problems that we have right now (like more than a
| billion leaked passwords in the wild)
| simfree wrote:
| So it adds no value over the long, randomly generated
| passwords from a password manager besides making a new
| standard and giving Microsoft a reason to push a new dark
| pattern on users to force higher uptake rates of this
| new, bespoke standard with limited support?
| Scion9066 wrote:
| It's a standard supported by multiple parties, not just
| Microsoft, including multiple open source password
| managers.
|
| And it does provide some benefits: phishing protection
| (no shared secret that can be intercepted or given to the
| wrong party) and the service does not need to store as
| much sensitive information (don't need password hashes
| that could be leaked and cracked, just a public key).
| ndriscoll wrote:
| Passwords are also a standard supported by pretty much
| everyone, and password managers (including those built
| into browsers) already generate long, unique, phishing
| resistant (it only prompts on the matching domain)
| passwords.
|
| The main difference I see with passkeys from a usability
| standpoint is that Firefox doesn't have built-in support
| for a software implementation, making them literally
| unusable for me.
| TheNewsIsHere wrote:
| Firefox does support passkeys but their native
| implementation is behind a feature flag. Beyond that
| Firefox add-ons (such as those for password managers) can
| enable support for their own purposes.
|
| For example 1Password can be used for passkeys in
| Firefox.
| ndriscoll wrote:
| I can't find that option's documentation. Do you have a
| link? The only documentation I've seen indicates that
| they only support hardware devices, and I don't own one.
| reginald78 wrote:
| Don't forgot the anti-features of:
|
| No ability to export your credentials.*
|
| Device attestation to allow blocking "undesirable"
| devices from authenticating and lock in purposes.
|
| *keypass was working on an export feature and there were
| already threats to use the attestation club to ban them
| from the landscape for not falling in line
|
| https://github.com/keepassxreboot/keepassxc/issues/10407#
| iss...
| UltraSane wrote:
| creds that can't be exported can't be stolen. It is a
| tricky tradeoff.
| calamity_elf wrote:
| my credentials aren't mine if I can't securely back them
| up and secure them in a platform independent way.
|
| That attack on KeepassXC is despicable.
| jonpurdy wrote:
| I found this out in October when trying to figure out
| this complaint.
|
| timcappalli from FIDO Alliance mentioned in that above
| thread that plain text exports shouldn't be allowed, and
| that password managers/providers should be blocked if
| they implement plain text export.
|
| Since that thread, there's a new spec that allows users
| to securely migrate passkeys from one provider to
| another, but no way to export to plain text (for debug
| purposes, or if there's a bug in the export/import and
| you need to troubleshoot, etc).
|
| For me, threatening to block providers for implementing a
| feature that I desire is a great way for me to lose all
| interest in passkeys completely. I don't trust FIDO
| Alliance to make the right call nor do I trust big tech
| companies to produce bug-free software.
| vel0city wrote:
| When you log into a site with a password, you're needing
| to transmit your actual password over the wire. Sure,
| you'll hopefully have encryption when sending that
| credential over, but in the end you'll be exchanging your
| actual password with some remote service. That remote
| service might be misconfigured, it might be misdesigned,
| it might be under attacker control. Now they have your
| whole credential.
|
| A passkey doesn't transmit your actual, full, repeatable
| credential over the wire. It's a challenge-response
| protocol, so only that one authenticated session would be
| intercepted. Kill all questionable sessions and you're
| good, they're not reusing it.
| jon-wood wrote:
| Passkeys include a key that the website you're logging in
| to holds, if a site can't present that key then the
| passkey doesn't work, meaning phishing attacks no longer
| work because 0utlook.com doesn't have the key that
| outlook.com holds.
| UltraSane wrote:
| Passkeys are tied to a specific website and can only be
| used for signing in on the website they were created for.
| Ajedi32 wrote:
| > randomly generated passwords from a password manager
|
| are impossible to enforce. If you present users with
| password field, a sizable percentage of them will just
| manually type in the same weak, compromised password that
| they've used on every other site they've ever created an
| account on in their life. Passkeys are much harder to
| misuse. That's where 99% of their value is.
|
| Yes there are also other advantages, like the fact that
| passkeys use public key cryptography, but those are tiny
| compared to the human factors improvements.
| hulitu wrote:
| > Passkeys are unique, so no more password stuffing
| attacks.
|
| Just like passwords. What is the difference ?
|
| > Passkeys can't be to short, in contrast to passwords
|
| So a "long password" is a "passkey" ?
| TheNewsIsHere wrote:
| >> Passkeys are unique, so no more password stuffing
| attacks.
|
| > Just like passwords. What is the difference ?
|
| >> Passkeys can't be to short, in contrast to passwords
|
| > So a "long password" is a "passkey" ?
|
| Of course not.
|
| Passkeys are effectively just key pairs defined by a FIDO
| standard. It's much more productive to think of passkeys
| as mutual certificate authentication designed for use by
| the masses.
|
| If you've ever used a Yubikey for primary authentication,
| you've already used a passkey.
| skydhash wrote:
| The issue is tying it to a device that can be easily
| lost. Yubikeys can be easily hidden and are not thief
| magnets.
| TheNewsIsHere wrote:
| Yep, you ideally don't have your only key/copy of the key
| on any one device.
|
| That's why the mainstream implementations are synced. Or
| why you have an extra Yubikey.
| ahofmann wrote:
| I really don't know how you're able to come up with the
| idea, that passwords are unique. They are in no aspect
| whatsoever unique. You as a user can try to use
| passwords, that are unique to you. That doesn't (can't
| and shouldn't) mean, that those passwords are unique
| against the database of a website, or other services.
| keybored wrote:
| > 1. Passkeys are unique, so no more password stuffing
| attacks.
|
| Not really relevant for password manager users.
|
| > 2. Passkeys can't be to short, in contrast to passwords
|
| Not really relevant for password manager users.
| Ajedi32 wrote:
| ~90% of people who are presented with a password input
| field are not and never will be "password manager users".
| 100% of people presented with a passkey prompt are,
| because the very nature of passkeys is that they're
| stored in what is effectively a password manager.
| keybored wrote:
| > > I don't understand the benefit of using passkeys in a
| password manager.
|
| Echoed in his ears.
| Ajedi32 wrote:
| Ah, I think I misunderstood that comment. From a global
| perspective "the benefit" compared to using passwords in
| a password manager is indeed exactly what I said, but I
| guess that user was asking more about the personal
| benefit on an individual level.
|
| From that perspective it just makes the UX slightly
| smoother and makes it impossible for the site to screw up
| and leak your plaintext creds. Other than that yeah
| there's not a big difference compared to using an
| autofilled, unique, randomly generated password. Which is
| good, because eventually sites are going to start phasing
| out that latter option for the exact reasons I outlined
| in my previous comment.
| growse wrote:
| Ah yes, the good old "only an issue for people who are
| holding it wrong" argument.
|
| The thing about good design is that it makes it
| impossible to "hold it wrong".
| keybored wrote:
| Ah yes the good old reply that failed to notice that this
| was in reply to the use of password managers
| specifically.
| growse wrote:
| Your argument is that password managers are fine if you
| use them correctly.
|
| That's a big "if".
| keybored wrote:
| It is at most a medium if.
| stetrain wrote:
| With a password manager storing unique passwords, your
| password is still being sent over the network to that
| website each time you log in.
|
| With a password manager storing passkeys, your private
| passkey is not transmitted as part of the website request.
| It can't be intercepted or accidentally/negligently stored
| in plaintext in a database or server logs.
|
| You still have to trust the secure syncing of your
| passkeys, just like you do with passwords, but there are
| still fewer threat vectors than with passwords.
| maeil wrote:
| This covers a negligible percentage of all hacked
| accounts and is at best a tiny part of what passkeys are
| supposed to solve.
| w0m wrote:
| same argument/logic works to justify not wearing seat
| belts or hell, not outlawing murder. "Won't stop/save
| everyone so not worth doing".
| acdha wrote:
| It's more than you think: if I can convince you to type
| in your Google password at g00gl3.com I can turn around
| and use that password for the real server. Passkeys block
| that attack.
| happymellon wrote:
| So they couldn't convince everyone to give up their
| privacy and use Facebook or Google to track our logins to
| other websites via "Login With", and this is a new way?
| acdha wrote:
| If by new you mean a completely different mechanism which
| does not share the privacy considerations of a single
| sign on service, yes. If you care about privacy, passkeys
| are a much better option.
| stetrain wrote:
| What's the privacy issue if I use a third-party passkey
| manager like Bitwarden or 1Password and the passkeys are
| unique for each website?
| TheSpiceIsLife wrote:
| Makes sense now. I shoulda read the document, but
| conversation is funner.
| nonrandomstring wrote:
| > a new problem
|
| Yes, the problem exists in multiple "places" and all schemes
| are different balances.
|
| There are many different kinds of "security". Each suits
| different needs, or addresses different threats. Not all are
| based upon "identity" as a central concept. Not all are based
| on secrets. For those that are, changing your secret from
| something you know to something you own merely shifts a locus
| of trust and mode of use.
|
| Passkeys (and ssh keys with passphrase) are a good solution in
| some cases, where you use multiple end points which may be
| compromised. But they are no better (and less flexible) than
| challenge response and one time passwords and other elaborate
| password schemes that are a superior access control secret in
| other situations [0].
|
| The problem is that most people don't understand the quite
| subtle interplay of factors. This is one area of cybersecurity
| education I'm spending more time on because regulations are
| going to place more emphasis on making good security choices
| (and not just accepting vendor defaults).
|
| Microsoft unilaterally deciding it thinks it knows what is
| "best " for you accords with its clumsy patrician over-reach,
| and cover for a pitiful security record in its products.
|
| Perhaps one of the most important meta-security factors is that
| you be able to select products that allow _you_ to choose your
| security parameters and how they interact as your situation and
| access habits change. But that responsibility requires
| understanding.
|
| [0] https://cybershow.uk/blog/posts/secrets
| vdelitz wrote:
| you can use a password manager to store your private-passkeys,
| so as long as you have access to it, you don't need to worry
| about lost devices
| 2Gkashmiri wrote:
| I dont get it. How is changing
|
| What you know then what you have then what you are
|
| To passkeys any better ? Sure you cant hack them but what happens
| with losing your phone ?
| arielcostas wrote:
| They are supposed to be synced, for example by Google's
| Password Manager, iCloud, or whatever tool you use (bitwarden,
| 1Password...)
| perryizgr8 wrote:
| Can they be synced to my paper notebook in my desk drawer?
| lioeters wrote:
| Can they be synced to my own server, or my local machine
| like laptop or PC?
| vbezhenar wrote:
| You can self host bitwarden.
| vbezhenar wrote:
| Technically you can, but most software will make it
| impossible or hard. It is not supposed to leave the secure
| storage.
| hulitu wrote:
| > It is not supposed to leave the secure storage.
|
| How do they authenticate if they are not leaving the
| secure storage ? Through telepatic transmission ?
| jsnell wrote:
| Obviously via public key cryptography. It seems that you
| lack a sufficient understanding on this subject to back
| up the repeated snarky comments.
| r2_pilot wrote:
| Then how are untrained users supposed to trust passkeys
| if they can't understand how they're secured when a third
| party is holding them?
| vel0city wrote:
| How are untrained users supposed to trust passwords if
| they don't understand the differences between unsalted
| SHA1 versus PBKDF2 versus bcrypt and probably don't know
| what practices their third party is doing to properly
| hash the password?
| skydhash wrote:
| Explaining password managers like the browsers' or
| 1password is easier than explaining passkeys. At least
| with password managers, you can export the whole database
| when switching platforms.
| endigma wrote:
| This thread is crazy, it reads like 2 people arguing but
| there are actually zero repeat commenters, like some sort
| of debate conga line
| TheNewsIsHere wrote:
| I agree. People ask the same questions about password
| managers just storing passwords.
|
| One of major failures of the passkey marketing is that
| the FIDO Alliance left it at:
|
| 1) Vendors marketing passkeys as this brand new thing for
| their customers;
|
| 2) Anyone technical needing to already know that passkeys
| weren't this brand new vendor specific thing, and reading
| the standards documents.
|
| Passkeys are essentially just a marketing name for FIDO2
| credentials with a focus on particular kinds of
| implementation. But FIDO didn't bother to handle
| communications to technical folks outside the
| authentication space, and they've failed to do so
| effectively beyond that area.
| reginald78 wrote:
| By using the built in device attestation feature to
| blackball any passkey providers that allow that,
| apparently:
|
| https://github.com/keepassxreboot/keepassxc/issues/10407#
| iss...
|
| Now imagine a whitelist of acceptable providers.
| Suddenly, you don't even own your credentials anymore.
| hedora wrote:
| I can't say I'll care all that much when they delete my MS
| account password, but LinkedIn and GitHub are going to be more
| painful.
| dp-hackernews wrote:
| adversary-in-the-middle == MITM
| ghusto wrote:
| I was reading that and thought "Wait, don't we already have a
| term for this?".
| skydhash wrote:
| If they use MITM, that will include themselves. A password
| manager doesn't try to log in for you. But most passkeys
| managers are MITM. At least we can audit OpenSSL code, and we
| don't have to care about our public keys.
| theyknowitsxmas wrote:
| Border security and thief's wet dream.
| jeisc wrote:
| the only secure device is turned off
| jsnell wrote:
| Blogspam for https://www.microsoft.com/en-
| us/security/blog/2024/12/12/con...
|
| The title is inaccurate. Microsoft doesn't actually "confirm
| password deletion for 1B users". They confirm it for millions.
| They have a concept of a plan for getting >billion people on
| passkeys as an auth factor, and will be able to get some of them
| to go passkey-only.
| mellow-lake-day wrote:
| > Our experiments show that people love passkeys and are ready
| for them.
|
| Really? I somehow doubt that.
|
| > If they don't enroll when you first ask, don't assume their
| decision is permanent
|
| No is supposed to mean no
| aeim wrote:
| Er, isn't it a bit manipulative to equate changing a software
| system with the more serious uses of that phrase?
| e3bc54b2 wrote:
| It is manipulative to constantly harass users with
| 'prompts' until they break down and give up.
| hulitu wrote:
| > It is manipulative to constantly harass users with
| 'prompts' until they break down and give up.
|
| "If it works for Google, it shall also work for us".
| Regards, Microsoft /s
| result2vino wrote:
| Did you want to actually answer the question? Or does
| your reply perhaps belong somewhere else?
| result2vino wrote:
| Yeah, well, the privileged nerds of HN, scrounging around
| for something to complain about, will often misappropriate
| language used by people with actual problems to complain
| about... _checks notes_ ...needing to use a passkey after
| complaining for decades about how bad passwords are.
| Nifty3929 wrote:
| I never took that phrase to be reserved for sexual
| situations - in fact my mom used to use it with me all the
| time over toys, ice cream, etc. "Come ON, PLEEEASE?!" "No
| means no..."
|
| I think it's a phrase that is often applied in sexual
| situations, but not intended to be exclusive to them.
| paweladamczuk wrote:
| > No is supposed to mean no
|
| One counterargument is that nobody forces you to use their
| services.
|
| I think the root problem is that nobody produces personal
| hardware over which the average person could conveivably
| assume full control. I'm not even sure it's possible, given
| how advanced the computer technology is.
| majewsky wrote:
| > One counterargument is that nobody forces you to use
| their services.
|
| Not specifically Microsoft, but more and more government
| services are accessible only through apps that are only
| offered through Apple's App Store or Google's Play Store.
| (Either directly, or because a generically eID app is
| used.) So in this case, I am absolutely forced to agree to
| either Apple's or Google's ToS to interact with my
| government.
| mistrial9 wrote:
| no you are seeing the easy ramp access pushed on you..
| government is unique (in the USA) that it is required by
| law to be accessible to citizens including disability
| etc.. you can do almost anything using some
| (terrible,slow,error filled) paper process IMHO .. and
| there is a systemic reason why this will remain true,
| even as they push "one phone,one person" dystopia
| hahn-kev wrote:
| There are other countries
| eikenberry wrote:
| I'm assuming those applications are hardcoded to use
| either Apple or Google (respectively) as the passkey
| service provider? IE. that the problem is that they don't
| allow you to configure your own 3rd party passkey
| service?
| nijave wrote:
| I don't mind passkeys and Bitwarden will take care of them
| for me. I enrolled most important stuff with hardware tokens
| and it's the same services now offering passkeys so I haven't
| migrated but probably eventually will.
|
| Microsoft only started supporting webauthn in the last couple
| years so it's surprising they're actually rolling out
| passkeys. Maybe they finally gave up on smart cards
| eikenberry wrote:
| Do you run your own Bitwarden server? If so are there any
| issues you've come across?
| Nifty3929 wrote:
| I just had a great, novel business idea. I'm going to start
| writing brief, ad-laden, content-free articles all about
| someone else's blog post. Glad I thought of that before anyone
| else did. Please don't steal my idea.
| porridgeraisin wrote:
| > And once that's done, the data suggests there will be no
| turning back:
|
| > Users are three times more successful signing in with passkeys
| than with passwords (98% versus 32%).
|
| > 99% of users who start the passkey registration flow complete
| it."
|
| I suspect this is because primarily tech oriented folks use
| passkeys today, and they are fairly unlikely to have trouble
| logging in with any method.
| noname120 wrote:
| Passkeys are already standard, enabled by default in all the
| popular web browsers, and thus already widely used by non-
| technical people (path of least resistance).
| maeil wrote:
| Hilariously that 32% may well include all the bots doing
| stuffing attacks.
| grraaaaahhh wrote:
| Also probably includes all the times my company has made me
| change my password. It always takes a good week before I
| remember that my old password isn't the one anymore.
| acdha wrote:
| It's because it's easier. Here's what an Apple user experiences
| for creating an account or signing in:
|
| 1. Tap the login with Face ID button
|
| 2. Tap to approve it
|
| It's even faster than using a password manager without MFA but
| safer than password+MFA, and you aren't spending any time
| goofing around with some poser's password complexity policy or
| rotating your password when their servers are breached.
| thousand_nights wrote:
| for real, it's so much better i've started using it
| everywhere, to the point where if a service asks me for a
| password i get really annoyed.
|
| no i don't remember this random string i typed in months ago
| and no i don't want to have to type in the password to unlock
| my password manager for the 82349th time
|
| this whole thread is perplexing, a forum full of tech people
| bitching about something that's more secure and more
| convenient
| nottorp wrote:
| ... until you drop your phone in the toilet, that is. Then
| be prepared to spend weeks resetting passkeys.
| acdha wrote:
| Most phones are waterproof and if your toilet holds your
| phone, laptops/desktops, and recovery keys it'll also
| take your password vault because it's an actually a black
| hole.
| brutal_chaos_ wrote:
| I currently have moat passwords synced with firerox. If I
| lose or break a device currently, I can restore from
| another, synced, device. If while using passkeys I lose
| or break my device, then what?
| coldpie wrote:
| > a forum full of tech people bitching about something
| that's more secure and more convenient
|
| I don't trust a cloud vendor to own my entire digital life,
| and I don't want to have to stand up and maintain my own
| super complex self-hosted passkey service. Passwords are
| easy, just stuff them in an encrypted text file. I have no
| idea how to self-manage passkeys.
| int_19h wrote:
| With iOS, at least, you just backup your phone (locally,
| no need for iCloud).
| coldpie wrote:
| That still means I have to depend on Apple to get access
| to my services, no?
| sahmeepee wrote:
| I've got to admit I found that 32% claim staggering. Does
| anyone know the source of that and what exactly was measured?
| lausbub wrote:
| What are passkeys?
| badgersnake wrote:
| Another way for Google to collect your credentials.
| ghjfrdghibt wrote:
| And Microsoft, as per the case here. Or Apple.
| maeil wrote:
| Moreso another way to promote vendor lockin and planned
| obsolence.
| whstl wrote:
| They're an authentication method that uses public/private keys
| instead of passwords. In websites the standard name is called
| WebAuthn.
|
| This is similar to SSH or git operates when you disable
| passwords and use keys in ~/.ssh, for example.
|
| You can store the private keys in YubiKeys or in password
| managers.
| stonemetal12 wrote:
| It is public key cryptography. You give websites your public
| key, and keep your private key hidden. When you sign in to a
| website, they send you a nonce. You then digitally sign the
| nonce with your private key. They verify that the signature was
| signed with your private key, allowing you to log in.
|
| There is no private info (aka a password) going out in public
| so you don't have to trust anyone to keep your password secret.
|
| It greatly reduces the attack surface of logging in, but the
| attack surface is moved to the weakest part of the system, aka
| the user.
| Tistron wrote:
| so OTP with the seeds backed up somewhere, and then passkeys on
| the devices I use often?
|
| Seems like this will also be difficult for a lot of non-technical
| ppl. Though I guess not much worse than forgotten passwords?
|
| In Scandinavia we have authenticators tied to the banking system
| (MitID in dk and BankID in sv), where if you lose it, you can get
| it renewed by going to your bank, or you can have a special
| hardware device at home that helps you renew it. Does this exist
| other places? These are used on more and more sites around here,
| where your real identity is important (everything utilities,
| banking, insurance, banking etc).
| kazinator wrote:
| So Microsoft blocks password attacks. A blocked password attack
| will never be successful. And they have to block a measly 7,000
| of such attacks per second across the entire organization.
|
| Wow ... how _not_ to convince me that passwords are a problem.
| hyeonwho4 wrote:
| I wonder how the internal metrics even define "password
| attacks". I have a 15 year old Skype account (with a long
| password) which I lost access to because Microsoft suddenly
| started requesting verification, insisting on 2FA via SMS to a
| 10-year-old phone number. Are all ten of my attempted logins
| counted in that statistic?
| avhception wrote:
| I'm really skeptical about passkeys. This blog post talks about
| it in detail:
|
| https://fy.blackhats.net.au/blog/2024-04-26-passkeys-a-shatt...
|
| Also discussed on HN at the time:
| https://news.ycombinator.com/item?id=40165998
|
| I think I'm fine with my uf2 / webauthn devices as second factor,
| thanks.
|
| (Edit: to be clear, I'm not the author of said blog post)
| growse wrote:
| Passkeys _are_ webauthn credentials.
| fbnlsr wrote:
| The problem with passkey is that it's obscure for the common
| folk.
|
| I'm a developer, yet for some odd reason I'm having a hard time
| understanding passkeys. Are they synced between devices? Do I
| need to set up a passkey per device? What happens if I have a
| single passkey on my phone and it gets lost? Do I lose access to
| that service?
|
| So many questions that need a clear and concise answer.
| vbezhenar wrote:
| Most implementations sync passkeys to the respective clouds.
| hulitu wrote:
| > Most implementations sync passkeys to the respective
| clouds.
|
| So, in the end, the old Microsoft mantra: "Your security is
| very important for us". Besides Microsoft, NSA, CIA, the five
| eyes and friends, no one has access to your passkey, this
| means is secure.
| acdha wrote:
| No. If you read the documentation, they only synchronize
| encrypted data.
| ghusto wrote:
| Do the keys need passwords to work, or is the key itself
| sufficient? i.e. Is it like an SSH key without or with a
| password?
| TheNewsIsHere wrote:
| The key itself, but the standard explicitly supports
| platforms, browsers, or password managers handling
| authentication to permit key use.
|
| For example you can have a passkey where the private key is
| on a security token protected with a PIN or biometry.
|
| You can have a private key live in a secure element on an
| endpoint too.
|
| You could make a browser plugin that requires no auth
| whatsoever if you wished.
| WorldMaker wrote:
| It depends on who is running your keys for you. Most of the
| vendors (Apple, Google, Microsoft) are using device-
| specific (hardware) keys to unlock the passkeys, which
| generally means that transitively you've first logged in
| with Face ID, Touch ID, Android Gesture, Windows Hello, PIN
| or one of the other names or brand names for "device-
| specific pass code or biometric" that unlocks your device's
| hardware security enclave.
|
| In your analogy terms it is akin to an SSH key stored on a
| hardware device like a Yubikey that you have to "push the
| button" to unlock. It is more secure than just an SSH key
| without a password, but depending on a lot of factors,
| including your personal threat model, may be more or less
| secure than an SSH key with a strong password. (You'd
| assume the Yubikey's unexportable hardware key is a lot
| stronger to break than any password, so it is potentially
| far more secure from brute force attacks, especially remote
| attacks with no physical access to try to export an
| unexportable key. It's reliant on physical device security
| so it is far more weak to "in the room"/"over the shoulder"
| attacks. At the end of the day most people's threat model
| is somewhere in the middle of the two extremes.)
|
| Of course if you decide to use a password manager like
| 1Password or BitWarden those passkeys are going to be
| locked behind your "master vault password" in a similar way
| to your other passwords.
| criddell wrote:
| Is there a fallback for when the respective cloud services
| are unavailable?
| crazygringo wrote:
| How do I log into that cloud account? Since I can't do it
| recursively with a passkey stored in it, can I?
|
| And what if that cloud account decides to cut off my access?
| growse wrote:
| Buy a yubikey. Use a password manager that supports
| passkeys. Enroll multiple credentials with your cloud
| account.
| crazygringo wrote:
| This is sounding more and more complicated. I don't want
| a Yubikey. How does a password manager help my cloud
| account? What does enrolling multiple credentials even
| mean?
| growse wrote:
| > How does a password manager help my cloud account?
|
| It's an alternative place to store webauthn credentials,
| if you're worried about being locked out.
|
| > What does enrolling multiple credentials even mean?
|
| You register multiple passskeys for your account on a
| service. So if you lose access to one (because you
| yoinked your phone into orbit), you can use the other
| one.
|
| It's as complicated as you want to make it.
| Pooge wrote:
| > Use a password manager that supports passkeys
|
| If the user is, what's the point of having passkeys? One
| using a password manager has (strong) passwords generated
| for them...
|
| First time I'm hearing about removing passwords and it
| sounds like they're implementing an even worse idea.
| growse wrote:
| Password managers don't stop you pasting that password
| into any random textfield on any website.
| drawfloat wrote:
| Until they are successfully explaining how to use these in a way
| that 70 year olds on eBay can understand, this should not be
| forced on users.
| josteink wrote:
| <<Activate login via FaceID>>. <<OK>>.
|
| Congratulations. You have a passkey.
|
| Was that easy enough?
| jedberg wrote:
| What happens when they lose or break the phone, or switch
| phones, which my parents do every two or so years?
| jf wrote:
| If they have a Google or Apple account on their Android or
| iOS device, then nothing happens.
| jedberg wrote:
| I mean in the interim. How do they get into their email
| to find their support contract to get another phone if
| they can't get into email without their phone?
| jf wrote:
| For Apple at least, you walk into an Apple Store, buy a
| new phone, and have them help you log into it again.
| jedberg wrote:
| What if you're traveling and there is no Apple Store
| nearby? And now you can't log into your email to get your
| travel itinerary or your transportation receipt?
|
| The greater point is not the specific edge cases, it's
| that they haven't been worked through. Even a
| sophisticated user like myself doesn't want to use
| passkeys exclusively yet because of this very reason. I'm
| not confident that I won't get completely locked out when
| it's absolutely critical that I get in.
| bongodongobob wrote:
| Except if you switch phone numbers and get a new phone.
| My iCloud email address is permanently fucked because I
| set up an iCloud account years ago with a different phone
| number. Since I no longer have the number or another
| Apple device synced to that iCloud account, I'm
| permanently locked out forever.
| Nathanba wrote:
| But don't you also get into that account via your
| passkey? How do you know that the passkey you are using
| to get into the Google/Apple account isn't the same one
| that will be lost if you lose your phone? I've actually
| implemented passkeys on my website and I still don't use
| passkeys for e.g my own Google account because I don't
| trust it.
| vel0city wrote:
| I actually recently unexpectedly broke my phone. Getting
| back into my Google account protected by passkeys was
| pretty simple though, I just logged in to my new phone
| with a passkey stored on another device. Which is fine,
| because I've got several different devices with passkeys
| on them.
|
| Same thing with logging into my mail provider which I use
| passkeys for.
|
| A few accounts I did have to go find a backup passphrase
| for, but none of those accounts are the kind of accounts
| I'd normally be trying to get into while on vacation or
| something.
|
| I don't travel very far or very long without a couple of
| different authenticators. If its farther than a bus fare
| and I'll be gone for a while, I'll probably have at least
| two, maybe three authenticators on me. For example, my
| phone, my laptop, and a yubikey. Its only a few dollars
| for the public transit around me, so if my car explodes
| on the other side of town with my bag containing my keys
| and my laptop in it and I had to jump out into the river
| to avoid the explosion and debris and it broke my phone
| I'll still be fine to get home with a few dollar bills in
| my pocket. Or hopefully those other physical security
| tokens commonly called credit cards will also still work.
| And there I'll probably have my desktop at home and
| another yubikey. But honestly that kind of thing doesn't
| happen to me _too often_ so I 'm not too worried.
| Nathanba wrote:
| All you said is that it worked for you, you even
| emphasize that your usecase was different because you
| have several devices. This doesn't relate to my question.
| vel0city wrote:
| > your usecase was different because you have several
| devices
|
| So we just normalize having multiple devices, and
| suddenly my use case is the same as everyone else's.
|
| Its not like I'm talking about everyone having a dozen
| $1,000 devices. Several of my authenticators were like
| $20-30 and have lasted over a decade even getting thrown
| in the washing machine and getting left in the rain and
| dropped in the pool. One was on my keys when I was daily
| driving a motorcycle in a rainy season and still works a
| decade later.
|
| People don't find it weird to have two car keys and those
| things often cost hundreds of dollars these days to be
| replaced.
| WorldMaker wrote:
| Ironically I've seen technical users far more confused by
| passkeys than 70 year olds on eBay. 70 years olds on eBay don't
| ask how the "Use Apple Face ID to Login to eBay" works and how
| secure it is, they just just generally trust Apple and eBay and
| just do it and it generally just works. It's the technical
| users that want to know all the details of passkeys down to
| minutia and have too many devices with syncing problems because
| at least one machine is a Linux machine with no hardware
| security enclave but "that's fine" because it is locked down to
| no real "cloud" access but still needs to login to eBay in an
| ancient Firefox fork that doesn't support passkeys once every
| couple of days for some hacky shell script bidder they've been
| running since they downloaded it off mIRC in the 90s...
| figassis wrote:
| I really just want passkeys to exist for a decade and all
| lockout/lock-in edge cases being resolved before I retire my
| password manager, and before I tell my mother to move to
| passkeys.
| josteink wrote:
| Why not use both? There are several password managers which
| supports passkeys.
|
| That's where I have mine.
| jedberg wrote:
| That's fine for me, but my parents not so much.
| gwbas1c wrote:
| > Passkeys not only offer an improved user experience by letting
| you sign in faster with your ... PIN, but they also aren't
| susceptible to the same kinds of attacks as passwords.
|
| I don't know about you, but a PIN is pretty much a password in my
| book.
|
| Once I figured out that I can use a password with Windows, I
| stopped using my PIN. (I didn't use Windows for about a decade.)
| It's much easier to remember.
|
| Even worse, on Windows, I'll only use passkeys on sites where I
| can use a Yubikey. If the passkey requires a PIN, I don't bother.
| I just can't be bothered to remember it.
|
| Otherwise, on Mac, my passkey supports my fingerprint sensor.
| Much easier.
| stetrain wrote:
| The Windows PIN is just a local password that isn't tied to a
| cloud account or ever sent across the network. Mine is a full
| text password, it doesn't have to be numeric.
|
| I haven't tried it but it should also work with "Windows Hello"
| supported face or fingerprint recognition.
| gwbas1c wrote:
| That is not mentioned anywhere, neither in the article, or
| when setting up a PIN.
|
| The common definition of a PIN is for things like using an
| ATM, where the PIN is for the account, not the card itself.
| lxgr wrote:
| The PIN is also for the card itself. The smartcard chip
| inside the card can validate it for offline transactions
| (although that's not as common in the US).
|
| I think a reasonable modern definition for a PIN is "a
| password that can safely be short"; more here:
| https://news.ycombinator.com/item?id=42446015
| vel0city wrote:
| > I don't know about you, but a PIN is pretty much a password
| in my book.
|
| Then your book is filled with misunderstandings of what the PIN
| function in Windows is actually doing.
| drusepth wrote:
| What's the difference between the two? I can log into my
| laptop with a password or a PIN; I assume anyone that steals
| or hacks my laptop can _also_ log in with a password or a
| PIN. PINs are inherently shorter and more simpler than
| passwords; why would anyone use a PIN over a password?
| toast0 wrote:
| If you change your motherboard, your windows PIN won't work
| anymore, and you'll have to login to the underlying
| microsoft online account.
|
| A regular local account with a password would still work
| after a motherboard change.
|
| This is assuming no bitlocker. If you have bitlocker, I
| don't know if bitlocker key recovery will also fix the pin
| (hopefully you printed the recovery key and can find it)
|
| I'm guessing this would also mess up passkeys.
| UltraSane wrote:
| AMD CPUs have fTPM built in so the passkeys are actually
| stored in the CPU. This is more secure because separate
| TPM chips on the mobo have been attacked by listening to
| the traces from the TPM to the CPU.
| toast0 wrote:
| Maybe the PIN doesn't change if you swap the motherboard
| and keep the CPU, maybe. But if you swap the motherboard
| and the CPU your PIN doesn't work anymore.
| hahn-kev wrote:
| The difference is that I can't login to your account using
| a pin. I need to use your master password or passkey, then
| once I have I can use a pin. Basically the pin is only
| local to your machine, so yes if someone steals your laptop
| it's the same, but there's a lot less people than can steal
| your laptop then can try to guess your Gmail password
| vel0city wrote:
| The PIN on a Windows machine is a secondary credential to
| unlock the primary local credential, with the primary being
| your actual password.
|
| Also, as mentioned in the sibling comment, PINs are just
| device-local credentials. They don't necessarily have to be
| numeric-only and can also be very long.
|
| You can have your computer re-challenge you for a full
| password on some interval. So have it force you to use your
| password on your first login of the day, then you can use
| your PIN to hop back in during the day and then have the
| PIN option time out after so many hours. Same with any of
| the Hello credential options.
|
| After too many failures with a PIN, it will disallow the
| PIN authentication entirely. So, its length isn't really a
| problem, it'll start to disallow PIN attempts after only a
| few wrong guesses. Once again, also configurable.
| Meanwhile, it'll always still allow a password although
| it'll start trying to slow you down on password attempts.
|
| PINs are supposed to be stored on the TPM or similar secure
| platform module, they're not stored on the local computer
| storage. So, there's not some easily accessible file to do
| brute-forcing outside of the computer.
|
| While consumer Windows isn't really Windows Hello for
| Business, the same basic ideas of PIN security are the
| same. Here's the FAQs on that which also go into some depth
| of why PINs over passwords:
|
| https://learn.microsoft.com/en-
| us/windows/security/identity-...
| reginald78 wrote:
| I don't understand the purpose of this at all then. That
| sounds like I now need to remember two passwords, one
| with all the problems passwords always had and a second
| one that requires my device to be useful. I hardly think
| two different attack vectors is better than one attack
| vector security wise, especially if one of the two former
| vectors is also the single later.
|
| I guess the idea is that it is easier to use. I just
| setup a PIN for Windows Hello. The PIN requirements were
| more strict than the password requirements, so that is
| hardly more convenient. Maybe this is punishment for not
| wanting to use a fingerprint or face scan which remain
| optional. For now anyway, it feels like all I did was get
| my goose half cooked and end up with two passwords
| whereas before I had one. Even if I did give my face scan
| or whatever, I still need to use my password to login to
| things so my original point about two attack vectors
| seems to still stand.
| vel0city wrote:
| > one with all the problems passwords always had
|
| No, because the PIN is tied to the device and becomes
| invalid much more quickly. A Windows password is
| potentially used in far more places and potentially
| across _many_ devices.
|
| > I guess the idea is that it is easier to use
|
| For many, it really is. On some of my devices which lack
| biometrics my pin is just a few numeric digits easily
| input with a small numberpad. The PIN is backed by the
| TPM which wipes it after too many failures. This is far
| faster and easier to type in than my full Microsoft
| account password which uses most of the normal complexity
| concepts such as length, mixed-case,
| letters+numbers+symbols, etc. Far easier to just type 4-6
| digits (or however long you want it to be) instead of
| dozens of mixed-case alphanumerics and symbols.
|
| For instance, I recently got a gaming handheld which runs
| Windows. I want to use my Microsoft account, but as
| mentioned its a long and complex password. It seems this
| device doesn't have any biometrics, so its either type in
| my very long password every time the screen locks on a
| software touch keyboard or just type in a short PIN
| backed by the TPM. Which seems like the better process?
|
| > it feels like
|
| You may feel that way, but a Windows Hello PIN is not a
| password. They're different things in many ways. I could
| continue throwing more documentation at you, but somehow
| I feel like continued facts aren't going to change your
| feelings about this.
| reginald78 wrote:
| > No, because the PIN is tied to the device and becomes
| invalid much more quickly. A Windows password is
| potentially used in far more places and potentially
| across many devices.
|
| I'm talking about the password classic here. It didn't go
| away. It remains one of the now two methods for signing
| in. Now there is also a second one while the original
| still exists, is it more secure? I don't see how two
| doors is stronger than one.
| 9x39 wrote:
| You could have a strong account password which is needed
| for remotely accessing the PC, and a simple PIN for
| convenience but which only works when authenticating
| locally.
|
| (I'm assuming this is a personal PC and not a corporate
| device, in which case this model is the same but the
| strong password is also used for many internal single
| sign on resources).
|
| Usually you pair this with a Windows Hello camera for
| face sign-in so you skip the logon hassle when in front
| of your PC.
|
| There are settings in the group policy editor to change
| the Windows Hello PIN settings, but it could depend on
| your Windows edition and whether you have admin rights.
|
| For example, if I use gpedit.msc > Computer Configuration
| > Administrative Templates > PIN Complexity, I see:
|
| Require digits, Require lowercase letters, Max PIN
| length, Min PIN length, etc
| gwbas1c wrote:
| > You can have your computer re-challenge you for a full
| password on some interval. So have it force you to use
| your password on your first login of the day, then you
| can use your PIN to hop back in during the day and then
| have the PIN option time out after so many hours. Same
| with any of the Hello credential options.
|
| That still requires making up and memorizing a PIN.
| vel0city wrote:
| Sure, but a short numeric PIN you probably type in
| several times in a day is probably pretty easy to
| remember. And once again also far easier to type in many
| situations than a long complex password.
|
| Or even better yet use biometrics instead of the PIN.
| tivert wrote:
| >> I don't know about you, but a PIN is pretty much a
| password in my book.
|
| > Then your book is filled with misunderstandings of what the
| PIN function in Windows is actually doing.
|
| The "PIN function in Windows" doesn't define what a PIN is.
| If Microsoft really meant the "PIN function in Windows"
| specifically, they should have said so in their blog post.
| Otherwise, in this context, PIN means this:
| https://en.wikipedia.org/wiki/Personal_identification_number.
| vel0city wrote:
| > but a PIN is pretty much ___a password___ in my book.
|
| > Once I figured out that I can use ___a password with
| Windows___, I stopped using __my PIN__.
|
| Context clues. Read the whole comment. Pretty much
| immediately after they start talking about PINs and how
| they're pretty much just passwords, they go to talk about
| using passwords instead of PINs in Windows. Each sentence
| isn't its own entirely separate universe devoid of any
| context of the previous words and sentences.
|
| What PIN do you think they stopped using immediately after
| referencing their Windows password? Think they stopped
| using their bank card PIN because they figured out how to
| go back to full Windows passwords?
|
| So no, they're not speaking generally about all PINs,
| they're specifically referencing it in the context of
| Windows accounts.
|
| https://www.grammarly.com/blog/writing-techniques/context-
| cl...
| stetrain wrote:
| Their post actually says "face, fingerprint, or PIN"
|
| When you set up a PIN in Windows it can either be numeric
| or a full text password, it's your choice.
| notatoad wrote:
| the way a PIN works in other contexts is the same concept
| as what microsoft means.
|
| Your PIN for your bank card doesn't give anybody access to
| your bankaccount. that would be terrible. your pin acts as
| a secondary level of authentication to secure the bank card
| that is your primary authenticator. just like a PIN in
| windows hello acts to secure your primary auth method - the
| computer that's already signed in to your microsoft
| account.
| notatoad wrote:
| A PIN is not a password, because it only works on a device that
| you have already autheticated using some much more secure
| mechanism.
|
| if there is anywhere that you can use a PIN without additional
| authentication it's not a PIN, it's just shitty insecure
| password.
| lxgr wrote:
| Not necessarily. You can securely use PINs over a protocol
| like SRP, as long as the backend can be trusted to perform
| rate limiting properly.
| lxgr wrote:
| > a PIN is pretty much a password in my book.
|
| My definition of a PIN is a password that can safely be short
| (i.e. low entropy), which means you can only use it against a
| system capable of enforcing a rate limit.
|
| That can be local trusted hardware (such as a secure enclave, a
| Yubikey etc.) or a remote backend via something like SRP.
|
| > If the passkey requires a PIN, I don't bother. I just can't
| be bothered to remember it.
|
| Then use your password! A PIN can, but does not have to be,
| short :) FIDO-compliant authenticators have to accept up to 255
| UTF-8 characters; you're by no means limited to a numeric
| 4-digit code.
| Havoc wrote:
| Is there a good ELI5 for passkeys somewhere? A quick google got
| me to a site that says:
|
| >Passkeys use Bluetooth technology, which requires physical
| proximity, to help verify the user.
|
| Which I somehow doubt is accurate.
| somat wrote:
| You probably know most of this, so sorry for the over
| simplification. but you asked.
|
| A passkey is an implementation of public key authentication.
|
| The private part should stay with you, this is your identity.
| The public part gets shared with others, they can use this to
| verify your identity. "microsoft passkey" wraps all this up
| into a simple tool that just looks like you are putting in a
| pin number.
|
| The vague thousand foot mechanism is. someone who wants to
| verify your identity will ask you to sign a unique number.
| because only you have the private part needed to to do this,
| only you can sign it correctly. they can then use the public
| part to verify the signature is correct. and know it is really
| you they are talking to.
|
| The private part is usually protected by a device, something to
| prevent others from using it. this is often just a password, in
| this case a PIN. but some times is a dedicated usb dongle. this
| only has to have local security guarantees not global network
| security guarantees. so a simple password like a PIN is not
| considered a problem.
|
| The primary advantage over a simple password based system is
| that the thing that is shared(the public part) is unable to be
| used as your identity so it can't be stolen like a password. or
| perhaps more accurately, it does not matter if the public part
| is stolen(it is already public knowledge)
|
| And now the irony, I have no proof, however I have a suspicion
| that because loosing the private part is the same as loosing
| your identity, that is, a big deal and a huge hassle to recover
| the account. I suspect microsoft is storing them internally.
| which means your account security degrades to a password based
| system where the password is basically pubic knowledge, that
| is, your so called security questions. what is your favorite
| color? is not a good password.
| vaylian wrote:
| Just to add to your explanations:
|
| 1. Passkeys contain the username and the domain of the
| service that you have registered with
|
| 2. Because passkeys contain the domain, it provides very
| strong phishing protections, because a look-alike website
| still has a different domain.
|
| Passkeys are resident keys. They take up storage space, which
| is a problem for dedicated hardware tokens which usually have
| limited storage space. A much nicer solution are non-
| residential keys that get recomputed on the fly based on the
| domain name that you want to authenticate against.
| happymellon wrote:
| So is this following the OpenID Connect/JWT type flow?
|
| The site registers itself with your passkey "wallet" (?),
| and logging in would use a signed request and your wallet
| provides a shared secured response so you both can confirm
| who you say you are?
| Havoc wrote:
| Thanks
|
| Sounds like basically public key logic with a biometric local
| wrapper?
| rsync wrote:
| How does this mechanism prevent breaking one of the
| commandments of encryption systems:
|
| _Thou shalt not sign arbitrary plaintext_
|
| ... if, as you say, a service first gives you something to
| sign with your private key ?
|
| What kind of "phishing" would it be if Mallory convinced
| Alice to create a new account on some new service for the
| purpose of leaking private key bits?
| fragmede wrote:
| A new private key is generates for each site, and only that
| site has the corresponding public key, and the domain name
| is checked, so malicious.com can't leak the private key for
| example.com.
| rsync wrote:
| Thanks!
| dsego wrote:
| It's like when you get the push notification on your smartphone
| for two factor auth. So instead of typing in a password you get
| a notification on a secure device. For example on macos I can
| save the passkey in the os/browser and use my fingerprint to
| log in instead of a password.
| dboreham wrote:
| Passkey is a cool marketing name for software emulation of a
| smart card. Hopefully you already know what a smart card does.
| jf wrote:
| Except in this case, the smart card generates a new key _per
| domain name_
| hooverd wrote:
| The FIDO Alliance can eat it until they support exporting
| passkeys and stop passive-aggressively threatening, "why don't we
| talk about this privately" anyone who tries to implement that.
| TheNewsIsHere wrote:
| There's a recently released draft for an export/exchange
| protocol. Multiple vendors have already signaled work on
| implementation.
| hooverd wrote:
| Oh, that's good news!
| iandanforth wrote:
| Passkeys are a terrible idea. They are security theater and a
| disaster for users waiting to happen.
|
| Imagine you're on vacation and have lost your phone. You want to
| go to a cafe and log into a chat app, an email service, whatever
| to contact your family. In the world that passkey advocates want
| this is impossible via the passkey flow. If you can't
| authenticate via a primary device that contains your private key,
| you're f-ed. Service providers know this so of course they will
| provide recovery mechanisms. (Not consistent recovery mechanisms
| of course, each will have their own convoluted and likely to be
| broken ones). If the recovery mechanism allows for knowledge
| based recovery (challenge questions) then you're basically
| telling people that they need N passwords rather than one
| password. Maybe that challenge question is just a long password
| (recovery key). Maybe it requires access to another system, which
| you likely don't have in this circumstance. So you're either back
| to having passwords, or you're f-ed. Security theater or a
| disaster.
|
| A service only has value if I can access it. I should be able to
| sit down at any computer in the world with the knowledge in my
| head and get access to any online service to which I subscribe.
| d4mi3n wrote:
| You're not wrong, but I think you're presenting this as a
| dichotomy when there's a lot of value to be had between the two
| extremes (passkeys all the way or passwords all the way).
|
| The big benefit to a passkey for a service provider is that
| when you see a user using one, you can assert things about that
| session--that this is the users device, that the session isn't
| likely to be spoofed, etc. These are useful things to know if
| you want to implement any kind of context-aware access!
|
| Passkeys certainly aren't a silver bullet, and I don't think
| they're really marketed or implemented well a lot of the time,
| but I'd caution against writing off the tech as a whole .
| GoblinSlayer wrote:
| How do you log in anywhere without a computer? You have a wifi
| receiver implanted in your head?
| culopatin wrote:
| Who said they would be on the moon? We're surrounded by
| computers we can borrow all the time.
| sleepybrett wrote:
| Without a 'personal computer' that contains your passkeys.
|
| Next up, cloud based passkey proxy services. Store your
| passkeys there they auth for you after you give them some
| other damn auth method.
| TimC123456 wrote:
| Yes, this is how we already use a password manager like
| iCloud Keychain or 1Password.
| echelon wrote:
| > security theater
|
| Laypersons probably don't see ATOs at scale. I worked at a
| fintech and it was a relentless uphill battle to protect our
| users. We saw massive distributed login attempts daily and
| constantly bought compromised passwords on the gray market to
| run against our users' accounts. We tried to encourage better
| password hygiene, 2FA, Fido, etc.
|
| You have to protect users from their own misunderstanding. When
| it comes to their bank accounts, improper security can be life-
| changing.
|
| The term "security theater" itself is often thrown around to
| criticize when it's completely undeserved. Lots of people use
| it to poke fun at the TSA, but the term totally dismisses the
| fact that hijackings have plummeted [1,2]. The TSA does its
| job.
|
| [1] https://www.statista.com/statistics/1240246/aircraft-
| hijacki...
|
| [2] https://imgur.com/a/xV9ebD9
| Longlius wrote:
| >The term "security theater" itself is often thrown around to
| criticize when it's completely undeserved. Lots of people use
| it to poke fun at the TSA, but the term totally dismisses the
| fact that hijackings have plummeted [1,2]. The TSA does its
| job.
|
| Your graphic shows 'worldwide' data rather than US data. How
| would the TSA be involved in reducing hijackings on flights
| outside of the US? The connection seems spurious at best.
|
| We could just as easily argue that hijackings correlate with
| other violent crime and the reduction in violent crime
| worldwide has led to their decline. Or that increased
| prosperity worldwide mitigates hijackings. There's very
| little basis to believe that TSA has anything to do with it.
| kaibee wrote:
| > The term "security theater" itself is often thrown around
| to criticize when it's completely undeserved. Lots of
| people use it to poke fun at the TSA, but the term totally
| dismisses the fact that hijackings have plummeted [1,2].
| The TSA does its job.
|
| Would you be interested in buying my rock that wards off
| tigers? Ever since the great Tiger apocalypse where the
| premier military power in the world went on decades long
| quest to kill all of the tigers and everyone learned of the
| dangers of tigers, my rock has been extremely effective at
| warding off tiger attacks. For just 12 billion dollars a
| year (adj for inflation annually) (https://www.tsa.gov/news
| /press/testimony/2024/04/16/fiscal-y...), you could have
| this extremely effective rock.
|
| edit: I'm pretty sure I clicked reply on GP's comment.
| Weird.
| nijave wrote:
| The TSA may stop hijackings but that doesn't mean it's doing
| it efficiently or following science based approaches.
| Backscatter machines are an example
|
| People do need protected from themselves (that's generally
| the point of regulation, lobbying aside)
| thought_alarm wrote:
| It sounds like you're arguing against passkeys, two-factor
| authentication, and password managers.
|
| Do you use single, easy-to-remember plain-text passwords for
| all of your accounts and services? If not, you need to
| understand what the recovery process is when your
| passkey/2FA/pw-manager is unavailable or lost.
| BadHumans wrote:
| I use easy to remember plain text passwords for services that
| are low risk. It's a spectrum. I'm not concerned about
| someone hacking into my Hacker News account for example but I
| am very concerned about someone breaching my bank.
| zamadatix wrote:
| GP doesn't seem to mention password managers. The nice thing
| about password managers vs passkeys is they need not be
| locked to a particular device or platform. I can sync the
| same database of credentials between my phone, pc, and laptop
| without worrying if they are from the same vendor. I can
| export backups. I can access it through my personal website
| on any device (assuming I also remember my personal website
| login too) if desperate.
|
| The problem with passkeys isn't the concept, it's the lack of
| flexibility in implementation.
| jazzyjackson wrote:
| Seems to be a common misconception, passkeys need not be
| tied to a device, they can be saved to a password manager
| and synchronized.
| josteink wrote:
| I in fact do this with Bitwarden on a daily basis.
|
| It works ok!
| zamadatix wrote:
| This prompted me to read more about it as I was quite
| certain this was the reason I had stopped using them. It
| seems the initial wave of complaints fed into some change
| about a year after the initial launch. Android 14 (Oct
| 2023) via the new Credential Manager API and iOS 17
| (September 2023) when 3rd parties could actually be a
| registered passkey provider.
|
| https://developer.android.com/about/versions/14/features#
| cre...
|
| https://www.dashlane.com/blog/dashlane-passkey-support-
| ios#:...
|
| Perhaps passkeys are more viable now with these changes?
| I'll need to give it another go and see. Thanks for the
| tip!
| jazzyjackson wrote:
| It surprised me too since I thought the whole point of
| passkeys is that you're using a thing-you-own to
| authenticate, but really the whole point is that the
| security credential is never transmitted to the service
| doing the auth.
| jerf wrote:
| I've been using them with my BitWarden/VaultWarden setup
| now for a while. I was also _extremely_ crabby about the
| idea of tying my accounts to hardware to the point of
| being unwilling to use them, but this problem is
| resolved. The resulting user experience is now the best
| of any login methodology and I remain in full control of
| my passkeys, up to and including the ability to back them
| up. I think it sometimes takes a "Never Offer Me
| Passkeys" from the browser sometime, just like they
| default to trying to get me to save my passwords into
| their vaults (and I always have to look up the magic
| setting to tell them to stop doing that on a new
| install), but it hasn't been that hard to make work.
|
| I think I've heard that the passkeys providers have an
| option to force it to be hardware, but I've yet to
| encounter that, and it would also make me quite cross
| without a _very_ good reason. I, personally, do not want
| my accounts tied to any particular bit of hardware, I
| want it tied to the single (very!) strong password I use
| for everything.
|
| Edit: Browsing through the rest of this HN conversation
| it seems the password managers have some PR to do. Many
| HNers are not aware that password managers, even perhaps
| the one they are already using, have the ability to store
| passkeys in them. If HNers don't know, certainly outside
| of the HN bubble it must be even less well known.
| recursive wrote:
| The passkey pitch needs to incorporate this. Last time I
| paid attention, which was a long time ago, passkeys were
| non-portable. This is a deal breaker for me, so I wrote
| the whole thing off. I guess they fixed it.
| donmcronald wrote:
| > I think I've heard that the passkeys providers have an
| option to force it to be hardware, but I've yet to
| encounter that, and it would also make me quite cross
| without a very good reason. I, personally, do not want my
| accounts tied to any particular bit of hardware, I want
| it tied to the single (very!) strong password I use for
| everything.
|
| If the functionality is built in, don't be surprised when
| they alter the deal and force it on you. What are you
| going to do if no one lets you use or migrate back to a
| username / password at that point?
|
| We've seen the same thing thousands of times from big
| tech. They give us a system that's tolerable, but
| designed to leverage us into a bad position in the
| future. Once there's a critical mass, they'll flip the
| switch and we'll all get screwed.
| swozey wrote:
| I use them for a bunch of things on a bunch of different
| devices/OSes and one light frustration I've had is I've
| accidentally stored a few of them in different apps
| because I'll be on a different device and either not have
| access to an app that I usually put the key in (1pass) or
| I'll mistakingly hit a "save passkey" that Windows, or
| Chrome, or whatever pops up. I've had to go in a few
| times and change my devices.
|
| I think this is because it's so new with these apps.
| 1password acts really strange with them sometimes and my
| chrome extension will lock up or not actually push the
| passkey through or whatever it does. Sometimes I just get
| annoyed and throw it wherever worked.
|
| When they're flawless they're awesome. I don't mind the
| quirks right now.
| Sophira wrote:
| Synchronized using what service? What's the
| authentication mechanism that would allow you to download
| your passkeys from this service?
| jazzyjackson wrote:
| Various password managers. They're just private keys.
| Optionally you can use a private key that is kept in a
| secure enclave on-device, these would not be
| synchronizable.
| jp191919 wrote:
| KeepassXC works great for this.
| nottorp wrote:
| And how do you protect the password manager, with a
| passkey that needs to be stored in another password
| manager, or with a password with all the security risks
| that come with it?
| acdha wrote:
| I think you're letting your emotions distract from the larger
| picture where millions of people are compromised on a regular
| basis because they use systems designed the way you want.
|
| Knowledge-based access is inherently problematic: if you don't
| police passwords, most people will be compromised because they
| use weak and/or shared passwords. If you use strong passwords,
| you're also screwed if you lose your phone so you're in the
| same reset game with trivia questions which are increasingly
| weak because they can be answered from information on
| Facebook/LinkedIn or from breaches from other companies which
| used the same question. New logins from previously unused
| devices in a new part of the world shouldn't work anyway
| because that's indistinguishable from a successful attack.
|
| Passkeys avoid all of that, but you need backups either in the
| form of a Yubikey or a recovery code in your wallet. Yes,
| that's annoying but there is no world where nobody is annoyed,
| so it should be a question of whether more people are
| inconvenienced by their accounts being breached versus
| traveling and losing all of their devices but still being able
| to remember their strong passwords.
| dboreham wrote:
| Of you have a Yubikey why do you need to use passkeys (which
| are essentially software emulation of a Yubikey).
| superfrank wrote:
| Because the vast majority of users don't want to bring a
| yubikey with them everywhere they go.
| nijave wrote:
| I'm curious if that's really true. I've had a Yubikey in
| my keyring for years and it's pretty convenient. It's
| smaller than my car key and isn't very noticeable.
|
| I have the NFC enabled variant so it can be used with a
| mobile phone
| dymk wrote:
| Yes, it's really true. How many of your friends and
| family members carry around a yubikey?
| nijave wrote:
| The technically savvy do. The others don't but not
| because they don't want to--they don't know they exist.
| Everyone I know carries around NFC devices--either work
| badges or credit cards. I don't see how having an extra
| NFC device in addition to the multiple ones you already
| have is a burden.
| doublerabbit wrote:
| I'm technically savvy. I don't nor want to own one.
|
| Why should I be forced to pay for a YubiKey? EUR60 is a
| fair chunk of money.
|
| Maybe buy me one I'll consider it otherwise I'm not
| convinced. I will once corporate gives me free open-
| source hardware.
| superfrank wrote:
| I'm an EM at a large tech company. Spent a decade as a
| developer. I have a Yubikey for work and I hate it. I
| understand why I need it and the value it provides, but I
| hate having to cary around one more thing.
|
| The fact that this user thinks the average person would
| be happy to have to cary one around is wildly out of
| touch.
| dymk wrote:
| > The technically savvy do.
|
| That's my point.
|
| Yubikey doesn't pass the grandma test. Your everyday user
| isn't going to be carrying one around anytime soon.
| superfrank wrote:
| I also have a Yubikey for work, so I know how they work
| and how small they are.
|
| I still stand by the idea that most users wouldn't be
| happy having to cary it around. We can't even get most
| users to use password managers which are built into their
| phones (1 in 3) and there was a collective meltdown when
| Apple removed the headphone jack which required people to
| cary a dongle for wired headphones. Telling people they
| need to cary around a yubikey for anything they want to
| log into just isn't going to fly.
|
| https://www.security.org/digital-safety/password-manager-
| ann...
| water-data-dude wrote:
| I'm trying to get people at my workplace to use yubikeys.
| I would have thought it'd be easy, since "touch the
| blinking green circle on your yubikey" is a way less
| obnoxious form of 2FA than "pull out your phone, wait for
| a text, type in the number" or "pull out your phone, open
| up the 2FA app, scroll to the service, type in the
| number". I was wrong though, it's like pulling teeth and
| I'm not sure why!
|
| I think you're right, any change has to fight against the
| "this is how I do it already" inertia.
| bsder wrote:
| For me, the problem with YubiKeys is not the normal
| usage. That works great.
|
| The problems are the "corner" cases: enrolling new keys,
| removing old keys, handling unintentional destruction of
| the key. The last one, in particular, is really
| problematic.
|
| Some of the security mechanisms that a YubiKey provides
| are an extreme inconvenience. For example, I want to be
| able to clone my key via some mechanism in case it gets
| destroyed. I don't want to have to enroll 3 separate keys
| in every service on the planet just in case I put one in
| the wash accidentally. That's not possible with a YubiKey
| --for good reason--but it's a significant annoyance.
|
| We consider "duplicating a physical key" such a common
| need that we have automated machines to do it at _7
| Eleven_. The fact that we don 't have the same
| consideration of digital ones is problematic.
| lxgr wrote:
| Yubikey was even planning working on a FIDO extension
| that would allow that for a while, but I don't think it
| went anywhere.
|
| It's a real shame, as I'd also love "Yubikey twins" of
| which I can put one in a safe deposit box and have the
| other one always with me, without needing to periodically
| synchronize them to all services I'm using them on.
| nijave wrote:
| How is a Yubikey any different than other physical keys
| people have been carrying for hundreds of years? It seems
| much more intuitive to carry a digital key for your
| digital accounts.
|
| Password managers have the added complexity of still
| needing a password themselves and all the quirks that
| come with auto filling and programmatically reading
| forms.
|
| I'm not sure Apple head phones are quite a fair
| comparison. Outrage was also due to proprietary
| connectors that were patent encumbered.
| addicted wrote:
| Where can I call to get the Yubikey locksmith in the
| middle of the night to show up and let me into all my
| accounts if I lose my Yubikey?
| coolspot wrote:
| nsa.gov - they are great, 5 stars
| superfrank wrote:
| > How is a Yubikey any different than other physical keys
| people have been carrying for hundreds of years?
|
| 1. Not everyone caries keys (I don't and haven't for
| years)
|
| 2. Because every other existing alternative doesn't
| require you to cary something extra. Asking people to
| cary something with them to be able to sign into accounts
| will feel like a step backwards to most people.
|
| 3. Because most people only need to pull out their keys a
| few times a day. Requiring a Yubikey for every sign in
| means you'd now need to constantly be pulling your
| Yubikey out to sign into things.
|
| > Password managers have the added complexity of still
| needing a password themselves and all the quirks that
| come with auto filling and programmatically reading
| forms.
|
| I don't buy this. I use Lastpass which is arguably the
| most widely used password manager. I sign in using the
| master password maybe once a month and it works
| seamlessly on my phone. Apple and Google both have their
| own native solutions as well and still only 1/3 of people
| use them.
|
| > Outrage was also due to proprietary connectors that
| were patent encumbered.
|
| I think you're living in a bubble. Just go look back at
| the headlines from when that was announced. Almost no one
| gave a shit about it being a proprietary connector.
| People were upset because they were being forced to buy
| and cary a bunch of dongles. Just look at the comments on
| these reddit posts:
|
| https://www.reddit.com/r/funny/comments/5a6lbd/it_just_wo
| rks...
|
| https://www.reddit.com/r/funny/comments/5j66d4/the_world_
| isn...
|
| https://www.reddit.com/r/dankmemes/comments/ox3s26/apple_
| do_...
| mebizzle wrote:
| I don't have a keyring or a car key anymore so any
| additional physical object to carry is less convenient.
| lxgr wrote:
| I used to do that for a while, and it got annoying very
| quickly. It still requires grabbing my keychain when e.g.
| sitting on the couch or lying in bed, NFC doesn't always
| read (there's very little UX feedback on whether I'm
| holding it in the right place and there is possibly an
| application layer problem or I'm not even close), and
| most of all it doesn't work on my computer, where I need
| to plug it in to the USB-C port (much less seamless than
| tapping).
|
| Now I only have the Yubikey as a backup authenticator for
| my most valuable accounts and use a software solution for
| most low-value things.
| lxgr wrote:
| The much bigger problem is that you also need to enroll a
| second Yubikey into every service you use, but also
| safely store that backup key somewhere, ideally outside
| your own house. That's just not realistic.
|
| Yubico had some ideas around "paired Yubikeys" which
| shared the same root secret, but I believe that model
| won't work anymore with FIDO/CTAP2 due to some counter
| value that was added there over U2F. (It might be
| possible for them to just not have a security counter;
| I'm not sure.)
| acdha wrote:
| Backups are good. If some guy grabs my phone, he doesn't
| automatically get the Yubikey at the same time. The same is
| true if my phone is damaged.
| pseudosavant wrote:
| Because I already have a device in my pocket that can
| easily do that "software emulation" that I'm less likely to
| lose, and it has a tracking ability?
| seethishat wrote:
| Knowledge-based access (something only stored in your head)
| has Constitutional protection in the United States. The same
| is probably not true for physical things such as phones and
| YubiKeys stored in your pocket.
|
| Not that I worry about that, but it is worth pointing out
| that you may lose some legal protections when you use
| physical things rather than your knowledge.
| acdha wrote:
| I have the most amazing coincidence to report about what
| protects my phone and Yubikeys.
| seethishat wrote:
| Unfortunately, the forensic devices that easily extract
| data from your phone, can't be plugged into your head.
| acdha wrote:
| According to the manufacturers, those forensic devices
| also don't work on my iPhone unless it's unlocked with a
| password, but this is also irrelevant because they can
| get the stored passwords from the same phone in any
| scenario where they can access the passkey.
|
| More to the point, this is also not what the average
| computer user is worried about. It assumes that they're
| targeted by police, have something they need to keep
| secret, and that those police can compel physical access
| but scrupulously obey civil rights protections.
| nijave wrote:
| Do you have a source for this? As far as I know, it's at
| best a legal gray area. I believe in most cases you'll
| still be held in contempt of court for not producing
| secrets needed to access information which the authorities
| have a warrant for.
|
| Additionally, it's a bit silly in the context of email
| since the authorities will obtain it from the service
| provider anyway.
|
| That said, you can still add an encryption key to your
| phone and you're back to "knowledge based" with the
| additional caveat a thief would also need the hardware as
| well.
| Sayrus wrote:
| That's heavily dependent on which country you're in. In
| France[1] it can go up to 5 years in jail for refusing to
| provide a password. In the US[2], it seems that passcode
| are protected since you may be self-incriminating but
| FaceID, passkeys and fingerprints are not. UK seems to
| allow police to require you to give your password under
| their anti-terror laws.
|
| [1] https://news.ycombinator.com/item?id=33550824
|
| [2] https://www.selectlawpartners.com/faqs/do-you-have-
| to-give-p...
| n144q wrote:
| [2] is the "constitutional protection" grandparent
| comment is talking about, since it is ruled by the US
| Supreme Court.
| connicpu wrote:
| The real answer is you shouldn't tell law enforcement
| anything without an attorney present, and the best advice
| would be to heed your attorney's advice on the matter for
| whether you personally should give up your passwords or
| not.
| binkHN wrote:
| > The same is probably not true for physical things such as
| ... YubiKeys stored in your pocket.
|
| There's nothing preventing you from password-protecting
| your YubiKeys.
| connicpu wrote:
| Right, they can seize my yubikey but the 5th amendment
| protects me from being compelled to hand over the pincode
| protecting it.
| jf wrote:
| You can get passkeys with knowledge-based access if you use
| 1Password, or if you set a PIN on your YubiKey:
| https://support.yubico.com/hc/en-
| us/articles/4402836718866-U...
| mort96 wrote:
| Locking people out of their accounts is pretty much a worst
| case scenario. It's so bad that services with passkeys
| generally _don 't want to risk it_, hence the knowledge-based
| recovery options. Which makes passkeys mere convenience
| rather than extra security.
| lolinder wrote:
| > Passkeys avoid all of that, but you need backups either in
| the form of a Yubikey or a recovery code in your wallet. Yes,
| that's annoying but there is no world where nobody is
| annoyed...
|
| We're not talking about annoyance here, we're talking about
| data breaches on the one hand and permanent account lockouts
| on the other. There is no world where the majority of people
| remember distinct passwords for each service, and there's
| likewise no world where the majority of users carry a Yubikey
| or even download their recovery codes at all, much less carry
| them with them.
|
| So we're left really with two choices at the extremes: do we
| go for the failure mode where people reuse passwords and lose
| money and data that way, or the failure mode where a company
| is physically incapable of restoring a customer's account?
| Given the choice between these extremes, companies will
| always choose the former.
|
| Now, these extremes aren't the only choices, but then you get
| to the crux of OP's argument: passkeys stored in a password
| manager aren't any more secure in practical terms than random
| passwords stored in a password manager. Your auth system is
| only as secure as its recovery mechanism (which is the
| observation that led Slack to initially not bother with
| passwords at all).
|
| There's one way in which I disagree with op, which is that
| passkeys prevent users from typing in a password and storing
| it in the password manager, which many users do--they
| effectively enforce random passwords rather than it being
| just a best practice that needs to be taught.
| jt2190 wrote:
| > [D]o we go for the failure mode where people reuse
| passwords and lose money and data that way, or the failure
| mode where a company is physically incapable of restoring a
| customer's account?
|
| Are you sure that Microsoft's solution means that they are
| "physically incapable of restoring a customer's account?"
| Apple's system keeps copies of recovery keys in their cloud
| [1], unless you explicitly tell them not to do this. It
| seems like a reasonable compromise for most people's
| security needs.
|
| [1] Or effectively something like that.
| lolinder wrote:
| I get to that, but as I said above you've now compromised
| the security of the passkey system, which means your
| passkeys are actually only as secure as your recovery
| mechanism, and for convenience sake that recovery
| mechanism is usually quite insecure.
| tptacek wrote:
| Sure they are: Passkeys are phishing-resistant, and random
| passwords are not. This is pretty basic stuff.
| lolinder wrote:
| Random passwords in a password manager _are also_
| phishing-resistant. My password manager remembers the URL
| that I used the password in and will refuse to fill it in
| on other pages unless I deliberately work around that
| protection. They may be less phishing-resistant than
| passkeys (in which case add it to the list of small
| disagreements I have with the original poster), but it 's
| not a wide open field for phishing attacks.
|
| And this is an important distinction to make--if passkeys
| have a terrible UX (which right now they absolutely do)
| and are only marginally better at phishing protection
| than a password manager, they could actually be a less
| secure solution overall by encouraging lazy workarounds.
| tptacek wrote:
| Passkeys are cryptographically phishing-resistant, and
| password managers just disable a convenience feature when
| a heuristic check fails. It's not the same thing. I don't
| care if you feel like the latter protection is sufficient
| for you or should be for others; they simply aren't the
| same, and that was what the comment upthread suggested.
| lolinder wrote:
| Whether or not they're the same as a bit of a red
| herring, the question is whether the marginal added
| benefit of cryptographic phishing resistance is worth the
| trade-off in UX which introduces new kinds of
| vulnerabilities due to undesirable user behavior and/or
| implementation workarounds. And to answer that question
| you can't just dismiss the security offered by password
| managers--it's a very real protection that needs to be
| factored in to your assessment of the strengths and
| weaknesses of each system.
| tptacek wrote:
| Take it up with the person who said the two
| countermeasures were literally equivalent. You're not
| going to get anywhere with me on this.
| lolinder wrote:
| Which user/comment are you referring to? The top-level
| comment? I'm the person you replied to initially, and
| that's not what I said, so I'm assuming you're referring
| to something else.
| tptacek wrote:
| _passkeys stored in a password manager aren 't any more
| secure in practical terms than random passwords stored in
| a password manager_
|
| It is my contention that this statement is:
|
| 1. Categorical,
|
| 2. False, _and_
|
| 3. Categorically false
| afiori wrote:
| One big selling point of passkeys is that almost every
| workaround is impossible, whether that is good security
| or bad UX or both seems to be under discussion
| lolinder wrote:
| If that's one of the big selling points then that's a
| problem, because workarounds are totally possible and
| actively implemented in the real world. As an obvious
| example: syncing passkeys is a workaround for their
| terrible UX that takes them further from the original
| design in ways that compromise some of the original
| security guarantees.
| wglb wrote:
| Can you illustrate how workarounds to passkeys are being
| actively implemented?
| fragmede wrote:
| Password manager support.
|
| If my password manager running on my desktop can
| provision and access the passkey for use on another
| device like my phone, then so can malicious code running
| on my desktop, and exfiltrate it to hackers. The original
| design, where the private key only exists on a TPM and
| the private key never leaves the TPM doesn't have that
| flaw.
| lxgr wrote:
| Not at all. One phishing vector is: (On a phone call)
| "Hi, this is $your_bank, please go to your password
| manager, open the entry for $your_bank and read your
| password out loud to me on the phone, thank you!"
|
| You can't read out a passkey, nor can you read out a
| challenge to somebody that they are to sign with their
| passkey, because it's not possible by design.
| acdha wrote:
| > passkeys stored in a password manager aren't any more
| secure in practical terms than random passwords stored in a
| password manager.
|
| This isn't true, and that's where your confusion comes in.
| Passkeys cannot be phished because the protocol includes
| the server name and does not expose the key to the remote
| server. The past decade of U2F/FIDO/WebAuth deployment has
| used that as the marquee selling point because it's a very
| common exploit which cannot easily be prevented with
| traditional passwords and MFA.
| afiori wrote:
| This ignores that most password managers check
| domains/origins the same way browsers do.
|
| the only difference is maybe in-app browser where the
| passkey integration might work more easily but even so:
|
| 1) it is still a matter of integration and/or using an
| actual browser
|
| 2) in-app browsers are inherently insecure anyway (at
| least on android)
| acdha wrote:
| > This ignores that most password managers check
| domains/origins the same way browsers do.
|
| No, it doesn't. Most password managers allow you to fill
| passwords for other domains and all of them allow copy-
| paste. The people who support those users know that
| phishers can convince people to do that which is why
| they're encouraging adoption of WebAuthn.
| OptionX wrote:
| So passwords are bad because users can't be trusted to chose
| strong passwords but for passkeys they suddenly are trusted
| to keep secure, comprehensive, backups?
| dsego wrote:
| Passwords can be phished, all you need is a convincing fake
| login form.
| acdha wrote:
| Passwords are bad because normal people can't remember
| strong passwords AND because they can be phished or leaked.
| Phishing is the most commonly-mentioned benefit for
| passkeys because it's widespread and cannot be eliminated
| from a password-based system.
|
| "Secure, comprehensive backups" sounds scary until you
| remember that it's only ever meant not disabling a checkbox
| for iCloud, Google, or Microsoft users.
| 0cf8612b2e1e wrote:
| What if my house burns down? How do I convince Google
| it's me, please give me my passkeys back? Call customer
| support?
|
| Any solution which does not allow me full autonomy to
| maintain a backup is not acceptable.
| wao0uuno wrote:
| Why should everything be dumbed down and idiotproofed these
| days? Why not educate people instead? Blame people not
| passwords. Passwords managers are good and free and every new
| phone has one built in. There is no excuse for using weak
| passwords anymore.
| tptacek wrote:
| Over years of trials security teams at places like Google
| have managed to successfully phish even people on those
| security teams. The verdict is in on whether this UX
| provides acceptable security.
| zelon88 wrote:
| I agree that enabling stupid people to keep being stupid is
| just kicking the can down the road. However I think we
| should blame identity providers, not passwords and not
| users. Passwords work when the identity provider doesn't
| have ALL of them, and users shouldn't be expected to be
| trustworthy.
|
| We just consolidated everybody's login into one platform.
| One monolithic database that contains the PII of
| EVERYONE.... What could present a bigger, better target
| than that? It's literally too good to pass up. Previously
| an attacker would have to compromise half a dozen vendors
| in order to completely pwn someone. Now they just need
| access to one.
|
| Additionally, password managers are dangerous. Not a single
| one or them has been able to go more than 12 months without
| reporting a significant hack. Just another consolidated
| attack vector.
|
| Like VPN providers. Why would I scourge the internet to
| gather browsing history of a target when the user has
| already consolidated that information into once place for
| me?
| lxgr wrote:
| Because even I, somebody that cares about all of this a
| ton, sometimes copy paste passwords out of my password
| manager because nothing else works. Because temporary read-
| only backend compromises shouldn't lead to catastrophic and
| persistent security breaches (because passwords are
| provided _in plaintext_ inside TLS, and TLS is often
| terminated at the edge). Because educating people for a
| complex and moving target like the details of
| authentication seems like a losing proposition at best, and
| like victim blaming at worst.
|
| So no, please don't blame people, blame bad authentication
| mechanisms (including passwords) and those that hang on to
| them despite better alternatives.
|
| > There is no excuse for using weak passwords anymore.
|
| Weak passwords are only a small part of the problem. You
| can get phished with even a 256-bit equivalent random
| string.
| donmcronald wrote:
| > Knowledge-based access is inherently problematic: if you
| don't police passwords, most people will be compromised
| because they use weak and/or shared passwords.
|
| I don't like it that the solution is to usurp control from
| the user and gate authentication through what will, in my
| opinion, ultimately be a small number of big tech companies.
| We'll eventually be dependent on having an Android phone, an
| iPhone, a Microsoft account, or similar. It'll be a world of
| "trust me bro" credential managers and you'll have to hope
| you never get banned by the big tech companies because it'll
| have a life altering impact if that means losing access to
| all of your accounts.
|
| The reality is that big tech has proven we can trust them
| because we're nothing more than 1 of a billion customers as
| far as they're concerned.
|
| > Passkeys avoid all of that, but you need backups either in
| the form of a Yubikey or a recovery code in your wallet.
|
| Passkeys create a huge burden in the context of managing
| devices and recovery codes.
|
| To start with, I'm not a fan of recovery codes. I have so
| many accounts that it's almost impossible to keep track of
| all the recovery codes. I have to organize them well enough
| that anyone who would happen to get access to my file cabinet
| would own my life.
|
| To mitigate that, I need a system for tracking which recovery
| codes I have in my file cabinet and I need a plan for
| rotating / revoking them if anyone gains access to them. Even
| worse, printed recovery codes are observable without altering
| the owner (aka me). Someone could photocopy all my recovery
| codes and I wouldn't know I've lost control of them.
|
| As for devices, I use Yubikeys for my high-value accounts and
| managing them is a huge pain in the ass. I have 5 sitting
| beside me. One is old, two are v4, two are v5. I didn't keep
| a list of all the accounts I used them for from day 1, so now
| I have to keep all of them. Forever. Just in case.
|
| The only way Passkeys will solve those problems is by taking
| complete control of authentication and treating it like a
| managed service. You'll be giving up control of your ability
| to prove your identity and, eventually, you're going to be
| paying a subscription fee for it.
|
| In my opinion it's almost a guarantee that Passkeys are going
| to be used as leverage _against_ users, not to benefit them.
| The sad thing is that once 99% of oblivious users are fooled,
| the rest of us are going to get the choice of using them or
| being shut out of everything.
| arcbyte wrote:
| I helped a family member set up an account on a state website
| which involved also creating an account on id.me. The amount
| of text message codes and email codes and usernames and
| passwords was ridiculous and incredibly difficult for them to
| follow. Passkeys would make it impossible
| figers wrote:
| Passkeys are in 1Password. I'm authenticated into 1Password on
| my phone, ipad, browser extension on multiple computers. As
| long as I don't lose access to all devices at the same time I'm
| fine...
| mort96 wrote:
| Passkeys are arguably slightly more convenient and not risky
| for those of us who are technically aware enough to use
| password managers, sure. But that's not what most people will
| do. Most people will see their phone ask them to add
| fingerprint/face unlock, so they do that, and now their
| passkey is stored only on their phone (or in iCloud if
| they're lucky).
| ncpa-cpl wrote:
| > Imagine you're on vacation and have lost your phone.
|
| A few years ago when SMS tokens and Authenticator apps where
| less common, I was able to do work without having my phone on
| the same room as my computer. Now I need to have it on my desk
| most of the time for logging in.
| CharlesW wrote:
| > _In the world that passkey advocates want this is impossible
| via the passkey flow._
|
| That's incorrect. I use passkeys to login automagically with
| many services, but nothing precludes me from logging in with my
| (20 character) passwords.
|
| > _If you can 't authenticate via a primary device that
| contains your private key, you're f-ed._
|
| That's also incorrect, for multiple reasons -- accounts support
| multiple passkeys, those passkeys are securely sync'd across
| multiple devices, recovery and backup mechanisms exist, etc.
| mort96 wrote:
| > That's incorrect. I use passkeys to login automagically
| with many services, but nothing precludes me from logging in
| with my (20 character) passwords.
|
| That is not the world which passkey advocates envision. In
| the case of those services you mention, passkeys are nothing
| but convenience; they provide no extra security. In the world
| passkey advocates envision, passkeys improve _security_ ,
| meaning the removal of password authentication options.
|
| I've already been temporarily locked out by one such service,
| because a Firefox update made the passkeys I store in
| Bitwarden inaccessible (Firefox would pop up a macOS Touch ID
| modal rather than the Bitwarden passkey). _That_ is the world
| which passkey advocates want, because it "improves
| security".
| Dylan16807 wrote:
| > _That_ is the world which passkey advocates want
|
| Okay, you don't have to take the hyperbole so far it's
| obviously wrong.
|
| They don't want your login to break, and a password vault
| could also break if you only had a password.
| mort96 wrote:
| I'm saying that the world which passkey advocates want is
| a world where if, for any reason, you can't log in with
| your passkey (due to a lost/broken device, a software
| bug, whatever), you'll be locked out of your account. I'm
| saying that to contrast with my parent comment, which
| claims that the world passkey advocates want is one in
| which passkeys offer some slight convenience advantages
| but no security advantages because they'll be an
| _alternative_ to passwords. Obviously they don 't want
| the software bugs, but we know bugs happen.
| brookst wrote:
| I'm not sure who these "passkey advocates" are, but are
| you really positive they are unanimous and completely
| homogeneous as a group?
| mort96 wrote:
| No group is unanimous and completely homogeneous. But
| judging by how often the security benefits gets brought
| up by those in favor of passkeys in these kinds of
| discussions (including this thread), my impression is
| that most of its advocates view it as a security benefit.
| Which means they need to replace passwords, not be an
| optional extra.
| macrolime wrote:
| For important sites like your email you'll add multiple
| passkeys. On less important ones you can just reset which
| passkey you use to login, using your email, if you lose
| one of your passkeys.
| mort96 wrote:
| That doesn't help with the posited example of "I lost my
| phone and need to borrow someone else's computer".
| Dylan16807 wrote:
| > I'm saying that the world which passkey advocates want
| is a world where if, for any reason, you can't log in
| with your passkey (due to a lost/broken device, a
| software bug, whatever), you'll be locked out of your
| account.
|
| And a world where people only use passwords has the same
| problem if you can't log in with your password.
|
| Moving from one single point of failure to another isn't
| great, but it's not a downgrade.
|
| (And just like it's possible to back up a password, it's
| possible to back up a passkey. And I know passwords can
| be memorized, but in practice it's bad passwords that get
| memorized.)
| mort96 wrote:
| How do I back up my passkeys? How do I get them out of
| iOS and into some file I control and can sync?
| CharlesW wrote:
| > _I 'm saying that the world which passkey advocates
| want is a world where if, for any reason, you can't log
| in with your passkey (due to a lost/broken device, a
| software bug, whatever), you'll be locked out of your
| account._
|
| Can you point me to a citation or two where passkeys
| advocates claim that passwords must go away and/or
| account recovery mechanisms must be abolished?
| mort96 wrote:
| If passwords remain, passkeys don't provide better
| security, only convenience.
| CharlesW wrote:
| The most notable example of why this is wrong: Passkeys
| are phishing-resistant. Using your passkey instead of a
| password (when both are available) ensures you're
| actually signing in to the site/service you expect.
| LegionMammal978 wrote:
| Elsewhere in this thread [0], passkey advocates go on for
| quite a bit about how vulnerable passwords are to
| phishing. Really, any account recovery mechanism not
| linked to hardware would seem to be vulnerable to
| phishing in the way they don't want it to be.
|
| [0] https://news.ycombinator.com/item?id=42443913
| ylk wrote:
| > In the case of those services you mention, passkeys are
| nothing but convenience; they provide no extra security.
|
| They do provide extra security, in that they ensure that
| you're on the correct domain instead of a phishing site.
| mort96 wrote:
| The phishing site will just ask you for a password,
| maaaaybe with some text explaining some BS reason why you
| can't use your passkeys but if it's a website which the
| user knows they have a password to, the kind of person
| who's prone to non-targeted phishing attacks likely won't
| even think to question why the passkey thing didn't
| trigger.
| ylk wrote:
| Honestly don't care to spend time on looking up the
| various states of 2fa proxies. But I've learnt so far
| that attackers don't build/use the most advanced tooling
| you can think of at all times. They often use the
| simplest thing that gets the job done. If it's not
| targeted, it's fine to not get the credentials of people
| with a passkey. Up until a significant portion of targets
| use passkeys, which I highly doubt to be the case as of
| now.
|
| Additionally, "the kind of person who's prone to non-
| targeted phishing attacks" is actually everyone --
| including infosec professionals spending lots of time on
| phishing campaigns for red team engagements. You just
| need to be lucky enough to reach them at the right
| (emotional, stressful, ...) moment. Getting grammar and
| spelling correct and even potentially even slightly
| customising each email is made much easier by AI.
| Knowledgeable users might, however, stop once their
| passkey doesn't work and try to understand why.
| doktorhladnjak wrote:
| Nobody is checking their email on vacation in an internet cafe
| in 2024. Losing your phone is a real pain these days.
| nijave wrote:
| I assume any device in an Internet cafe is riddled with
| keyloggers so now you've lost your phone /and/ email account
| lisper wrote:
| > I should be able to sit down at any computer in the world
| with the knowledge in my head and get access to any online
| service to which I subscribe.
|
| The problem with that is you have no way to be sure that the
| knowledge in your head won't somehow make its way into someone
| else's head. There's a reason that phishing is a thing.
| mort96 wrote:
| It should be a non-goal to prevent users from making mistakes
| in ways which harms everyone.
| nijave wrote:
| >Imagine you're on vacation and have lost your phone
|
| This is a solved problem.
|
| a) you can make a phone call b) you can print important travel
| documents ahead of time c) you can bring a backup device on
| your travels. I leave a Yubikey with my house keys in the hotel
| or sleeping accommodations and carry my phone
| jimbob45 wrote:
| _Yubico 's explanation of the name "YubiKey" is that it
| derives from the phrase "your ubiquitous key", and that
| "yubi" is the Japanese word for finger._
|
| The Yubikey is greatly held back from wider adoption because
| of its stupid name.
| beart wrote:
| Here are some successful companies with odd-sounding names:
| Google, GoDaddy, Survey Monkey, Nvidia, Caterpillar, Coca-
| Cola
| notatallshaw wrote:
| > b) you can print important travel documents ahead of time
| c) you can bring a backup device on your travels.
|
| While I remain on the fence about passkeys, I often see this
| argument from advocates when things go wrong along the lines
| of: "why didn't you securely store your backups and keep them
| with you at all times"
|
| Firstly, it's annoying when a user is already in that
| situation, it does not help them solve the problem right now.
|
| Secondly, it clearly faces a scalability issue, a significant
| proportion of passkey users right now tend to be well
| informed on the authentication model and threats, but when it
| scales to billions of users many of them will not be well
| informed and will not think about how to be prepared for when
| things go wrong, potentially locking them out of everything
| they would need to fix the situation.
|
| While I appreciate the advantage this model gives, I struggle
| to imagine it will work well on the unsuspecting public.
| rurp wrote:
| > I struggle to imagine it will work well on the
| unsuspecting public.
|
| Right, that's because there's a 0% chance we end up in a
| world where everyone who uses the internet reliably carries
| a Yubikey or similar backup on their person. It's wild to
| me how many people here are seriously proposing this as a
| solution. That might work fine for a typical HN poster, but
| expecting it to scale to the general public is some insane
| tech bubble myopia.
|
| In reality companies will either provide enough workarounds
| to negate any security benefits or a whole bunch of people
| are going to lose access to accounts they own. If passkeys
| ever get widespread I'm guessing we'll see more of the
| former option, leading to a lot of unnecessary confusion
| and very little practical benefit.
| Tomte wrote:
| > They are security theater
|
| You claimed that but didn't support it. They may be a bad idea
| (and I disgree), but how are they ,,security theater", which
| means they are insecure?
| tptacek wrote:
| You made a case for Passkeys having a flawed UX, but not one
| for them being security theater. Words mean things; "security
| theater" is a term of art for things people do for enhanced
| security that add no security, and Passkeys are not that.
|
| Downthread, you claim that Passkeys (if stored in a password
| manager) are no more secure than a random password stored in
| that password manager. That seems obviously to be false;
| Passkeys are phishing-resistant, and stored passwords are not.
| So that might be where your misconception comes from.
| mecsred wrote:
| I don't understand what is meant by phishing-resistant. There
| always need to be systems to authorize new devices or allow
| users to re-prove themselves if they loose the primary proof.
| Is the idea that scammers would have difficulty adapting
| phishes to access these resources? If "hello this is Jeff
| Bezos what is your password" works why wouldn't "hello this
| is Jeff Bezos please click authorise a new device so I can
| transfer you 1000$"
| brookst wrote:
| Because in the former case the attacker now has your
| password and can post it for everyone else to abuse. In the
| latter, which is still a problem, there is no transitivity.
| You're screwed with this one attack, but if you revoke
| their access that's it. They cannot re-use the credentials.
| mecsred wrote:
| Being able to revoke individual credentials is definitely
| a benefit. I'm not convinced about the transitivity,
| what's stopping one access from authorizing more? I
| suppose that would be asy to flag in an audit? Either way
| it's not really resisting the phishing, that's moreso
| resisting abuse once the credentials are gathered in any
| way.
| w0m wrote:
| To summarize this comment chain, the initial argument is
| 'passkeys are not impervious to all attacks therefore
| they are security theater' vs 'passkeys help
| significantly in the most common attacks, therefore they
| are worthwhile.'
|
| Statistics are hard. People have a bad habit of seeing
| 'not 100% fullproof' and thinking that said something is
| therefore worthless. Same senseless argument people made
| in the 80s against wearing seatbelts, and 4 years ago
| thinking it was a legitimate argument against wearing
| masks in the middle of a pandemic.
| afiori wrote:
| I believe that the crux of it is that password managers
| with autocomplete already have about the same level of
| protection and are both more flexible and have less lock-
| in
|
| passkeys imho are being pushed because:
|
| 1) a lot of people will not use a (good) password manager
|
| 2) it allows more lock-in for the providers
| (ios/android/1password/etc.)
| tptacek wrote:
| To a first approximation no normal person uses a password
| manager (people find them extraordinarily hard to use;
| source: did trainings with a bunch of different cohorts),
| and the two solutions _do not_ have "about the same
| level of protection". I watched a fintech company try to
| get people to stop _relaying credentials through SMS with
| scammers_ , and that problem was practically
| insurmountable. I do not believe "autofill" is the fool-
| proof defense you think it is.
| ziddoap wrote:
| > _I don 't understand what is meant by phishing-resistant_
|
| By far the most common phish is "click this link or your
| account will be shut down" which brings you to a fake
| Microsoft/Google sign-in page, where they say "please enter
| your credentials" (or some variant of this). This flavor of
| phishing is eliminated by passkeys.
|
| Phishing schemes will try to adapt, and some may still be
| successful. That is why it is not called "phishing-proof".
| mecsred wrote:
| That's a particular scheme that might be fooled, but
| what's stopping someone from making a version of the same
| scheme that redirects to a prompt on the real site which
| authorizes them as a new user? I'll admit web
| technologies aren't my area of expertise but I have
| little doubt it's possible based on my interactions so
| far. E.g. discord allowing me to log in to a new device
| by scanning a QR code with my phone and clicking OK.
|
| Ultimately the point of phishing is to attack the user
| instead of the technology. If the user has any control
| over access to their account, phishing is largely
| unaffected.
| nailer wrote:
| >what's stopping someone from making a version of the
| same scheme that redirects to a prompt on the real site
| which authorizes them as a new user
|
| I can give a better answer than the sibling:
|
| The passkey is domain bound, so the UI won't show up on
| the phishing site before the passthrough can even happen.
|
| Password managers are also domain-bound though.
| samcat116 wrote:
| > what's stopping someone from making a version of the
| same scheme that redirects to a prompt on the real site
| which authorizes them as a new user?
|
| This would require compromising the website as a whole
| Arnavion wrote:
| >This flavor of phishing is eliminated by passkeys.
|
| ... and also eliminated by password managers that use
| autofill based on the domain name.
| tptacek wrote:
| No it isn't, because people will manually fill things in
| when autofill doesn't work. People will go out of their
| way to feed credentials to sites that look authentic;
| it's a genuinely hard problem. (I've had the displeasure
| of having to work on it for financial industry clients.)
| lolinder wrote:
| Can you elaborate (or provide a source that does) on how
| passkeys prevent a phisher from just MITMing the initial
| passkey setup with some nonsense claim about your session
| expiring? I'm probably mistaken here, but my interactions
| with passkeys always make them seem to be trust-on-first-
| use, which is a very phishable strategy.
| samcat116 wrote:
| Passkeys are tied to a DNS name, so unless they were able
| to take over the DNS of a site, they wouldn't ever even
| be offered to authenticate the password. Additionally the
| private key never leaves the device regardless, so if you
| were tricked to setup a new passkey on a fake site, you'd
| just end up creating a new Passkey for it and the site
| would get some new unique public key.
| Arnavion wrote:
| The passkey on the MITM site could not be used with the
| original site if they were on different domains. If the
| MITM site is on the same domain as the original site,
| then either you've compromised the original site or
| you've got in-roads with a trusted CA to fool the browser
| into accepting your cert, and passkeys don't protect
| against those.
| lxgr wrote:
| Authenticating yourself with a passkey cryptographically
| signs a challenge issued by the site you're trying to log
| in at, and your WebAuthN client (usually your browser)
| only signs challenges it knows about.
|
| The important point here is that there is no way for you
| to have your browser sign an arbitrary (e.g. an
| attacker's) challenge, since you can't input the
| challenge at all.
|
| This makes WebAuthN strictly better than static
| passwords, TOTPs (which are "unidirectional" in nature),
| and even "enter code 123456 into your authentication
| device and provide the code it displays"-like flows
| (which is a bidirectional challenge-response, but a
| MITMable one).
| ndriscoll wrote:
| Ironically, just about the _only_ sites where it makes
| sense to do this as a user are... those from the
| financial industry, who in their infinite wisdom
| frequently decide to prevent autofill. There 's otherwise
| basically no reason to ever open the password manager or
| to know any of your passwords.
|
| In any case, if you have a KBA recovery mechanism, then
| anyone who would go dig through their saved passwords to
| put into a phishing site will also just enter the
| recovery info into a phishing site and enroll an
| attacker's passkey.
| tptacek wrote:
| See the comment from 'nailed downthread. I think some
| people on this thread are trying to axiomatically re-derive
| what Passkeys and FIDO2 are. Phishing resistance is
| literally the point of FIDO2.
| lxgr wrote:
| There is no "authorize a new device" for passkeys. You'd
| need to actually run the "register new passkey" or
| "authenticate using passkey" flows on the attacker's
| device.
|
| That's why they are so much more secure than passwords and
| even TOTP or "click approve to authenticate" flows!
| EVa5I7bHFq9mnYK wrote:
| Shouldn't the app storing the private key be protected by a
| 4-digit PIN, or a fingerprint, both of which are less secure
| than a plain old password? What have we achieved?
| lolinder wrote:
| If it requires physical access to the device to enter the
| four-digit PIN or scan a fingerprint, that would be a
| substantial step up from passwords which could be used from
| anywhere in the world.
| benreesman wrote:
| I tend to agree @tpatek but I'm really too much of a security
| newb to hold a strong opinion.
|
| What's the best resource in your opinion for learning enough
| about passkeys for a lay person to make informed decisions on
| them?
| tptacek wrote:
| How about... an interview with Adam Langley about their
| design and properties?
|
| https://securitycryptographywhatever.com/2022/08/11/passkey
| s...
|
| (I'm not being totally serious).
| adrr wrote:
| And if you have 2FA setup and no devices. You're also screwed.
| Its the exact same scenario.
| mort96 wrote:
| Yeah, TOTP is also a huge problem.
| donmcronald wrote:
| Microsoft Authenticator push notifications are even worse.
| It's _super_ easy to lose accounts if you lose your device
| because they are _not_ included in backups and there 's no
| warning that you should have two devices registered when
| setting it up.
|
| Normal users aren't going to keep a backup device, let
| alone keep track of which accounts are associated with
| which devices they own. Normal users need something in a
| portable format that can be backed up. Anything that can be
| backed up can be stolen and anything that can be stolen
| shouldn't be used for single factor auth like Passkeys are
| promising.
| macrolime wrote:
| Or if all your passwords are in a password manager on your
| phone
| eikenberry wrote:
| Isn't the difference that with passkeys you'd have 1 password
| for all passkeys where when using passwords directly you'd have
| a different one for each site. The benefit of passkeys here
| being that you shouldn't need that password most of the time so
| you don't expose it. You get the benefits of unique passwords
| per-site with only 1 actual password. The same benefits of a
| password manager but with better unique passwords.
|
| The main downside to passkeys currently is that I cannot be my
| own service provider. Having that I don't see a big downside.
| reaperducer wrote:
| _of course they will provide recovery mechanisms_
|
| Or, maybe they won't. Are Google and other free-as-in-facebook
| services going to suddenly open customer service departments?
|
| I got permanently locked out of Facebook because during a phone
| OS update, the 2FA app somehow lost my Facebook information. I
| can't log in to Facebook because the 2FA app can't authorize
| it. I can't add my Facebook account to the 2FA app without
| first logging in to Facebook. I've sent my photo ID to Facebook
| a number of times, but it just goes into a black hole and I
| never get a response.
|
| On the plus side, I have a lot more time to do meaningful
| things, and not scrolling my life away like a drug addict.
| derefr wrote:
| > Maybe that challenge question is just a long password
| (recovery key).
|
| Specifically, recovery keys are designed to be so long and
| complex that no human could possibly memorize them, ensuring
| that they're written down / printed instead of memorized --
| thus making them a "something you have" credential rather than
| a "something you know" credential.
| lxgr wrote:
| > They are security theater
|
| Passkeys are highly secure compared to passwords. All problems
| I know of (and there are quite a few!) revolve around
| availability, not security.
|
| All problems you do write about after this are indeed related
| to availability, but then you shouldn't call them "security
| theater".
| christina97 wrote:
| The argument is that service providers will not accept the
| reduced availability and so will deviate from the pure
| passkey way into some patchwork of security theater.
| jmclnx wrote:
| Unless this is 100% free, easy and no PI, I will tell people to
| move to Linux
| boohoo123 wrote:
| "Passwords are no longer safe, the future is passkeys. Thus you
| can log in with face, touch or a PIN"
|
| PIN - a personal identification number (aka a password)
|
| This is one of those times where there is usually an ulterior
| motive behind this decision. Most cases in the form of power
| and/or control.
| acdha wrote:
| If you're going to speculate about ulterior motives, fill in
| the supporting details so people can tell you're not just
| promulgating conspiracy theories.
| 015a wrote:
| Its a _lot_ harder to share the passkey for e.g. your Netflix
| account among friends.
| acdha wrote:
| So you think that Netflix has gone to Microsoft to start a
| multi-year industry-wide standardization process to change
| how people login because that's easier than looking at
| their own log files?
|
| Netflix didn't crack down on shared passwords when they
| were growing rapidly but that's not because they couldn't.
| 015a wrote:
| I don't, but yes; many seriously actually believe this is
| why the industry is moving to passkeys. It isn't logical,
| it isn't reasonable, but these are your customers.
| acdha wrote:
| So that sounds like an argument for better education, not
| recirculating baseless conspiracy theories.
| recursive wrote:
| Baseless? Can you think of a reason why Netflix _wouldn
| 't_ support it for precisely this reason? Their campaign
| against account sharing is widely publicized. Do you
| think account sharing is easier or harder under passkeys?
| Just because it's a conspiracy theory doesn't mean it's
| false.
| acdha wrote:
| It's baseless because it's pure speculation without any
| evidence, or even a coherent argument for why they'd go
| to so much work for something they already do at much
| lower cost.
| recursive wrote:
| I think the argument is misunderstood here. I'm not
| saying this is the _only_ reason that Netflix would be in
| favor of passkeys, just that it 's one reason, not even
| the main one.
|
| Here's the argument. I guess it's up to you whether you
| think it's coherent.
|
| 1. Netflix dislikes account sharing. They'd rather have
| two people pay for two subscriptions. They're a business,
| and are in favor of higher subscription numbers. 2.
| Passkeys make account sharing harder. Customer behavior
| modeling probably suggests that some fraction of account
| share-ers would create new subscriptions if they switched
| to passkeys. 3. Of all the reasons Netflix is in favor or
| against passkeys, this reason is in favor of them, via 1.
| and 2.
| nijave wrote:
| I haven't tried--cant you share passkeys stored in your
| password manager?
| 015a wrote:
| Yes, if you're both using the same password manager. But,
| while you live in Silicon Valley bubbleland, most people
| don't. The world's most popular password manager is
| Excel; and sadly it does not support sharing passkeys
| (or, really, passkeys at all).
| samcat116 wrote:
| You just hit the share button for the passkey in
| Apple/Google Passwords/your password manager
| 015a wrote:
| That only works if the share target is using the same
| password manager.
|
| If you asked most people "what password manager do you
| use" they would give you a blank stare; but sadly, the
| answer is rarely "I'm not using one" the answer is
| usually Apple or Chrome or whatever is built in and most
| convenient.
| vel0city wrote:
| The PIN is not a password. Two very different concepts in what
| they're actually used for.
|
| The password to decrypt your password database isn't your
| actual password to the logins contained within, its just a part
| of the process to get it.
|
| The PIN to unlock a passkey isn't the credential itself. Its a
| part of the process to be able to use the credential.
|
| Meanwhile, an account password _is_ the credential.
| dambi0 wrote:
| In some scenarios that's really a difference without
| distinction though.
|
| If I have a key to my house attached to a chain so it can be
| used to open the door but not leave the property and then
| secure it in a lockbox. If someone steals the key to the
| lockbox they technically don't have access to the house key
| but they can still rob my house
| vel0city wrote:
| Your scenario makes it so the house key doesn't matter in
| the end though; if they're able to get to the lockbox to
| use the lockbox key they're already in the house and thus
| already able to rob it regardless of whether they got the
| lockbox key. In the end your door lock did nothing for you
| at all. I don't get how that relates to using a PIN stored
| in the TPM to protect your actual password, other than
| suggesting "well your account can be hacked without even
| touching your device" which I mean yeah sure.
|
| But in the end that PIN is still different from that
| Windows/Microsoft password. The PIN only works on that one
| device and gets totally invalidated after only a few
| failures. This is untrue of passwords which usually never
| get fully invalidated and are then used across multiple
| devices.
|
| If you manage to find out my PIN to log into device A with
| my Microsoft account is 1234, you don't have access to my
| Microsoft Account in general or on device B. If you see I
| log in to my device A with hunter42 (my Microsoft account
| password), you can now log in to my Microsoft account and
| every other device I'm using my Microsoft account.
|
| Is that a difference without distinction? I'd say that's
| quite a bit of distinction! And that's only one of the many
| differences!
| dambi0 wrote:
| Which is why I was careful to say that it was a
| difference without distinction only in some scenarios.
| Namely offline attack to a physical device.
|
| In this scenario, even with the attempt restrictions the
| attacker has a couple of chances of relatively easy
| guesses, before falling back to the password protection.
| If we consider shoulder surfing, it's a lot easier to
| distinguish a four or six digit PIN than a password.
|
| I aware the PIN doesn't give actual access to credential
| and so doesn't impact online attacks. But that isn't the
| only scenario.
|
| Incidentally how much work is "in general" doing when you
| talk about the access Io Microsoft services granted by
| the PIN + TPM? It isnt zero access is it.
| vel0city wrote:
| > how much work is "in general" doing when you talk about
| the access Io Microsoft services granted by the PIN +
| TPM?
|
| I mean you can't just go to microsoft.com and log in
| knowing only my pin on a single device. If you know my
| PIN for a device, but you don't have the device, you
| don't have access to my Microsoft account at all.
| dambi0 wrote:
| And if I do have the device? And I have guessed the PIN?
| vel0city wrote:
| And if you have all my devices? And what if you have all
| my external security tokens? And what if you also have
| all my passwords? And what if you have a complete replica
| of every thought in my head? And what if what if what if
| what if...
|
| Sure. Whatever buddy. Nothing is truly secure. If they
| guessed my password as well along with my device I'd be
| in an even worse situation. At least my PIN just
| disappears forever after a few failed attempts and
| requires that physical device.
|
| Needing a physical device which wipes itself after a few
| failed attempts is more secure than having a password
| that could be used anywhere on any device however many
| times they want to guess.
|
| > without distinction only in some scenarios. Namely
| offline attack to a physical device.
|
| There _is_ a distinction in this domain though, and it 's
| pretty massive. Offline attacks at guessing passwords, if
| you fail the PIN a few times (three on most of my
| machines) the PIN gets cleared never to be used again.
| Meanwhile you can keep trying the password over and over.
| The account password on the device isn't getting cleared.
| So I can make the PIN pretty simple and easy to type in
| while making my regular password very long and
| complicated. It doesn't matter if its a pain to type in,
| because its not like I'm typing it in every time I walk
| away and come back to my computer.
| recursive wrote:
| They're secret sequences of characters that grant access. The
| rest is implementation details.
| vel0city wrote:
| A bicycle and a semi-truck are both machines with rubber
| tires to move people and things a faster speed than
| walking. The rest is implementation details.
|
| X and Y are both Z. The rest is implementation details.
| Except sometimes "implementation details" makes the two
| pretty radically different in usage.
| dambi0 wrote:
| And sometimes they don't :)
| recursive wrote:
| A semi truck can carry dozens of tons of cargo. A bicycle
| can carry dozens of pounds of cargo.
|
| A PIN grants you access to the service. A credential
| grants you access to the service.
| vel0city wrote:
| > A PIN grants you access to the service
|
| Incorrect. The PIN does not grant access to the service.
|
| If all you have is the PIN, you don't get access to the
| service. Therefore, its not the PIN that grants the
| access.
|
| If you know my keepass database passphrase, but don't
| have the actual database file, do you have access to the
| services contained within?
|
| And as acdha mentioned, the entire login workflow is
| radically different with security keys / passkeys. Its a
| radically different implementation of authentication with
| different guarantees.
|
| Do you leave SSH open on port 22 with only password
| authentication? It's just the same as using SSH keys,
| just a difference in implementation.
| recursive wrote:
| > If all you have is the PIN, you don't get access to the
| service.
|
| That depends what the service is. If the "service" is a
| session on my desktop PC, then it absolutely does grant
| access. You'll have to take my word that if I type my PIN
| into it, it will start an interactive session.
|
| My kid wants to play minecraft, but he can't because he
| doesn't have the PIN. If he did have the PIN, he could
| play minecraft.
|
| I am willing to believe that the implementation of the
| PIN is totally different from passwords, but in this use
| case, the user experience is identical. The "attacker"
| does NOT need the password.
| vel0city wrote:
| It is still not the PIN in the same way the password to
| the password vault isn't the password to an account. If
| you had a physical TPM that got removed, your pin
| wouldn't do anything. If the TPM got reset in the BIOS,
| the PIN wouldn't work. It's a step in the authentication
| workflow, but the PIN itself is not the credential. If a
| person tried to RDP to that computer with the PIN, they
| wouldn't be able to access it.
|
| If your kid fails the PIN too many times, the PIN gets
| disabled. No more PIN retries until the real password
| gets used. If they tried the password a bunch of times,
| they'd get a timeout but could come back in a few minutes
| and try again.
| acdha wrote:
| Except in this case it's really important to learn how the
| implementation works because it has meaningful differences:
|
| If you login to Google.com with a password, the remote
| server knows your password and if you are phished the
| attacker can use your password to access Google.
|
| If you login to Google.com using a passkey secured by
| Windows Hello, your PIN or biometric check is between you
| and your computer, and the passkey is used for a public key
| exchange with Google's servers. They do not know your PIN
| and you cannot be phished. That's a transformative change.
| otterley wrote:
| Before iPhones had biometric authentication, a PIN was the only
| means to unlock the cryptographic key that protects your data
| on the phone. It still is; you can bypass Face ID and Touch ID
| at any time by entering your PIN.
|
| So it's not like this is a new thing. It's the same concept,
| but applied to a PC as well.
| nijave wrote:
| The ulterior motive is compromised accounts and the support
| needed to deal with them is a tremendous waste of time and a
| liability.
|
| Switching to hardware backed authentication reduces risk and
| support. Face/touch/PIN are an additional layer to protect
| against hardware theft.
| galleywest200 wrote:
| My company uses Azure SSO so I am curious if this is just
| coincidence... but just this morning I had two (2!) separate
| desktop support technicians reach out to me today asking if I got
| my passkey set up for the company portals.
| 015a wrote:
| The software industry has _zero_ concept of how much pain and
| suffering passkeys are going to cause the average person, almost
| entirely because the average American has an iPhone and a Windows
| laptop and there 's literally nothing built-in to iOS or Windows
| that will sync passkeys between these two devices. The world's
| most popular password managers are Excel and Apple Notes, in that
| order; these apps do not support Passkeys.
|
| Passkeys are not going to happen, and its the industry's fault.
| Its a bad standard that solves some problems the industry itself
| has, by creating more problems for consumers. If you force
| consumers to move to only-passkeys, you're going to lose
| customers, and it might not even be their choice, you're just
| making the decision to lock people out.
| josteink wrote:
| > The software industry has zero concept of how much pain and
| suffering passkeys are going to cause the average person,
| almost entirely because the average American has an iPhone and
| a Windows laptop and there's literally nothing built-in to iOS
| or Windows that will sync passkeys between these two devices
|
| Then you register multiple passkeys for the website, just like
| you would register several Yubikeys.
|
| It's a 1-click process, and no HW-token required. Most people
| will be fine.
| spencerflem wrote:
| How do you log in on the other device to set up the second
| passkey?
| growse wrote:
| Using the "passkey on other device" flow, which usually
| involves QR codes.
| hbn wrote:
| What if my phone irreparably broke?
| Mindless2112 wrote:
| Then you use the "lost my passkey" process, which should
| be the same as the "forgot my password" process. Most
| services should treat passkeys like unphishable
| passwords.
|
| Passkeys do not (and are not intended to) solve the
| problem of lost credentials.
| nottorp wrote:
| They're intended to aggravate it instead.
| eikenberry wrote:
| > Then you register multiple passkeys for the website, just
| like you would register several Yubikeys.
|
| So just like Yubikeys, when you lose one of those keys you'll
| need to go to the 100's of sites where you registered that
| key and change it. This is not a good plan.
| devsda wrote:
| > Most people will be fine
|
| this assumes majority of population has the means and
| discipline to purchase, register and maintain multiple pass
| keys and/or devices.
|
| There's a world outside the developed countries where a
| typical yubikey can cost 10-20% of a family's monthly income.
|
| A family where phones are the only tech devices in the
| household and the phone is typically in a 100-150 USD price
| range and costs about half of monthly income.
|
| By making passkeys mandatory we are asking them to get
| multiple of yubikeys/phones per person in the family ?!
|
| They cannot afford to and will not maintain multiple passkeys
| or backups.
|
| Orgs will have to build a way to help them recover their
| accounts easily without further costs or just ignore them as
| "edge cases".
| 015a wrote:
| Many services which support passkeys do not support multiple
| passkeys. The big ones have figured out that we need support
| for multiple, but sadly just like with Yubikeys not everyone
| got the message on that.
|
| But, its like I said: You have zero concept of the struggle
| that is already happening and will continue to get worse.
| That's what I mean when I say that the software industry has
| zero concept: You think you have the solutions, but you
| actually haven't even grasped the full scope of the problem.
| jf wrote:
| An alternative viewpoint to consider is how much pain and
| suffering passwords cause large companies or identity
| providers.
|
| One example: Large organizations often spend $1m/yr on password
| resets alone.
| vorpalhex wrote:
| "Hello, IT, my toddler accidentally dropped my phone in the
| ocean. I can't log into anything now. No, I can't restore my
| iCloud keys onto my Windows laptop. Please help."
|
| I suppose corporate gets to overnight you a yubikey in 2-3
| days?
| 015a wrote:
| That's why I very specifically said: Passkeys solve problems
| that corporations have, by moving the problems on to
| consumers.
|
| Our industry was done writing reliable, quality software
| years ago, so it shouldn't come as any surprise that we want
| to keep going in that direction. Passwords have such an
| obvious, fantastic, beautiful quality in how when all else
| fails you can verbally say out loud "my password is X C J 5
| 4..." Its the ultimate form of reliability: non-digital,
| spoken or written language.
|
| Passkeys throw that away. I don't care about any of the other
| arguments. Our industry wants to build less reliable
| software, so we built passkeys. I don't know why we're
| obsessed with building things that are less reliable instead
| of more reliable, but we are. Its sad, its insane, and
| frankly I'm getting so damn tired of trying to push for
| reliability every day and instead seeing Microsoft just throw
| weight around, get hacked, throw weight around again, get
| hacked again, and somehow still reap respect for their
| position in matters of security.
| mxey wrote:
| Apple's password manager is available for Windows, although I
| don't know if it supports passkeys.
|
| Also, there are mechanisms to use a passkey from another device
| (over Bluetooth I think?)
| dblitt wrote:
| Yes, its called "hybrid transport", and its a flow where a
| laptop presents a QR code to a mobile phone, who then sets up
| a BLE connection for one time use of the passkey.
|
| https://www.corbado.com/blog/webauthn-passkey-qr-code
|
| (Not sure how the "cloud assisted" part of caBLE works)
| nottorp wrote:
| So... you need to carry two electronic devices for this so-
| called security solution?
| helloooooooo wrote:
| No... you can also sync with iCloud Passwords, or use a
| hardware token, like a Yubikey.
| nottorp wrote:
| So a Yubikey is not an electronic device that you need to
| carry?
|
| iCloud Passwords don't run on an iPhone that is an
| electronic device that you need to carry?
|
| Those electronic devices that you mention don't each
| store the keys in a proprietary format and you can't
| access them without the vendor's cooperation - i.e.
| vendor lock in?
| munchler wrote:
| Apple has a password manager? What is it called? I'm a
| typical iPhone/Windows user and have never heard of it.
| fckgw wrote:
| Apple has had a password manager baked into iOS for 11
| years now. It was initially called iCloud Keychain and
| buried in the system settings, now it's been broken out
| into the "Passwwords" app as of iOS 18. There are
| extensions for Chrome to use the app on Windows PCs as
| well.
|
| https://support.apple.com/en-us/120758
| 015a wrote:
| iCloud Passwords is not built-in to Windows, so users have to
| know to install it. Most don't. Most iPhone users don't know
| they're using iCloud Passwords. In fact, many aren't (because
| it is oftentimes toggled off in settings because their
| grandson told them to do it or some other b.s. like that).
|
| And, also, it _barely_ works, if the wind is blowing in the
| right direction; was clearly built by a long forgotten team
| to check a box.
|
| They've also released a Chrome extension, but no Firefox
| extension (actually, they did release a Firefox extension,
| but it only works on MacOS). Again, you have to know to
| install this.
|
| The Windows Hello bluetooth system for passkeys has never
| worked for anyone I've seen try to use it. The display &
| scanning of the QR code works better. But, that only works if
| the passkey was generated on iOS and is being used on
| Windows; if the passkey was generated on Windows and needs to
| be used on iOS, you're probably screwed (I've never seen
| Windows try to pop open its webcam, if the device even has a
| webcam, to scan a QR code on another device.)
| lima wrote:
| It's not quite as bad, your average user with an iPhone or
| Android phone will be fine. Just scan a QR code on the Windows
| machine and log in with the phone.
|
| The problem is that the UX for this is extra super confusing,
| and people will end up with passkeys that aren't backed up
| anywhere and get locked out of their accounts.
| gpm wrote:
| "Just"? You just added minutes of figuring out where your
| phone is and how to scan a QR code to a log in process.
| ylk wrote:
| Find your phone: https://www.icloud.com/find/
|
| Scanning a QR code: https://support.apple.com/en-us/102680
|
| The time investment could even be worth it, since "Signing
| in with a passkey is three times faster than using a
| traditional password and eight times faster than a password
| and traditional MFA", according to the article.
| doublerabbit wrote:
| Find your phone: https://www.icloud.com/find/
|
| -> I have that turned off
|
| Scanning a QR code:
|
| -> My camera lens and my front one doesn't work. It
| doesn't bother me, and feel no need to fork out to
| upgrade. I use a digital camera if I want to take
| pictures.
|
| I'm not the only one, I know many of folk who are in the
| same situation from drunken nights out.
|
| What then? Or people without smart phones?
| indrora wrote:
| I don't have many things against passkeys for _corporate_
| accounts, but I don 't think we're going to fully destroy
| passwords in the personal space. To the hardline Passkey-for-
| everything advocates, I pose the following situation:
|
| In your sleep, your house has burned down. You have zero
| devices, and your backup keys are stuck in a building you do
| not have access to for another several hours. You have made
| it out of your home with: Your wallet, containing $20 cash, a
| handful of slightly melty credit cards, an ID that is almost
| readable, and your keys. The credit cards are fucked and will
| need to be replaced. Your ID is mostly readable.
|
| This is the situation that I pose for most people to try and
| get undone from. I then amp it up another notch:
|
| you have no job and are unemployed currently. You cannot make
| use of any insurance system as you have been deemed
| "impossible to insure" due to your status. You currently live
| in a cardboard box behind a restaurant in downtown.
|
| And before you go "why would a homeless person need email",
| it's required for lots of services, as is a phone number that
| can at least have voicemail at it (this is a service that
| Futel^1 provides in some places). You can't assume that
| physical artifacts will continue being in the possession of a
| dishomed person. One of the common reasons for losing all
| your personal effects in this situation is the state
| literally taking everything down to your clothes away^2.
|
| ^1 https://futel.net/ ^2
| https://www.realchangenews.org/news/2024/06/05/sweeps-
| triple...
| janalsncm wrote:
| All of this makes me realize that availability is my
| biggest risk. My passwords are all 30 character random
| alphanumerics and I have none of them memorized.
| indrora wrote:
| This is, ironically, why I ended up with 1password over
| bitwarden: Their recovery process is down to "You can
| recover with paper, or another member of your family with
| access can break you into jail to get your account back
| up."
|
| I have tested this process with my partner. the only
| thing that I _cannot_ replace is the TOTP token to add
| new devices (however this is bypassed when recovering
| from paper). I have legitimately considered etching the
| recovery data into a small glass (borosilicate) dish
| using selective laser etching.
| fragmede wrote:
| For mainstream people uninterested in such things, this
| isn't a solution, but since the question was posed to "me",
| one way back into digital life that is not passkey specific
| is https://dangerousthings.com/product/apex-flex/
| 015a wrote:
| What if the passkey was generated on Windows and you're
| trying to sign in to iOS?
| WillyWonkaJr wrote:
| Proton Pass does this. It's browser extension will also
| generate and store passkeys in your Proton account making it
| accessible to any device.
| Nifty3929 wrote:
| What is a browser extension? Do I need to take a class on
| that? Where do I buy one?
|
| Really, not being snarky here. If I asked my dad to install a
| browser extension he would drive his laptop to my house and
| ask me to install it for him. If I wasn't available - then it
| just wouldn't happen.
|
| My mom can't see, so maybe she's okay?
| 015a wrote:
| Not built in. The number of Windows users who use Proton Pass
| is a rounding error toward zero.
| thedanbob wrote:
| If Microsoft really wants to push passkeys, why do they require
| Microsoft Authenticator for passwordless accounts? I already have
| a passkey set up and I'd be perfectly happy to delete my
| password, but I can't because I don't want yet another
| authenticator app exclusively for an account I barely use.
| tialaramex wrote:
| From the HN pushback I think this will end up like IPv6. I get to
| have nice things and some others likewise - many people get to
| repeatedly say "Nice things are impossible" and roll their eyes.
| I guess they're having fun in their own way?
|
| It's nice when we build a non-brainer technology which gets
| adopted at scale by default, as happened for TLS 1.3, or even
| when other motives overwhelm the instinctive conservatism (e.g.
| Let's Encrypt) but that can't always happen and it looks like for
| WebAuthn the conservatives are going to stick by passwords "From
| my cold dead hands" etc.
|
| One problem with HN in particular is that there are a lot more
| decision makers here, so more people whose conservatism means
| they're going to build, promote and demand worse solutions since
| the better option is in their minds impossible. That's
| unfortunate, it means there's a good chance that over the next
| years I'm going to be using more important services which have
| terrible authentication on account of somebody senior said
| "Passwords are good, we should require passwords" and anybody
| disagreeing was hushed or worse fired. So that's not great, but
| it is what it is.
|
| Anyway, for the few people who get why this is a good thing but
| understandably don't trust Microsoft (or Apple, Google, Facebook,
| I dunno, Epic Games?) I have a suggestion: All of this technology
| also works fine with a Security Key, which is a thing you can buy
| from Yubico (or several other outfits, but Yubico is easiest if
| you have no idea what you're doing) for like $25. And if you -
| like me - use Security Keys those "But what if I lose it?"
| questions can be answered by Technology Connections' favourite:
| The magic of buying two of them.
| lxgr wrote:
| Security keys (i.e. "roaming authenticators" in WebAuthN
| language) have significant practical usability and availability
| downsides.
|
| > "But what if I lose it?" questions can be answered by
| Technology Connections' favourite: The magic of buying two of
| them.
|
| And the magic of having to access both of them every time you
| create a new account anywhere, which probably means you'll keep
| them both close by - increasing the availability risk.
|
| A more realistic recommendation would be to use an open source
| FIDO backend such as Bitwarden or Strongbox that let you cross-
| platform sync and, worst case, export your credentials if the
| vendor goes down a bad path.
| water-data-dude wrote:
| Wait.
|
| "In the two years since passkeys were announced and made
| available for consumer use, the FIDO Alliance reported a few
| weeks ago, "passkey awareness has risen by 50%, from 39% familiar
| in 2022 to 57% in 2024."
|
| I don't think that math works? Am I misinterpreting something?
| Eisenstein wrote:
| 50% of 39% is 18. Add to 39 to get 57%.
| silentguy wrote:
| (57-39)/39 ~= 46
|
| I think they meant 50% increase from the 39% .
| jedberg wrote:
| That's why we use points when talking about changes in
| percentages. :)
|
| Imagine it was 100 people. 39 were aware. 50% of that is 20. So
| now 57 are aware, which is 18 more than before, which is pretty
| close to 20.
|
| So yeah, it was a change in 50%, but it was only 18 points
| higher.
| gavinhoward wrote:
| One thing passkey proponents forget is password-authenticated key
| exchanges (PAKEs).
|
| PAKEs use passwords, and they are unphishable. That is the
| direction we should go to avoid vendor lock-in.
| jf wrote:
| Does PAKE protect against scenarios like "password written on
| sticky note", "fake login page hosted at login.nnicrosoft.com",
| or "scammer impersonating IT staff"?
| gavinhoward wrote:
| From the first, no.
|
| It does handle the second and third, IIRC.
| lima wrote:
| It doesn't handle these either - what stops the user from
| entering their password on an attacker-controlled phishing
| page?
|
| Passkeys work because the user can't be tricked into
| entering their private key on a phishing website.
| gavinhoward wrote:
| Browsers could help with this. They just don't.
| growse wrote:
| Where's the vendor lock-in?
| gavinhoward wrote:
| Cloud sync.
| growse wrote:
| That's not an inherent feature of passkeys.
| gavinhoward wrote:
| True, but you either have that or a catastrophic loss of
| identity if you lose it.
| growse wrote:
| Only if you tie your identity to a single cloud provider?
| gavinhoward wrote:
| I mean if you don't gave cloud sync, then if you lose
| your phone, you have lost those passkeys.
| tomjen3 wrote:
| Passkeys are an excellent way to lock yourself into your current
| device and out of your accounts if you ever move away.
| addicted wrote:
| I haven't dug into this but I must be missing something with
| passkeys.
|
| It's the same issue I had with getting a Yubikey.
|
| The odds that I lose a piece of hardware that I'm carrying on me
| seems orders of magnitude greater than the odds of having my
| password cracked.
|
| How does one recover from a lost device (other then backing up to
| Apple's private cloud in which case you're beholden to them
| forever to be able to access your own accounts).
| Biganon wrote:
| I have two Yubikeys, one of them never left my home
| mgulick wrote:
| So do I, but this is annoying because I need to have physical
| access to both of the keys when setting up 2FA on an account,
| or hope that I remember to add the backup yubikey when I get
| back home.
| vorpalhex wrote:
| The great thing about bitcoin crap is that it's real world
| public/private keys used by the general public.
|
| And oh man tons of almost millionaires have lost their
| backups. Tons of people still have stolen credentials.
| Basically nobody can "do it correctly".
| EvanAnderson wrote:
| The "have a backup token" workflow seems like tedious make-
| work. I have to remove it from its "safe place" and keep it
| proximate to my primary token while I enroll it in everything
| my primary token is enrolled in.
|
| The workflow to enroll a new backup token (when the primary
| is lost and the backup becomes the primary) also seems like
| tedious and error-prone make-work.
|
| It would great if I could load my backup token's public key
| into my primary token and export a copy of the primary
| token's secrets, encrypted with the backup token's public
| key. When I lose my primary token I would only need to
| restore my backup token and be back in business. That
| eliminates the make-work of enrolling on the backup token.
|
| Of course, this scheme allows for "cloning" of a token so
| it'll never be allowed by the "security" nannies who know
| better than us.
| xur17 wrote:
| > It would great if I could load my backup token's public
| key into my primary token and export a copy of the primary
| token's secrets, encrypted with the backup token's public
| key. When I lose my primary token I would only need to
| restore my backup token and be back in business. That
| eliminates the make-work of enrolling on the backup token.
|
| Yes, exactly this. At one point I had a list of services
| that I utilize along with a list of the yubikeys I had
| enrolled on each. My plan was to enroll my backup key
| periodically (retrieving it from its safe place to do so).
| This ended up being a giant pita, and despite my best
| efforts, the list became out of date. In the end I just use
| Google Authenticator for everything since I can back it up.
| mihaaly wrote:
| I have 3, yet having two pretty important systems where only
| one (a single 1!) yubikey allowed to be registered or only
| support phone app based MFA. (having the misfortune being
| made to work with about two dozens of web services, it is
| soooo twentyfirst century putting everything into the clouds
| regardless if it is a good idea or not)
|
| I ended up disabling MFA in one case - with the most terrible
| flavour of implementing MFA - because f you!, they ask me to
| re-login on my stationary main home computer repeatedly for
| 'security reasons' (idiots) and I too many times end up the
| particular MFA gadget being somewhere else than at the reach
| of my hand, obstructing my efforts and workflow too often.
| Using computer systems are wasting efforts nowadays rather
| than helping, with the forcing through of cutting edge
| advanced 'solutions' without thinking about the broad picture
| (the curse of single-mindednes).
|
| And then we did not even talk about my bank, completely
| different animal giving no shit about third party physical
| keys, yet another different way to get blocked if not done
| exactly as those particular fellas dreamed of in cheerful
| company meetings not caring collaborating on generic
| approaches.
|
| MS is particularly bad and not to be trusted with their
| "insightful design" (it is told this way in the article,
| HAHAHA, funny guy) solutions f-ing up two things while
| pushing a marginal one through. With important ones the ratio
| is higher.
| Glyptodon wrote:
| I have a second one but its pointless, I'm bad about
| registering it as a backup token in the few places that even
| have UIs for doing it, most places don't even let you
| register more than one.
| swozey wrote:
| I'd appreciate it if they let me block specific countries, etc
| from even attempting to log in. You can see the failure attempts
| somewhere in your user settings and I have them all day long from
| countries I'll never step foot in and quite a few adversarial.
| agentultra wrote:
| Aren't passkeys centrally hosted? So if MS gets breached or
| decides I don't matter they can just lock me out of my life if I
| host my passkeys with them?
| physicsguy wrote:
| I use Bitwarden. I don't mind passkeys ending up there. But i
| want them all in there. I find the UI/UX is really poor with
| browser extensions, etc. and preferentially trying to use the
| OS's password manager to store passkeys.
| mgulick wrote:
| I think technical people understand the mechanics of using
| Passkeys, having them backed up to multiple devices etc, but
| there's no way my 70 year old father is going to be able to
| understand that. He barely knows the difference between the
| computer login and his gmail login. My parents are also not
| wealthy-enough to have Apple take care of all of this for them.
| He has a hand-me-down Linux laptop because all he needs is Google
| Chrome. Thankfully I've been able to teach my parents to write
| down their passwords in a password book.
|
| I can't tell you how many times I've ask my father "what's your
| google password" and he says "I don't have a google password". I
| like the idea of eliminating passwords, but inevitably his phone
| is going to break or his computer is going to crash and he needs
| a way to recover.
| it_citizen wrote:
| The password book of every person around me become awful over
| time. They don't distinguish between uppercase and lowercase,
| they write bad notes, most of the content is outdated,
| sometimes there duplicates and overall cause me more headache
| than anything.
|
| I hate password books. I don't have a better solution though.
|
| For now, I teach them to use chrome password manager for now
| and log in their chrome account when they need help. It sucks
| too. But at least I don't get angry with their notes.
| koolba wrote:
| > 99% of users who start the passkey registration flow complete
|
| What about the flow where 99% of users don't know how to back up
| and restore passkeys and get permanently locked out of their
| accounts?
| choeger wrote:
| And passkeys only work with Microsoft OS, Microsoft Browser or
| some other thing that Microsoft controls?
|
| Not hat I would ever imply that Microsoft has anything than our
| best interests in mind...
| int_19h wrote:
| It is an open standard that is supported by all major OSes and
| browsers.
|
| In fact, I would wager that the majority of current passkey
| users are on iOS (since Apple has been pushing this for a while
| now, and it's nicely integrated).
| Nifty3929 wrote:
| https://www.microsoft.com/en-us/security/blog/2024/12/12/con...
| myflash13 wrote:
| How do I backup my passkeys? I can print out a hard copy of
| passwords and even 2FA code generator strings, but I haven't seen
| an easy way to export and import passkeys. This is a problem.
|
| If it were as simple as printing out a list of QR codes or URL
| strings I would be happy, but so far no password app I know of
| supports this.
| justinholt wrote:
| At the moment, export/import is not part of the "Passkey"
| standard. The FIDO Alliance has a draft of the Credential
| Exchange Protocol that would allow such actions. Allowing the
| trivial export of a passkey would end up defeating the
| cryptographic protections they offer.
|
| https://www.bleepingcomputer.com/news/security/new-fido-prop...
| dcchambers wrote:
| If you are comfortable using a cross-platform app like 1password,
| then passkeys _can be_ a pretty great user experience even across
| ecosystems.
|
| But Passkeys have a huge problem: They assume you will never have
| your device(s) stolen or broken or otherwise made inaccessible.
|
| What happens if you're out of the country on holiday and your
| phone/laptop gets stolen and you need to log into your account(s)
| from a brand new device? You're mostly shit out of luck if you
| use passkeys. Especially because most peoples' backups/account
| recovery is a google email or icloud account which...requires you
| to have a known device handy to access them or set them up on a
| new machine.
| apitman wrote:
| A lot of the arguments I'm seeing against passkeys are
| essentially that they are worse for power users who already have
| a password manager. But they're not mutually exclusive. I've been
| using bitwarden to store some passkeys. The UX is excellent.
| Everything is seamlessly synced across Linux, Android, and
| Windows.
|
| I do worry a bit that using a passkey tends to disable MFA
| requirements, so basically anyone with access to my bitwarden
| vault can log into those services.
___________________________________________________________________
(page generated 2024-12-17 23:01 UTC)