Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Security Checklist

securitychecklist.org

Post reply on HN
Print view View original

11–20 of 65 posts

Re: Security Checklist

#11

Post by beefhash »

tptacek wrote: post #4

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 con…

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?

Re: Security Checklist

#12

Post by ams6110 »

tptacek wrote: post #4

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 con…

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.

Re: Security Checklist

#13

Post by ajkjk »

nmjohn wrote: post #5

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 emb…

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.

Re: Security Checklist

#14

Post by tptacek »

beefhash wrote: post #11
tptacek wrote: post #4

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 con…

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.

Re: Security Checklist

#15

Post by beejiu »

msbarnett wrote: post #6

> 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-b...

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.

Re: Security Checklist

#16

Post by elchief »

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

Re: Security Checklist

#18

Post by ejcx »

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.

Re: Security Checklist

#20

Post by erikpukinskis »

nmjohn wrote: post #5

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 emb…

> 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.

Post reply on HN