Was wrestling with these points myself... With respect to case-1 adding 0% security:
- Is a hijacked session the same as an exposed password? a hijacked session compromises a single session on a single system, while a stolen password constitutes a cross-session and (because passwords are re-used) often a cross-system breach. At the very least, probably better to keep the damage temporary and in-house rather than be the system that's used to compromise everyone else? - Also, consider OAuth- it issues tokens in lieu of passwords to allow for third party access, which provides the safety of limiting access and duration of access, and of invalidating the token if required. To me a session cookie is somewhere between a token and a password in that respect. - Many major sites implement case-1 security- Facebook for example. There's got to be *some* reason for that? - The login-only vs all-the-time SSL options aren't my idea, I took it from WordPress (http://codex.wordpress.org/Administration_Over_SSL). Again, assuming there must be a reason. As for your PS, I don't see how the scenario you describe would be any different from a site that is all SSL all the time? The user has to start at an HTTPS login screen somehow- are you saying the whole HTTPS concept is BS? Feel free to keep this going- I'm no security expert, just trying to get a handle on in it all-- On Thursday, September 20, 2012 10:47:22 AM UTC-4, Niphlod wrote: > > ok, i got the point on having a hard time implementing case-1 with web2py. > Please humour me, what I didn't got over those kind of requirements is > basically.......case-1 adds 0% security. > If there is a man in the middle, he can "scoop" the cookie just as he > would scoop the password in the case of no HTTPS at all on the site (so, > user A gets access to whatever B can see). > Is it just to "reassure" the majority of dumb users with a nice padlock on > the login page or it gives some kind of *actual *protection? > > PS: leave aside the fact that SSL certificate allows your site to be > "trustworthy" (user A knows that the site at http*S*://example.com is > managed by Yarin). > If you are trustworthy for only *some *of the urls, you publish something > at http*S*://example.com and something at http://example.com, and users > need to know *in advance* that your login is on a http*S*, *and pay > attention before hitting "login"* to avoid a simple dns poisoning attack > (i.e. for their computer http://example.com points to the site managed by > a - very bad - Niphlod, that can fake whatever is there on Yarin's http*S* > ://example.com/login on Niphlod's http://example.com/login). > That is a nice "theoretical" security gain (Niphlod can't have a working > http*S*://example.com/login because he doesn't get to know the private > key of the certificate, and users are at least "warned" that the > certificate is not right) but with "normal" users (click everything shiny? > yes!, install this toolbar? yes! format the c: drive? yes!) means more or > less 0% achieved security (given that they hardly "know in advance" that a > padlock on the page is "required" to be there). > > Am I missing something ? > > --
