Ask HN: How do you handle security for your website(s)?
- Transparency is a dependency of trust; if it&#x27;s not transparent (e.g. open source), then it&#x27;s not trustworthy, full stop<p>- Read the latest NIST guidelines on software security; whether or not you trust the U.S. government (you shouldn&#x27;t), NIST still has very solid security advice, and a lot of the rest of the stuff in this list is derived from NIST guidelines<p>- Establish a mandatory security policy for your website&#x2F;organization<p>- Make regular backups, and store them on a separate server; test your backups regularly (e.g. by restoring them to a staging&#x2F;test server identical to production)<p>- Stream log entries (or routinely back up log files) to a separate server<p>- Don&#x27;t use Windows<p>- Don&#x27;t use (non-LTS) Ubuntu, Fedora, Arch, or any other Linux distro which prioritizes the &quot;latest-and-greatest&quot; features over stability; prefer more stable distros like (open)SUSE, RHEL&#x2F;CentOS, Debian, or an LTS release of Ubuntu (though I&#x27;d personally wait a year or so after an LTS Ubuntu release or an openSUSE release to give Canonical&#x2F;SUSE (respectively) time to shake out the inevitable bugs)<p>- Never install software unless it&#x27;s absolutely necessary<p>- Never install software from untrusted sources<p>- Never allow the use of passwords for SSH logins; <i>always</i> use key-based authentication (or disable SSH entirely)<p>- Never try to roll your own authentication unless you really know what you&#x27;re doing (or you <i>really</i> want to learn what it takes and have no interest in using it in production) and it&#x27;s absolutely necessary; 99 times out of 100, there&#x27;s a library for your language that already does it with a much more comprehensive threat model than the one you&#x27;re envisioning (and in the remaining 1 in 100 cases, there are at least plenty of smaller libraries that handle individual components of an authentication system)<p>- If you do roll your own authentication, at least try to use something like OAuth via an existing identity provider so that you don&#x27;t have to store credentials (and that so that you can lean on that provider&#x27;s expertise)<p>- If you do roll your own authentication <i>and</i> your own credential storage, make sure all passwords are hashed (SHA2 at minimum) with per-password-unique salts<p>- If you do roll your own authentication, play it safe and force the use of HTTPS site-wide<p>- If you do roll your own authentication <i>and</i> your own credential storage, try to provide some kind of multi-factor authentication, preferably one compatible with Google Authenticator; no, security questions don&#x27;t count<p>- If you do roll your own authentication <i>and</i> your own credential storage, allow and encourage users to use long passphrases<p>- If you do roll your own authentication <i>and</i> your own credential storage, don&#x27;t force users to reset their passwords every $NUM days; only force a reset if there&#x27;s reason to believe that the user&#x27;s account is compromised<p>- If you do roll your own authentication <i>and</i> your own credential storage, don&#x27;t require users to include certain character classes in their passwords<p>- Have it in writing that nobody working on behalf of your website will ever ask users for their passwords<p>- You can&#x27;t have a data breach if you don&#x27;t have any data; only store sensitive user data if you absolutely know for sure that you need it (hint: if it&#x27;s for &quot;analytics&quot; or ads, then you don&#x27;t need it)<p>- If you do need to store sensitive data, ensure that it is encrypted (most full-featured SQL databases support encryption at various levels of granularity; for NoSQL databases or non-full-featured SQL databases, you&#x27;ll want to make sure data is only sent to the database in an encrypted state)<p>- If you do need to store sensitive data, play it safe and force the use of HTTPS site-wide<p>- Hell, might as well just force HTTPS no matter what; it ain&#x27;t like TLS certs are expensive (thank you, Let&#x27;s Encrypt!)<p>- Routinely audit things like GitHub&#x2F;Bitbucket&#x2F;GitLab&#x2F;$SOURCE_CODE_HOSTING_SITE repositories, Slack channels, AWS&#x2F;Heroku&#x2F;$APPLICATION_HOSTING_PROVIDER accounts, etc. to ensure that only the people who should have access do have access<p>- Make sure all persons involved in developing and maintaining the site use long passphrases and multi-factor authentication wherever possible (most source code hosting sites and cloud providers offer 2FA, and quite a few - like AWS - can even enforce it on all your organization&#x27;s accounts)