Slightly off topic at this point, but:
If you're really interested in rolling your own security fixes (which I
don't recommend - it's a lot harder than it looks) you might want to read
"Applied Cryptography" by Bruce Schneier.
>Of course it would be a mistake if you just hash the password and send the
>hashed password, because then the hacker would just have to send the same
>hash to login! So instead you take the password and the sessionId(or some
>random variable sent by the server) and hash them together(on the
>browser). This hashed value is then send to the server.
2 questions/points:
* You're assuming here that there's no way to fake the session, I presume?
* How do propose to share this "random number" without Eve the Eavesdropper
finding it out?
Given that either the session or the "random" number can be maintained
secret (and you only use the secret one), this is a viable solution.
Keeping these two elements secret is another matter.
>The server retrieves the password from the database(he will know the
>username because it is sent in plain text) hashes it together with the
>sessionId(or the random variable) and compares the two hashes. If they
>match he knows that the user knows the password. This way the hacker has
>no chance because the hash value sent over the internet changes for every
>login.
--
* Jim Cheesman *
Trabajo:
[EMAIL PROTECTED] - (34)(91) 724 9200 x 2360
If we do not succeed,
we run the risk of failure.
--
To unsubscribe: <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>
