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") --
