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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
