Re: Securing a website...storing hashed passwords?
From: David Whitney (intrepid_dw_at_hotmail.com)
Date: 07/29/03
- Previous message: Rob Slade, doting grandpa of Ryan and Trevor: "REVIEW: "A Guide to Forensic Testimony", Fred Chris Smith/Rebecca Gurley Bace"
- In reply to: David Whitney: "Securing a website...storing hashed passwords?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: 29 Jul 2003 12:19:39 -0700
After I wrote my message, I realized the problem and realized the
solution.
The solution was to change a subtle detail of what I send over the
wire that eliminates the need to store the clear pwd on the server.
The solution is to compute the hash of the candidate password, then
combine that hash with the server's random number, and hash that
result. That final hash is sent to the server. At the server, we can
take the hashed password from the database, rehash it with the
server's random number appended. If those two strings match, we infer
the user entered the correct password. No cleartext password is ever
transmitted, nor is one ever stored.
Another way of putting it:
Candidate hash to server = hash(hash(candidatePassword)+randomNumber)
rather than hash(candidatePassword+randomNumber)
Thanks anyway,
David
intrepid_dw@hotmail.com (David Whitney) wrote in message news:<63563b00.0307270514.c3bcedd@posting.google.com>...
> Hello, all...
>
> I've been trying to become smarter about the proper way to improve the
> security for a web site that presumably won't have an SSL option. I
> keep going in a bit of a circle, so I thought I'd solicit some
> opinions.
>
> Here's my intent:
>
> The server will supply a random value to a login page. The user will
> enter a password, and a javascript routine will combine that password
> with the random value and create an MD hash. That hash will be sent to
> the server on submit of the page.
>
> On the server end, I'll take the user's password (and here's the
> confusion for me), the random number, recompute the hash, and if that
> and the submitted hash match, access is granted.
>
> This scheme presupposes the availability of the original password on
> the server, presumably in a database - but cleartext pw's in the
> database are obviously a nono. The preferred scheme is to store a
> hashed password in the database; but if I do that, I can't reconstruct
> the password to compute the hash based on the random value the server
> supplies to the login page. If I encrypt the password into the
> database, I have a key management issue, eg storing either a symmetric
> or private key in a web configuration page.
>
> So either I'm storing an important key in a config file and relying on
> file security, or I'm putting a plaintext/encrypted password in the
> database, so either way it seems I'm violating a rule. Is it a matter
> of risk management, or am I missing something more fundamental?
>
> I hope this makes some sense; I'm composing this message in a hurry
> and I'm not sure it's written as clearly as I'd like....thanks for
> your patience!
>
> Thanks,
> -David
>
> p.s. Please reply to group; email in header is long dead.
- Previous message: Rob Slade, doting grandpa of Ryan and Trevor: "REVIEW: "A Guide to Forensic Testimony", Fred Chris Smith/Rebecca Gurley Bace"
- In reply to: David Whitney: "Securing a website...storing hashed passwords?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
