'Passkey' technology that allows authentication without a password has a trap, be careful if you are using a hardware authentication device such as YubiKey
'Passkey' is a mechanism that allows you to log in to various websites without a password, and major technology companies such as Apple, Google, and Microsoft are
Firstyear's blog-a-log
https://fy.blackhats.net.au/blog/2023-02-02-how-hype-will-turn-your-security-key-into-junk/
There are two types of passkey authentication mechanisms: a method that does not store the key on the client side, and a method that stores the key on the client side. If you do not store the key on the client side, generate the key used for authentication in advance, encrypt it using the master key of the security key, and send it to the 'Relying Party (RP)' that is the party that uses the authentication information. Put. At the time of authentication, as shown in the figure below, a key is extracted from the authentication information ID sent from the RP, and a random number called a 'challenge' is signed to prove that the user is legitimate.
The key stored on the service side as described above is also called 'Non-Resident Key' or 'Non-Discoverable Credential'. Since only the master key is stored in the security key, there is no problem even if you create a large number of accounts. However, it is necessary to enter the ID first so that the appropriate authentication information ID is sent during authentication.
On the other hand, in the method of storing the key on the client side, in the authentication procedure, instead of decrypting the authentication information ID, the key stored in the security key is selected, and the challenge is signed with that key to prove its legitimacy. Prove it.
By storing the key on the client side, it is possible to eliminate the need to enter not only the password but also the ID, but it is necessary to secure the storage space for the key. According to Mr. Brown, key storage space is very valuable in hardware authentication devices. YubiKeys, for example, can only store 20 to 32 keys.
A further complication arises with which versions of the Client to Authenticator Protocols (CTAP), specifications for communication between clients and hardware authenticators, are supported. Hardware authentication devices that support CTAP2.1PRE or CTAP2.1 can update or delete keys stored internally. In the case of , it is impossible to change or delete the saved key once.
So if you store the wrong key, you either give up space for that key or reset the whole device, but resetting the whole device changes the master key, All credentials associated with that device will stop working.
The use of passkeys is spreading as
There is no problem in storing the key on the client side because the storage capacity limit is loose in passkeys using smartphones. I would like to use it properly according to the client, but in the specifications at the time of writing the article, the request level is divided into three stages when you want to use the 'Resident Key (RK)' method in which the Relying Party (RP) stores the key on the client side. Even if you request 'rk=preferred' as shown in the figure below, the RK method will be selected for hardware authentication devices with limited storage.
Until the above problem is resolved, specifying 'rk=discouraged' is the next best thing. It is also stated that a possible solution is to oblige hardware authentication devices to secure storage where FIDO can store thousands of keys.
Related Posts: