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

Web Developer Security Checklist

simplesecurity.sensedeep.com

Post reply on HN
Print view View original

101–110 of 249 posts

Re: Web Developer Security Checklist

#101

Post by user15672 »

sho wrote: post #14

While it means well, I think some of this advice is pretty bad, or at least unbalanced. From the very first section: > Encrypt all data at rest in the database ALL data? How are you supposed to query against it then? What does "at rest" even mean in the context of an always-on database? An encrypted partition or something? I'm not even sure what this is supposed to mean and it is certainly not common practise. > Use…

Some this advice seems to come out of a cargo cult development handbook. That may sound a little harsh, but it's better to have a tendancy to take any article that states "Always do X" or "Never do Y" with a handful of salt.

If you don't know enough about your own systems requirements, lists like this are going to have you doing work that you don't understand, doesn't need doing (or worse, is detrimental) and if you do, you probably don't need to be using checklists like this to do your job.

Re: Web Developer Security Checklist

#102

Post by pjmorris »

"Finally, have a plan"

I'd argue that you're more secure and your life is easier if the plan (threat model), or at least the planning, come first. The greater your understanding of your data, users, platform, and attackers, the more likely you are to make good (e.g. secure, economical) choices about infrastructure, design, implementation, testing, incident response, etc.

"Plans are nothing; planning is everything." - Dwight D. Eisenhower

Re: Web Developer Security Checklist

#103

Post by valar_m »

slackingoff2017 wrote: post #76

Come on man, 4 submissions in 5 days all leading to your startup's website? And a profile created 5 days ago with zero comments on anything you didn't post? You could at least try to make it look like you're doing more than promoting your startup.

OP's submissions appear to comply with all of the site guidelines. What does it matter if they also happen to send traffic to his startup?

Re: Web Developer Security Checklist

#104

Post by atemerev »

sho wrote: post #14

While it means well, I think some of this advice is pretty bad, or at least unbalanced. From the very first section: > Encrypt all data at rest in the database ALL data? How are you supposed to query against it then? What does "at rest" even mean in the context of an always-on database? An encrypted partition or something? I'm not even sure what this is supposed to mean and it is certainly not common practise. > Use…

I think, the author is right, and you might be not.

"Data at rest" means the data that you have no intention of querying soon. Which implies "hot" / "cold" data partitioning, which is usually a good idea. Can be complicated, but commonly encountered in financial backends.

Two layers of encryption can be better than one (if logically and temporarily separated). Encryption algorithms are usually not a problem; credentials compromise or out-of-band vulnerabilities CAN be a problem.

Finally, ANY type of input sanitization is wrong way to do security, and should be employed only as an absolute last resort. Prepared statements provide strong semantic separation guarantees, and you can use ';drop table users; _safely_ as your query parameters. Otherwise you'll be stuck between the requirements corner cases (do you know that legal names can include quotes and apostrophes?) and security requirements, and it is the war that is impossible to win.

Re: Web Developer Security Checklist

#105

Post by pgsandstrom »

aeronautic wrote: post #100
rubidium wrote: post #99

Earlier quoted context omitted.

"A very old password (say 1 year) has a higher chance of being subverted purely because there is more elapsed time wherein attackers could have gained access." Any actual evidence for this? My counter-hypothesis is if your password lasts 6 months of attempted hacks it'll last >6 years (unless social engineering attempts succeed). I ask because rotating goes against the current NIST password guidance. In fact, for you…

Sorry, I should be clearer (late here). With time passing, the chance of you or anyone with access to the password being socially engineered, or some other human error, or a hack on your PC desktop systems, increases linearly with time. The password may last a decade of brute force cracking, but we humans .... continue to make mistakes far more frequently. So rotating passwords protects against the accumulation of hu…

Rotating passwords will only help in a very specific situation: When the password has been leaked, but you have not yet been hacked.

If someone has already gained access to the system, changing passwords are not sufficient.

If no one has gained access to the system, rotating passwords does not protect you against social engineering.

Re: Web Developer Security Checklist

#106

Post by mirimir »

pjungwir wrote: post #51
sho wrote: post #14

While it means well, I think some of this advice is pretty bad, or at least unbalanced. From the very first section: > Encrypt all data at rest in the database ALL data? How are you supposed to query against it then? What does "at rest" even mean in the context of an always-on database? An encrypted partition or something? I'm not even sure what this is supposed to mean and it is certainly not common practise. > Use…

Totally agree about the encryption. I've set up databases to run on encrypted disks (LUKS or nowadays on AWS you can get encrypted EBS), but I feel like that is really just to tick the "encrypted at rest" compliance checkbox, because if the machine is turned on, anyone can read the data (subject to normal file permissions of course). As far as I can tell the only threat this is protecting against is someone physicall…

Maybe it's useful to mention security procedures for VPN privacy services. You accept credit/debit card payments, and need to retain records for dealing with fraud, satisfy VAT requirements, etc. Your exit servers need to check account status, check for existing connections to limit concurrency, and so on. But in case adversaries have your exit servers seized, you want them to be clean. So you run them read-only, with no persistent storage, and you do authentication etc with remote servers, using hashed account names and passwords.

Countermail, for example, does the same for its email servers. For Tor relays, there's tor-ramdisk.[0]

0) https://lists.torproject.org/pipermail/tor-talk/2017-Februar...

Re: Web Developer Security Checklist

#107

Post by aeronautic »

pgsandstrom wrote: post #105
aeronautic wrote: post #100

Earlier quoted context omitted.

Sorry, I should be clearer (late here). With time passing, the chance of you or anyone with access to the password being socially engineered, or some other human error, or a hack on your PC desktop systems, increases linearly with time. The password may last a decade of brute force cracking, but we humans .... continue to make mistakes far more frequently. So rotating passwords protects against the accumulation of hu…

Rotating passwords will only help in a very specific situation: When the password has been leaked, but you have not yet been hacked. If someone has already gained access to the system, changing passwords are not sufficient. If no one has gained access to the system, rotating passwords does not protect you against social engineering.

Nicely said.

The one mod I'd suggest is:

If someone has gained access to the passwords and has not used the password yet or was not interesting in directly using the password themselves, but rather, they on sold it. There is a window of opportunity that rotation helps.

For example: you may be on one of the password lists being sold in the dark web. The owner of the list isn't hacking you, but those purchasing the list will some time soon.

So more specifically, you could be compromised by malware on a PC holding the password and that password may be extracted, sold and may not be used against you for months. Rotation helps in this case which is more common than we care to admit.

Re: Web Developer Security Checklist

#108

Post by user15672 »

atemerev wrote: post #104
sho wrote: post #14

While it means well, I think some of this advice is pretty bad, or at least unbalanced. From the very first section: > Encrypt all data at rest in the database ALL data? How are you supposed to query against it then? What does "at rest" even mean in the context of an always-on database? An encrypted partition or something? I'm not even sure what this is supposed to mean and it is certainly not common practise. > Use…

I think, the author is right, and you might be not. "Data at rest" means the data that you have no intention of querying soon. Which implies "hot" / "cold" data partitioning, which is usually a good idea. Can be complicated, but commonly encountered in financial backends. Two layers of encryption can be better than one (if logically and temporarily separated). Encryption algorithms are usually not a problem; credenti…

> Finally, ANY type of input sanitization is wrong way to do security, and should be employed only as an absolute last resort.

Ok, that's just plain wrong and absolutely wreckless advice. Everything from software development 101 classes to OWASP data validation can call you on that. If you don't understand why you're wrong, please, please, please stop developing software now until you can understand it.

Re: Web Developer Security Checklist

#109

Post by brlewis »

pjungwir wrote: post #51
sho wrote: post #14

While it means well, I think some of this advice is pretty bad, or at least unbalanced. From the very first section: > Encrypt all data at rest in the database ALL data? How are you supposed to query against it then? What does "at rest" even mean in the context of an always-on database? An encrypted partition or something? I'm not even sure what this is supposed to mean and it is certainly not common practise. > Use…

Totally agree about the encryption. I've set up databases to run on encrypted disks (LUKS or nowadays on AWS you can get encrypted EBS), but I feel like that is really just to tick the "encrypted at rest" compliance checkbox, because if the machine is turned on, anyone can read the data (subject to normal file permissions of course). As far as I can tell the only threat this is protecting against is someone physicall…

As far as I can tell the only threat this is protecting against is someone physically pulling the drive and walking off with it.

Are you saying that that threat isn't worth protecting against?

Re: Web Developer Security Checklist

#110

Post by nkozyra »

brlewis wrote: post #109
pjungwir wrote: post #51

Earlier quoted context omitted.

Totally agree about the encryption. I've set up databases to run on encrypted disks (LUKS or nowadays on AWS you can get encrypted EBS), but I feel like that is really just to tick the "encrypted at rest" compliance checkbox, because if the machine is turned on, anyone can read the data (subject to normal file permissions of course). As far as I can tell the only threat this is protecting against is someone physicall…

As far as I can tell the only threat this is protecting against is someone physically pulling the drive and walking off with it. Are you saying that that threat isn't worth protecting against?

Every potential threat should be considered, but weighed against likelihood when prioritizing.

Sometimes you make cost/benefit consolations. 100% airtight would be great, but 100% airtight doesn't actually exist. Most organizations with finite resources have to make risk/reward decisions when there are as many threats as there are with web development.

Post reply on HN