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

Not even trying.<p>Seriously, you wouldn&#x27;t believe the number of companies&#x2F;people who <i>don&#x27;t even try</i>. I&#x27;m talking &quot;db.run(request.body)&quot; levels of not-trying, &quot;the shared admin password is &#x27;turtle&#x27;&quot; levels of not-trying; &quot;the medical records are protected because they&#x27;re on a hidden share&quot; levels of not-trying.<p>These are all things that I&#x27;ve seen.<p>Second to that is <i>thinking</i> that you&#x27;re trying because every once in a while you have a vague sense of paranoia.<p>&quot;Let&#x27;s use MongoDB so we&#x27;re safe from SQL injection.&quot; &quot;We need to proxy the API because that&#x27;s what other people do.&quot; &quot;The WiFi password is secure because it&#x27;s 26 characters long -- even though we&#x27;re still using WEP.&quot;<p>Also things I&#x27;ve seen.<p>I know I&#x27;m not any better either. Given the opportunity, I would <i>always</i> hire a professional to audit my stuff.

Lack of <i>working</i> backups. It&#x27;s appalling how many people depend on systems with no backups.<p>Forget ransomware and other exotic attacks, what happens if after 7 years your hard drive decides to die on you?<p>I don&#x27;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 <i>a few</i> solutions.<p>Backup, backup and backup again :-)

Willful ignorance.<p>its 2017 and yet still the biggest vulnerability of them all is willful ignorance.<p>People have agendas to fulfill. Can&#x27;t let the truth get in the way. Haven&#x27;t found a budget to fit in the truth looks like we will have to do without it for now.<p>What is the truth?<p>Well nobody cares about security.<p>Who knows about the truth?<p>Mostly everybody<p>Why doesn&#x27;t anyone do anything about it?<p>Trying hard just doesn&#x27;t cut it anymore as we can see those with influence would rather destroy the entire internet for mass surveillance.<p>Also don&#x27;t forget about 2FA

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.

• Password requirements outside of length really don&#x27;t do squat except make it harder for people to remember their already weak passwords<p>• Using the same short passwords over and over again.<p>• Using short passwords &lt;8 characters<p>• Using very commonly used passwords (password123)<p>• Security questions<p>Just use a password manager. Choose one strong 10+ character password that you can remember. Choose the first letter of every word from song lyrics you like if you have to.<p>Example: lwbeiycwlmdrgag (loving would be easy if your colors were like my dreams red gold and green).<p>It would take the standard web hack billions of years to figure out that password. Even if someone had massive computing resources behind the crack (not typical, and very expensive) it would take over a week. Password123 or Fido16 might take a minute.

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&#x27;t just try to filter out what might not look like the ten things.

As a pen tester, the biggest problem is management not caring or understanding. If there is a budget for pen tests, there are failsafes for data loss (offline, so they can&#x27;t be cryptolocked), monitoring is in active use, developers are given time to learn about and write secure software, and sysadmins given the time and budget needed, then it&#x27;s usually quite alright. That might sound like a lot, but to most people here it&#x27;s basic stuff. There are many companies that get it right, though of course I have a biased point of view (and I&#x27;m aware of it) because the ones I see have a budget for security tests.<p>As for a single, common mistake for iot&#x2F;apps&#x2F;firmware altogether, that&#x27;s an overly broad question. I think the best answer I can give is not updating things when updates are available. That&#x27;s the easiest way to get compromised without even writing a single line of vulnerable code.

Default passwords.<p>Bad secret management (hardcoded in Git, shared secrets not changed after an employee left ...)<p>Dev and live not properly separated&#x2F;dev not properly secured.<p>Services exposed to the internet that shouldn&#x27;t be.<p>Old and forgotten software &#x2F; appliances.<p>Don&#x27;t forget about the dev&#x2F;sysadmin workstations!

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

On a general level, no systematic accounting of assets.<p>Can you get me most or all of the following in an hour or so?<p>- List of people with production API credentials and which ones per person<p>- List of accounts with weak passwords or lacking 2FA<p>- Who has SSH access to each of your servers?<p>- All portal logins per employee<p>- Show me the last 3 production data sources this specific employee accessed<p>- Per data source, list people and services that can read&#x2F;write<p>- Network diagrams and policies<p>A lot of organizations can&#x27;t. It&#x27;s boring bookkeeping, but systems have to be put in place to keep this information correct and up to date. Otherwise, there&#x27;s nothing to manage or secure!

The biggest security mistake I see is the History.<p>Talking about history of :<p>1. Slack channels ( lot&#x27;s of private stuff &#x2F; links go to #general )<p>2. VCS ( lot&#x27;s of passwords &#x2F; tokens are in the commit history )<p>3. JIRA ( lot&#x27;s of private information &#x2F; company secrets are there )<p>Usually only one of those three can cost the company a big lawsuit if some employee&#x2F;freelancer is deliberately being hired to make damage.

Most common? Simply not having a security mindset whatsoever day-to-day. If you build <i>anything</i> you should be thinking about security, even if all you&#x27;re thinking is why security isn&#x27;t an issue for some particular project. It&#x27;s always important to understand where the boundaries are because they will change. I&#x27;ve seen countless examples of people playing fast and loose with security merely because they never thought about it or don&#x27;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&#x27;t think about it and just don&#x27;t care.<p>A lot of people have the mindset &quot;oh, who would ever hack me? my app is just small potatoes&quot;. And this is how you end up with things like the mirai botnet.

Emailing back password in plain text - hey this is the password you&#x27;ve just set, don&#x27;t forget it!<p>I&#x27;ve only had it happen to me about 4 or 5 times in the past 15 years or so. But it makes me so disappointed each time that I literally want to find that developer and knock him&#x2F;her out with the ugliest hammer I can find.

Most common mistake I see: sharing your passwords with multiple people. Even when the product lets you have more than one account.<p>Mistake websites make: only letting you have one user account.

Organizational firewalled &quot;internal networks&quot; that everyone connects to.<p>People opening untrusted web content and email attachments in Acrobat Reader and Office.<p>Reliance on antivirus products.

Critical functionality implemented in client code rather than the backend.

Not training the employees:<p>I can provide email filtering, DNS filtering, firewalls and all sorts of technical solutions to security.<p>It all goes to pot if someone gets click-happy on weird websites or email attachments or falls for the &quot;Your $Company_President need to transfer some funds&quot; email.

Using string concatenation to build paths or SQL queries. My previous boss is a big fan of this. I&#x27;ve frequently broken his stuff by adding or omitting trailing slashes. The SQL injection potential is obvious.<p>Our ticketting system is written in-house and is a diabolical mess of Teach Yourself PHP In 24 Hours - every trope of poor PHP development is in there. Certain sensitive pages are so badly written they&#x27;re IP-restricted to our office to reduce the chance of them being exploited.<p>And a major one - passwords as a 1337 spelling of the username. We use this A LOT.

Because there are people like me who &quot;scan networks&quot; themselves to sleep counting specimens. I&#x27;m looking at you, petrochemical company with open video conference system a few miles away, and you battery powered terrain shift monitoring sensor at old oil rig that became a 300 meters wide hole, visible from space, and you, TV station with such the helpful admin that he exposed a page titled &quot;intranet&quot; to help the not so tech savvy journalists access FTP, with the credentials on the page of course, and tomorrow&#x27;s news prompts and contents with write permissions, or you, radio with firewalls still on default config (may the soul of Heaviside haunt your waves), or you, Telco employee with meticulously noted credentials on a sheet of paper for such banal infrastructure, or you, law enforcement officer leaving a flash drive with secret technical specs on a new system in an internet cafe because you needed something to store &quot;onanism inducing material&quot;.<p>- Default config.<p>- But the machine isn&#x27;t a website, it doesn&#x27;t have a name, just an IP address. Who would find it?<p>- Just execute user SQL query &#x2F; eval user code, what could possibly go wrong? I&#x27;m sure all the docs telling you no string substitution, not even with a gun on your head, is just exaggeration..<p>- Password is domain name.<p>- Password comparison in JavaScript, rendered, readable (a special place in hell for this one).<p>- And of course, clear text passwords. Gotta love that one.

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.

Unescaped variables in HTML and SQL.<p><pre><code> &lt;p&gt;Hello, &lt;?= $username ?&gt;.&lt;&#x2F;p&gt; </code></pre> and<p><pre><code> $sql = &quot;update tbl set x = &#x27;{$_POST[&#x27;x&#x27;]}&#x27; where id = {$_POST[&#x27;id&#x27;]}&quot;; </code></pre> For HTML, use htmlspecialchars, better yet a shorter wrapper function like h(), better yet a template language like Handlebars.<p>For SQL, use parametric queries. (Most people call them parameterized queries, but with so many suffixes in English, why not choose the more musical one?)

1. Secrets in source. This is by far the easiest one to &quot;see&quot;.<p>2. In Ruby code, I see a surprising amount of `eval`; mostly `class_eval`

Lack of understanding of string escaping.<p>- Trying to remove&#x2F;escape &quot;bad&quot; characters on input or thinking that only &quot;user&quot; input needs escaping. This means anything that slips past the filtering can do unlimited damage. Any &quot;special&quot; characters get lost or mangled in uncontrollable ways. The right way is to escape data on output.<p>- Thinking &quot;escaping&quot; is one universal thing that can be done in advance. This leads to HTML-escaped text in email subjects, SQL-escaped strings in HTML, etc.<p>- Forgetting that nested contexts require multiple levels of escaping (e.g. an URL argument in string in JS in an HTML script tag requires URL-escaping followed by JS string escaping followed by HTML-script escaping).<p>- Voodoo escaping such as `sprintf(buf, &quot;cmd &#x27;%s&#x27;&quot;, arg)`

Appending strings together for SQL queries (SQL injection just waiting to happen).<p>Passing in user info for a query, instead of using session or token encoded data (Impersonation just waiting to happen).<p>Bad passwords&#x2F;keys, and bad management of those secrets.<p>No plan for backups, or not having a way to restore backups.

Most common security mistake: Lack of a Patch Management Policy that is actually followed.<p>Just look at WannaCry. The Patch was released March 14th and the worm was released May 12th.<p>That shows everybody who was compromised simply didn&#x27;t have a regularly scheduled Patch Management Process in place.<p>From WannaCry Wikipedia page:<p>&gt;A &quot;critical&quot; patch had been issued by Microsoft on 14 March 2017 to remove the underlying vulnerability for supported systems, nearly two months before the attack, but many organizations had not yet applied it.<p>&gt;Almost all victims are running Windows 7 or newer.<p>Same with web apps, have a regularly scheduled Patch Management Policy in place for the Libraries, Gems, Modules, Packages, etc you use.

Most mistakes are basic, but they come about because people don&#x27;t test their code&#x2F;sites with the mindset of an attacker. This is pretty much always the case when it comes to XSS, and SQL-Injection attacks.<p>There are lots of words written about security, so it&#x27;s hard to pick a single thing. But my vote would be for &quot;enumerating badness&quot;, and &quot;default permit&quot;, which are kinda related.

Part of my day job is reviewing vulnerability reports for a load of software written mostly in C&#x2F;C++.<p>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&#x27;s been freed, not initializing memory properly before using it, type confusions causing values to be treated as pointers, etc.

The OWASP Top Ten is a great list of vulnerabilities that we test for in the Financial Services industry before releasing new code: <a href="https:&#x2F;&#x2F;www.owasp.org&#x2F;index.php&#x2F;Category:OWASP_Top_Ten_Project#tab=OWASP_Top_10_for_2017_Release_Candidate" rel="nofollow">https:&#x2F;&#x2F;www.owasp.org&#x2F;index.php&#x2F;Category:OWASP_Top_Ten_Proje...</a>

No infrastructure secret management or very bad infrastructure secret management:<p>* Private SSH&#x2F;AWS API Keys in Github<p>* Shared Prod Passwords<p>Not applying updates to infrastructure regularly

The top comments here are really harping on things that aren&#x27;t necessarily actionable (with the exception of backups, but I&#x27;d split hairs on whether that&#x27;s a security mistake or a business process mistake). I interpret your question to mean security mistakes that have an actionable basis.<p>The most common security mistake I see is API authorization errors, in the abstract. More specifically, I see this manifest itself reliably as insecure direct object references. Nearly every security assessment I have ever been on has had an API where you can slightly alter a parameter value and bypass authorization controls altogether to access another user&#x27;s account (or whatever other state-changing action you can think of in the context of their session).<p>In an era where just about everyone knows what SQLi and XSS are, actual logic errors fly right under the radar and authorization controls are not implemented universally.<p>To be <i>even more specific</i> - do you have a microservice architecture? Have you tested that every backend service has the same authorization controls in place? When was the last time you tested this?<p>Put your backend services behind a common access policy (you can use something like Kong for this), and make sure that you parameterize all calls <i>between services</i>, because someone can and will access your privileged services through a less privileged service using an unexpected or undocumented call. For that matter, use internal access policies to discriminate between more and less privileged services. It doesn&#x27;t matter if you have a DMZ and firewall open IP traffic if you give a user-facing service access to a more privileged service - users can hop between them.<p>And when you deprecate an internal legacy API, <i>actually remove</i> it from being accessible by other services. This is probably still the number one way that people find really serious vulnerabilities in Facebook. I&#x27;ve seen cases where user input was used by Service A to directly query Database B using fallback API C, giving the user de facto arbitrary read access to the entire table. Database B is always firewalled to outside internet traffic in these scenarios, but Service A gets a free pass to access internal resources and voila.<p>It&#x27;s fairly straightforward to classify specific technical issues, but if your APIs for various backend services are not properly set up with authorization controls you open the door to remote code execution, command injection, server-side request forgery...it&#x27;s pretty bad. And it&#x27;s largely unknown by developers because they are hyper-focused on common web vulnerabilities, which frankly are mostly solved by using the right libraries these days.

Password reuse and easy-to-guess passwords. Most of the time, it&#x27;s not even the users themselves who are to blame but non-sensical password policies (like &quot;Password must contain characters XYZ and be no longer than 8 characters&quot; and &quot;Password must be renewed after 30 days.&quot;).

Writing security related code themselves instead of using a battle tested library. Never underestimate how many security holes there can be even in simple looking code.<p>The most common one for this is login systems. I&#x27;ve custom written ones with bugs so bad that a blank password worked for every login.

Locking down files in the name of &quot;security&quot;; configs and logs. Everything containing even the most banal pieces of information.<p>The result? All our sysadmins marching around as root all day because it&#x27;s the only way they can get any work done.<p>Seems to be the default on several Linux distros these days.

Having everything out of date.<p>Servers, computers, software, (people), everything. Many exploits have been published on exploit-db.com targeting software that has already been patched. My fortune top-100 company is the type of company that will decide to update to Windows 10 when Windows 15 comes out.

12+ yr exp in security<p>default&#x2F;dev&#x2F;test&#x2F;guest accounts+passwords with easy to guess credentials<p>exposing servers and services to the internet when not needed (memcached, hadoop, mongo, etc)<p>Insecure Direct Object Reference<p>Not blocking known hostile entities (known bad ASNs, known bad netblocks)

Mission critical logins&#x2F;passwords put on a notepad directly on your desktop.<p>It is appalling how many old school places do this.<p>Also, if you open up the top drawer of someone&#x27;s desk, you are pretty likely going to find passwords there too.

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

Documentation of complex systems.<p>If you do not have documentation explaining how the system works, its dependencies, diagrams, etc, you will have a hard time fixing security errors.<p>What happens if the guy that built the system leaves?

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.

Obvious one but not using HTTPS would be up there.

Not sanitizing user inputs and whitelisting query parameters. Also sharing private keys over emails or through file sharing.

Running the web app server in debug mode in prod.

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

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