On Sat, April 9, 2005 11:51 am, trlists@xxxxxxxxxx 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
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
