To be fair, a lot of it is moving to drones killing drones.
My prediction is that future wars will actually involve increasingly fewer humans and will be more about tech+manufacturing vs. tech+manufacturing. And of course insurgents + lowcost tech vs. increasingly nonlethal hightech.
This would allow wars to continue without as much of the growing political backlash.
Those who make fun of crystals fail to realize that technology is literally a race to who can etch the finest/smallest inscriptions into the most perfect crystals. Followed by who can best feed the knowledge of the world into those very crystals via optimal mechanations such that those crystals produce intelligence.
Interesting theory but 20 bytes seems like a lot to match given only the entropy of dates. Can you make this theory quantitative, IE show that with the entropy of n, arbitrary date, and choice of rand implementation there are sufficient degrees of freedom to hit 20 bytes?
Profit incentives work great for the person paying. The problem is you are no longer the person paying, your insurance is. And insurance pays for filling cavities, they pay nearly nothing for preventative services.
It's easy to say add inspections. What specific regulations/laws would you put in place and how do you prevent regulatory capture?
Randomly generated strong passwords for all practical purposes are just as good as passkeys and keep you as the user in control. If you really need to copy/paste between a laptop and mobile or give it to a friend/family member, you can.
What do passkeys offer users that rand strong password + password managers don't?
They have to be transmitted. They (or their hash) have to be stored. And so so many get that wrong.
There is nothing to prevent you from entering your super secure unique password on the wrong site if you get phished.
Passkeys don’t get transmitted. They’re used for cryptographic signing.
Passkeys can’t be entered on the wrong site, the sites they work on is an inherent property of the key.
You can’t store a passkey wrong on the server, it’s a unique public key. If your entire database is stolen, it’s useless. No one else can login with your credentials because they don’t have the private key.
Unique strong passwords, TOTP, 2FA, one time sign in emails, none of those offer this stuff.
Passwords are fundamentally broken. They cannot be fixed. Cryptography is the solution in passkeys are the implementation.
Everyone knows to hash passwords now and browsers basically enforce SSL. This is not a practical differentiator.
>Passkeys can’t be entered on the wrong site, the sites they work on is an inherent property of the key.
They are still susceptible to malicious enrollment. If a user is convinced a fake site is real, to the point that they are opening their password manager to copy the password to it, you should assume they will do the equivalent with a passkey (re-enroll attacker's key or register attacker's passkey).
>If your entire database is stolen, it’s useless.
As are databases containing strong randomly generated password hashes. What is your threat model here, they somehow forgot to hash their passwords yet they are still hashing session tokens, storing customer data in completely separate databases, safely storing private keys, etc.? It requires quite the strawman scenario to apply.
> They are still susceptible to malicious enrollment. If a user is convinced a fake site is real, to the point that they are opening their password manager to copy the password to it, you should assume they will do the equivalent with a passkey (re-enroll attacker's key or register attacker's passkey).
This is only technically true because of the definition of what a passkey is is vague.
Hardware Attestation solves this problem and is "good actually". The issue with attestation is when site attempt to restrict which enclaves/sources can register keys. But if you don't restrict who/what can register keys, attestation is super useful for preventing this exact issue.
When you register your key initially you establish your hardware attestation parameters. The attacker cannot know those parameters unless they were the ones to initially register you for the site as the public attestation signature is unique per-key and the private one per-use with the public one verifying the private one.
So if you have remote attestation you can verify whether the source presenting the signature for auth is the same source that created the signature and trivially block MITM attacks. Likewise for more complicated custody/proxy chains.
This just by itself largely solves MITM key re-enrollment attacks but tech camps that support passkeys either ideologically oppose attestation (due to understandable enclosure fears) or enforce hardware attestation for enclosure purposes without bothering to address MITM/signature origin checks.
Can I do hardware attestation across several devices yet? My desktop, my phone, a console, my girlfriends phone of a different brand if I need to log into a shared account, etc?
It seems like one of those things that only works if you're sticking to one ecosystem.
Yes. You can register as many different passkeys as you want. Any limitation in passkeys registration quantity is a limitation of the website/app itself and not a limit of the spec, etc.
? If a website sucks and can't support multiple passkeys that's not a flaw of passkeys. It's a flaw of the website. You could make the exact same argument for TLS or 2FA or every other security feature.
If the developer fucks up the website/app, that is their fault and not a failure of the technology.
>that is their fault and not a failure of the technology.
Respectfully, you should consider reconsidering this mindset. The best engineers and tech designs take into account not only how users will use a technology but also how they will misuse it.
Only in theory. Suppose you are a bank, which enclaves/sources/devices do you support vs. not support? What do you do for users on a desktop PC that don't have an enclave? Phishing sites will leverage your weakest enrollment option.
Strictly speaking it's mainly hardware attestation but it's technically "hardware based passkeys" and "remote attestation". So if you rely on attestation in general and don't restrict the attestation source it works just as well.
Software passkeys can be stolen if the client is compromised but they aren't vulnerable to MITM or phishing as long as attestation is used.
> which enclaves/sources/devices do you support vs. not support?
You support all of them and prefer the strongest configuration for the source available.
If you've registered a hardware based key with attestation and then an attack tries to intercept that via phishing or MITM, the key already has its capabilities established and if you try to use the key without attest it should fail.
If you register a key without attestation support then you may be vulnerable to MITM or phishing but you can't intercept a user/their passkey with a stronger set of capabilities and downgrade them.
Stealing passwords is already an incredibly rare attack nowadays. The attack is almost always on the cred reset path. Suppose a user loses their phone with the secure enclave and wants to login to your site using their laptop without a secure enclave.
Are you really going to block that cred reset on the grounds that it's a downgrade? You're going to have a lot of users calling your support asking why they can't login after switching devices.
So you allow it, then oops it was not a laptop, it was a phishing site.
The argument I'm making is that the only MITM/phishing vulnerability is in the initial passkey registration and not in the auth.
So once you have a passkey and the flow supports attestation, as long as you use the passkey you are effectively immune to MITM and phishing.
Now if you input a password or recovery code or whatever and use that to register a new passkey that's initial passkey registration again and not MITM or phishing of the passkey itself. The reason this matters is because you can register as many passkeys as you want. Say you sign up and log in on your phone. Now you register a passkey on the phone. You want to log in on your laptop, use the key from your phone to log in and register one for the laptop as well. Now you lose your phone or your laptop, you use the other to log you in and set up a new passkey for that device.
Once that initial passkey was registered the auth process is pretty watertight and each device you regularly use gets a new key after auth so you generally always have at least one device that you can use to get into your others.
Now of course if you only have one device and it gets destroyed or if all your devices are destroyed in a fire or flood or whatever then you have to go through the untrusted reset/re-registration flow but in all other scenarios you always default to the passkey-based "use another device you own" methods to register new keys.
TLDR: the point is that you very rarely ever do a true cred reset. The flow itself incentivizes multiple passkey auth methods such that bootstrapping new keys from an untrusted environment is rarely if ever required. This works best for "core services" like your email/google acct/apple acct/microsoft acct where you are generally expected to want access to them anywhere you do stuff so the passkey flow is best pared with SSO to increase the odds you've used the acct on at least one other device.
The phishing site will say something like "Your passkey is out of date, click here to create a new one" I call that cred reset since it is similar to password reset, perhaps some sites support multiple passkeys, in that case the phishing site will use the register new passkey path instead of reset existing.
Phishing sites already frequently target the reset/create-new-password path because it's actually easier to get a user to generate a new password vs. trick their password manager. Plus 2FA is usually required anyway since no 'remember me' cookie is avail so a password reset is equal in difficulty to a password login.
That method still works just fine with passkeys right?
The key problem is that sites have made users so used to having to generate a new password/credential that they think nothing of it. It's something you just do every few months for most websites esp. secure websites like banks. Even on the same device users are being trained to generate multiple passkeys, one for chrome, one for safari/apple, how about a third for the phishing site.
> That method still works just fine with passkeys right?
Kind of? But it really depends and there's a lot of edge cases the phishing website would have to dodge to avoid breaking the custody chain.
If you force the user down to "use your password/security questions/whatever" to auth and create a new key then yes phishing is still viable here but one of the key advantages of pushing for a passkeys-first approach is that you can make the other auth methods harder. i.e. mandate password + 2FA as a strictly backup method instead.
> The key problem is that sites have made users so used to having to generate a new password/credential that they think nothing of it. It's something you just do every few months for most websites esp. secure websites like banks.
Yep and passkeys explicitly exist to eliminate this behavior.
> Even on the same device users are being trained to generate multiple passkeys, one for chrome, one for safari/apple, how about a third for the phishing site.
Well here the caveat is that the phishing website would have to force the user back down to password-auth or security questions or whatever other "weak" method and then use that to create a passkey but not have perms to do anything else.
Now if the phishing site tries to MITM the actual passkey registration flow there are a lot of ways to detect a phishing attempt and terminate the registration and alert the user through alternate contact methods.
TLDR: there are probably still ways to execute a phishing attack but to succeed they have to be far more sophisticated and there's countless ways to accidentally break the passkey auth chain in a way that halts the attack.
> (re-enroll attacker's key or register attacker's passkey).
What is the mechanism to do this? As I understand it, the passkey is basically a public/private key pair. You'd have to download the attacker's key pair into your passkey system? What passkey system allows you to provide a key pair, rather than always generating one? I'd like to see a step-by-step walkthrough that doesn't involve a straightforward phishing scenario, or running privileged commands on the users computer (if you can do that, all bets are off.)
How? Public keys are public keys. They are designed for full disclosure. They are "leak proof" in the sense that leaks should not ever matter. The useful thing about public key infrastructure is that it asymmetrically moves the security threat to managing the private key, which is in the user's hands, and away from the public key. With a strong password I have to assume that both my Password Manager is up to the task of not leaking it and that the remote website handles my password correctly (including salting and hashing and not leaking and not using a hash algorithm with known collision flaws and not using a hash algorithm with large well known rainbow tables, etc…). With a passkey I mostly only have to worry that my Password Manager is up to the task, those are the threat models I get to worry about, I no longer have to worry about if a remote website is keeping pace in the ongoing arms race because all they have is a public key that I don't care if it leaks.
Going to be pedantic, and suggest you are always safer with nobody having your public keys that have no legitimate reason to do so. Is it dangerous in and of itself? Is it very likely to cause you a breach? No. But does it in some way expand the attack footprint, however theoretically? Yes. At least in the age of AI.
Here's one way to screw it up: make the public key the password. Normally only the user and the site know the user's public key for a given site, so it's as secure as a password, and nobody notices the problem.
I don't know how you could screw that up and not break the UX flow in a way that would have some sort of noticeable hiccup, given the Webauthn API as it has been standardized. The response to a Passkey challenge includes only a short fingerprint or "unique name" of the public key, not the full public key. Off the top of my head I think you only see the full public key in registration steps, and then if you try to re-register a key most Passkey implementations are going to enroll an entirely different key.
I'm sure that there are big enough fools out there, I'm just thinking there might be signs they are doing something wrong in that case.
The article describes a straightforward phishing attack that works specifically against accounts that are _not_ protected by passkeys:
> Depending on which multi factor method the account uses, the victim sees a matching fake screen, whether a one time code prompt, an authenticator app number match, or an SMS page.
The only sense in which passkeys have anything to do with this at all is that the attackers used the word "passkey" in their emails. When a phishing campaign with the subject line "Your Mailbox is Full, Log In to Fix Now!" succeeds, that does not demonstrate an interesting vulnerability inherent to your mail server's mailbox size limits.
Right, if you phish the credentials to an account that is not protected by a passkey, one thing you can now do is set up your own passkey on it. That's exactly what passkeys would've protected the victim against!
The other articles you've linked also describe attacks against accounts that allow non-passkey logins, or attacks that require a compromised browser.
There will never be a login that doesn't involve a potentially compromised device/OS/browser/password manager. As long as using a passkey means using those things too, having a passkey isn't enough to keep attackers out of your accounts. They can be pretty good about keeping legitimate users out of their accounts though. You just have to weigh that risk against the risk of you falling for a phishing attack.
Security is never perfect, if your device is already compromised, you have bigger issues. None of the traditional methods would protect against compromised devices anyway.
The point is that passkeys significantly reduce the attack surface.
In this attack, it sounds like the key step was that the user entered their username and password, thinking they were preparing to enter a passkey. It wasn't the passkey system itself (which would prevent this attack), it was the transition from password → passkey system that was attacked.
In any case, if you can get the user on the phone and convince them to let you walk them through a bespoke auth flow, I doubt there is any auth mechanism that would stop this. This is why every auth system these days is constantly telling you "We'll never ask for X", because at that point, the game is over.
> In any case, if you can get the user on the phone and convince them to let you walk them through a bespoke auth flow, I doubt there is any auth mechanism that would stop this.
Exactly. Passkeys can't solve the problem of phishing. At best it only makes it more difficult. Phishing is less of a concern to me personally than losing my access to my account because of the complexity and fragility of passkeys. I've read enough horror stories, even from very capable people, about people who were screwed because they thought they were doing the right thing by setting up passkeys. Passkeys sound like they might be great for many other people. My vulnerability to phishing doesn't justify the risk of passkeys.
That's like saying that there's nothing wrong with passwords, it's a bug in the human that can't tell the difference between their bank's website and some random web form with their banks logo slapped on it created on wix.com
Attacks on passkeys have been because of flaws in the OS, or the browser, or the password manager, but none of those things are going away any time soon. Passkeys depend on those things, which means they aren't are solution to the problem of phishing. They just make phishing harder.
Passkeys also make things harder for the legitimate user though, and there's a very real question of whether the protection they offer is worth the trouble.
You're arguing theory and not practice. In theory they're better of course. The problem is the implementation. And implementation is a mess because everyone is trying to lock you into their own little ecosystem.
Exactly! Whereas passwords are extremely flexible and can be stored, managed, and written down in numerous ways that are vendor-independent. Want to store your passwords on sticky notes in a safe? Go ahead! Want to use Bitwarden? Yep, you can. KeePass for offline storage? Yes! With good password hygiene (128-bit entropy, never reusing passwords) there is virtually no risk, especially with 2FA added.
You can (and should) do the same with passkeys. Like SSH keys, they're just text.
Save a passkey in Bitwarden, then export your vault as JSON. You'll see a nice plain text JSON block with your passkey that you can print, or backup, or import into whatever replaces Bitwarden.
> There is nothing to prevent you from entering your super secure u quiet password on the wrong site if you get phished.
You replied to someone talking about password managers, which objectively do exactly that.
> Unique strong passwords, TOTP, 2FA, one time sign in emails, none of those offer this stuff.
And Passkeys don't offer portability, user choice, or user control.
Cryptography may be a solution, passkeys are one technical implementation that at is core is designed around smartphone-first, vendor-first, brand-loyality-first thinking.
password managers do not do that. open up your password manager, press "copy" on the password, and then paste it into a random website. it will paste it.
(i think 1password just recently enabled an option that will warn you if the website is different than the one it has, but it still lets you paste it)
You can not use a passkey on the wrong site. Period. They’re unphishable.
Short of somehow talking a user through finding the full private key and getting them to send that to you, there is no way to trick a user into giving you what you need to get into a website impersonating them.
That’s absolutely not true with a password manager. They may TRY to prevent you from ACCIDENTALLY entering it on a website, but they don’t stop you.
> Short of somehow talking a user through finding the full private key and getting them to send that to you, there is no way to trick a user into giving you what you need to get into a website impersonating them.
It is Schrodinger's Bob - Both technically literate enough to know how to do that, while also not being technically literate enough to spot the phish or determine why autofill isn't working/the password manager isn't matching.
This is where Passkeys shine, in an edge-case user that is neither of the two most common user types. Basically a unicorn situation.
Copy and paste is not a skill that requires much technical literacy. I've not seen a Password Manager that makes the copy button hidden or hard to find or need much technical skill to use.
Many "legitimate" websites, especially corporate "SSO", accidentally train users that autofill just doesn't work some of the time. Example Corporation's SSO configuration generally has users put their password into auth.example.com, except when the app in question is using some weird SAML flow and accidentally ends up at saml.example.com or auth.okta.com. An old legacy internal app still needs the password inputted in an HTML Basic Auth prompt due to a redirect through oldauth.example.com. The user learns to just copy and paste and have no idea why autofill works on some internal apps and not others because they have no idea what SAML is or why a legacy app is special/different from modern ones.
It happens on the public web, too, to a lesser extent. A website goes through a "rearranging deck chairs phase" and can't decide if id.example.com is cooler than auth.example.com or if they should just put login only on top level example.com and flip back and forth over a few weeks as different internal teams "win" or various A/B tests run.
>It is Schrodinger's Bob - Both technically literate enough to know how to do that, while also not being technically literate enough to spot the phish or determine why autofill isn't working/the password manager isn't matching.
you must not work in regular corporate environments. this happens all the time.
yes, they know how to hit the big "copy" button but don't know how to debug an extension.
take a year or two to work security (or general IT support) in a non-tech-company corporate environment, and get ready to have your socks blown off. people become exceptionally literate with things they interact with all day (excel is great example of this) yet have no idea that google.example.com isn't an official google website.
> Passkeys don't offer portability, user choice, or user control.
This is objectively false. Every major platform provides user choice in Passkey Manager. It's the same flow/settings to setting up a third party Password Manager.
All of the ecosystems have defaults that include some amount of portability: iOS defaults to Passkeys synced through iCloud Password Manager and backed up/restored with device backups. Android defaults to Passkeys synced through Chrome Password Manager. Windows defaults to Passkeys synced through Edge Password Manager. All of the ecosystems have plugin systems to support third party Password/Passkey Managers such as 1Password or Bitwarden.
Most devices that support Passkeys support a QR code bootstrapped flow for cross-device/cross-ecosystem Passkey challenge signing via Bluetooth LE.
Most ecosystems deliberately don't provide explicit private import/export to help protect users, but that's more an implementation detail than a technical requirement, and mostly not an implementation detail for "lock in" reasons but for simple security reasons: the private key you cannot export is the private key that is harder to steal by bad actors. The private key that you cannot manually import is the private key that can't be installed by bad actors.
You lose a device or the local DB that keeps your passkey and you are screwed.
You need to migrate from one login domain to another (rebranding, change of login providers...) and none of your customer credentials will carry over.
Your password might not be stored anywhere except in your head.
Your local storage gets compromised and your passkeys are there for the taking (password in your head isn't).
"Cloud" password managers who hold your passkey private key part is exactly like them having your password and are worse than websites having proper cryptographic hash of your password: they might not be e2e encrypting it (you were comparing with sites doing password hashing wrong too), so a breach exposes all your passkeys just the same.
My point is that there is no panacea. Passkeys are like SSH keys for the web. I still put a passphrase on my SSH keys. Do you?
Passkeys can be, and have been, stolen and hijacked. They make it more difficult for scammers and hackers to get into your accounts, but not impossible. How many phishing emails have you personally fallen for that this is your #1 concern over the fragility and complexity of passkeys?
By that reasoning passwords are 100% secure too, it's the human's fault when they fall for phishing sites! Passkeys depend on humans, password managers, devices, certificate authorities, browsers, and operating systems. That's not even including the implementation itself (https://www.esentire.com/blog/securing-passkeys-thwarting-au...)
All of this means that even when you're using a passkey an attacker could still break into your accounts. Passkeys can make it harder for them, but it can make it harder for you to get access to your accounts too. For me, I don't think the risk of phishing is worth the trouble passkeys would cause me.
Typically the user gives a website their public passkey, which does not need to be kept secret since it’s public. If the website is hacked the attackers only get information that is already public.
You seem to be talking about a scenario where a user’s private keychain on their computer is compromised and the attacker is able to access other systems from that same machine without the user’s knowledge. (Note that the keychain data is itself encrypted so can’t be used from a different computer.)
It's not just the end user that you have to worry about, attacks are helped by the fact that websites suck at passkeys too
"...we developed PASSKEYS-ATTACKER. The tool allows for precise manipulation of WebAuthn messages at every step of the protocol and integrates 15 attack types of which 10 were not covered in previous work. Among them, 2 attack types have critical CVSS scores. We discovered them on 18 out of 103 evaluated websites. These attacks take over user accounts, delete their passkeys, or lock them out of their accounts. Nearly half of the tested sites (53) were vulnerable to at least one attack with a high CVSS score, exposing users to threats such as phishing and session fixation." https://www.usenix.org/conference/usenixsecurity26/presentat...
Nothing of this explains anything, at best it increases the confusion. If anything, all this mumbo jumbo pushes me further away from using passkeys than before.
- Your Passkey Manager generally offers some form of multi-device sync. Most Passkey Managers are the same as Password Managers so it may even be a multi-device sync you are already used to.
- Devices support a flow where a QR Code kicks off a Bluetooth LE handshake between two devices to sign a one time Passkey challenge. That can be used for one time login on devices you don't sync your Password Manager to or to help bootstrap additional Passkeys on the new device.
my passkeys are in 1password, and accessible from any device i have 1password installed on. it's a very smooth experience (both adding new ones and using existing ones).
> There is nothing to prevent you from entering your super secure u quiet password on the wrong site if you get phished.
Replying only to this part, using a password manager with autofill solves this problem. The password manager (I use Bitwarden, but there are others) can check the site you're trying to log in to, and only autofill passwords that are for that site. I don't have to do any work to differentiate example.com from thisisexample.com, because Bitwarden will only show me the example.com password.
The secure part of a passkey does not have to be transmitted. It’s public key cryptography. It’s used to sign something as proof that you control the key.
And for that reason, the server does not have the secret. It only has the public key, which is useless on its own. So it can be stored in the database in plain text unencrypted. And you’re not really taking any risk.
Passwords are not cryptography. People may use cryptography to store them at rest, or their hash. But the true password still has to be transmitted. The first time, and every time.
>But the true password still has to be transmitted. The first time, and every time.
The password never has to be transferred. In fact never having the password should be the goal. Not even a first time. Don't let the password leave their device. You transmit the hash.
That just means the hash is effectively the real password. If an attacker gets a hold of the hash that you transmitted, they can use that to authenticate to the server.
All that you gain by transmitting the hash, is that the attacker will need to modify the client's request to inject the stolen hash.
If the client (website or app) runs on the attacker's own devices, this is trivial. I suppose it is a valid obstacle if we are talking about an ATM or similar locked-down client.
Which makes the hash the password and the hash of the hash the hash. You achieved nothing. If you truely don’t want to send the password, there are of course ways. But it’s a heck of a lot more complicated than this and no one is doing any of it because… Passkeys is what you end up with.
Wow, you sound like you know what you're talking about.
> They have to be transmitted. They (or their hash) have to be stored. And so so many get that wrong.
Ok, you've stopped sounding like you know what you're talking about.
Passwords have to be transmitted or stored. They don't have to be transmitted and stored. As you note, we usually opt for transmission but not storage. You could do it the other way around.
> There is nothing to prevent you from entering your super secure unique password on the wrong site if you get phished.
> Passkeys can’t be entered on the wrong site, the sites they work on is an inherent property of the key.
They can still be entered. Not working isn't the same thing as not being sent. A cryptographic exchange should hopefully fail before anyone who's pretending to be the counterparty you want learns enough to impersonate you. But you can enter anything anywhere.
> Unique strong passwords, TOTP, 2FA, one time sign in emails, none of those offer this stuff.
Unique strong passwords offer the following:
1(a). They are never transmitted (well, once), and provide phishing resistance; or
1(b). They are never stored, and provide leak resistance.
2. In the event of compromise, no other credentials of yours are simultaneously compromised.
It's true that it would be nice to enjoy phishing resistance and leak resistance.
Here are some other things unique strong passwords offer:
3. You are free to establish any relationship you like, with anyone you like. You don't need permission from Yubico to create an account somewhere.
4. Yubico can't pretend to be you.
You might notice that passkeys don't offer any of those. Your comment appears to enthusiastically endorse the idea that passkeys are a trap.
> Passwords are fundamentally broken. They cannot be fixed.
This is the "PGP is fundamentally broken" argument again. It will never be valid.
If you ask any followup questions, the reason that "PGP is fundamentally broken" is that people use Outlook plugins, and those plugins mean that they're constantly sending email in plaintext when they should have sent it encrypted. There's a very, very simple solution to this.
Don't use Outlook plugins. Run PGP yourself.
Before you send your email, check whether it looks more like "OK, everyone's ready for the kidnapping on Thursday" or "Eb+h+Q1iDEYUgJlO5GTtmcibC+D1E9oJWvZeoy9I2tpqxe9j/iokAx0R". You will be able to tell the difference. Nobody has ever failed at telling these apart.
If you were about to send the email, but it's still in plaintext, don't send it.
Passwords are no more fundamentally broken than PGP is.
That's not accurate. If that were true, then a hacker stealing password hashes would
enable them to instantly log in, without cracking them. Rainbow tables and dictionary attacks exist for a reason.
Pass-the-hash has been tried in NTLMv1 and thankfully that was the end of that failed experiment.
Modern password authentication is performed by the client sending a plaintext password encapsulated within a symmetrically-encrypted tunnel. On the Web that's with TLS. The server then uses bcrypt or another scheme to hash the password (along with the stored salt) and compared that resulting hash with the value in the table.
>then a hacker stealing password hashes would enable them to instantly log in, without cracking them
How do you know the hashed value stored in the database is the same hashed value the user submitted? Server side I can add a salt and hash more before storing or comparing.
> How do you know the hashed value stored in the database is the same hashed value the user submitted?
Please explain how authentication would occur without a comparison between the user's submission and a value stored at creation/update of the passphrase.
Sure, you could MITM still if all you do is that, as with anything it depends on what you are defending against.
If you are defending against clear text being discoverable, then bcrypt hashing with a unique salt on the client is good enough.
If you are trying to prevent MITM you can combine that salting with public/private key transmission of the bcrypt hash to the backend (effectively the same idea as pass keys without the downsides).
MITM just affects your service, and doesn't always matter depending on what the service is, for example, a recipe manager doesn't need to have bullet proof security.
As the hash is being encrypted with the public key in the client, that would require that the client be compromised. In which case the original password is already exposed at that point, thus a discussion of the transport is no longer the concern.
The point of a hash is that the password is not stored on the machine long term. Thus, if an attacker gains access to the back-end and exports all the hashes, you can't reuse the hashes themselves to login. I.e. you need to do a password-cracking attack, which is infeasible with a password of sufficient length.
I don't care if someone gets my password hash. They aren't going to crack it due to the complexity of it.
> Whenever I've written authentication, passwords are hashed on the client side and never transmitted in the clear.
While rare, a couple of sites which has many (>1000) users have sent me my password in the plain when I told I forgot them.
Many sites have e-mailed my password in the open when I registered, as well.
I don't defend passkeys here, but too many weak links are present in password based flows today. If someone uses per-site strong passwords, one can contain the leaks, but use the password even once, and the problem grows exponentially.
I immediately emptied my account with BBVA (a major bank with $37B yearly revenue) after their app asked me to validate my identity by entering "the fourth character of your password". Subsequent attempts asked for different ordinals. This was in 2023.
You are supposed to send the password, via TLS so it's not in the clear, to the server to be hashed.
If you hash on the client... then the hash essentially becomes the password, and defeats the purpose of a hash. I could just steal the hash and use it.
Good I still don't want to know the password. If the first stage hash is compromised there are bigger issues, bigger than even if the database of hashes or passwords got hacked.
But the sites where I actually care if my account gets compromised - Steam, FastMail, DigitalOcean etc. - are very unlikely to screw up password storage.
I'm never going to bother with paranoid security inconveniences for the crappy website my local pizza place uses.
They are tied to the issuing domain and the system that carries the passkey will refuse to present it to any other domains. It’s more or less impossible to fall for phishing or a spoofed site. Your password manager may have similar functionality for automatic filling of forms but less sophisticated users can often be tricked into providing passwords via copy and paste.
Phishing is even easier. Instead of "open your password manager, copy your password and paste it here" it becomes "your passkey is out of date, click here to enroll a new passkey. As part of this process a reset link will be sent to your email and code to your phone. Do not share the code with anyone."
If your account is already not protected by passkeys (it has access to traditional username + password credentials), it can be phished regardless.. in those cases you just need to send them a traditional "reset password" phishing email.
The point is that those attacks would be (nearly) impossible if you have a truly passwordless system.
The less sophisticated users can use their passkeys then, and the rest of us who know what we’re doing and have been for 25 years can continue to not support vendor and platform lock-in and forced device attestation. The amount of marketing and push behind passkeys does not feel entirely genuine to me.
You know how to feed the site certificate into gpg before every login to check for url phishing attacks? I usually have to ask my password manager to do that (which didn’t exist 25 years ago)
Bitwarden browser extension, and I imagine most other password managers, will only offer to auto-fill a password if the site matches. There's a setting to choose the exact rule, but the default is matching the domain name.
So if you get sent to goog1e.com, your password manager won't prompt you to enter your Google passwords. Though of course, you could still manually paste it in if you got somehow convinced that it's a legit site.
As I understand it, in theory, there is no "secret" exchange over the network with passkeys, once they are initially set up (one side sends a challenge to decrypt, and the challenge is one-time use. The decryption all happens locally.) And so they aren't as vulnerable to phishing or other common ways to steal passwords (such as key loggers, which don't even involve the network.)
But in my opinion, the solutions that passkeys provide come with the costs that are being discussed here, and I haven't found the trade-off worthwhile.
---------
Oct 14 - 12:30pm...
---------
There is a wall of text below your question and _none coherently, concisely answer your question: "What do passkeys offer users that rand strong password + password managers don't?"
Other comments suggest that Franklin would have eventually gotten there on her own. Her work was key to the discovery as we know it, which wouldn't have happened without it. To me, that's the whole story.
Specifically the antiparallel base matching was the important bit, agreed, but minor nitpick. The first alpha helix wasn't solved until 1951, so one year earlier. Their ubiquity was very novel.
It reminds me of how provably secure software was all the rage for awhile. Until people found that the idealized system/lemmas were so far from reality that the proved security was worse than meaningless because it gave a false sense of security.
In order to prove security, you must first simulate the universe.
Fake news has been harming democracy since democracy was invented. Remember those indian scalpings? Mostly made up by Benjamin Franklin to rally support for colonial gov.
If anything social media is a benefit to democracy vs. legacy media because it dilutes the power of any one voice, it's very hard to control all social media whereas a couple conglomerates now own nearly all of legacy media.
Looked at another way, if democracy cannot withstand social media and made up stories then it's not a stable system of government. Stories of the end of history are greatly exaggerated, historically democracy is far less successful than autocracy, perhaps due to this issue.
The stability of autocracy is greatly exaggerated. It often can't even withstand the leader dying. Government stability is the great feature of democracy. I'm not quite as confident as I used to be, but I'm still pretty confident that my country will have a new leader in 2029 and that there will not be a violent civil war accompanying the transition.
It's stable in the sense that the next government will very likely be autocratic even if the leader changes. Power tends to concentrate. The phenomenon in the 20th century where multiple governments actually diffused power from a monarch to a parliament or democracy is overall rare and arguably that trend has long since reversed.
a hallmark of fascism and dictatorships is the capture of media, and the censorship of it.
i find it hard to accept that the solution to your problem here is that democracy must fall because of propaganda, when the very same propaganda is what leads to dictatorship.
Without a way to create objective dialogue, what is any system of government other than the picture it paints. Facts, and nothing else, is the only way to maintain a democracy.
Once you permit subjectivity, conjecture, and propaganda, like, say... when right wing billionaires buy create fox news, buy cnn, john oliver, colbert, every local news network (sinclar), washington post, tik tok, twitter, etc etc etc etc etc........ democracy is no longer possible.
In the US, social media has been captured by propaganda not because an authoritarian government has made it so through law and violence, but because the consumers like the propaganda.
The current situation is the result of free speech and consumers being able to choose the kind of content that they enjoy.
It is hard for me to avoid the conclusion that your argument in effect logically implies that free speech should be further curtailed and that elites (but the Right Elites) should be in control of the sources of content.
Which is a defensible position to take, actually. But people generally don't take it because reduction in free speech and consumer choice is anti-democratic. So the essence of this position is actually that we have too much democracy, not too little.
You just need to go one step further. The fear of billionaires buying media is used to justify increased government control of media and ultimately leads to a ministry of truth.
Once the ministry of truth gains power, democracy is finished.
The extremely unpopular citizen's united supreme court case was in many ways a last ditch attempt to prevent the creation of the ministry of truth. It likely won't last.
In the grand scheme of things, the gov claiming a perpetual 21%+ of all income of AI (all) companies is not all that different from owning a small percent of said AI companies. The financials and even incentives are basically the same.
It's somewhat entertaining to watch both sides argue about this as if it's some major difference when both are actually aligned on wanting bigger gov and more gov ownership/control of corps (one party via taxes the other wants it direct).
That's my point, the gov already owns a ~21% royalty on the income of every company that operates in the US via the corporate tax. And it's more than that if you consider other taxes.
Who is we and what is ownership? Taxes are nice because it's just straight cash, no meddling (other than the myriad of laws they must follow). "Ownership" meaning you want whatever political party/group in power in the moment to able to directly command businesses on top of adding laws and taking money seems a bit like overreach to me, in addition to being costly resource-wise.
We the people who the government represents as a whole, and it can take many forms, yeah, but I am pretty partial to direct ownership of a percentage. The value we provide to these entities deserves it.
No, I am 100% serious. There is no reason to fuck around. Anything is better than the dystopian hellscape we are headed for currently. The time for discussion is past. The time for action is now. If corporations don't want this to happen, they need to get off their ass and start fixing what they broke before the people have to.
I would make the case that government ownership of the machinery of commerce makes both worse. The money and power inherent to this arrangement is corrosive to both sides. Keep them separate and let each fight the other to the proper tension point. If we want revenue there is already a way to do that - we call it taxes
> that something gains a lot of power over the institution.
Yeah, that hypothetical is terrifying! It's not like our entire government is in the pocket of the largest of these corporations anyway! That would be an entirely new scenario that we should avoid at all costs!
Just because you have a bee in your car doesn't mean you should ignore the hive growing in the trunk. It's silly to reject all threats because a less severe version of that threat already exists.
There are countries where the entire government is the pocket of the largest corporations. The US is not one of those countries. It can get much worse if you allow it.
My prediction is that future wars will actually involve increasingly fewer humans and will be more about tech+manufacturing vs. tech+manufacturing. And of course insurgents + lowcost tech vs. increasingly nonlethal hightech.
This would allow wars to continue without as much of the growing political backlash.
reply