Striking the balance: App security features and usability
Last week, I installed a new app from the Google Play store onto an Android device. While the app was downloading and installing, I took a look at a few of the user reviews and found their contents interesting. Four of the top 10 comments were both negative and related to security. The comments have been paraphrased for anonymity purposes:
- Other than having to login every time it’s great. Is it really soooo hard for the app to have an option to save username and password?
- Is there a reason the app won’t keep me logged in? I just want to open the app see my preferences and get on with placing my order. Overall the app is great, just frustrating my info isn’t there when I want it to be.
- Other than seeing “Warning” when you first open the app (certificate issue?) it’s great to send our customers to. It really helps us help them through the sales process.
- Awful! Why are things never built with the customer in mind? The app doesn’t save any of my information; clearly security got to the app and made it as unfriendly as possible. Apps should make my life easier, not slow me down otherwise I’d just login from the regular site.
While it is a little funny to see the impressions that actual users have about us security folks, it’s still frustrating to read all of these comments. Why do users feel as it has to be an either or choice: security vs. performance, security vs. usability, or security vs. functionality? You should want and have both. Well-designed security controls should be as seamless as possible and only even exist when absolutely necessary to protect sensitive functionality.
The app I downloaded is used primarily by business travelers. These are people who are on the go, in a hurry, and typically aren’t in a position to whip out their laptops to conduct business. They rely on their mobile devices to get things done. In this case, users were practically begging for functionality to allow them to be remembered by the app and not have to re-authenticate every time they use it. How upset would these same users be if they lost their phones and as a result had to cancel credit cards and change passwords because their details were therefore vulnerable?
There is really only one trade-off when it comes to security, and that is security vs. development cost/time. Development costs and times can impact time to market, which can be a critical factor when it comes to mobile apps. But keep in mind that it is significantly less expensive to build security in and develop a feature correctly the first time as opposed to developing an insecure feature that has to be patched later on.
We all know that storing a password on a mobile device is unacceptable. But there is no reason that an authentication token with a limited lifetime can’t be stored on a mobile device. For sensitive functionality, like purchasing or funds transfers, the app can simply require re-authentication. In the case of this app, the developers had three options:
- Do not implement the storage of credentials. This requires no development cost/time, and it is secure, but the users are definitely not happy.
- Implement the feature insecurely. Save the username and password in cleartext on the device. This will require development time X.
- Implement the feature securely. Store a temporary authentication token on the device. Require re-authentication for sensitive functionality. This will require development time Y.
It is true that Y is slightly longer than X, but if option #2 is selected, then the actual development time will be X + Y, as the feature must be patched in a later release. I want to believe that this company has made the right decision to implement this feature securely from the start, which will minimize costs in the long run.
As security professionals, it is our job to recognize the needs of our clients and their users. Security should never be about saying “no.” It should be about working with clients and understanding their needs in order to give their users what they want without exposing them to any unnecessary risks.
