Ask HN: What is the most common security mistake you see?

I work in government. Hard-coded passwords, sharing production passwords by email, etc., is the norm.

In my organization, forcing users to change passwords every x months. Everybody I know ends up picking simpler to remember passwords from a pool as a result.

infrastructure department says: "applications is responsible for security" application department says: "infrastructure is responsible for security" developer ask: "Can I help you?"

Default passwords.

Bad secret management (hardcoded in Git, shared secrets not changed after an employee left ...)

Dev and live not properly separated/dev not properly secured.

Services exposed to the internet that shouldn't be.

Old and forgotten software / appliances.

Don't forget about the dev/sysadmin workstations!

1. Secrets in source. This is by far the easiest one to "see".

2. In Ruby code, I see a surprising amount of `eval`; mostly `class_eval`

Lack of working backups. It's appalling how many people depend on systems with no backups.

Forget ransomware and other exotic attacks, what happens if after 7 years your hard drive decides to die on you?

I don't know. The backup is the first thing that needs to be setup and tested when you buy a computer. Windows and Mac have build-in systems for point-in-time backups and linux offers more than a few solutions.

Backup, backup and backup again :-)

Organizational firewalled "internal networks" that everyone connects to.

People opening untrusted web content and email attachments in Acrobat Reader and Office.

Reliance on antivirus products.

Most common mistake I see: sharing your passwords with multiple people. Even when the product lets you have more than one account.

Mistake websites make: only letting you have one user account.

The biggest security mistake I see is the History.

Talking about history of :

1. Slack channels ( lot's of private stuff / links go to #general )

2. VCS ( lot's of passwords / tokens are in the commit history )

3. JIRA ( lot's of private information / company secrets are there )

Usually only one of those three can cost the company a big lawsuit if some employee/freelancer is deliberately being hired to make damage.

Not realizing that the mind is supreme and the mind is fallible.

Critical functionality implemented in client code rather than the backend.

No infrastructure secret management or very bad infrastructure secret management:

* Private SSH/AWS API Keys in Github

* Shared Prod Passwords

Not applying updates to infrastructure regularly

Not keeping software and systems on a regular update schedule.

Willful ignorance.

its 2017 and yet still the biggest vulnerability of them all is willful ignorance.

People have agendas to fulfill. Can't let the truth get in the way. Haven't found a budget to fit in the truth looks like we will have to do without it for now.

What is the truth?

Well nobody cares about security.

Who knows about the truth?

Mostly everybody

Why doesn't anyone do anything about it?

Trying hard just doesn't cut it anymore as we can see those with influence would rather destroy the entire internet for mass surveillance.

Also don't forget about 2FA

Not training the employees:

I can provide email filtering, DNS filtering, firewalls and all sorts of technical solutions to security.

It all goes to pot if someone gets click-happy on weird websites or email attachments or falls for the "Your $Company_President need to transfer some funds" email.

Blind trust in open source package managers. Look at the damage the removal of left-pad from npm caused, for example, and imagine what could have happened if the author had malicious intent.

Obvious one but not using HTTPS would be up there.

Using bad programming languages, honestly. Most security problems boil down to type errors, but it's poor language choice that leads to making those.

This is a very old history, but iptables rules designed to not being permanent by default and reseting itself at reboot without notice was a big one.

Appending strings together for SQL queries (SQL injection just waiting to happen).

Passing in user info for a query, instead of using session or token encoded data (Impersonation just waiting to happen).

Bad passwords/keys, and bad management of those secrets.

No plan for backups, or not having a way to restore backups.

Most common? Simply not having a security mindset whatsoever day-to-day. If you build anything you should be thinking about security, even if all you're thinking is why security isn't an issue for some particular project. It's always important to understand where the boundaries are because they will change. I've seen countless examples of people playing fast and loose with security merely because they never thought about it or don't understand the issues. Even today, right this second there are people who are writing code that is vulnerable to sql injection, people writing web app software without sanitizing their inputs, people writing remote execution vulnerabilities, etc, etc. All because they just don't think about it and just don't care.

A lot of people have the mindset "oh, who would ever hack me? my app is just small potatoes". And this is how you end up with things like the mirai botnet.

Part of my day job is reviewing vulnerability reports for a load of software written mostly in C/C++.

Bugs leading to memory corruption vulnerabilities are the most common mistake I see. So things like, not doing proper bounds checks before accessing an array, using memory after it's been freed, not initializing memory properly before using it, type confusions causing values to be treated as pointers, etc.

Not understanding that fundamentally a whitelist is safer and better than a blacklist. I have gotten into many fights about this in my work about this because it always leads to a hole later when something new or unknown sticks its head out. If there are ten things it is supposed to be able to do make a list of ten things, don't just try to filter out what might not look like the ten things.

On a general level, no systematic accounting of assets.

Can you get me most or all of the following in an hour or so?

- List of people with production API credentials and which ones per person

- List of accounts with weak passwords or lacking 2FA

- Who has SSH access to each of your servers?

- All portal logins per employee

- Show me the last 3 production data sources this specific employee accessed

- Per data source, list people and services that can read/write

- Network diagrams and policies

A lot of organizations can't. It's boring bookkeeping, but systems have to be put in place to keep this information correct and up to date. Otherwise, there's nothing to manage or secure!