#Keeweb otp registration#
#Keeweb otp password#

To achieve this, we add an additional step to HMAC function that depends on used authenticator and an additional value stored in the header (let's call it HMAC*): HMAC*: (data, x) => MasterKey = KDF( PasswordHash вЁЃ HMAC_N(Challenge) ) MasterKey = KDF( PasswordHash вЁЃ HMAC_2(Challenge) ) We want to find a way to make such challenge that: MasterKey = KDF( PasswordHash вЁЃ HMAC_1(Challenge) ) As it's not possible to program your own secret, these authenticators can't have equal HMAC transformation and instead they provide HMAC_1, HMAC_2, and so on. Our goal is to have several authenticators each of them would be able to open the database. If there's an open file, KeeWeb tries to match entries from files with entries on the YubiKey, so that both are displayed on the same details page. When you open YubiKey from the open screen, the app shows codes saved there as read-only entries.

MasterKey is the encryption key used to decrypt data stored in the database After modifying codes on the YubiKey reopen it in KeeWeb to load new codes.

Challenge is something stored in the public file header.

HMAC is the transformation performed by the authenticator.

#Keeweb otp password#

PasswordHash is calculated based on entered password.KDF is a so-called key derivation function, one-way resource-hard transformation, such as Argon2.In this case the master key is calculated as follows (this explanation is simplified to illustrate the idea): MasterKey = KDF( PasswordHash вЁЃ HMAC(Challenge) ) To open the database, we need both things. Let's assume, we want to protect our database with a password and a YubiKey. In the KDBX format, such kind of hashing is used to calculate the master hash based on salt stored in the public file header. hmac-secret is a FIDO2 assertion, most of authenticators check user presence, for example, on a YubiKey you need to press the button.downside: space for these credentials is very limited, it's usually around 5.20 credentials per authenticator in total, if it's implemented at all.benefit: we don't have to store credential id (however we still need to identify the authenticator, so there's not much benefit here as it's also noted in the linked issue in KeePassXC and we can just use regular, not persistent credentials).To retrieve such credential, most of authenticators will present the PIN question.

FIDO2.1 defines discoverable (aka 'resident') credentials.

Even if it's non-resident (see below), the authenticator must not accept credentials produced not by this authenticator.

Credential id must be generated by the authenticator, it's not possible to make your own one.

This means, you can't make a backup of your YubiKey that would produce the same hash based on the same input. It's not possible to provide your own secret when making a new credential.

The secret used for signing data is stored on the authenticator and is never exposed.

Some notes to clarify the implementation:

challenge, client-defined data (512 bit).

#Keeweb otp registration#

credential id generated by the authenticator, obtained during credential registration (512 bit).FIDO2 hmac-secret extension provides support for hashing arbitrary data using a secret attached to a credential stored on the authenticator. вќ— This document is not ready and cannot be used for implementation, it has unresolved security issues.ДЇirst, some context. This is a draft of using hmac-otp FIDO2 feature for YubiKey support in KeeWeb.