In Information and IT Security there is a nasty tendency for specific "best practices" to become inviolable golden rules, which then leads to people recommending that they are applied regardless of whether they are appropriate for a given situation (similar to Cargo Cult Programming)

A good example of this is the common approach to password policies which applies a one-size fits all 8-character length requirement combined with high complexity requirements, 12 previous passwords stored in a history to stop re-use, 3 incorrect attempt lockout and 30 day rotation.

The 30 day rotation is intended to lower the window of opportunity for an atacker to use a stolen password, however it is likely to lead users to use sequence passwords meaning that if an attacker can crack one instance they can easily work out others, actually reversing the intended security benefit.

The high length and complexity requirements are intended to stop brute-force attacks. Online brute-force attacks are better mitigated with a combination of sensible lockout policies and intrusion detection, offline brute-force usually occurs when an attacker has compromised the database containing the passwords and is better mitigated by using a good storage mechanism (e.g. bcyprt, PBKDF2) also an unintended side affect is that it will lead to users finding one pattern which works and also increases the risk of the users writing the password down.

The 3 incorrect lockout policy is intended to stop online brute-force attacks, but setting it too low increases account lockouts and overloads helpdesks and also places a risk of Denial of service (many online systems have easily guessed username structures like firstname.lastname, so it's easy to lock users out)

What are other examples of Cargo-Cult security which commonly get applied inappropriately?

  • 18
    This sounds suspiciously like a discussion question, Rory.
    – tylerl
    Commented Sep 16, 2013 at 16:46
  • Sorry, Rorry. This is indeed a discussion question. The closest closure reason is opinion-based. One way I could see this is as a CW at best.
    – Adi
    Commented Sep 16, 2013 at 16:50
  • 31
    @tylerl Adnan oah come on, live a little. Break some rules, pee in the shower.
    – rook
    Commented Sep 16, 2013 at 16:59
  • 9
    @Rook: It's all pipes! What's the difference?!
    – Scott Pack
    Commented Sep 16, 2013 at 20:56
  • @tylerl Yeah, but an objectively (mostly) answerable discussion question, with especially useful answers about the pitfalls that people fall into in information security. Commented Aug 4, 2017 at 3:07

8 Answers 8

  • Closed source is more secure than open-source as attackers can view the source code and find and exploit vulnerabilities. While I'm not claiming this is always false, with open source software it's at least possible for outside experts to review the software looking for gaping vulnerabilities/backdoors and then publicly patching them. With closed source software that simply isn't possible without painstakingly disassembling the binary. And while you and most attackers may not have access to the source code, there likely exist powerful attackers (e.g., US gov't) who may be able to obtain the source code or inject secret vulnerabilities into it.

  • Sending data over a network is secret if you encrypt the data. Encryption needs to be authenticated to prevent an attacker from altering your data. You need to verify the identity of the other party you are sending information to or else a man-in-the-middle can intercept and alter your traffic. Even with authentication and identification, encryption often leaks information. You talk to a server over HTTPS? Network eavesdroppers (anyone at your ISP) knows exactly how much traffic you sent, to what IP address, and what the size of each of the responses (e.g., you can fingerprint various webpages based on the size of all the resources transferred). Furthermore, especially with AJAX web sites, the information you type in often leads to a server response that's identifiable by its traffic patterns. See Side-Channel Leaks in Web Applications.

  • Weak Password Reset Questions - How was Sarah Palin's email hacked? A person went through the password reset procedure and could answer every question correctly from publicly available information. What password reset questions would a facebook acquaintance be able to figure out?

  • System X is unbreakable -- it uses 256-bit AES encryption and would take a billion ordinary computers a million billion billion billion billion billion years to likely crack. Yes, it can't be brute-forced as that would require ~2256 operations. But the password could be reused or in a dictionary of common passwords. Or you stuck a keylogger on the computer. Or you threatened someone with a $5 wrench and they told you the password. Side-channel attacks exist. Maybe the random number generator was flawed. Timing attacks exist. Social engineering attacks exist. These are generally the weakest links.

  • This weak practice is good enough for us, we don't have time to wait to do things securely. The US government doesn't need to worry about encrypting the video feeds from their drones - who will know to listen to the right carrier frequencies; besides encryption boxes will be heavy and costly - why bother?

  • Quantum Computers can quickly solve exponential time problems and will break all encryption methods. People read popular science articles on quantum computers and hear they are these mystical super-powerful entities that will harness the computing power of a near infinite number of parallel universes to do anything. It's only part true. Quantum computers will allow factoring and discrete logarithms to be done in polynomial time O(n3) via Shor's algorithm rendering RSA, DSA, and encryption based on those trap-door functions easily breakable. Similarly, quantum computers can use Grover's algorithm to brute force a password that should take O(2N) time in only O(2N/2) time; effectively halving the security of a symmetric key -- Granted Grover's algorithm is known to be asymptotically optimal for quantum computers, so don't expect further improvement.

  • 17
    I'd add a corollary to your first, and that is "Open source is more secure than closed source because there are lots of people scrutinizing the code for issues."
    – Xander
    Commented Sep 16, 2013 at 17:25
  • 9
    "My computer is invulnerable because it isn't/has never been/will not ever be connected to the internet." Commented Sep 16, 2013 at 19:35
  • 3
    @drjimbob Or software with open source but completely developed in-house without using a mess of contributors (c.f. Red Hat Enterprise Linux).
    – ithisa
    Commented Sep 16, 2013 at 20:32
  • 2
    @Xander Case in point: ProFTP
    – Phil
    Commented Sep 16, 2013 at 20:44
  • 4
    I'd add another corollary: popular open source is more secure than closed, I could create my own crypt suite and open source it, but that is likely to be insecure because no one would care about it enough to try and improve it Commented Sep 17, 2013 at 8:59

Some examples:

  • Bigger keys. 4096-bit RSA, 256-bit AES... more bits are always better. (See the comments: there is no point to have keys bigger than the size which ensures the "cannot break it at all" status; but bigger keys imply network and CPU overhead, sometimes in large amounts.)

  • Automatic enforcement of "safe functions" like snprintf() instead of sprintf() (it won't do much good unless the programmer tests for the possible truncate, and it won't prevent using a user-provided string as format string). Extra points for strncpy() which does not do what most people seem to assume (in particular, it does not ensure a final '\0').

  • "Purity of the Security Manager". As an application of the separation of duties and roles, all "security-related" decisions should be taken by a specialist in security, who is distinct from the project designers and developers. Often taken to the misguided extreme, where the guy who decides what network ports should be left open on any firewall has no knowledge whatsoever about the project, and deliberately refuses to learn anything in that respect, because independent decision is more important than informed decision.

  • 5
    Could you elaborate on why a larger key may not be better than a smaller key?
    – Phil
    Commented Sep 16, 2013 at 18:31
  • 6
    Larger keys imply higher bandwidth and CPU usage, and may imply interoperability issues as well; beyond the sizes where the key, by itself, is "unbreakable with Earth-based technology", extra length is just dead weight. RSA-2048 and AES-128 are already at that point.
    – Tom Leek
    Commented Sep 16, 2013 at 18:46
  • 1
    I see. If I were you, I'd add that to your answer.
    – Phil
    Commented Sep 16, 2013 at 20:37
  • 2
    I agree with your sentiment that more bits isn't always better--sometimes its weaker-- for reduced-round AES-256 is weaker against some attacks than AES-128. But when the extra milliseconds of CPU time is not an issue (e.g., encrypting a few files), more bits doesn't necessarily hurt and may protect against advances in attack method. RSA-2048 is comparable to 112-bit strong assuming a L(1/3) = e^O(N^1/3) general number field sieve, though recent math breakthroughs reduced that to L(1/4) = e^O(N^1/4) for discrete log.
    – dr jimbob
    Commented Sep 17, 2013 at 5:45
  • 2
    Some expect this will be extended to factoring, which would leave RSA-2048 only ~75-bit equivalent strength (making the sketchy assumption of same constants as 112-bit analysis in our big-O analysis) while RSA-4096 would be ~96-bit strong. RSA-768 was broken once with a distributed effort and had 76-bit of security using the old L(1/3) sieve. Similarly, one could choose AES-256, if you fear your adversaries will build a quantum computer at some point and be able to break AES-128 in 2^64 time with Grover's algorithm. Again, agree always use bigger is wrong, but sometimes it makes sense.
    – dr jimbob
    Commented Sep 17, 2013 at 5:48

I'll add my own appsec examples that I have seen while consulting:

  • "I'll email you an encrypted zip and include the password in the same email..." This has happened to me more than once. A locked door won't stay locked if you leave the key in the door.
  • "But you couldn't have gotten SQL Injection and SMTP injection, we called sanitize() on everything!". There is no way to make a variable safe for every use, you need to use the sanitation routine for the job.
  • "We cannot be hacked because we only use XXX platform/language/OS". Every platform has security problems, period.
  • "We have a yearly security assessment, you won't be able to find anything." Frequency != Quality. Having frequent assessments is a good thing, but this does not guarantee anything!
  • "We have a WAF, which means we don't have to actually patch anything." Yeah, so this happens... I had a client that didn't patch known CSRF vulnerabilities, because they assumed the WAF would be able to stop these attacks. (No WAF can do this. I once found a WAF that claimed it could "prevent all of the owasp top 10", and the WAF's HTTP management interface was vulnerable to CSRF.)
  • Wouldn't it be possible for a WAF to inject & verify CSRF tokens automatically?
    – SLaks
    Commented Sep 16, 2013 at 21:41
  • @SLaks I haven't seen anything like that.
    – rook
    Commented Sep 17, 2013 at 3:10
  • I wonder why...
    – SLaks
    Commented Sep 17, 2013 at 4:08
  • 1
    Regarding your first point, most of the corporates I've dealt with have to do this to get round the filters in their email system. The scanners (GMail included) won't allow you to send zip files with exe files in them, so you need to encrypt the zip file to send it (although personally I just rename the zip file to zop, then GMail leaves it alone!) Commented Sep 19, 2013 at 9:17
  • 1
    WAF = Web Application Firewall, for those (like me) not familiar with the acronym. Commented Aug 4, 2017 at 3:01
  • Passwords must be salted and hashed before storing in the database. SHA-1 is a good fit, SHA-512 is perfect.

I still hear that one from many security professionals, security training, and current security guides.

  • 9
    512 > 1. Bigger is better right?
    – user10211
    Commented Sep 17, 2013 at 6:12
  • 1
    Correct me if I'm wrong, but with the collision vulnerabilities in SHA-1 wouldn't any of the SHA-2 algorithms (SHA-256, SHA-512, etc) be better?
    – Hyppy
    Commented Apr 22, 2015 at 12:24
  • 2
    @Hyppy That's the point, these are "cargo cults" - i.e. not correct. As to your point - SHA-2 is not acceptable for password protection either - see security.stackexchange.com/a/31846/33
    – AviD
    Commented Apr 22, 2015 at 12:58

Using SSL only for the login page rather than all the authenticated areas of a website.

  • 8
    Or even worse, the login page uses http, but embeds a https iframe or posts to a https target. Trivial to use practically undetectable SSL Strip. (Stackexchange OpenID, I'm looking at you). Commented Sep 18, 2013 at 7:38
  • Oh man, this one really bugs me! I have also seen websites that are HTTPS, but the login iframe is HTTP. Like wtf, what developer came up with that brilliant piece of work?? Commented Aug 4, 2017 at 3:03

Just one, but it's a biggie: "Information Security is a technology problem, that can be fixed with technology."


In order to prevent people finding out whether certain users exist in the system - hiding whether the password was incorrect or the username was invalid during a failed login attempt, ... While at the same time offering a password reset form that does leak this info.


"Our website can't be hacked because we are using SSL". Sir that just makes it more easy to exploit if its vulnerable because even your IDS/IPS is rendered useless by the SSL stream.

  • 3
    Your intrusion detection/prevention system could have copies of your private keys and be able to decrypt incoming/outgoing TLS traffic.
    – dr jimbob
    Commented Sep 16, 2013 at 17:59
  • @drjimbob Most of the time that is not the case. And even with the private key, SSL is not something that is going to protect the website against any kind of exploitation at the application level.
    – void_in
    Commented Sep 16, 2013 at 18:30
  • Well, TLS can prevent say network eavesdroppers from listening in on passwords, session cookies, as well as the URL/data that's being accessed. Many sites that claim to be "hacked" merely have someone using an admin account with captured password and defacing the content. Agree, TLS is not in anyway a catch-all--it only prevents network eavesdropping/tampering (and really you should be using TLSv1.2 - though its fine for servers to accept TLSv1.1 from old browsers; you really shouldn't use any SSL or TLSv1.0). Agree, it doesn't prevent against SQL injection, CSRF, XSS, buffer overflow, etc.
    – dr jimbob
    Commented Sep 16, 2013 at 22:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .