englishcas.blogg.se - Keeweb chrome extension

RemoveListener resource://gre/modules/ExtensionCommon.jsm:2523 OnChanged chrome://extensions/content/child/ext-storage.js:332 RemoveListener resource://gre/modules/ExtensionChild.jsm:886 RemoveListener resource://gre/modules/ExtensionChild.jsm:663 _send resource://gre/modules/ConduitsChild.jsm:108 It can also provide a way to securely share the secret with iOS without current hacks.SendRemoveListener on closed conduit ConduitsChild.jsm:108 This is probably the best, but it needs some collaboration across forks, so that it's accepted everywhere. It needs some math to decide if it can be done right, I'll try go through it when I have time. I haven't thought much about it yet, but I can imagine the way it will work. This way the calculated HMAC will be used as an additional encryption key to get the secret and you can enroll as many keys as you want.

Use additional fields in the file header for secret sharing. I don't find it not a good solution and I would discard it. But it still doesn't sound right and probably it won't be implemented like this across forks. When you save the db, it makes a backup that can be opened with that separate key. I can imagine something like there's another key stored in the db that is used for backups. So, now the biggest question is, how to provide support for multiple keys? Without backup, using a YubiKey with kdbx doesn't make a lot of sense. Because of (1.), there won't be an option to unlock the database using just the seed, without your YubiKey, which means Safari integration won't work. I don't have a possibility to check it though, as far as I know you need to have MFi for testing this. I'm also not sure if this will work on iOS, but maybe it will.Discussion in the linked issue makes me think that libfido2 doesn't work on Windows, however there seems to be a workaround (use Windows API), if the workaround works, it should be fine, just a bit more code.The usage of hmac-secret FIDO2 extension also not implemented in any of forks, so we don't have anything to compare.

(1.) means it's obviously not compatible with the existing implementation.

For now, I'm not sure what to do with this and it's a blocker for adoption.

💥 It's not possible to change or manually set the seed (unlike in the Yubico's implementation), which means, you won't be able to program another YubiKey with the same secret.

It generates equal results for the same input, so it's technically usable as a HMAC implementation and it can be relatively easily coded. I did some investigation, and the script linked in the issue ( hmac-secret.sh) works well with a YubiKey with a small correction for a combination of macOS and YubiKey.