Skip to main content
added 925 characters in body
Source Link
Walfrat
  • 426
  • 2
  • 12

We don't know where your server credential are stored.

But obfuscation is about the code, not the data of various non-code file or memory. And even if your credentials are hardcoded, they won't be changed by an obsfucator.

Whatever the way your credential are handled at some point those credential will be load up into memory before being sent to your server for authentication. Which mean as long as someone can have access to the full memory (running a android simulator for instance) they could get those credentials.

Also if you're not using SSL to communicate with your server, simply listening the network will permit to catch those credential.

The main question is, why are you using those server credentials ? To limit the access of your API to your server against simple bot or against the FBI ? As long someone is motivated enough, he will be able to figure out your API. But do you really need to protect let's say against a state agent trying to crack you ? You will lose.

Security is about risk management, so first determine what reasonable risk you want to handle.

Edit : about the TCP/IP connexion

There isn't much I can answer from this, however if you want to protect the privacy of your users, then your server credentials aren't enough. To me the only point of your server credentials is to disallow an easy access to your server API.

Now if you want to protect the data of your user from another user (from the point of view of your server), then your user should have their own login/password that grant them access to their data from your app. And your server code must make it not possible to access user datas if not authenticated as the correct user when using the public API.

Of course as an administrator you might need access for administration purpose (debug, check backups, stats,...). But then it would be preferable that those aren't part of the publicily exposed API, instead you could setup a protected SSH connexion and do your stuff when directly connected to your server.

I don't think there is much more I can say.

We don't know where your server credential are stored.

But obfuscation is about the code, not the data of various non-code file or memory. And even if your credentials are hardcoded, they won't be changed by an obsfucator.

Whatever the way your credential are handled at some point those credential will be load up into memory before being sent to your server for authentication. Which mean as long as someone can have access to the full memory (running a android simulator for instance) they could get those credentials.

Also if you're not using SSL to communicate with your server, simply listening the network will permit to catch those credential.

The main question is, why are you using those server credentials ? To limit the access of your API to your server against simple bot or against the FBI ? As long someone is motivated enough, he will be able to figure out your API. But do you really need to protect let's say against a state agent trying to crack you ? You will lose.

Security is about risk management, so first determine what reasonable risk you want to handle.

We don't know where your server credential are stored.

But obfuscation is about the code, not the data of various non-code file or memory. And even if your credentials are hardcoded, they won't be changed by an obsfucator.

Whatever the way your credential are handled at some point those credential will be load up into memory before being sent to your server for authentication. Which mean as long as someone can have access to the full memory (running a android simulator for instance) they could get those credentials.

Also if you're not using SSL to communicate with your server, simply listening the network will permit to catch those credential.

The main question is, why are you using those server credentials ? To limit the access of your API to your server against simple bot or against the FBI ? As long someone is motivated enough, he will be able to figure out your API. But do you really need to protect let's say against a state agent trying to crack you ? You will lose.

Security is about risk management, so first determine what reasonable risk you want to handle.

Edit : about the TCP/IP connexion

There isn't much I can answer from this, however if you want to protect the privacy of your users, then your server credentials aren't enough. To me the only point of your server credentials is to disallow an easy access to your server API.

Now if you want to protect the data of your user from another user (from the point of view of your server), then your user should have their own login/password that grant them access to their data from your app. And your server code must make it not possible to access user datas if not authenticated as the correct user when using the public API.

Of course as an administrator you might need access for administration purpose (debug, check backups, stats,...). But then it would be preferable that those aren't part of the publicily exposed API, instead you could setup a protected SSH connexion and do your stuff when directly connected to your server.

I don't think there is much more I can say.

Source Link
Walfrat
  • 426
  • 2
  • 12

We don't know where your server credential are stored.

But obfuscation is about the code, not the data of various non-code file or memory. And even if your credentials are hardcoded, they won't be changed by an obsfucator.

Whatever the way your credential are handled at some point those credential will be load up into memory before being sent to your server for authentication. Which mean as long as someone can have access to the full memory (running a android simulator for instance) they could get those credentials.

Also if you're not using SSL to communicate with your server, simply listening the network will permit to catch those credential.

The main question is, why are you using those server credentials ? To limit the access of your API to your server against simple bot or against the FBI ? As long someone is motivated enough, he will be able to figure out your API. But do you really need to protect let's say against a state agent trying to crack you ? You will lose.

Security is about risk management, so first determine what reasonable risk you want to handle.