Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses

Re: Plaintext passwords?

by FoxtrotUniform (Prior)
on Mar 22, 2002 at 20:17 UTC ( #153638=note: print w/replies, xml ) Need Help??

in reply to Plaintext passwords?
in thread We blame tye.

    Unfortunately, storing the crypted version of the password on the server means that the client has to send the password to the server in plaintext. Either you hide that with SSL, or you accept the fact that you have no real security.

    If you try to protect the password in transit by using something like HTTP digest authentication, then you have to store the password (or some equivalent secret information) in plaintext on the server. Which is the bigger vulnerability?

Some excellent points, no_slogan. It's kind of depressing that the current state of the art, as far as anything common enough to be useful goes, relies so much on plaintext passwords. (Although you might be able to get the client to hash the password before sending it over the wire, using a browser plugin of some sort. Provided that you trust the plugin.)

Is there a better way of doing user authentication for sites like PerlMonks out there that doesn't rely on pie-in-the-sky technology? (Preferably something that doesn't involve shared secrets, which IMHO are just too much trouble.) Having the client hash the password before sending it over the wire is a start, but doesn't help much if the server isn't who the client thinks it is, since the attacker can just play back the password hash at the real server.

I'd look up some ideas, but my copy of Applied Crypto is at home, and I'm not. Anyone else?


Replies are listed 'Best First'.
Re: (FoxUni) Re: Plaintext passwords?
by no_slogan (Deacon) on Mar 23, 2002 at 17:12 UTC
    Having the client hash the password before sending it over the wire is a start, but doesn't help much if the server isn't who the client thinks it is, since the attacker can just play back the password hash at the real server.
    That's why HTTP digest authentication includes a variable "nonce" value. The server sends the nonce to the client when it first attempts to access the page. The client calculates the hash of the password and the nonce together, and sends that back to the server. The server verifies that the hash it recieved was calculated with a valid password and a nonce that was actually sent to that client recently.

    If someone tries to replay an old password hash, the server won't accept it, because it won't have a valid nonce.

    If the nonce used contains some (cryptographic) function of the time and the client's IP, you can avoid the problem of having to have the server remember which nonces are valid.

    The problem, of course, is that the server has to have the password in plaintext so it can calculate the hash and see if it matches the one it got from the client.

      How about this:

      • Store the hashed password on the server.
      • Hash the password on the client (using Javascript PasswdMD5 or something), then cat on a sufficiently random session ID and hash it again. Send that hash to the server.
      • The server takes the session ID, cats it onto its copy of the hashed password, hashes the result, and compares that hash to the one it got from the client.

      So the server isn't keeping around any plaintext passwords, and the session ID acts as a one-time key to prevent replay attacks. For extra tasty goodness, you can do this through SSL to prevent attackers from sniffing the session ID, although unless they know the original password hash (which, since we're not storing the password in plaintext anywhere, is mildly unlikely) the worst damage they could do with a sniffed session ID is chuck a bogus hash back at the server and give the real user a "sorry, try again" message (if that).

      I'm a bit leery of this system, because it seems too simple. Can you see any problems with it?

      Update: Cacharbe expressed some doubts about the "sufficiently random" session ID. Basically, the idea is that the server picks a random integer (from /dev/random or something similar), keeps a copy, and sends it off to the client. Client hashes their password, cats the session ID onto the password, hashes _that_, and sends it back over the wire. Server cats the (same) session ID onto its hashed password for whoever the client claims to be, hashes it, and checks it against the hash it got back from the client.

      The problem with this (which I only just saw -- augh!) is that the server's still storing information that can be used verbatim to attack a client account. If I can get the hashed password from the server, then I can just connect, get a session ID, and go from there. In short, it isn't really a step up from storing passwords in plaintext on the server. Oh well, back to the drawing board.


Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://153638]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (4)
As of 2023-03-30 17:21 GMT
Find Nodes?
    Voting Booth?
    Which type of climate do you prefer to live in?

    Results (74 votes). Check out past polls.