Normal user authentication is done by comparing "hash"-values. A simple example of this:

The user password is hashed with PBKDF2 on the client using a salt (the salt is the hash of the user password concatenated with his username). That result is then sent to the server where it is again hashed with some unique per-user random hash value and stored in the database with the unique salt.

Now, is it more/less secure if I associate a user account with a random BLOB of data encrypted using as key the hash of the PBKDF2 output concatenated with a unique salt?

So instead of matching a hashed password to prove who you are, you now decrypt some random BLOB to prove who you are. What are the implications? It is more computationally intense to decrypt a BLOB? Are there any security downsides?

What are the implications if the BLOB is not random, but we use the username?

Thanks for you explanation!

  • 4
    What problem are you trying to solve, and what reason do you have to believe that this approach is better suited to solving it than existing solutions? Mar 22, 2013 at 22:56

2 Answers 2


The most basic authentication scheme looks like this:

  1. Client knows password.
  2. Client shows password to server.
  3. Server is happy.

Password hashing is done only to counter a secondary threat: that some bad guy succeeds at having a peek at the server files or database, through some illicit but common way (SQL injection attacks are usual). We don't want that bad guy to immediately learn all the user passwords. That would be inappropriate. To avoid that, the server will not store the passwords themselves, but only some values which are sufficient to verify a password. This is where hashing occurs. The server hashes the passwords, with a slow and salted hash function, so that the envisioned attacker with sharp eyes will at least have to perform some substantial work for each password he will recover.

But that hashing is entirely a server business. The client does not see it. From the point of view of the client, the protocol is just "show the password". How the server decides that the password is the correct one or not, is completely irrelevant to the client.

The basic protocol is usually sufficient because it will be played within SSL (aka HTTPS in a Web context), which ensures that the client has some a priori guarantee that it is sending the password to the right server, and nobody else can spy on it. We need something like SSL anyway, to prevent the connection from being commandeered once the authentication has been done. So we might as well use it and just show the password to the server.

Nevertheless, some other protocols have been designed, in which the raw password is not shown to the server. Motivation is either distrust of the security guarantees provided by SSL and its digital certificates, or just disregard of the risks of hostile hijacking (the protocol is played "in the clear" and it is just assumed that attackers are passive only -- a singularly optimistic stance, verging on the naivety, but it was much more common in the late 1980s and early 1990s). These are challenge-response authentication protocols. Your proposal with the "encrypted blob" is of that kind. The server sends a value to the client (the challenge) and expects the client to process it in some way which involves the password (that's your "decryption"). The server verifies that the client properly responded to the challenge.

In general, challenge-response protocols are not a good idea. They have the following drawbacks:

  • The main benefit of a challenge-response protocol is to avoid showing the password to a fake server. But showing the password to a fake server occurs only if the client accepts to talk to a fake server in the first place, meaning that the transport medium can be subverted and allows replay attacks and men-in-the-middle. This is bad news. The overall situation is rotten and should be fixed in a much more thorough way than using a challenge-response protocol. Wearing a lifejacket is good, not being on board the Titanic is better.

  • The server must have a way to verify the response to the challenge. It is very hard for the server to avoid storing something which is password-equivalent. For instance, if the challenge is "you, client, decrypt this blob !", then the server must have encrypted some data to produce the challenge blob; otherwise, how would the server know that the decryption worked ? And to do the encryption, the server must know the encryption key, i.e. the password, not a hashed version thereof. You have lost the benefits of slow and salted hashing. Keeping the server's database invisible from the attackers becomes critical again.

  • If the server is fake (and you are using a challenge-response protocol instead of just show-the-password precisely because you deem it possible that the server is fake), then that fake server will still learn a value which is deterministically computed from the password, i.e. something which is sufficient to mount an offline dictionary attack (the bad guy tries potential passwords at the full speed of his GPU, on his own machines). That's not good. (Speaking of which, your suggestion to use the "hash of the user password concatenated with the username" as salt is not a salt at all, because of this determinism.)

  • A client who responds to a challenge is a client who can compute. This does not map well to a Web context. In a Web context, client code is Javascript, and Javascript is feeble; it is not good at computationally intensive tasks.

These drawbacks can be fixed, with another tool: mathematics. Maths are great. They allow a more recent and considerably niftier class of authentication protocols, called password authenticated key exchange. These protocols allow for mutual authentication (the client also gains some guarantee that it talks to the right server; they resist offline dictionary attacks (even a fake server, or a fake client for that matter, does not learn anything which would be sufficient for that), and the best of them avoid having to store server-side some password-equivalent data. The most oft-cited PAKE protocol is SRP. SRP has the additional benefit of being integrated in SSL/TLS, which is good because even with the best authentication protocol in the world, you still need something to protect whatever data you will send afterwards.

  • Thanks for your response. A quick extra question. Using the username concatenated with the password as salt is indeed not a good salt for exactly that reason, but for salting client-side with PBKDF2? That result is again salted and hashed on the server with a per user unique salt? So the "real random stuf" happens on the server. The purpose of salting on the client-side is such that the server nevers sees the users real password.
    – Anonymous
    Mar 23, 2013 at 21:29
  • @SanderDemeester why is it a problem for the server to see the real password? My guess is that, since people tend to reuse passwords, the server folks may gain more knowledge about the user than what they should, and you're trying to prevent that. Is that correct? This is a tough problem, and I can't give any advice, but answering your question: see this for more info about why using predictable salts is not ideal.
    – mgibsonbr
    Mar 24, 2013 at 11:07
  • That is correct, i really want it to be TNO, Trust no one. The server side should have zero knowledge. So i'm looking into SRP at the moment. To see how they solve the problem.
    – Anonymous
    Mar 24, 2013 at 12:13

Encryption is not a magic wand that solves all problems. Specifically encryption only solves the problem of secrecy (authenticity and integrity are not addressed). The use of encryption without a method of integrity checking is a known vulnerability that leads to cryptographic oracles. To prevent malleability attacks an authentication code is used, and an HMAC is a common method of generating an authentication code... So you are back to using a hash function!

Hash'ed authentication schemes are common. The real benefit is that you are not spilling the password to a party that doesn't know the plain text password to begin with. A good example of this is the WPA handshake and NTLM authentication. Connecting to a rouge WPA AP will not spill your plaintext t password, because the plaintext password is never transmitted to the AP. (Which sounds like magic!)

  • Thanks for the response, encryption does indeed solve a different problem. But my question was what would be the difference if you use encryption to proof identify.
    – Anonymous
    Mar 23, 2013 at 18:33
  • @Sander Demeester Yes, and cipher text alone cannot be trusted without a method of integrity checking.
    – rook
    Mar 23, 2013 at 18:35

You must log in to answer this question.

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