On 13 Apr 2005 Richard Lynch wrote: > I have what I consider a MINIMUM standard level of security for any site > that asks for a password. > > That would include: > Not storing the password *ANYWHERE* in clear-text. > Not in database. > Not in $_SESSION > Not in COOKIES
Agreed. I see less risk for temporary storage in $_SESSION in the case where the server is well-protected logically and physically, but it's so easy to encrypt (if session storage is needed at all) that there's no reason not to. > Not storing an encrypted username/password in $_SESSION/COOKIE if having > those values provides access. Because at that point, the encryption is > rather meaningless, as it's really a clear-text 32-character code that > happens to be the encrypted value of something secret, but the clear-text > 32-character code gives the Bad Guy access, whether they know the secret > or not. > > If your content/application/data is important enough to warrant a > username/password, then it should be important enough to secure with this > minimal level of security, IN MY OPINION. Here I think we disagree as by this logic no one should store anything in a cookie that provides access (beyond a short temporary timeframe). There are many kinds of sites where users want some privacy or control over their own account but also want the convenience of staying logged in, and where there is little or nothing any Bad Guy skilled enough to go steal the cookie would bother with. For example, many discussion board logins fit this description. I personally use a different password for each one I'm on (it's not very many), and far prefer the convenience of not having to go look it up every time over the "security" of having it expire, particularly since the very worst someone can do if they gain access is post as if they were me. The analogy is that the Bad Guys who know how to break into bank vaults just don't care about my (hypothetical) shed full of garden tools, and if they do test their skills there, the garden tools aren't that valuable anyway. And if in order to prevent this highly unlikely theft I have to remember my key every time I go out to do some work, that's a poor tradeoff to me. What we're arguing about is whether the garden shed [web site] should be designed so that I *have* to use a key (i.e. require a specific level of security) or whether I as the user can choose. For anything involving money or significant personal data, or other similar risks, yes, to me the login security should be forced. But for less important assets there are real benefits to security practices that give the user more control. Some of this is simply a question of whether there is a category of stuff that is important enough to protect with a password but that doesn't require more careful security, login expiration after a short time and other protection mechanisms. I think that category exists, sounds like you are saying you think it does not. > If users forget passwords, they should get new random passwords, with the > application/email directing them to change those passwords to memorable > (to them) but hopefully un-guessable (to Bad Guys) values. Agreed. My clients don't always agree but I think this is correct. > I would contend that anything less is simply a false sense of security, > provided to the un-informed, by using inherently insecure > username/password methodolgy. > > The fact that 10 zillion sites are currently doing exactly that does not > make it "right". > > You obviously disagree, and think everything is just hunky-dory in the 10 > zillion sites that are leaking passwords to any Bad Guy with half a clue. Well I hope that was a bit tongue in cheek. I didn't say that nor do I think that. There's a lot of bad security out there. That doesn't make someone like me who disagrees with a particular set of security principles into someone who thinks all bad security is fine. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
