Posted by Richard Lynch on 04/12/05 02:32

On Sat, April 9, 2005 11:51 am, trlists@clayst.com said:
> Well, just because I'm not sure it is worth the effort. What is the
> point of storing a hash code as a proxy (in the colloquial sense of the
> word) for an encrypted password if knowing the hash code gets you the
> same access as knowing the password?

Because the hash code will change VERY frequently.

> True, the hash code can have a
> timeout -- but so can the cookie.

Who cares about the Cookie if they've already got the PASSWORD?!


> For places where the point of the PW
> is authentication only, and not control of access to significant
> resources, I'm not sure there is any benefit to complicating things.

You have to assume the user of the PW has been stupid and set the PW to
the *same* PW as their bank account.

Now, do you *REALLY* want to be shlepping that back and forth in plain
text, and then just blame the user.

Sure, it *IS* their fault for being that stupid.

That ain't gonna win them back as a user when *YOUR* site wiped out their
bank balance!

>> I can't see where the convenience lies. For you as a developer, you've
>> already got the necessary code to do the token thing so there is
>> practically no difference whether you use a token or a password. For the
>> user, what are they going to do with an encrypted password -- are you
>> going to tell them how to decrypt in the case that they have forgotten
>> the password?

Hunh! The *user* never really sees their encrypted password. They've got
no use for that.

Review how it works, and think it all the way through with a User, Server,
and Bad Guy all doing their best.

> A fair comment. I guess it is more just about keeping things simple
> where appropriate.

But who decides where it is appropriate?

Every godamn web-site is asking me for a password these days.

It's like a need a password to fart. [Excuse the language, but that's how
bad it is.]

Am I supposed to remember a different password for 10,000 different sites
I visit?!

That is *NOT* a reasonable expectation for users.

You have to assume your password is being shared across another 1,000 sites.

Hopefully, they're all as worthless as yours.

But if they are *NOT* and they have financial data, *YOUR* site had better
not be the weak link in the chain that leaks out your user's password.

> Just as an FYI, I'm partly playing devil's advocate here. I've never
> written anything that stored the encrypted PW in a cookie (though I
> have stored encrypted user IDs that way for a "remember me" feature).
> I'm just reacting to the sense that there is One True Way to handle
> this issue. In software development there are most often many good
> options.

*WHY* would you not store some kind of hash of the user ID?!

setcookie('remember_me', md5($username));
..
..
..
select username from users where md5(username) = $_SESSION['remember_me']

Is that really any harder?

> A digression to a related issue (where I did take the conservative
> approach): A system I'm working on now was originally set up with
> password hashes in the database -- the PW itself was never stored. But
> the client wanted an "email me my password" feature so we had to
> encrypt and store the PW. Of course if someone had access to the
> database they'd get a lot of other stuff probably more useful than PWs
> so I don't worry about this too much. But I would rather have used the
> hash.

Please tell me what URL that is. I want to BLOCK it so I never ever ever
visit it. Thank you.

Even my lowest-level stupidest password for the 10,000 sites I don't care
about shouldn't be stored in clear-text !

--
Like Music?
http://l-i-e.com/artists.htm

[Back to original message]