On 11 Apr 2005 Richard Lynch wrote: > > 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. Fair enough. And I also take all the points about plaintext passwords. I don't think anyone was talking about that (I certainly was not). > You have to assume the user of the PW has been stupid and set the PW > to the *same* PW as their bank account. Fair enough. The approach I was talking about does not protect against that and that is a flaw. The random token approach does a much better job. > > 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?! Because in that particular system no one considered the user ID to be valuable. It is a little more complex to store and look up a hash, but not dramatically so. > > 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 ! Who said anything about *storing* the PW in clear text?? For the record, it is stored encrypted, though I know this is weak protection since access to the server gets you access to the decryption key. For the web portion of this there is no visibility to the password at all. For the email portion, of course there is as the password has to be sent in clear text as it is useless otherwise. I personally would prefer to use a "Reset my password" approach and display the new PW over an HTTPS connection, but that does not meet my client's needs. And "Email me my password" features are widespread -- used most often on web-based discussion boards and the web-based interfaces for mailing list software. Are you saying they are all wrong and no one should develop or implement them, or just that you personally would never use that feature? On the general issue -- there are sites with login security practices that are excellent, good, mediocre, poor, or nonexistent. What's bugging me here is not the idea that we should know about and use good practices, and from being willing to put forward my own questions I've learned a lot about that in this discussion. What's bugging me is that there is a tone suggesting that everyone should be using the highest- level security practices for all data no matter how unimportant. I have always learned that you match the security practices to the value of the assets protected and the level of threat. A shed in my back yard should be locked but it does not need an alarm system tied to the local police. My house might. The local bank should do way better than that. Etc. Web site security has the added problem that we do allow people to use the same key for the bike shed and the bank, but beyond that there are still tradeoffs and decisions to be made and not everything requires the same degree of protection. Also I think it is easy to forget about the difference in the level of threat posed by a routine vs. rarely or randomly used feature. If an encrypted password is stored in a cookie every user of the site is vulnerable and the entire universe of user accounts is open to attack if someone can figure out how to decrypt it. On the other hand an "email me my password" feature is only open to attack when used and for the people who use it. The number of systems or events which it produces for attack is much smaller. That doesn't make it secure but it is likely less of a threat than practices which create vunerabilities automatically on every system which connects to the site. This kind of discrimination seems to often be absent in the discussions here, but when implementing seurity in a real system I contend you have to do it. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
