I wish there was a password manager with a different focus.
In the way where there would be a server (selfhosted) that has the passwords and is well protected. Then, on the server, I can configure access to the secrets on my clients and — and that is important — restrict the number of secrets that can be accessed per time. And on each client I want to be told if secrets got accessed by another client.
Because, optimally I would use passkeys and other means of authentication, except for initial auth. But if my client gets compromised I don't want it to be able to access and exfiltrate all secrets at once. That is basically the worst case scenario.
I don't understand why it's not common in password managers to have different categories of how important a secret is and better control/transparency to detect compromised clients and contain the impact.
I suspect that's uncommon because basically every password manager works offline so isn't querying the server on each request, and implementing something where you trust a compromised client to rate-limit itself and report back appropriately seems like a lot of work to protect against a pretty specific threat model.
Right. That's why I think that the client syncing (all) credentials is just what I don't want/like and there must be a server, since a compromised client can obviously not be trusted to doing any rate-limiting.
And the server also needs to inform about usages, since otherwise a compromised client could just extract everything slowly over time.
Does that make sense?
Otherwise, basically just one compromised client means that suddenly all my credentials need to be considered stolen and have to be changed everywhere.
> This is emphatically not fundamental to LLMs! Yes, the next token is selected randomly; but "randomly" could mean "chosen using an RNG with a fixed seed."
This. Thanks for saying that, because now I don't need to read the article, since if the author doesn't even get that, I'm not interested in the rest.
It should be noted that that is not an inherential advantage of passkeys over passwords. It is possible to achieve the same with passwords, e.g. by using a hash-cascade.
Sure, but then you still need a protocol between user agent and website. If you just do this in Javascript, you're not protected against phishing sites just forwarding the password entered directly.
Passkeys can in fact be backed by exactly this, i.e. a HMAC-only stateless implementation backed by a single password: https://github.com/lxgr/brainchain
> Sure, but then you still need a protocol between user agent and website.
Yes of course. Just like you do for passkeys.
> Passkeys can in fact be backed by exactly this, i.e. a HMAC-only stateless implementation backed by a single password: https://github.com/lxgr/brainchain
No, not quite. It's written on there:
> "Login" with your passphrase, and you can create non-discoverable WebAuthN credentials (don't call them passkeys, but definitely be reminded of them) at ~all~ some websites supporting them (...)
That's the thing: with passwords, a website/app cannot prevent you from controlling the password yourself. With passkeys and attestation it can.
But attestation for passkeys is dead. Neither Apple's, nor Google's implementation (with negligible exceptions) support it anymore, so any site demanding attestation will immediately disqualify > 99% of all potential users.
Some still might, e.g. for corporate or high security contexts, but I don't think it'll become a mass-adopted thing if things don't somehow drastically change course.
It's still in the standard. They could remove it, but they don't, so from my perspective it's just like how Google wasn't evil. Until they decided otherwise.
Yes, because hardware authenticators (like Yubikeys) still commonly support it, and it makes sense there.
I guess they could add an explicit remark like "synchronized credentials must not support attestation", and given the amount of FUD this regularly seems to generate I'd appreciate that. But attestation semantics seem to be governed more by FIDO than the W3C, so putting that in the WebAuthN spec would be a bit awkward, I think.
Hm, I disagree. I prefer if the user has the freedom to choose how they want to do things. At the cost of some users choosing the wrong way and then getting problems. It's a question of balance, but when I look at recent tech/internet history, I tend to not want to give central authorities any more power than they already have.
Ideally, sure, but the reality is just that some entities are not only reputationally, but also legally required to bear the liability for account takeovers.
In other words, you have a principal-agent problem: Users doing custom software passkey acrobatics and the banks liable for any funds lost.
Preferably, use of attestation should be limited to these (and enterprise) scenarios, and I do share the concern of others starting to use them as weak proofs of humanity etc.
> Ideally, sure, but the reality is just that some entities are not only reputationally, but also legally required to bear the liability for account takeovers.
Seems like an absolutely rare edge case to me. Or maybe even just a misunderstanding. I doubt there is a law that says that. If anything, I could imagine a law saying that a company has to take "sufficient precautions".
But even if what you say were to be true - that's not something to solve with tech. That means the law should be changed.
Bank and payment card transactions are arguably a pretty big part of everyday life to most people.
> I doubt there is a law that says that.
Reg E/Z in the US and PSD2 in the EU pretty firmly put the burden for these types of situations/losses on the bank/PSP. They don't specifically mandate the "how", but for better or worse, industry perception and common practice is for that to include root detection, blocking VoIP numbers from receiving SMS-OTPs etc.
> That means the law should be changed.
The law that makes banks liable for most cases of account compromise? I'm actually quite happy with that, even if it comes with some unfortunate externalities.
It is absolutely unfair to say it. Just like passwords stored in a password manager, passkeys can be copied out of the device for safekeeping. Because you can copy them out, a user can be induced to give them to someone.
I saw passkey boosters go very, very rapidly from "Passkeys are immune to phishing!" to "Passkeys are phishing resistant!" when lots of real-world people started using passkeys and demonstrated that you absolutely must have a way to back them up and move them around.
Yes, they're synchronized, but I wouldn't call that "copying them out", as that to me implies somehow getting access to the raw private key or root secret bytes.
Both Apple and Google have pretty elaborate ceremonies for adding a new device to an existing account in a way that synchronizes over passkeys.
> ...as that to me implies somehow getting access to the raw private key or root secret bytes.
When passkeys were first introduced, they were 100% stuck to the device that they were created. There was absolutely no real way to copy them off. This is when proponents were -correctly- making the claim that they were immune to phishing.
When lots of users (who -notably- were not supported by whole-ass IT departments who set up and run systems that handle provisioning and enrolling new devices) started using passkeys, the correctness of the thing that many non-boosters were screaming ("You have to have a way to back these up and move them between devices!") became abundantly clear. Passkeys became something that could be copied off of devices, and proponents -correctly- switched to the claim "Passkeys are phishing resistant".
Once things switched around so that passkeys were no longer stuck on a single device, third-party managers got the ability to manage and copy passkeys. [0]
Hopefully it's now clear that the shift from "they never leave the device" to "they do leave the device" (and the consequences of this change) is what I'm talking about.
[0] At least, they will for the next five, ten years until the big players decide that it's okay to use attestation to lock them out to "enhance security".
It sounds like part of the problem is that two rather separate standards of "phishing" are getting conflated:
1. "Hi, I'm your bank, log in just like you normally do." (Passkeys immune.)
2. "Hi, I'm your bank, do something strange I've never ever asked you to do before by uploading some special files or running this sketchy program." (Passkeys just resist.)
The problem with the expansive definition is it basically starts to encompass every kind of trick or social-engineering ever.
That qualifies as "immune to phishing" as far as I'm concerned. No reasonable person using a reasonable implementation will ever be successfully victimized in that manner.
We need to stop pretending that padded cells for the criminally incompetent are a desirable design target. If you are too stupid to realize that you are being taken for a ride when asked to go through a manual export process and fork over sensitive information (in this case your passkeys) to a third party then you have no business managing sensitive information to begin with. Such people should not have online accounts. We should not design technology to accommodate that level of incompetence.
If you can't stop driving your car into pedestrians in crosswalks you lose your license. If you can't stop handing over your bank account number to strangers who call you on the phone you lose all of your money. If you eat rotten food you get sick and possibly die. If you hop a fence and proceed to fall off of the cliff behind it you will most likely perish. To some extent the world inherently has sharp edges and we need to stop pretending that it doesn't because when we do that it makes the world a worse place.
Then you should write assembly only. Like `MOV`, `ADD`... can't really get simpler than that.
Problem is, that makes every small part of the program simple, but it increases the number of parts (and/or their interaction). And ultimately, if you need to understand the whole thing it's suddenly much harder.
Surely you can write the same behaviour in "clever" (when did that become a negative attribute?) or "good" way in assembly. You are correct. But that's a different matter.
Google isn't even good at engineering great software.
They have some good people working on some good projects. If you look at the relation between software-quality of their average product and number of developers they have... yeah I don't know. Maybe hiring tons of new-grads that are good at leetcode and then forcing them to use golang... is not what actually makes high quality software.
I could believe that they are good at doing research though.
Most of the core products at Google are still written in pre-C++11.
I wish these services would be rewritten in Go!
That’s where a lot of the development time goes: trying to make incredibly small changes that cause cascading bugs and regressions a massive 2000s C++ codebase that doesn’t even use smart pointers half the time.
Also, I think the outside world has a very skewed view on Go and how development happens at Google. It’s still a rather bottom up, or at least distributed company. It’s hard to make hundreds of teams to actually do something. Most teams just ignored those top-down “write new code in Go” directives and continued using C++, Python, and Java.
I wouldn't say most. Google is known for constantly iterating on its code internally to the point of not getting anything done other than code churn. While there is use of raw pointers, I'd argue it's idiomatic to still use raw pointers in c++ for non owning references that are well scoped. Using shared pointers everywhere can be overkill. That doesn't mean the codebase is pre c++11 in style.
Rewriting a codebase in another language that has no good interop is rarely a good idea. The need to replicate multiple versions of each internal library can become incredibly taxing. Migrations need to be low risk at Google scale and if you can't do it piecewise it's often not worth attempting either. Also worth noting that java is just as prevelant if not moreso in core products.
> Static types, algebraic data types, making illegal states unrepresentable: the functional programming tradition has developed extraordinary tools for reasoning about programs
Looks like the term "functional programming" has been watered down so much that now it is as useful as OOP: not at all.
Look, what matters is pure functional programming. It's about referential transparency, which means managing effects and reason about code in a similar way you can do with math. Static typing is very nice but orthogonal, ADT and making illegal states unrepresentable are good things, but all orthogonal.
In the way where there would be a server (selfhosted) that has the passwords and is well protected. Then, on the server, I can configure access to the secrets on my clients and — and that is important — restrict the number of secrets that can be accessed per time. And on each client I want to be told if secrets got accessed by another client.
Because, optimally I would use passkeys and other means of authentication, except for initial auth. But if my client gets compromised I don't want it to be able to access and exfiltrate all secrets at once. That is basically the worst case scenario.
I don't understand why it's not common in password managers to have different categories of how important a secret is and better control/transparency to detect compromised clients and contain the impact.