mirror of
https://github.com/pocket-id/pocket-id.git
synced 2025-12-09 14:53:00 +03:00
🚀 Feature: Support for password + security key or double passkeys authentication flow #68
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @TommyTran732 on GitHub.
Feature description
Passwordless login, while being secure, is not the most secure method available, because:
A more secure way to handle authentication is to support one of these flows:
Pitch
My users are quite security conscious, so having to entirely trust a hardware or software implementation of passkey is quite off putting. It would be nice to have an option to opt-in to more secure authentication flows.
@TommyTran732 commented on GitHub:
@TommyTran732 commented on GitHub:
A lot of them do not require any "sophisticated attackers".
Like with the Yubikey 5 Nano example, you can see that the plastic just cracks and falls off on its own.
Here are a few other examples:
And keep in mind, these do not encrypt their internal storage against the user PIN. The vast majority of keys are like that. In fact, I am only aware of 2 security keys that provides any kind of encryption: Trezor devices and the OnlyKey.
There is a reason why we encrypt our laptops, phones, and hard drives. We do not want people to just be able to pick up our devices and access our data. So why take the risk that someone can just pick up your security and log into all of your accounts?
The risk of compromise is always there, and it doesn't always take a state actor or someone at that level to pull this off. This is a downgrade from the traditional MFA model of "something you have and something you know", because if the key is vulnerable (which they are found to be all the times), you are down to just "something you have".
@kmendell commented on GitHub:
What makes pocket-id unique is the passkey only behavior, so we do not plan on adding password authentication. While security concerns are valid, we have answered these concerns in previous issues about how passkeys are more secure and have a more difficult attack surface.
Ill leave here for @stonith404 to add anymore notes as well.
@ItalyPaleAle commented on GitHub:
IMHO, I don't think Pocket ID is the right solution for this level of security requirements.
If your adversaries are sophisticated enough to be able to break into Yubikeys, you are dealing with state-level actors stuff, and have different problems than what Pocket ID is designed for. It's the
Even then, it's more likely than adversaries with this level of sophistication would be able to find other flaws in Pocket ID - or even result to physical violence (relevant XKCD)
@ItalyPaleAle commented on GitHub:
All of the links you share require physical access to the security key, and some require very sophisticated hardware (e.g. for Google Titan, they are performing a side-channel attack studying the electromagnetic signals and then using a custom ML model). While possible, they still require lots of sophisticated attackers.
@TommyTran732 commented on GitHub:
@savely-krasovsky
All I know it is that with various keys it is possible to gain access to their flash storage with relative ease and that their internal storage is not encrypted.
So do you walk around with an unencrypted laptop? Must be so secure because nobody ever steals your hardware right?
They do not. In the case of Bitwarden for example, the users are compelled to use the web vault to perform certain actions from time to time, and the web vault can be trivially compromised by malicious server or reverse proxy. Or in the case of Apple Keychain, the keychain is encrypted against the device PIN. How many iPhone users set a diceware passphrase on their phone? Or is it simply the norm for people to use an extremely weak 4 digit PIN?
It depends on the key and the firmware. Not all FIDO2 security keys are created equal.
@savely-krasovsky commented on GitHub:
@TommyTran732 come on, are you seriously using state-of-the-art attacks as an example? And essentially assuming unlimited time and money? Given what hardware and resources they used to restore one key. Not to mention that they would have had to steal it beforehand. Even synced passkeys set a very high bar for security, and security keys just raise it even higher.
@stonith404 commented on GitHub:
@TommyTran732 please refer to #446, I think @savely-krasovsky has explained this very well there.
@savely-krasovsky commented on GitHub:
All I know it is that without extensive knowledge that only few people posses and a bunch of expensive hardware nobody will be able to hack your keys "with relative ease".
In my opinion, both @ItalyPaleAle and I are trying to tell you that your threat model is very different from the one the developers had in mind when Pocket-ID was created. You're expecting to be targeted by state-level actors, or at least by a group with the resources to hire leading specialists with high-end labs to carry out a targeted hack, which could include stealing your key beforehand. IMO, Pocket-ID isn't a good fit for that, simply because it wasn't advertised or developed as a "highest-security" product to begin with.
@ItalyPaleAle commented on GitHub:
The reasons we encrypt our laptops' drives are VASTLY different: because extracting data from a laptop's hard drive requires nothing more than a screwdriver and a SATA cable (so every person with minimal IT training can do that), for compliance reasons (FIPS/HIPAA, etc), or to make it easy to re-sell them (because SSDs are hard to securely erase). There's more: these threats are often non-targeted (thousands of laptops are left at airports every year by distracted travelers...), and once someone has your laptop you generally cannot perform a remote wipe.
You're trying to say it's equivalent to using state-of-the-art, extremely sophisticated attacks on security keys. Which are generally targeted (just finding a YubiKey at the airport won't help much if you don't know whose key it is and for which accounts), and require very complex methods and tools. You can also remotely disable the security key (removing its association to the account) as soon as you realize it is lost, rendering it useless.