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

31–40 of 65 posts

Re: Security Checklist

#31

Post by Karunamon »

xpinguin wrote: post #26

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…

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

Re: Security Checklist

#33

Post by brainfire »

xpinguin wrote: post #26

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…

> It's my information to be stolen, not yours.

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.

Re: Security Checklist

#34

Post by tombrossman »

ams6110 wrote: post #27
ejcx wrote: post #18

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…

Can you recommend a good reference for properly setting up HPKP?

This is a good guide: 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"';

Re: Security Checklist

#35

Post by tptacek »

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.

Re: Security Checklist

#36

Post by koolba »

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

Re: Security Checklist

#37

Post by mrmondo »

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?

Re: Security Checklist

#38

Post by newman314 »

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…

I've always said "security, just like disaster recovery, is a lifestyle, not a checklist".

Re: Security Checklist

#40

Post by movedx »

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…

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

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 :-)

Post reply on HN