On Mon, April 11, 2005 9:13 am, Chris Boget said: >> Please refrain from such speculation, because it does nothing to improve >> the state of security within our community. This idea of storing >> passwords in cookies is absurd. > > Is the above sentiment true even if you store the password as some sort > of hash (md5 or otherwise)? YES! If you have to maintain a "login" over time, your first pass should be to use the built-in session handling functions. http://php.net/session_start Those have been proofed by professionals, and are subject to massive peer review that you can't hope to duplicate. Simply tie the session_id() to the user's record TEMPORARILY, and remove the association after X minutes of inactivity. In addition, if the content or identity of your user is worth *ANYTHING* at all to you, if you care at *ALL* about any kind of security or privacy, you should add additional controls. #1. Set the time-out on PHP's session to the shortest value you can live with, and not have your visitors/boss angry. This is a no-brainer and easy to implement. You have no excuse for NOT doing this. This time-out should be somewhat longer than X (above) but still as short as you can make it. #2. Add an ever-changing random token to their Cookie data on each HTTP exchange. If they don't send back the right token from their previous "click", challenge them to identify themselves with a password, then take them on to what they asked for. This takes a little bit of work, and you have to be careful that not even the sharpest Bad Guys can predict your token, not even if they already have the previous token[s]. It also makes their "Back" button not work, which is a bit of a pain, but less so if you warn them from the login page it won't work. Also be sure to include that same warning in the fine print at top/bottom of all protected pages. If your challenge for a password succeeds, they should end up exactly where they wanted to be when they "clicked" on your site. This is minimally intrusive to legitimate users. A really sharp Bad Guy can still stage a man-in-the-middle attack and pass data back-and-forth, merely observing the interchange, or subtly changing only content that will go un-noticed (they hope) while preserving the tokens and not completely hijacking the session. *BUT* that requires *WAY* more skill/time/resources than "average" Bad Guy. #3 Minimize the number of pages that are password-protected. Or, rather, SEPARATE the content that matters from the "open to all" There is NO POINT to protecting your "about" page or your "FAQ" page etc. By focussing your efforts on the data that matters, you have a lot less scope to worry about for buglets that leak security. Your delineation between "public" and "private" areas should be OBVIOUS to all users, to all programmers, to all DBAs, to *anybody* remotely connected to the project, whether they read documentation or not. This will minimize the odds of a Technical Blunder that exposes data. This is easy for a NEW project if you Design it from the get-go. It can be "challenging" for an existing project, but it's worth it. #4. Track independent corraborating information about the user such as IP address, browser characteristics, and even their average time between HTTP connections. IP addresses change, but in predictable ways for a given session. Some browser characteristics change over time/request, some do not. Human users have typical speeds at which they work. So you can't use any one clear-cut setting here, but rather can produce a percentage "indicator" that this person is still this person, for sure. If you're not sure, challenge them for the password again, but then take them to where they were going in the first place. This will be minimally intrusive, but ensure that they are who they say they are. This is the most complex to implement, and isn't that much of a barrier -- But may be worth considering. I'm sure there are more Good Ideas out there. http://phpsec.org is your first resource for them. "Security is not ON/OFF. It's a gradient." -- me :-) -- 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
