https://www.inversoft.com/guides/2016-guide-to-user-data-sec...
It covers 10x what all the other guides cover in terms of server and application security. It was posted a few weeks ago on HN but didn't make the front-page.
If a 10 minute guide gets users 90% of the way, then they're more likely to do it. And that's good enough to cover a majority of automated attacks.
Update: I take it back – they've provided scripts to run this stuff. I will explore these. Thanks for the link.
https://github.com/inversoft/passport-js-example
It uses Ember, Node.js, Express, Sequelize, MySQL and Passport User Database (https://www.inversoft.com/products/user-database-sso).
EDIT: And now the HTML version has a TOC, too! Talk about immediate gratification -- kudos to whoever did that!
E.g. Apache 1, BIND, sendmail, cgi-bin, ifconfig, etc.
Compare this page http://www.tldp.org/HOWTO/Quota.html to this page https://wiki.archlinux.org/index.php/Disk_quota . TLDP organized HOWTOs like mini-books; tables of content, multiple authors, versioned releases, and of course, you could download them all and search through them by category. And they didn't assume things like the distribution setting up a bunch of the tools and system for you, so you learned how the tools actually worked.
I appreciate TLDP for what it is and the details they go to. But Arch wiki can easily be read as a FAQ for all modern systems. And it will usually send you to other places for details (sometimes TLDP as well)
https://www.digitalocean.com/community/tutorials/7-security-...
Github recommends 4096 now, for what it's worth. [1]
>Pushing database backups offsite
This is a really bad idea and a good way to get owned. Database backups must be PULLED from the server, not pushed from it. Separately, you also need to test that you can restore from your backups periodically.
There were a couple other things I disagree with, but they're in the realm of personal preference. It's also interesting that this guide uses Linode which is a hosting company known to have had quite egregious security issues in the past. [2]
[1] https://help.github.com/articles/generating-a-new-ssh-key-an...
One way to do this is with S3, for example, is to use an IAM role with only the "PutObject" permission, and enable object versioning for the bucket to prevent a compromised server from being able to delete data by overwriting existing files.
Maybe the extra layer doesn't add much security, but if it's a simple config change and it does add something, wouldn't it be worth doing?
You could make a similar point about the centralized backup management server - it needs to have "some kind of login" to all your production database server, so of that host is compromised (which might only store encrypted copies of your backup), so are all your database servers if those privileges can be escalated. You could argue that one backup host is easier to secure than a complex system such as AWS, but then I would argue that it would probably be hard to beat the track record of S3/IAM. ;-)
Both approaches have their place. If you're dealing with a large number of hosts and a lot of data, the backup host will quickly become a bottleneck and you're probably better off with the append-only approach. If that's not a concern for you (i.e. you're not running into any bandwidth limits on the backup hosts) and want to deal with operating yet another service to avoid the risk of e.g. IAM privilege escalation, the other solution might be a better fit.
Just make sure your database server doesn't have permission to delete backups (e.g. Have it POST a backup via HTTPS). There is nothing wrong with db server initiated backups.
Of course, this is an edge case, but I believe setting up a pull-based backup system is still going to be less work than a write-only push system.
Of course, your servers shouldn't be SSHing to your backup servers, but that goes both ways.
Plus, the Inversoft guide specifically states that backups must be encrypted. I could put my backup ZIPs on a public Github repository and no one would be able to access the user data stored inside it. Therefore, it really doesn't matted if they are pushed or pulled.
I remember seeing a "hacking" website get wiped along with all of its backups about 15 years ago and it left a very strong impression on me regarding this issue.
It is sometimes more secure to push because it requires no inbound connections or authorizations the live machine.
> Passwords should always be hashed using a strong, one-way hash algorithm. [...] hashed with an algorithm like SHA-256 7 times.
If they had simply written "just use bcrypt" they'd be much closer to 2016-era security practices.
Regardless, using a salted, multi-pass algorithm will keep everything nicely secured using nearly any hashing algorithm.
Remember the goal is not to crack one user's password using a brute force lookup table, it is to crack everyone's password.
And it is designed to prevent what your last sentence says.
https://github.com/FallibleInc/security-guide-for-developers... (work in progress)