The Cost of Application Security

Introduction

During application security audit, the designated team observed the following:

“In course of applying brute force on login module of the application, when invalid password was entered in application, the error message “Incorrect password” displayed, whereas, when invalid user id was entered then the message “Invalid User id” got flashed. Thus, this different messaging text can facilitate the attacker in enumerating valid accounts and hence makes the proof of vulnerability of application.”   

On the basis of the aforesaid observation, the team recommended that a generic and consistent message - regardless of the fact whether either it was user id or was it password which was incorrectly entered- to be displayed. 

When we analyzed our application, we found the reason for inconsistent messages. It was due to two levels of validations of user’s credentials. One was client side and another was server side. The client side validation prompted “Invalid user Id” and server side validation, once failed, displayed “Incorrect Password”. The further analysis also reveled that observed inconsistency was not inadvertent rather it was, to some extent, intended to facilitate genuine user to spot which possible erroneous entry he/she was making, while logging into the application. If the message were consistent he would be clueless and that would increase his chance to repeatedly make wrong entry in logging and eventually the user will end up with the notorious message:” You have entered so many wrong passwords, so Access blocked”. We wanted to punish attackers but perished our innocent user .In that sense, the convenience of user suffered.

In light of that, if we analyze the problem at hand, the very recommendation here, poses one broader question: Should we cut down the privilege of regular genuine user just to obstruct the every possible route of attack? I guessed your answer, you will say-‘it depends’. But you as developer are made obliged to think along this line, but application security team does not bother to assess the cost of effort in attacking the system. For them, every porous border is vulnerable and every path, if can be traversed, however extravagant, shall be traversed, even if nothing valuable could be found through that route. If the auditing team is just suggestive and only provides information about the application this hardly does matter and the developing team decides which one really poses threat to security and therefore needs to be plugged, and which can be ignored on the altar of convenience to the user(not developer) ,as the situation demands. But if following the recommendation and tuning the application to comply with the recommendation is mandatory then incorporating application security mechanism can deteriorate the quality of application in many other fronts, as in the above case the convenience of user suffered because login module arrested genuine user, and even denied him the right to know the reason of arrest. The other quality attributes which can suffer, in that way, are maintainability-when cross cutting code is written to incorporate security logic-, portability-window bases security can not be reused when application is transited on web.

Now, my resolution to such situation is that  C&S which, in many organizations, works like an independent constitution body needs to be brought  in main stream of  the development of the application. The recommendations proposed by C&S needs to be analyzed in terms of its cost and benefit. As for instance, the security requirement which is the part of the domain of the application is mandatory and therefore must be incorporated. There is no choice at all here. But if the choice is between application security - not inherent with the domain- and the other quality attributes of the application then our course of action should be in such a way that at the end of  the development /installation, the security features either feel like the innate attribute of the application- lest it appears as a fifth wheel attached to it- or if it  does not seem to be achievable in elegant way then my recommendation is: Make the cost of breaking the system higher than the earned profit out of committing such misdemeanor. Do not make application security feature burdened on the soul of the application. Let it be natural. Let it be as much it is necessary. And let be relevant.

To make my point little vivid, let me conclude my submission with an anecdote. The analogy is not perfect- I admit, but it reflects the tinge of morale of the article.  

A king was threatened of death. The courtiers of king decided to block all possible paths through which the death could accost the king. First the Palace gates locked up, then all windows. Brick by brick the ventilations of room kept closing until when the last ventilation was to be cemented, the minister around yelled- stop. Do not cement it; the king shall die of breathlessness. This last ventilation, through which only, the air can flow across now, is the only possibility of life.., otherwise the death is certain. That last withheld brick, by not participating in building security wall, rather participating in un-building it, became the possibility of life. And then just to increase the possibility of life, brick by brick ventilation were opened, windows and doors were opened and it lasted until the Palace became beautiful as before and after then a reasonable and sufficient security had been installed just to prevent the possible attacks. The point to ponder here is: Will you kill yourself in self defense?