|
|
Posted by trlists on 04/09/05 21:51
On 9 Apr 2005 Jason Wong wrote:
> > I might, depending on
> > the needs, store a hash code as others have suggested
>
> Why not in *all* cases?
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? True, the hash code can have a
timeout -- but so can the cookie. 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.
> 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?
A fair comment. I guess it is more just about keeping things simple
where appropriate.
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.
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.
--
Tom
Navigation:
[Reply to this message]
|