|
|
|
|
|
|
by SahAssar
1951 days ago
|
|
|
The cookie can be easily cloned since it has to be readable to the browser so it can be sent to the service. Also the cookie is issued to the browser after presenting other credentials to login like password, 2fa and magic links so it does not fill the same role at all. Cookies make a very bad "something you have" factor since they are constantly sent over the network, so at any point there are many different load balancers, application servers and so on that could reasonably claim to be the "thing you have". Cookies are also (usually) issued by the service, not by the client so by definition they have been on some other device that is not the device you want to prove you have before landing on the device you want to prove ownership of. What makes hardware tokens (like the yubikey) fill this role better is that the algorithm (which is really pretty standard crypto) runs on the device and the device is specifically designed to not reveal its keys, so it's easier to assume that anyone that can present proof of the keys also has the physical object. Secure enclave (and that is why I mentioned TPMs in the previous post although it seems like it would require a TEE) could fill the same role as a yubikey, but is often not used that way except for the device vendors login (like apple id). Even if your password is encrypted in a way that only the secure enclave can unlock if you can get it out of there then it is not as secure as something that you can only prove possession of (and not extract). |
|
|
Just want to take this moment to remind everyone that the yubikey have a protocol to configure it. Nobody knows the code that runs that prototocol. Nobody knows the full capabilities of said prototocol. the best hint we have is the semi-opensource configurator python/cli utilities which are just a bitmashing client of the published capabilities.
thank you.