Re: New Input type proposal

On Jan 11, 3:13 am, Alexander Mueller <noem...@[EMAIL PROTECTED]
> wrote:
> Ben C wrote:
>
> > I was referring to the common practice of using one pet's name as a
> > password.
>
> Sorry, didnt notice the pun :).
>
>
>
> > Some point in that yes, but really users shouldn't use the same
password
> > for different sites, or at least, should use one password for
> > low-security unim****tant sites and a different one for bank accounts.
>
> I agree, but thats another point and they usually use the same password
> for different sites.
>
>
>
> > How does munging alter that situation? If he can replay the first
access
> > (by getting hold of the hash used) then won't he just get his very own
> > replaysalt in just the same way?
>
> > Can you describe an example, step-by-step, of a session in which the
> > replaysalt provides some benefit that one-time session numbers don't?
>
> 1.) The user requests a site.
> 2.) The server sends the login form, issues a random replay salt and
> stores it in a session.
> 3.) The user enters the necessary information.
> 4.) The browser hashes the entered password and hashes the result once
> more with the replay salt.
> 5.) The server hashes the stored hash with the previously issued replay
> salt and compares the result to the given value.
>
> Alexander


Hi Alexander,

For clarity of my own mind, I have painted it out in colour.   Could
you confirm that this is the idea...


Assuming a clear password is stored in a database/file on the server
with the username as the key to the password table.
eg...
UserName        Password
ralphmalph      fido
discooctopus    secret
bill            momoney

1. Web client requests a login page.
2. Server creates a session with a session id
3. Server creates a salt value (available for this session only) (eg.
"D8SD67586DF987FD")
4. Server creates the login page with the value as such....
    <input type="hash" hash="md5" salt="D8SD67586DF987FD"
replaysalt="" />
    ... and serves the web page
5. Web user enters his login details as username of "discooctopus"
with a password of "secret"
6. Web browser encrypts the password using md5 with the salt
"D8SD67586DF987FD"
7. Web browser posts the login details (user name and hashed password
only (not the salt)) to the server.
8. The server then does this...
   i.  lookup the given user 'discooctpus' from the database.  The
result is the password of 'secret'
   ii. this value of 'secret' is encrypted using md5 with the salt
"D8SD67586DF987FD"
   iii. Check to see if the encryptes value is the same as the hash
value posted from the web client.



Does this capture your idea simply?