> Is TLS1.2 the only supported protocol?
Do you know what the implications are from actually implementing that? One probably should do additional research before making that decision.
> Have you ensured that your content cannot be embedded in a frame on another website?
X-Frame-Options isn't the only way to achieve that.
> Have you ensured that the Internet Explorer content sniffer is disabled?
This really is only relevant if your site is hosting untrusted content.
> Are you using fail2ban to throttle ssh login attempts?
> Have you disabled password-based login over ssh, and only allowed key-based login?
The first really is of debatable value if the second is also used.
> Do forms set a cross-site request forgery cookie?
Cookies are not the only way to do this. More common, in my experience, is including the csrf token in the dom (either in a form field as a "hidden" input or as a meta tag)
> Do you have an account recovery flow? Delete it immediately.
Lol.
It's a great checklist for someone who knows what every item on the list is and more importantly, _why_ it is on the list - but it is not something that should be blindly followed.
Yes, I agree that an expandable "explanation and subtleties" section would be wise, but I'm very glad this exists even without.
I thought designing for security meant both removing privileges and preventing escalation of privileges? I might think my site doesn't host untrusted content, but I might turn out to be wrong about that.
It's worth thinking about what checklists are traditionally used for:
Checklists are a form of risk mitigation that comes out of the disaster investigation world (the FAA is the checklist OG in my mind). The idea is not to create a document that handles every possible situation and every possible corner case, preventing the need for human thought or expertise. The idea is to build up, over a period of time, lists of crucial things which
a) have some chance of getting forgotten and
b) can't be constrained through design
and put them in lists small enough to tick through regularly. It's a way of catching brain farts before they kill someone, not an attempt to replace proper engineering.
>> Have you disabled password-based login over ssh, and only allowed key-based login?
> The first really is of debatable value if the second is also used.
Actually, no. It makes perfect to block repeat offenders because they might get lucky; they might be exploiting an RCE you're not aware of that takes multiple steps; and they could be trying to DoS that server by filling the logs and thus your disk (and with most people using default 10GB disks on their VMs these days, this isn't too hard to imagine.)
Besides, the right answer is: use bastion hosts to proxy SSH connections, preventing them from the outside world, and also port knocking :-)
Agreed
> It makes perfect to block repeat offenders because they might get lucky
No, just no, please don't spread this nonsense. There is no such thing as "lucky" when the probably being discussed is 1 in (2^4096 - 1).
> they might be exploiting an RCE you're not aware of that takes multiple steps
I'll take my chances. If unauthed RCE exists in SSH (regardless of number of attempts required) there are far more serious implications than any server I manage. Additionally, I'm curious if you have an existing CVE where this kind of exploit has ever been discovered.
> they could be trying to DoS that server by filling the logs and thus your disk ... this isn't too hard to imagine
Hard to imagine? No. have I ever actually seen in the real world? Also no. Even if one server happened to be dos'ed by this, not a big concern, that's why you run multiple redundant servers behind a load balancer. The only viable attacks would be random in nature since attackers have no idea what the IPs of your actual app servers are. (And if someone can mount an attack that can determine them, you probably have bigger problems then a dos attack from ssh logs)
All in all, I feel like this just strengthens my original point, of viewing security as a checklist is a dangerous approach, one needs to actually understand what they are doing.
I'm all for layered security, but the problem with using it just because "why not" is that this methodology leads to an environment where there is so much "stuff" nobody knows what is secure, what is not secure, and what strange dependencies were the only reason something was secure in the first place. As far as security goes, everything should have a well-defined purpose.
> Do forms set a cross-site request forgery cookie?
Some legitimate forms of CSRF mitigation do utilize a cookie, but the checklist is dangerously misleading as worded. An anti-CSRF token in a cookie will do absolutely nothing on its own - it needs to either be in a header or the DOM, as you mentioned.
Any forged request an attacker compels a victim to send will include all cookies, not just the session cookie, rendering this protection useless.
>Are password entropy checks done during user sign-up, using, say AUTH_PASSWORD_VALIDATORS?
No. It's my information to be stolen, not yours. So then it is my choice, whether to use 123 as password or not. Why should I care to manage the complex password, when I use your service eg. twice an year and have no important information there? (if you really believe that people are eager to fill website with their authentic personal info unless they do not have other options, you are probably fooling yourself).
The better alternative is just no registration at all :)
>Are failed login attempts throttled and IP addresses banned after a number of unsuccessful attempts
So, you hadn't listened the previous piece of advice and forced me to create password that would've passed through the password checker. Six months passed and now I have to remember (I really don't want to bother with managing and storing password to your service anyway) it. As you could imagine, it takes several tries, dozen or two, maybe even three - depending on that cool password validator of yours. Do you say, that I need to use tor or have some pool of spare IP adresses just to login to your service?
>Are all form fields (with the exception of password fields) validated with a restrictive regex?
Aha, start with an email and surname, polish with an address;) Then your service will make it straight to the oblivion even faster!
>Do you have an account recovery flow? Delete it immediately.
Quite appropriate actually: when all tor exit nodes are banned by your login attempt throttler, that retards with severe memory impairment (whom you sometimes by mistake call "clients" in your marketing bullshit) still must not have a glimpse of a chance to use their account!
And when the site gets broken into years later, irresponsible users (or "morons" as you put it) will pillory them publicly even though it's their own damn fault for using a crappy password or using the same password for their email.
The number of people who will stop using a site because they can't meet basic password strength requirements is minimal and not worth caring about.
Me?! God is my witness, I do not. Rather, it is creators of that "checklist", who suggest that your users are idiots, who should be punished even for being unable to remember their password. IMHO, the really bad thing about the list is the fact that technically legit (I am not a webdev though) points are casually mixed with statements implying derogatory stance towards target users. I do not want you to control the ways I manage my information, that's the point of my rant.
After all, it is not a big deal if some crappy SV startups whose ultimate fate is to die silently after an year or two anyways, will adopt the practice. Problem arises when thing would go in the wild, bringing only headache and distraction to those who is able to control their information flow.
Many computer logins protect information other than the password-bearer's- for example, any business or government. As a result it's best to consider it, then discard as your use case may require.
I absolutely agree on the account recovery point - it WILL happen, your choice as designer is just whether it happens within a designed process or without.
That is my problem, as the user, not yours. If you'd like to help, then just put some warning or notification on the form, and I'll appreciate that. Just don't prohibit registration if password of my choice is eg. '1'.
Most of the time, your bussiness - is your service, not the access to it.
That's confusing. Are you saying 3 dozen login attempts for an existing account shouldn't trigger a lock out?
That seems unusual. ;)
Please, whatever you do, do not try to regex validate people's names. A friend couldn't complete an order on a site the other day because it was rejecting his name as "invalid" per its shitty regex.
See also Falsehoods Programmers Believe About Names[1]
[1] http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-b...
Or email addresses, without knowing all the legal characters. (An annoying percentage reject '+', which is a great Gmail tool for spotting how your email address "leaks out".)
see rfc 7085 "Top-Level Domains That Are Already Dotless"
https://webcache.googleusercontent.com/search?q=cache:rySaMA...
* You're right now fine with 2048 bit keys. The thing that jeopardizes 2048 bit keys might end up knocking RSA out entirely.
* There's really no point to fail2ban if you disabled passwords for SSH, and doing that is much more important than fail2ban.
* The checklist item for password security should make it clear that you need a password hash (PBKDF2, bcrypt scrypt, Argon2), not just a "hash".
Given the context, the only big thing that's missing is HPKP.
You probably need to support TLS 1.1 for some older clients
Password entropy checks should only be used in a corporate environment. You'll lose customers in a retail environment. You should certainly encourage your customers to use high entropy passwords, but forcing them to will just lose you money.
Login throttling and IP banning is a waste of time. Login throttling will just DoS yourself. You need CAPTCHA or Proof of Work.
Synchronizing Token (CSRF token in hidden form fields) is better than CSRF cookies
Use a real HTML parser (*Soup) to invalidate XSS form input not regex
For anyone curious about how much slower try "openssl speed rsa2048 rsa4096" for a quick benchmark. The results are ugly.
Plus user agents that aren't browsers
`always` has no meaning, and probably indicates a typo in an nginx configuration.
As others have pointed out, there is other TLS advice here that you shouldn't follow blindly, like a 4096-bit cert (especially if your intermediate is smaller) or TLS 1.2 only. Rationales and trade-off explanations would help avoid misuse of this checklist.
The SSL Labs checker is probably the best tool to use for all the automatable TLS checks.
Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"
That said, when I test an Apache site I've set up using that same directive I don't get the "always" so I'm not sure where it's coming from (in the example).
> Strict-Transport-Security: max-age=63072000; includeSubdomains; always
I agree. All sites should be using HTTPS only and HSTS is a great thing, but if you blindly follow this guide you might break your subdomains that don't support HTTPS (third party or whatever crazy situation you have). The same thing goes for HPKP which tptacek suggested below.
There's a right way and a very wrong way to use HPKP and if you go mucking with these headers without fully understanding them yourself you might break your site for a ton of people.
I had a difficult time getting it to work without throwing errors for either Nginx or SSL Labs tests and it was down to good old single vs. double-quotes. Copy-pasting the output from a policy generator is not at all guaranteed to work well.
Here's a template you can use, substituting EXAMPLE for your certificate hashes (and optionally the report URI). Tested and working on Nginx and multiple third-party validators:
add_header Public-Key-Pins 'pin-sha256="EXAMPLE"; pin-sha256="EXAMPLE"; max-age=86400; report-uri=" https://report-uri.io/report/EXAMPLE"';
> Do you have an account recovery flow? Delete it immediately.
Which is, of course, not practical in most situations.
I haven't seen anyone do this, but as a user, I would prefer an option for my account information to be emailed to me in a relatively readable format, so that I can keep my data / re-upload it if I ever want to undelete my account.
https://www.ssllabs.com/ssltest/
But I don't see a way to automate a test for the integrity of (say) a password recovery flow or that one user cannot access another user's data.
What about users who need to, you know, recover their account?
In my applications, it was the customers who demanded that account recovery flows be removed, which I imagine is far from your own experience.
I will make a note about the intended customer group in the page . . .
Lol. Have fun doing this at scale for any consumer site.
Like everything else in security, having a password reset/account recovery flow is a trade-off between security and convenience. For the vast majority of websites, convenience wins.
