When talking about security, we should always remember that this is a never-ending process of development. During this process, all shots are allowed - we use hardware, software, and procedural methods. But it looks like the battle between good and evil never stops, that is why knowing your enemy is extremely important.
Applications now become more vulnerable to a variety of threats, as more apps become accessible via networks. The level of security shows how much safety you’re ready to give the users, and hence, how confident they would feel about your work. This is one of the main points if we touch on the reputation of your startup.
Using your smartphone doesn’t seem a big deal, but the amount of every hour attacks on mobile devices rises each year all over the world. For a developer, this is the field of special attention. Here we work with a so-called “malware” (short for “malicious software”), by which we understand any disruptive software created to damage mobile or computer operations.
There are three areas for developers to take care of:
As for possible consequences, their amount springs up like mushrooms overnight. We consider the most well-spread actions of attackers.
To know better which tendencies exist now in the field of mobile security, we’ll consider a spreadsheet from the last Security Report published by Check Point in spring 2016.
As you’ve probably noticed, stealing credentials and sensitive information is a basic interest for attackers and should the main reason for developers’ concern.
This concrete case is about how an incorrect token can help attackers to get info about all users in your application.
First of all, let's see what is an authentication token. It is an "electronic key" which is used to prove user's identity. Here’s how an authentication token works from the user’s perspective:
Tools which we used for testing this case. (Black box)
The first step is to create a proxy connection in the mobile phone and a sniffing tool.
The second step is to get and save API calls which a user sends from mobile phone to your server when login. For understanding how the backend generates a token, we log in with two different users’ credential.
Login request from the user number one:
Login request from the user number two:
As you can see, we sent two login requests from two different users but with same auth tokens and got them from the server successfully for both requests.
The third step is to get a request from the user profile screen and a response on it from the server.
Request from the profile screen:
Response on it:
A significant issue is that the password is not encrypted in the response. Generally, for this screen, we don't need the password at all.
Now we know how one can get data for the user’s profile and we know that the server sends user's email and an encrypted password in response.Let's just edit this request and try to get a response with data from the other profile. The last request was with user ID 122, now we will send user ID 121.
Voila! We successfully got a response with the credential from another user’s profile.
In the end, it may be noted that any attacker can get credentials of all users in this application.
Feeling safe is one of the basic human needs. And if we live in the mobile era, developers should satisfy this need completely. There are more and more attackers appear all over the world, and methods they use are improved every day. That is why lots of companies now are interested in researching not just past experiences but also future tendencies of possible threats.
It turned out that various types of private information and users’ credentials are in the biggest danger now. Above all, we’re talking about the personality, one of the most important human values. As developers, we create a value but not take it away providing users with a low level of security. The method described in the article is only one among plenty of others, but we hope it could be a reason for you to think about users’ safety even more thoroughly.
If your application connects to a secure server, managing credentials shows your professionalism. Data in foolproof security systems is saved in memory, not on the disk. At the same time, storing usernames and passwords with an access token wouldn’t be a good idea. As your application communicates with lots of people, comfort them with the best you have, including a perfectly built security system.