I've read questions targeting the usage of basic authentication over HTTPS. Since the connection is already secure, except e.g. a compromised certificate, communication should be rather safe.

But I work in a research project where HTTPS might not be an option and the location which hosts our database has already been breached recently, leaving me with an uneasy feeling about storing, even encrypted user credentials.

So I came up with the idea of using asymmetric encryption. The server only stores only the users public key in the database. Turns out WebAuthn already set out to tackle this problem. Unfortunately it is not widely adopted yet and therefore would require us to generate the public key in a different way, e.g. based on a chosen user password. Is it feasible to use a custom implementation of said idea to guarantee a secure credentials exchange and authentication?

PS: I'm not very profound with the literature. Does anyone have a paper for this kind of approach specific to web technologies?

  • 3
    Don't roll your own crypto. That's recipe for disaster.
    – vidarlo
    Jan 30, 2023 at 14:53
  • 1
    You're not supposed to downvote if the OP has a bad idea, only if the question is not well researched or similar... That's just toxic, especially to newcomers... Jan 30, 2023 at 17:41

2 Answers 2


1. To me it looks like an XY problem.

an uneasy feeling about storing, even encrypted user credentials

May be this is reason. You don't need to store passwords, neither plain nor encrypted. Store passwords hashes. Then even if the database is again compromised, the attacker will not know the passwords.

Solution: Use some resource-intensive password hashing algorithms like Argon2, bcrypt, scryt, PBKDF2. This will prevent from brute-forcing in case password hashes are leaked.

2. About asymmetric encryption

work in a research project where HTTPS might not be an option

If HTTPS is not an option, then I would suppose that an own scheme based on asymmetric cryptography should be even less an option than HTTPS. You would have to solve all the problems that HTTPS solves, or more precisely, the problems that TLS solves. For instance:

  • How will server know that particular public key belongs to particular user? TLS uses certificates. How will you solve it?
  • If the key of particular user is leaked, how will you implement replacement of the keys and how will you prevent requests that use the old key pair? TLS relies on revocation lists. What will be your solution?
  • If a private key is leaked, and if the attacker has recorded the traffic for a long time, like weeks or months, the whole recorded traffic can be encrypted. TLS prevents it. How will you prevent it?
  • Even if the attacker has no private keys and cannot decrypt the traffic, but knows that at particular moment particular command was sent from client to server, the attacker can just resend corresponding fragment of the traffic, and your server will accept it and will perform the commands encrypted in this fragment. In TLS such scenario is impossible. How will you solve it?

Solution: Try to use TLS.

  • Minor caveats: 1: Strong password hashing is incompatible with HTTP Basic auth (no session, creds checked every request) which is one of the reasons people simply should not use basic (or even digest) auth (salted fast hashes are insecure but still better than plain or encrypted passwords). 2: The third bullet point (forward secrecy) is optional in older versions of TLS and only mandatory starting with 1.3. But those are minor nitpicks; these are all good concerns (along with many others like preventing spoofing another user's activity after authentication).
    – CBHacking
    Jan 30, 2023 at 20:19
  • @CBHacking: 1) As I understand, the author does not want to use Basic Auth and is looking for alternatives. The title confirms this: "Using asymmetric encryption as authentication". Means, asymmetric encryption instead of Basic Auth.
    – mentallurg
    Jan 30, 2023 at 20:44
  • @CBHacking: 2) You are right. I assume that one is not forced to use other versions than TLS 1.3.
    – mentallurg
    Jan 30, 2023 at 20:45
  • Fair point about moving away from basic auth, but in the asked-about case it would be away from passwords entirely. So yeah, just to clarify, the best solution is: Use TLS, with passwords, where the passwords are not directly stored but are instead salted and hashed using a strong passwords hashing algorithm.
    – CBHacking
    Jan 30, 2023 at 20:59
  • @CBHacking: OK. If you want a bit nitpicking 🙂 , I'd change your statement. It does not matter if password is stored as a plain text or as a hash. If something secret is sent, it should be protected. I'd put it in this way: Use TLS when passwords are transferred.
    – mentallurg
    Jan 30, 2023 at 21:19

Use client certificates

We all know that with HTTPS (i.e. HTTP on top of TLS) the server presents a certificate which the client validates in order to know that it is talking to the right server.

A less known fact is that the client can also (optionally) present a client certificate to the server. The server can then use that information to identify the user who is accessing, reject access to certain paths if a valid certificate was not providing, etc. This is all well tested and supported by both web servers and web browsers (even if the process to import client certificates could be consider a bit cumbersome).

The server does not know any secret from the user (not even hashed secrets), it only needs the public key of the CA (typically a custom one) that is vouching for the client certificates.

Still, if you don't trust such a location, it might not be a good place for hosting the rest of the database contents, either.

Note: You claim "HTTPS might not be an option", but like other users before, I contend you do want to use HTTPS. You are probably thinking of something like a password form in a https page, which is quite different. If your really can't use HTTPS, you should explain the limitations that lead to that. (but with no https or equivalent technology, you are pretty much doomed here)

  • Thanks for your answer and your concerns! I will dig into user certificates and see if that might be a fitting solution to our problem. Jan 31, 2023 at 12:01

You must log in to answer this question.

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