The original post can be found here.
However, since the proportion of German-language posts in this forum is rather low, I decided to share the ideas from that post with a wider audience through this post.
Background: Once you’ve spent some time experimenting with (FIDO) security tokens, you quickly become aware of the vulnerabilities that still exist in the current design and the potential attack vectors. This also raises the question of how such security tokens should be used effectively. It should be apparent to anyone - at the very latest after reading the documentation and other sources - that one should not rely solely on the existence of a single Nitrokey.
I also wonder whether - depending on the intended use and role of the security tokens - we should maintain additional pairs of Nitrokeys (or alternatives). I’m thinking of a strict separation of roles, for example, along the following lines:
- Two security tokens/Nitrokeys each for important online accounts related to software development
- Two security tokens/Nitrokeys each for access to Machine A (login, disk encryption, etc.)
- Two security tokens/Nitrokeys each for access to Machine B
- Two security tokens/Nitrokeys each for an additional online identity
- Two security tokens/Nitrokeys each to secure a password database for all non-FIDO2-compliant online accounts
The reasoning behind this approach should be clear: Even the use of a (FIDO2) security token does not, in theory, offer complete security.
In addition, the effort involved can get out of hand if you use a single key for multiple roles and - let’s assume for simplicity’s sake - it fails to function as intended (unfortunately, the support forum has several examples of this “non-use case”). Then you’re faced with a multitude of dependencies with different behaviors: The key is used for OpenPGP, FIDO2, and TOTP, but the software’s behavior varies depending on the use case - for example, during a reset. If the key becomes damaged or is no longer usable for other reasons, managing it quickly becomes cumbersome and confusing. Furthermore, I’m still not entirely sure that the flash memory outside the security element is written to in a way that doesn’t wear it out too quickly. After all, this issue was a concern even among well-known SSD manufacturers in their early days.
That’s why I’m considering a setup where this dependency tree consists, if possible, of a single root (token) and a few additional leaves (credentials). This greatly simplifies management in the event of a failure.
For example: Suppose you have a security token (plus a backup token) for SSH on various machines; the token is restricted to use with SSH. If another security token with different roles becomes unusable, at least this dependency tree remains completely unaffected, which should significantly reduce the administrative burden in the event of a “failure.”
In particular, I consider the ability to destroy a device’s credentials using fido2-token -R <device> to be a serious design flaw in the specification as it currently stands. While it is sometimes argued that this function is comparable to formatting a hard drive, I do not find this line of reasoning convincing. As the owner of a hard drive, I can take appropriate precautions - such as creating backups - that allow me to undo an error or even an attack with a single command or by launching a program. However, this option is not available with (FIDO2) security tokens, as they are not only designed for local use but as well for use on numerous online platforms. If such a token suddenly becomes invalid on around 100 websites, the owner has to restore access to every one of those websites. Thus, this command not only represents a vulnerability in the FIDO2 system, but also makes it necessary to consider which security tokens should be used, in what combinations, and for what purposes. That is the background to my question. I therefore hope to receive as many experience-based answers as possible.
The number 100 is used here merely as an example and does not reflect the actual capacity of a Nitrokey, even though it has been reported that other solutions do support a comparable number of access points.
To reiterate this point: Even though one should consider how to ensure the safest possible use and provide for multiple security tokens, I still believe that physical security tokens are the far superior solution compared to the software-based passkey solutions currently being discussed. All too often, these passkey solutions are siloed and frequently seem like an attempt by major platform providers to differentiate themselves from one another. Interoperability is often given less emphasis there than in FIDO2. In addition, passkeys can easily lead to a complex management situation that you might not even want to get into. Just a side note.
In my view, physical security tokens are clearly preferable to purely software-based passkeys for the simple reason that they can remain physically disconnected from the system for more than 90 percent of their lifetime of use.
My current plan therefore calls for a clear physical separation of the individual roles using additional security tokens. However, the resulting costs are likely to be a significant deterrent for many home users. In my view, there is therefore still a considerable need for further development in this area.
To briefly summarize:
My main concern is the distribution of roles across different tokens, in order to minimize the administrative burden in the event that a token needs to be replaced.