If a security measure is implemented that doesn't provide any additional security benefit, can it be considered harmful?

As an example, consider a login page where the user is asked to enter their username, and then their password twice (for "security reasons").

There are two arguments here:

  1. If it gives the user peace of mind and isn't decreasing security, then what's the harm?
  2. If there's no actual benefit, the additional "peace of mind" given to the user is harmful because it gives them a greater sense of security than is valid.

I've frequently argued the second point, but the first opinion seems to be more common - particularly in the business community.

What do you think? Should redundant security measures be actively removed or is there really no harm in keeping them?

Note: the example isn't an actual case

  • 5
    I think you're right. Two risks: 1) it may give users a false sense of security, causing them to behave less cautiously/securely elsewhere, leading to an overall loss of security; 2) it may annoy users, incentivizing them to deliberately bypass the security system (e.g., choosing a shorter weaker password, so they don't have to type as much) or decreasing their willingness to comply with security measures.
    – D.W.
    Commented Jan 17, 2011 at 6:01

7 Answers 7


Any feature that "doesn't provide any additional [...] benefit" should be removed, security-related or otherwise. Besides increasing complexity and friction, it can introduce additional attack surface and end up making you less secure.

  • 2
    I am sure it also takes resources away from legitimate features/projects that would provide a benefit.
    – Wayne
    Commented Dec 3, 2010 at 0:18

I agree with the above comments, plus a relevant business issue: security measures cost money (in the same way that software features cost money) and a business has finite budget for security, usually not enough. The two downsides to ineffective controls are that some budget is being wasted and that the impression the board will get of their security team is poorer or less effective than it should be.


No, it's the same with software features.

If you produce something that does not add value it's waste. When it comes to redundant security the waste is even bigger since each wasted second in an IT system is multiplied by every user. That is assuming that the extra security "feature" takes user time.

Even If it doesn't affect users directly, such as double encrypting with chifers doesn't add extra security (such as Ceasar for example) then it will still degrade performance.

  • In the example I gave, the extra time is negligible if (first == second) .... Would you still consider it wasteful if it's not degrading performance?
    – Damovisa
    Commented Nov 19, 2010 at 5:07
  • And more to the point, is it harmful as well as wasteful?
    – Damovisa
    Commented Nov 19, 2010 at 5:07
  • Extra added logic that does not add to security, increases the amount of code to maintain and the amount of code security and feature related issue can hide. so yes, extra "features" is directly harmfull for security.
    – Morten
    Commented Nov 23, 2010 at 0:01

usually as Peter Stone said, it increases the attack surface. well the point is since it is not used, it will be forgotten and hence it shall remain not considered for any patch in case needed. therefore, the attacker can focus on these unpatched security or functional feature to do the attack, that can for instance be escalation of privilege...


Usually, when a page requires the same password to be entered twice, it is in order to detect typing errors -- which are more common with passwords because of the "blind entry" thing. In particular with registration pages, because a wrongly entered password implies a recovery procedure later on, procedure which necessarily has a non-zero cost. Stating that the double entry is for "security reasons" is just a way to make the user comply; users are accustomed to go through weird hoops as long as it is a "matter of security". But this is not really about security.

More generally, there is a delicate balance between some desirable characteristics:

  1. The user shall accept to comply with the security features.
  2. The user shall gain confidence in the system being secure.
  3. The system shall be secure.
  4. The user should be able to behave in a non-security-obsessed way.

Point 4 is important if the user is a potential customer and we want him to finally enter his credit card number and buy stuff. Point 3, of course, is important if you want to avoid trouble. Point 2 is about the "peace of mind". Point 1 means that the user may become the enemy quite fast.

These characteristics are not independent from each other. For instance, if you want a secure system (point 3) and thus require users to have long passwords (e.g. more than 12 characters), then users will rebel and begin to select long-but-weak passwords, or write them down on paper notes (failure on point 1, implying a failure on point 3). Talking too much about security may make some users obsessed about it. Building user confidence is also part (but only part) of making the user non-paranoid.

An analogy can be made with airport security. System security (point 3) is achieved through various hidden measures, most of which being luggage X-ray scanning, and an awful lot of police intelligence work on travelers. User confidence (point 2) is built through a display of visible security features, such as full-body scanners and hordes of mean-looking guards. Here, user confidence is about making people aware that the power-that-be are doing something about the security problems that they worry about; however, it is not really necessary that the security features that the users see are also the security features that actually enhance security. Use compliance (point 1) is enforced by those scary placards which warn you, as an airplane travelers, that "making statements about security" can plunge you into deep trouble, including missing your plane, paying a big fine, or possibly going to jail. To some extent, travelers are made non-paranoid (point 4) by exposing them to airport employees who all look utterly obsessed about security; the traveler instinctively reacts by taking the opposite stance. All of this, of course, is expensive (a full-body scanner is not the cheapest piece of hardware ever, and guards receive wages on a regular basis).

So there is no harm in having a security feature which is useless with regards to actual security, as long as it provides some gain somewhere, e.g. in building user confidence. However, there may be some cost involved, and since human beings are not machines, assessing that cost can prove difficult.

  • Oy. I was going to +1 you a whole bunch, until I got to the part about airport security. Completely disagree with you on that - but then, since the question is tagged [security-theater], I shouldn't complain, right?
    – AviD
    Commented Jan 15, 2011 at 23:31

It may or may not be directly causing a reduction in the security of your system, you need to look at your threat model to decide that. It may be annoying your users, and you need to investigate that. It certainly cost you money to deploy and perhaps to maintain, and that's definitely wasted resource.

However, it may also be that this (mis)feature introduces other vulnerabilities, by being poorly coded or misconfigured. You should probably remove it.


I would say it is harmful. Providing a security blanket to an end user is completely pointless. For instance if I have to enter my password twice to log into the same site, I will become suspicious as to why the site needs my information twice. Which leads me into thinking that someone has done something to the site in question. In all reality it is decreasing security as it gives an extra attack vector for a malicious person.

  • The example you are using is not a very good one. Many sites force a re-authentication of a user when processing sensitive transactions (for example, a financial transfer that is outside of the pattern of financial transactions that have been done in the past). Other than the specific example, I agree with the rest of your comment.
    – ygjb
    Commented Dec 3, 2010 at 7:05
  • @ygjb "Many sites force a re-authentication of a user when processing sensitive transactions (for example, a financial transfer that is outside of the pattern of financial transactions that have been done in the past)." When is that useful?
    – curiousguy
    Commented Aug 25, 2012 at 3:00
  • The theory is that by forcing a reauth reduces the likelihood that an out of pattern transaction is the result of a session hijacking or replay attack. Also, sorry for the lag in response o_O
    – ygjb
    Commented Sep 19, 2013 at 6:40

You must log in to answer this question.

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