16 ms·

Security Checklist

149 points by nthompson 11y ago

r3bl 11y ago
This seems great! Now, all that is needed is someone who will automate this list across X most popular websites.
foobarbecue 11y ago
It'd be nice if this was an actual checklist. i.e. checkboxes rather than images of a checkmark so that you could run through it.
- gerry_shaw 11y ago
  I thought so too. I also thought it so too so I created this: https://github.com/gshaw/security-checklist https://github.com/gshaw/security-checklist
  - nthompson 11y ago
    Damn dude. This looks way nicer than my page (and has links to hipper tools) . . . I need to take a course in web design . . .
tptacek 11y ago
Quibbles: * 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.
- beefhash 11y ago
  Wouldn't it be wise to wait for argon2 to get some more cryptanalysis and testing in the field before jumping on it, sticking to scrypt or bcrypt in the meantime?
  - tptacek 11y ago
    No. The reason not to use Argon2 is that it doesn't have great library support yet. Password hashes don't really fail like ciphers do. Nothing that is discovered in Argon2 is going to make it worse than PBKDF2, and using PBKDF2 is just fine if that's all you've got.
    - dsacco 11y ago
      >> and using PBKDF2 is just fine if that's all you've got. Yeah, people spend way too much time wondering if they should use scrypt, bcrypt, PBKDF2, etc. There are legitimate differences, but unless you know those ahead of time it's almost certainly better to just choose one instead of waffling around.
    - technion 11y ago
      The reference library we do have looks set to make further breaking changes[0], which complicates this further. [0] https://github.com/P-H-C/phc-winner-argon2/pull/119/files https://github.com/P-H-C/phc-winner-argon2/pull/119/files
    - devit 11y ago
      Huh? A password hash could happen to be reversible, or could map lots of passwords to the same value.
      - tptacek 11y ago
        No, neither of those things are going to happen. It might happen if you designed a password hash from first principles, but that is not how Argon2 was designed, or, really, any of the Password Hashing Contest finalists. They're built on top of existing crypto primitives.
- ams6110 11y ago
  Agree on fail2ban w.r.t ssh, though it can still be useful in other scenarios e.g. blocking brute-force attacks on a website login page, or on an API.
- theandrewbailey 11y ago
  4096 bit keys are useless if your root or intermediate is 2048 bit. How many CAs even offer 4096 roots and intermediates? Do CAs even bother to ask, or do they give you 2048 anyway, because FU?
nmjohn 11y ago
There's a problem with viewing security as a "checklist" problem, it treats everything as binary, black or white problem/solutions. In reality, this is _far_ from the case. For example: > 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.
- ajkjk 11y ago
  And yet this is so much more useful than the hundreds of pages of blog posts and security advisories that have to be individually a) found and b) understood in order to do security correctly on even a simple website. Yes, I agree that an expandable "explanation and subtleties" section would be wise, but I'm very glad this exists even without.
- erikpukinskis 11y ago
  > This really is only relevant if your site is hosting untrusted content. 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.
msbarnett 11y ago
> Are all form fields (with the exception of password fields) validated with a restrictive regex? 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-believe-about-names/ http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-b...
- beejiu 11y ago
  In addition, a poorly written Regex can open you up to a Regular Expression DOS attack. If anything, it should be on the security checklist as something not to do.
- __john 11y ago
  A friend and I made this for fun. It is a joke and only here for entertainment value, don't put it in production. https://github.com/JonZudell/Genetic_Expression https://github.com/JonZudell/Genetic_Expression
- DrScump 11y ago
  <do not try to regex validate people's names> 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".)
  - NickNameNick 11y ago
    And a huge number don't suport email addresses with 'bare' tld's. see rfc 7085 "Top-Level Domains That Are Already Dotless" https://webcache.googleusercontent.com/search?q=cache:rySaMANuZuIJ:https://tools.ietf.org/html/rfc7085+&cd=2&hl=en&ct=clnk&gl=us https://webcache.googleusercontent.com/search?q=cache:rySaMA...
    - breakingcups 11y ago
      I thought those weren't allowed / encouraged by either ICANN nor IAB? They have a real-world possibility of colliding with internal hostnames.
Taig 11y ago
What is the meaning of the last point? > Do you have an account recovery flow? Delete it immediately.
- tyingq 11y ago
  They seem to be saying you should have no online process to deal with lost passwords, forgotten userids, etc. Which is, of course, not practical in most situations.
  - andreyf 11y ago
    I thought this at first, too, but giving the author the benefit of the doubt, perhaps they meant that if someone deletes their account, you should actually delete their account, not just disable it. 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.
    - tyingq 11y ago
      Sounds like a great idea, but I wouldn't word that as "Do you have an account recovery flow? Delete it immediately." Account recovery is shorthand for forgotton passwords and userids everywhere I look.
      - andreyf 11y ago
        might be a stretch but https://en.wikipedia.org/wiki/Principle_of_charity https://en.wikipedia.org/wiki/Principle_of_charity
Laaw 11y ago
Is the problem with account recovery the fact that it means "deleted" isn't actually deleted?
garrettr_ 11y ago
> Do you have an account recovery flow? Delete it immediately. What about users who need to, you know, recover their account?
- nthompson 11y ago
  This checklist was designed for corporate-to-corporate and corporate-to-military sites which host data deemed valuable. If you are designing consumer websites where the user data is not particularly sensitive, then this advice is not appropriate. 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 . . .
elchief 11y ago
4096 bit RSA key is overkill and slow. 2048 is fine for years 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
- tombrossman 11y ago
  I see a surprising number of tutorials on blogs recommending 4096bit keys and I do wonder if people know just how much extra load that is. A properly set up HTTPS site with 2048bit certs will be pretty fast - about the same as HTTP and your time will be better spent optimizing other things like images. For anyone curious about how much slower try "openssl speed rsa2048 rsa4096" for a quick benchmark. The results are ugly.
- theandrewbailey 11y ago
  I might be missing something, but I've never come across software having TLS 1.1 support without TLS 1.2.
  - elchief 11y ago
    https://en.wikipedia.org/wiki/Template:TLS/SSL_support_history_of_web_browsers https://en.wikipedia.org/wiki/Template:TLS/SSL_support_histo... Plus user agents that aren't browsers
deleted 11y ago
[deleted]
ejcx 11y ago
By the way. If you aren't well versed in web application security, don't just blindly follow guides likes this, especially when dealing with headers. You really should learn about the technologies > 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.
- ams6110 11y ago
  Can you recommend a good reference for properly setting up HPKP?
  - tombrossman 11y ago
    This is a good guide: https://scotthelme.co.uk/hpkp-http-public-key-pinning/ https://scotthelme.co.uk/hpkp-http-public-key-pinning/ 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"'; https://report-uri.io/report/EXAMPLE"';
lolidaisuki 11y ago
Web server security is pretty narrow portion of all security fields.
deleted 11y ago
[deleted]
lgarron 11y ago
I don't see e.g. a GitHub repo to comment on, but the HSTS header example is `Strict-Transport-Security: max-age=63072000; includeSubdomains; always` `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.
- tombrossman 11y ago
  I think the "always" is from Apache, and if I'm reading the site correctly it is an example of a header value being returned. An example Apache directive from https://cipherli.st/ https://cipherli.st/ would be: 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).
- nthompson 11y ago
  The 'always' was a typo, thanks for the catch.
xpinguin 11y ago
I could call that list deliberately malicious from user experience standpoint: >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!
- Karunamon 11y ago
  >No. It's my information to be stolen, not yours. 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.
  - xpinguin 11y ago
    >irresponsible users (or "morons" as you put it) 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.
tacone 11y ago
It would be nice for this to become a github repo with all the bash scripts in the page.
tptacek 11y ago
The "account recovery flow" thing is, for everyone asking, presumably an in-joke about how every application pentested for the first time ends up having some gameover flaw in its password reset.
koolba 11y ago
> Do you have an account recovery flow? Delete it immediately. 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.
- bweston92 11y ago
  When I saw that all I thought was how else might a user recover their account?
mrmondo 11y ago
Good start indeed, it'd be nice to have a small open source tool to do these checks, maybe even with a simple web interface - anyone seen a simple security checklist / analyser that's well maintained with the latest standards?
- nthompson 11y ago
  SSL labs is the gold standard: https://www.ssllabs.com/ssltest/ 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.
  - mrmondo 11y ago
    Yeah that's what I use at present, if it's not an A+ it's not OK. Would be nice to have an open source version of this that could perform additional checks though.
cdevs 11y ago
I know the majority decision is keys over passwords but every time I hear a security issue its over keys being stolen as typical malicious programs knows the standard go to place to grab them after getting you to sudo something evil. and the next response is you have time to change them before blah blah blah but attackers don't send you a email that says hey I have your keys! Wouldn't fail2ban with passwords be better for those who don't know how to manage every step of this ?

149 points by nthompson 11y ago

r3bl 11y ago

This seems great! Now, all that is needed is someone who will automate this list across X most popular websites.

It'd be nice if this was an actual checklist. i.e. checkboxes rather than images of a checkmark so that you could run through it.

gerry_shaw 11y ago
I thought so too. I also thought it so too so I created this: https://github.com/gshaw/security-checklist https://github.com/gshaw/security-checklist
- nthompson 11y ago
  Damn dude. This looks way nicer than my page (and has links to hipper tools) . . . I need to take a course in web design . . .

tptacek 11y ago

Quibbles: * 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.

beefhash 11y ago
Wouldn't it be wise to wait for argon2 to get some more cryptanalysis and testing in the field before jumping on it, sticking to scrypt or bcrypt in the meantime?
- tptacek 11y ago
  No. The reason not to use Argon2 is that it doesn't have great library support yet. Password hashes don't really fail like ciphers do. Nothing that is discovered in Argon2 is going to make it worse than PBKDF2, and using PBKDF2 is just fine if that's all you've got.
  - dsacco 11y ago
    >> and using PBKDF2 is just fine if that's all you've got. Yeah, people spend way too much time wondering if they should use scrypt, bcrypt, PBKDF2, etc. There are legitimate differences, but unless you know those ahead of time it's almost certainly better to just choose one instead of waffling around.
  - technion 11y ago
    The reference library we do have looks set to make further breaking changes[0], which complicates this further. [0] https://github.com/P-H-C/phc-winner-argon2/pull/119/files https://github.com/P-H-C/phc-winner-argon2/pull/119/files
  - devit 11y ago
    Huh? A password hash could happen to be reversible, or could map lots of passwords to the same value.
    - tptacek 11y ago
      No, neither of those things are going to happen. It might happen if you designed a password hash from first principles, but that is not how Argon2 was designed, or, really, any of the Password Hashing Contest finalists. They're built on top of existing crypto primitives.
ams6110 11y ago
Agree on fail2ban w.r.t ssh, though it can still be useful in other scenarios e.g. blocking brute-force attacks on a website login page, or on an API.
theandrewbailey 11y ago
4096 bit keys are useless if your root or intermediate is 2048 bit. How many CAs even offer 4096 roots and intermediates? Do CAs even bother to ask, or do they give you 2048 anyway, because FU?

nmjohn 11y ago

There's a problem with viewing security as a "checklist" problem, it treats everything as binary, black or white problem/solutions. In reality, this is _far_ from the case. For example: > 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.

ajkjk 11y ago
And yet this is so much more useful than the hundreds of pages of blog posts and security advisories that have to be individually a) found and b) understood in order to do security correctly on even a simple website. Yes, I agree that an expandable "explanation and subtleties" section would be wise, but I'm very glad this exists even without.
erikpukinskis 11y ago
> This really is only relevant if your site is hosting untrusted content. 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.

msbarnett 11y ago

> Are all form fields (with the exception of password fields) validated with a restrictive regex? 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-believe-about-names/ http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-b...

beejiu 11y ago
In addition, a poorly written Regex can open you up to a Regular Expression DOS attack. If anything, it should be on the security checklist as something not to do.
__john 11y ago
A friend and I made this for fun. It is a joke and only here for entertainment value, don't put it in production. https://github.com/JonZudell/Genetic_Expression https://github.com/JonZudell/Genetic_Expression
DrScump 11y ago
<do not try to regex validate people's names> 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".)
- NickNameNick 11y ago
  And a huge number don't suport email addresses with 'bare' tld's. see rfc 7085 "Top-Level Domains That Are Already Dotless" https://webcache.googleusercontent.com/search?q=cache:rySaMANuZuIJ:https://tools.ietf.org/html/rfc7085+&cd=2&hl=en&ct=clnk&gl=us https://webcache.googleusercontent.com/search?q=cache:rySaMA...
  - breakingcups 11y ago
    I thought those weren't allowed / encouraged by either ICANN nor IAB? They have a real-world possibility of colliding with internal hostnames.

Taig 11y ago

What is the meaning of the last point? > Do you have an account recovery flow? Delete it immediately.

tyingq 11y ago
They seem to be saying you should have no online process to deal with lost passwords, forgotten userids, etc. Which is, of course, not practical in most situations.
- andreyf 11y ago
  I thought this at first, too, but giving the author the benefit of the doubt, perhaps they meant that if someone deletes their account, you should actually delete their account, not just disable it. 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.
  - tyingq 11y ago
    Sounds like a great idea, but I wouldn't word that as "Do you have an account recovery flow? Delete it immediately." Account recovery is shorthand for forgotton passwords and userids everywhere I look.
    - andreyf 11y ago
      might be a stretch but https://en.wikipedia.org/wiki/Principle_of_charity https://en.wikipedia.org/wiki/Principle_of_charity

Laaw 11y ago

Is the problem with account recovery the fact that it means "deleted" isn't actually deleted?

garrettr_ 11y ago

> Do you have an account recovery flow? Delete it immediately. What about users who need to, you know, recover their account?

nthompson 11y ago
This checklist was designed for corporate-to-corporate and corporate-to-military sites which host data deemed valuable. If you are designing consumer websites where the user data is not particularly sensitive, then this advice is not appropriate. 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 . . .

elchief 11y ago

4096 bit RSA key is overkill and slow. 2048 is fine for years 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

tombrossman 11y ago
I see a surprising number of tutorials on blogs recommending 4096bit keys and I do wonder if people know just how much extra load that is. A properly set up HTTPS site with 2048bit certs will be pretty fast - about the same as HTTP and your time will be better spent optimizing other things like images. For anyone curious about how much slower try "openssl speed rsa2048 rsa4096" for a quick benchmark. The results are ugly.
theandrewbailey 11y ago
I might be missing something, but I've never come across software having TLS 1.1 support without TLS 1.2.
- elchief 11y ago
  https://en.wikipedia.org/wiki/Template:TLS/SSL_support_history_of_web_browsers https://en.wikipedia.org/wiki/Template:TLS/SSL_support_histo... Plus user agents that aren't browsers

deleted 11y ago

[deleted]

ejcx 11y ago

By the way. If you aren't well versed in web application security, don't just blindly follow guides likes this, especially when dealing with headers. You really should learn about the technologies > 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.

ams6110 11y ago
Can you recommend a good reference for properly setting up HPKP?
- tombrossman 11y ago
  This is a good guide: https://scotthelme.co.uk/hpkp-http-public-key-pinning/ https://scotthelme.co.uk/hpkp-http-public-key-pinning/ 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"'; https://report-uri.io/report/EXAMPLE"';

lolidaisuki 11y ago

Web server security is pretty narrow portion of all security fields.

deleted 11y ago

[deleted]

lgarron 11y ago

I don't see e.g. a GitHub repo to comment on, but the HSTS header example is `Strict-Transport-Security: max-age=63072000; includeSubdomains; always` `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.

tombrossman 11y ago
I think the "always" is from Apache, and if I'm reading the site correctly it is an example of a header value being returned. An example Apache directive from https://cipherli.st/ https://cipherli.st/ would be: 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).
nthompson 11y ago
The 'always' was a typo, thanks for the catch.

xpinguin 11y ago

I could call that list deliberately malicious from user experience standpoint: >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!

Karunamon 11y ago
>No. It's my information to be stolen, not yours. 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.
- xpinguin 11y ago
  >irresponsible users (or "morons" as you put it) 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.

tacone 11y ago

It would be nice for this to become a github repo with all the bash scripts in the page.

tptacek 11y ago

The "account recovery flow" thing is, for everyone asking, presumably an in-joke about how every application pentested for the first time ends up having some gameover flaw in its password reset.

koolba 11y ago

> Do you have an account recovery flow? Delete it immediately. 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.

bweston92 11y ago
When I saw that all I thought was how else might a user recover their account?

mrmondo 11y ago

Good start indeed, it'd be nice to have a small open source tool to do these checks, maybe even with a simple web interface - anyone seen a simple security checklist / analyser that's well maintained with the latest standards?

nthompson 11y ago
SSL labs is the gold standard: https://www.ssllabs.com/ssltest/ 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.
- mrmondo 11y ago
  Yeah that's what I use at present, if it's not an A+ it's not OK. Would be nice to have an open source version of this that could perform additional checks though.

cdevs 11y ago

I know the majority decision is keys over passwords but every time I hear a security issue its over keys being stolen as typical malicious programs knows the standard go to place to grab them after getting you to sudo something evil. and the next response is you have time to change them before blah blah blah but attackers don't send you a email that says hey I have your keys! Wouldn't fail2ban with passwords be better for those who don't know how to manage every step of this ?