Codepath

Never trust users

Security is largely about validating trust. Who can we trust? Who are those out to do us harm? How can we identify those people either online or in person? What information can we trust?

Be paranoid. Most users are not out to get you, but a few are, and it is difficult to tell the difference.

A large portion of security problems stem from the simple fact that determining identity with certainty on the internet is tricky. What identifies a user? Their IP address? Their username and password? The cookies saved in their browser? Having access to a particular email account (especially for resetting passwords)? Having particular knowledge such as mother’s maiden name or social security number? Having an employee badge?


Who not to trust

  • Hackers
  • Stolen laptops
  • Stolen passwords
  • Former employees
  • Unhappy employees
  • Contractors

Happy co-workers today can become unhappy or former employees tomorrow. We should not assume that any user is above making accidental mistakes, having lapses of good judgement, or changing their attitudes. "Desperate people do desperate things." It is impossible to predict how someone will act in the future.

Contractors are a particular security concern. They need access to systems and data but yet they are not employees. They are often not as fully-vetted as regular employees or are transient. It is important to make it easy to monitor their usage and expire their access.

You might think that you can trust yourself at the very least. Surely a system you build should trust you. But...

  • What if someone discovers your login information?
  • What if someone sits down at your desk when you walk down the hallway?
  • What if your laptop is stolen?
  • What if you inadvertently have installed malware on your computer?

The person behind the keyboard is not you, but your code will not know that. Suddenly, "you" are not trustworthy anymore. Even the most trusted individuals can have their laptops stolen or passwords compromised, and if that happens then the user accessing the system may not be as trustworthy as you expect. You server needs to treat every log in with suspicion.


Don't send emails of secure information. It could be viewed in transit, but even more likely, it will get forwarded or archived.

Don't print out secure information. It can get lost or misplaced. It can end up in an insecure trash can. Hackers use dumpster diving to research individuals for phishing attacks, for social engineering, or to footprint a target organization.

And not trusting users extends to the offline world too. Social engineering attacks depend on getting insiders to extend undeserved trust to outsiders.

Fork me on GitHub