[deleted]
Security Checklist
21–30 of 65 posts
Re: Security Checklist
#22What is the meaning of the last point? > Do you have an account recovery flow? Delete it immediately.
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.
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.
Re: Security Checklist
#23I 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.
Re: Security Checklist
#24There'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 emb…
Good comment. To expand on this in particular, as I haven't seen anyone else mention it:
> 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.
Re: Security Checklist
#25Earlier quoted context omitted.
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?
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.
>> 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.
Re: Security Checklist
#26I 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!
Re: Security Checklist
#27By 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…
Can you recommend a good reference for properly setting up HPKP?
Re: Security Checklist
#28Earlier quoted context omitted.
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.
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 m…
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.
Re: Security Checklist
#294096 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. Logi…
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.
Re: Security Checklist
#30I 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…
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/ 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).