What does 'App Security' really mean? What does it mean to keep an app secure, so that our users can do what they want, but we can stop malicious people from causing them and us harm?
Information Security is the notion of preventing people from doing things with the application.
There are many aspects of security. Wikipedia’s article on information security does a good job of identifying five main categories: confidentiality, integrity, availability, authentication, and non-repudiation. That might sound a bit vague, so let’s explore them by taking a look at some examples of each for a financial payments application and its cloud-based server. Let’s look at it from the point of view of me, a user, and see how we, the system designers, might approach the problem.
Confidentiality: I don’t want other people to access my financial information. So we use HTTPS to encrypt all communication with the server, and we ensure all data stored on the device is secure.
Integrity: I don’t want anyone tampering with my transactions, or deliberately or accidently replaying the communication to make a transaction happen twice. So we give a unique identifier for each transaction (perhaps involving time), so that the server will spot a repeated message. And we ensure all transaction communications include a Message Authentication Code (a sophisticated checksum) so the server will spot a tampered message.
Availability: I need to use the app whenever I want. So we ensure we have more than one instance of the server, perhaps even in different locations, with failover between them. And we install systems and procedures to spot ‘Denial of Service’ attacks, where attackers generate huge numbers of requests to prevent genuine requests from being processed, and to take the appropriate actions.
Authenticity: I don’t want other people pretending to be me. So we implement ways to identify a user initially – typically username and password, or perhaps credentials initially sent by post – and simpler ways, such as several-digit passcodes to re-identify me as user when I start the app. I don’t want to be tricked into giving up my authentication credentials either; so we ensure that HTTPS checks that the server is the correct one, not someone ‘spoofing’ it.
Non-repudiation: My bank wants to be able to prove that I did request each specific transaction. So we ensure the server keeps complete logs, and that the logs contain enough detail to be sure that a passcode has been entered, or in some other way to prove that I requested each transaction.
These are just examples of some of the issues; the full list of security considerations for the financial applications I have helped produce is typically many times this, and our solutions have been many and varied. But I hope you get the idea …
- Charles
Image credit ©istockphoto.com/alengo. Text by Charles Weir, copyright (c) Penrillian Ltd, used by permission.