Dangerous Web Security Features
tunetheweb.com
Dangerous Web Security Features
1–10 of 42 posts
Re: Dangerous Web Security Features
#2Disagree with HSTS being 'dangerous' in 2019. There are not really any good excuses left to have any parts of your website (new/different subdomains included) unable to use https. On the other hand, HPKP is a lot easier to mess up and is more situational, but HSTS should be standard by now.
The author's recommendations are still good (If everyone tried to set up strict HPKP+CSP on their websites, I can imagine how many would break), but I view things like "If you've a sub-site that you never got round to securing (e.g. http://blog.example.com), then you've just forced yourself to upgrade with this policy." as a positive, not a negative (hence the word 'upgrade').
Re: Dangerous Web Security Features
#3Disagree with HSTS being 'dangerous' in 2019. There are not really any good excuses left to have any parts of your website (new/different subdomains included) unable to use https. On the other hand, HPKP is a lot easier to mess up and is more situational, but HSTS should be standard by now. The author's recommendations are still good (If everyone tried to set up strict HPKP+CSP on their websites, I can imagine how ma…
HPKP as people know it is being withdrawn from browsers so there is no need to discuss it further.
Re: Dangerous Web Security Features
#4(2015), edited (2018).
I've had week-long HSTS on my personal website for a few years (which is short enough that most clients ignore it) out of an abundance of caution/FUD, and it hasn't really been a problem - I have had periods where my cert expired (for complicated reasons, I renew Let's Encrypt certs manually every three months, and sometimes I don't get around to it in time), but I didn't remove the regular HTTP 301 to HTTPS during that time. So I don't think permanent / preloaded HSTS would have been a problem.
On other sites I've set up since then, I've built them on top of hosting that assumes reliable HTTPS and renews it for me, e.g., Twisted with txacme or AWS Cloudfront with Amazon's CA. So I've been able to assume working HTTPS from day one.
In October 2017, Google announced plans to deprecate self-service HPKP for exactly the reasons outlined in this article, which took effect in late 2018. See https://developers.google.com/web/updates/2018/04/chrome-67-... and the links provided . If you're a major site and you really, really know what you're doing and you're confident the risks outlined in this article , you can still get a hard-coded HPKP entry in the browser source code.
Re: Dangerous Web Security Features
#5And then we come to the most dangerous item, because you have least control over it: preloading HSTS right into the browser.
I can't say specifically why, but there's something about a browser that treats a certain list of sites specially, by default, that just doesn't sit well with me. I've had this feeling ever since I heard about the feature. Not exactly net neutrality, but somewhat reminds me of it.
Re: Dangerous Web Security Features
#6Can we add minimum password complexity requirements to this list? There is nothing more annoying than having to adjust my already 128-bits of entropy password because the website feels I need a special character. Plus, now hackers have a guide for what the password looks like.
Re: Dangerous Web Security Features
#7Disagree with HSTS being 'dangerous' in 2019. There are not really any good excuses left to have any parts of your website (new/different subdomains included) unable to use https. On the other hand, HPKP is a lot easier to mess up and is more situational, but HSTS should be standard by now. The author's recommendations are still good (If everyone tried to set up strict HPKP+CSP on their websites, I can imagine how ma…
I definitely agree there's no excuse not to use TLS anymore.
I recently ran into this on a city of Vancouver website for voting information. While any page that had a form used HTTPS, all other pages forced the user to use HTTP. Like, for those pages, it redirected to unencrypted even if you typed in https://. Including the page with polling location information.
So any malicious actor in a privileged position, like a public WiFi network operator, could have effectively prevented people from getting accurate poll location information, effectively DoSing prospective voters.
I tried to bring this to their attention, but I got a response telling me their IT guy says it's not a problem because no user data is submitted on those pages. Never mind that it was probably more work to selectively enable TLS per URL and leaves important content vulnerable to manipulation. Incredible!
It's like the old "all of our download links use HTTPS", but the downloads page is served unencrypted. Frustrating.
Re: Dangerous Web Security Features
#8https://connect.ed-diamond.com/MISC/MISC-102/L-en-tete-HPKP-... ?
https://news.ycombinator.com/item?id=15089513 I'm giving up on HPKP, Aug 24, 2017
Re: Dangerous Web Security Features
#9Disagree with HSTS being 'dangerous' in 2019. There are not really any good excuses left to have any parts of your website (new/different subdomains included) unable to use https. On the other hand, HPKP is a lot easier to mess up and is more situational, but HSTS should be standard by now. The author's recommendations are still good (If everyone tried to set up strict HPKP+CSP on their websites, I can imagine how ma…
Caching. If Netflix wants to let company or University x cache their shows, they can just distribute over http encrypted blocks of content. Same with package distribution (although these are usually verified via signing)
Re: Dangerous Web Security Features
#10Can we add minimum password complexity requirements to this list? There is nothing more annoying than having to adjust my already 128-bits of entropy password because the website feels I need a special character. Plus, now hackers have a guide for what the password looks like.
NIST 800-63b actually recommends against character class requirements[1] in favor of minimum length requirement and blacklists of breached passwords and other obvious passwords. Sites that require special characters are not following the current best practice.