@walib65081 I think most people are comparing features that other services offer with ones at BW without understanding the type of security that both have to offer.
At far as my knowledge goes , BW encrypts/decrypts its vaults with a single key , and this key is derived from your master password by PBKDF2 sha256.
From this its clear that only by using your master key and following the above process would decrypt your vault.
Any comparison with other services which offer multiple ways to authenticate including QR code or temporary password wouldnāt be fair as most other services donāt offer zero knowledge encryption i.e they often own the decryption keys to your vault.
In most cases their services are server encrypted and not client side encrypted.
So its easy for other services to implement features like qr code login or temporary password as the company has access to decryption keys and can open vaults on the clients behalf after verifying users identity through this method.
Therefore the philosophy with which both services are made should be taken into account when suggesting for newer ways to login.
Thanks
I wonder if each session could get a public+private key pair. Then when you go to generate a QR code, you have to enter in the current sessionId. The the authenticated session could then lookup the public key of that session, encrypted some secret, your device would then scan the QR code and decrypt with itās private key.
Then whatever that secret is could be used to authenticate the session.
Iām not arguing for it. But some people are asking and I figured Iād add my own thoughts on how it might be not horribly implemented. Below is a loose abstract concept. I will be assuming both clients have internet access.
Authed Client: Select to create QR code
1a. Create/Get client local public key. This is not stored anywhere but the local client. Possibly ephemeral.
1b. Prompt user master-password, validate, and temp store
1c. Create QR code containing (client local public key, public session identifier(server side knows))
Scan QR with unauthed client.
2a. Get/create client local public key pair
2b. Encrypt unauth client public key with auth client public key
2c. Send encrypted payload to server targeting public session identifier of auth client, signed with auth clientās public key
Auth client receives response unauth client
3a. Validate signature of encrypted payload with local private key
3b. Decrypt encrypted payload with local private key
3c. Encrypt and sign captured master-password(or derived) from step 1b with auth client private and unauth client public
3d. Display new QR code or transfer via central server, the encrypted payload from 3c
Unauth client verifies and decrypts payload to extract master-password(or derived), allowing the client to do whatever it needs to do to setup the rest of the session, download the vault, and decrypt it
Iām sure some variation of this could be quite secure.
My bank just enabled this feature and honestly: I LOVE IT A LOT!
It feels so safe to use and itās super easy. One of the best login methods there is.
Yes, please implement SQRL as a protocol within Bitwarden to authenticate me to a website, rather than as an authentication method to oneās vault (in lieu of master password).
Thanks for merging all the various instances. Please note that you merged in SQRL Identity however, it is NOT the same as here.
This request is for an authentication method into Bitwarden.
The merged-in request in question is for implementing the SQRL identity/auth protocol for association with items within the vault and to authenticate to those sites.
Please split these back out and reopen SQRL Identity
I believe this may be the same principle that is applied when you use passwordless WebAuthn sign in on a guest browser. You are provided a QR code that your device then needs to validate. Others may be able to confirm as I have only tried direct passwordless sign in using Appleās passwordless implementation that has been rolled out to sites like eBay and BestBuy (US). Bitwarden is introducing this in 2023.
Yes, definitely the same principle. The key difference (among many) between WebAuthn passwordless and SQRL is that secrets are generated and stored per entity with WebAuthn (hence passkeys, aka passwords you donāt need to enter manually), while SQRL has implemented it such that the secret doesnāt need to be stored, since the identity can generate it at any time on the fly once unlocked, and therefore is notably lighter weight. It could still catch on, but Iām afraid that time has passed, and the less robust, less adaptable, less portable option has won out.
I am liking the login with device feature. But I feel that qr code functionality would greatly improve this workflow as I dont always get the notification on my device in a timely manner.
