@Niphlod 1) "only valid point here is a sort of "netiquette" among web developers"
Wrong- this is a matter of protecting the user. I may have a site that doesn't deal with anything important. Let's say it allows users to see their friends' baby pictures. They need to login so that we know what babies to show. Session gets hijacked? Big deal, you can see someone else's babies. But half the users are gonna use the same password they use for their paypal account. Should they have? no. But you don't want to be the vector by which that stuff happens. 2) It's a cpu issue I can't follow your conclusion here. You say it's not important in 2012, and yet Facebook still defaults to it and WordPress continues to offer it. It may not be a good trade off in most cases, but it's certainly common practice. I think we're still missing something here... 3) Caching issue outdated This is good to know- was not aware. 4) Mixed content issue Mixed content is not always a choice. If you pull images hosted on other HTTP sites, boom, you're stuck with mixed content, and some browsers don't handle it elegantly. IE throws a pop up in your face. Chrome shows a warning indicator on all your HTTPS pages in a session if just one page has mixed content. This is why we are making all-SSL an option but not the default on our site- we interface with Facebook, pull thumb images from outside pages, etc and don't want the pop ups or warnings. We don't deal with sensitive data so the trade-off makes sense to us, but we're certainly not gonna be passing around our users' passwords unprotected. 5) Still don't understand your PS. Can't tell if you're talking about user perception or actual DNS poisoning, but the first point is out of scope I think- my concern is that WE know what is secure- I'm not counting on the user to know or care. As for the latter, I still don't see how the scenario is any different if both case-1 and case-2 require a user to be redirected to https://example.com/login if they type in http://example.com/login. lost me on this one. On Thursday, September 20, 2012 12:56:50 PM UTC-4, Niphlod wrote: > > Well, this list is often used to discuss "good behaviours", so, let's > brainstorm. > > >> - 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 site that compromises >> everyone else? >> > > The only valid point here is a sort of "netiquette" among web developers > (users have a few username-password and use those in each and every site): > sort of "if only all sites gave secured SSL access"... no gain in your's > site security at all. Session expiration is another beast to tackle (users > will feel "good" without re-entering the same username-password if yet > authenticated "some time ago".....but the "time window" is very different > from site to site - just think to different requirements as admin > dashboards, banking accounts, data entry, blogs, forums, etc etc). > >> >> - Many major sites implement case-1 security- Facebook for example. >> There's got to be *some* reason for that? >> > > Yep, saving CPU :P. Users and data security was never a "level A" goal to > facebook (and, respectfully, the data in facebook is not "superprivate" > anyhow). They have a default method for "non-concerned citizens", but you > can tune the preferences to allow "only https navigation" as well if I > remember correctly (I was never a fan of facebook). Probably the > "netiquette" aforementioned works for facebook "big times": if you "leak" > to man in the middle passwords for billions users it "a worst thing" than > leaking 1k usernames-passwords. > > >> - 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. >> > > Quote: > Which Should I Use? > > FORCE_SSL_LOGIN is for when you want to secure logins so that passwords > are not sent in the clear, but you still want to allow non-SSL admin > sessions (since SSL can be slow). > > FORCE_SSL_ADMIN is for when you want to secure logins *and* the admin > area so that both passwords and cookies are never sent in the clear. This > is the most secure option. > This probably has to do with Wordpress being installed on every shared > hosting facility in the world..... speed vs security just to not leak > password (but leak cookie) is not a dealbreaker in 2012 for us (at least > until python shared hosting improves the coverage). An addendum to the > 37signals link you posted before: is dated 2008! Even IE8 now caches > correctly by default if cache headers are set. > > >> 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? >> > > BS? What am I, mad ? Absolutely not! The obvious big +1 is that no man in > the middle can ever see the exchanged data between Yarin server and user A. > As for "users concerns" and dns poisoning, if every page of > http://example.com "normally" redirects to httpS://example.com, then > users knows that every page of Yarin site is providing a padlock (and at > least a good 70% spots the difference). > > Phishing is always behind the corner (e.g. https://exampl*3*.com), but if > you are concerned you can buy "similar" domains and manage those yourself. > > >> >> Feel free to keep this going- I'm no security expert, just trying to get >> a handle on in it all-- >> > > Neither am I, but what's the point in 2012 of using partially ssl for your > site? If the data is private, needs to be secured ("data" as in, e.g., > personal information, like phone no or address). When a page like > http://example.com/profile shows you your address, your man in the middle > will read it. > Should I really go buying a relatively expensive SSL certificate to > provide the "sort of netiquette" said before: maybe yes, but you're > confirming that security on your site is not a "level A" goal. > If the reply here is "browser don't cache well ssl resources" I can assure > you that the situation changed a lot in the last years (mostly from the > time big sites like google, yahoo, twitter & co. allowed a "complete https > navigation" in their domains). > If the reply is "SSL encryption and handshaking is hurting my CPU" I'd say > that also in this "realm" situation changed a lot: you can get a hell lot > of more raw-power/buck than 4 years ago (while instead bandwith-related > costs tends to be more "statical") > --
