- #Keeweb otp registration#
- #Keeweb otp password#
When saving the file, we need to generate a new challenge-response on this authenticator. 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. It can be used online, as well as in Windows, Linux and macOS.
#Keeweb otp password#
MasterKey is the encryption key used to decrypt data stored in the database KeeWeb is a cross-platform password manager compatible with KeePass.Challenge is something stored in the public file header.HMAC is the transformation performed by the authenticator.
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.
0 kommentar(er)
