Dan Eloff
dan.eloff at gmail.com
Tue Apr 25 18:37:59 EDT 2006
On 4/25/06, Deron Meranda <deron.meranda at gmail.com> wrote: > On 4/25/06, Joshua Ginsberg <listspam at flowtheory.net> wrote: > > > Surely it can't be all that easy? There must be some tricks for > > > securing things that I'm not aware of. Something I'm misunderstanding? > > Proper website security is a very tough thing to get correct. > The history is littered with big companies that have gotten it > wrong: HotMail, Yahoo, Amazon, etc... Fortunately for many > sites just close enough is good enough. You really need to > determine what kind of security you need to figure out what to do. Ironclad. I collect a lot of personal information about people (including myself) and I don't want anybody else gaining access to that. > Using cookies instead of (or in addition to) HTTP authentication > (Basic/Digest) is in many cases somewhat better, mainly because > you have better control over the browser memorizing passwords > and that the server can make it easy to log off a user (just try to > log off when using HTTP authentication). Tell me about. I just implemented a mixed authentication system yesterday (wrote my own impl of basic auth protocol, because an auth handler wasn't working well for me) and was annoyed to discover that even when I logout, the browser logs me right back in. I ditched that now. I could have saved myself the trouble had I done my research better to start with. > If you want to do any sort of log off or expiration, you should also > include the expiration date in the cookie content (and properly > encrypted or signed), since the actual cookie expiration property > is modifiable by the user. How can anyone cause trouble like that? If a user goes to that much bother to logout without being logged out, then he deserves to not be logged out. Maybe on a shared computer it could be an issue, but you shouldn't have a live session cookie on there anyway after your done with it or you've got a security hole you could drive a tank through. > And if not *everything* is over TLS/SSL, then it's not worth putting > too much effort into it anyway. (Which, btw, google mail can > operate in all-SSL mode if you start at the page > https://mail.google.com/ when you first log in). Confirmed, I don't think I'd worry about that at home, but I'd definitely use that feature on public networks. >Even then though, > if you're not validating client certificates, TLS/SSL is severely > handicapped already from man-in-the-middle attacks. I don't understand that could you please briefly explain it? Why am I not validating client certificates and how do I do that? > > What I do (by using mod_python) is to use a cookie-based system. <snip> Sounds very good actually. Ok how's this for a design: Login over https, send two cookies, each with a signed SID, one cookie with secure enabled. Set the secure cookie with the path (say /secure) where everything needs to be done with https. If the unsecured cookie is present, and the SID checks out, and the session is still valid, create the session (so basically the user is logged in.) http is used preferentially after that. However any pages where the user can access his information or do anything that you wouldn't want someone else doing is in /secure and uses https. Mark the session as 'secure' if the secured cookie is also present and the SID checks out. Unless the session is marked secure for the /secure directory, log them out and return them to the login screen. This should be done in one place prior to handing off to a handler like you did, so omitting it in a single handler doesn't create a security hole. One thing I'd love to know how to do though, is make sure all links pointing to the /secure directory use https. I use purely relative links inside my website because it makes moving code from development server to production server and back really easy. Probably you could do it with mod_rewrite. Thanks for sharing your valuable input! -Dan
|