Developers should care about a project’s security requirements, even if they don’t have them in their backlog and SOW. Security can definitely impact the product that they are building. Recently one of our customers, a project manager with a small team of in-house engineers, requested that we implement a 2-Factor Authentication (2FA) feature for their app, since their business is regulated by a state agency based on the data that their app processes and stores. No problem! We quickly and easily implemented their requested software feature. After using the feature for several weeks, however, they began to get annoyed by typing one-time code every time they would log in to the interface.
Can you guess the next feature request they had for us? Correct, they wanted «remember me», so they wouldn’t have to input code every time during the login process. And this is where our expertise really kicked in.
Konstankino started to review this requirement closely to see how it might fit into the overall product design and architecture as well as applicable regulations.
The original idea from the customer development team was to use the JavaScript library to «remember» the user’s agent (read: browser) and then – based on the fingerprint – decide whether or not to allow access without 2FA code.
In a nutshell, 2FA is a process that involves something that the user knows (username and password) and something that the user has (a one-time unique code). Were we to actually implement such a feature, we would ruin this principle, and here is why:
- We were about to be dependent on some third-party JavaScript library that might have some vulnerabilities in the future, or may already have risks;
- We about to get another attack vector which is a JavaScript code, Ouch!;
- JavaScript code that helps to make a decision for the next step in the 2FA process? – That sounds scary!;
- We have another dependency to update in case of vulnerability and if there is no patch - we (or some other developer) will need to come up with the patch themselves.
None of those facts were of long-term benefit for the product we are helping to build. Therefore, we started to talk through those items with the customer to make sure the risks were understood and accepted.
As it turned out, the customer was not ready to accept such risks (wisely!). So we suggested an idea to make 2FA less obtrusive by white-listing specific personnel from well-known locations. They accepted this solution and it has significantly increased their satisfaction with minimal additional risks. This is very good example of a scenario in which security requirements were not aligned properly with the business requirements. In fact, the customer was not aware of such concerns and risks at all until we analyzed the scenario and educated them.
We believe communication and a team work is so important. Sharing expertise is no less important, to make sure everyone is aware of the ramifications of every decision that impacts their app’s security.