Some service like Bitwarden use the password to encrypt part of your personal data, so that nobody except you can access it, and they archive this because the server only gets your password's hash from your login prompt the server never knows your password and therefore can actually encrypt your data with your password.

But if we where to actually pass-out passwords, because some mostly unfounded thoughts of they being evil, what mechanism would we use such that we can have authentication without password that allows to encrypt part of our user data in a way that the server cannot infer the secret as is done by hash functions, such that the login secret can be stored in a password manager/it can be written down in paper and entered in a webpage without the browser implementing any authentication extensions or standards?

  • 2
    "some mostly unfounded thoughts of they being evil" - "passwords" by themselves are not considered evil by "unfounded thoughts". Easy to remember passwords are considered evil from the standpoint of security since they are easy to break. Hard to remember passwords are considered evil from the perspective of users since they are hard to remember. Mar 25 at 11:15
  • @SteffenUllrich They cold simply write them down!!!! And no it is not a problem if the user stores with responsability their notes
    – Delfin
    Mar 25 at 11:20

2 Answers 2


Bitwarden an others use client-side encryption with a client-side secret to ensure that data can only be decrypted on the client (and not the server storing the encrypting vault). So your question is basically what client-side secrets exist which are "not a password".

This could be basically anything which can hold or produce data usable as encryption key: long passphrases together with a key derivation function, locally stored (random) keys protected by local biometry, data stored on external devices like hardware tokens or mobile phone, ... How useful these are as an alternative really depends on more requirements than "not a password", like how expensive, how easy to use, how easy to use in a multi-device environment, how easy to use in corporate environments ...

... such that they can be used without some locally stored data nor some special hardware?

If the encryption key (or anything which can be used to derive it) should not be stored locally, then it obviously must be stored remotely since it can not be recreated (for decryption) out of nothing. Remotely means some trusted party, either some trusted system inside the corporate environment or some somehow trusted third party or a combination of multiple parties (to reduce the risk of one party being compromised). Of course, the secret then somehow must be retrieved from this party (or parties) which means some kind of authentication with a sufficiently secure mechanism is needed.

  • @Delfin: extended the answer. In short: if it should not be stored locally it must be stored remotely and then retrieved in a secure way. Mar 25 at 11:12
  • Not I mean, that it shall not depend in any specific hardware or the data stored in any specific device. Like stored in a Password Manager, but without needing to add extensions to the browser
    – Delfin
    Mar 25 at 11:14
  • @Delfin: a) you need to have some encryption key b) it needs to come from somewhere. Basically you have in impossible restriction for b) in that it should not be locally stored, not remotely stored, not derived from something stored locally, remotely, on a device, in the brain of the user .... This is impossible. Mar 25 at 11:17
  • It can be derived from something else. Preferably for an interactive challenge process, where the server puts challenges to the client to be filled with help of the secrets, and the server may also to solve some challenges and in the process a secret can be derived that can be used by the user to encrypt their data
    – Delfin
    Mar 25 at 11:19
  • "such that the login secret can be stored in a password managed and entered in a webpage without the browser implementing any authentication extensions or standards" probably should work
    – Delfin
    Mar 25 at 11:25

One obvious solution for non-password-based authentication is public/private key pairs. This is widely used already, with mTLS (client certificates), SSH, and FIDO2/Webauthn/Passkeys being the best-known examples (though there are many others). The server only ever knows the user's public key (which isn't secret at all), and the ephemeral challenge value that it sends when the user tries to log in. The client knows the private key, which it uses to sign the challenge (thus proving ownership of the private key) and sends the signature back, and the server validates the signature for the challenge using the user's public key (thus verifying the user holds the private key) and lets the user in. This is usually handled automatically (e.g. as part of the TLS handshake).

Now, by itself this only gives authentication, not encryption. However, if you use a key type that supports asymmetric encryption (RSA is the most common here, though elliptic curve cryptography - which is secure with much shorter key lengths than RSA - also works through the use of ECIES), then the client can also generate a symmetric key, encrypt (wrap) it using their own public key such that it can only be decrypted using their own private key, encrypt and authenticate arbitrary data using the generated symmetric key (in unwrapped form), and then send the wrapped symmetric key + the ciphertext of the data (along with a MAC/authentication tag) to the server (after authenticating). The server later returns those encrypted items to the client (after authenticating), and the client uses their private key to unwrap (decrypt) the symmetric key, and the symmetric key to decrypt and verify integrity of the data (and later re-encrypt it if changes are made).

This implies the use of the same private key for both client authentication and for decryption. I'm not aware of any protocol that currently does this, and it has one obvious potential failure mode: if the process of signing is too similar to the process of decrypting, then a malicious server could present the wrapped key (or some derivation of it) as the challenge, and when the client signed it, potentially extract the unerapped symmetric key from the signed response. The obvious solution here is to use one key pair for authentication, and a different key - probably a symmetric one, since at this point there's no value in asymmetric encryption any more - for encryption. That increases the size of the secret data that the client needs to know and have ready at every client, but not too drastically; it's often impractical (though not impossible, through the use of mnemonic tools such as key phrases) for a human to memorize even one secure private key much less a private key plus a symmetric key, but it's trivial to store them both on a flashdrive or, ideally, a hardware security module of some kind (such as a smart card/Yubikey/etc.).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .