in reply to Web based password management (or how *not* to blame tye)

Passing the password as an MD5 hash isn't any better than passing it in the clear, if it weren't done over SSL. Just thought I'd point it out and make it explicit.

I've done something similar in the past. If we wanted to be truly paranoid we'd implement S/Key. (I wish I had my JavaScript S/Key implementation working, maybe someday...).

UPDATE: Some reading on S/Key; RFC 1938, RFC 2289

--
perl -pe "s/\b;([st])/'\1/mg"

  • Comment on Re: Web based password management (or how *not* to blame tye)

Replies are listed 'Best First'.
Re: Re: Web based password management (or how *not* to blame tye)
by maverick (Curate) on Mar 24, 2002 at 21:43 UTC
    um...ya..duh. Pardon the blonde moment. I was thinking of a different scheme and combined two. The javascript md5 thing would work if you sent along a random salt into the login page, then the password (or the md5 crypted password) is crypted with this salt and then sent to the server. Thus capturing it wouldn't do any good, since to login again, there would be a different salt.

    Better?

    /\/\averick
    perl -l -e "eval pack('h*','072796e6470272f2c5f2c5166756279636b672');"

[reply]
      Yeah, that would be closer to what I did in the past ;-) I used the session ID as the salt. And reset the session on failed attempts.

      --
      perl -pe "s/\b;([st])/'\1/mg"

[reply]

In Section Meditations