I am starting this thread to just explain the basics of implementing security in your application.
No matter how good or successful your application is, if you have bad security, you are waiting for a night-mare to happen. This would be informal. You can ask questions. I may use examples of applications i have tested by developers here but will leave their identity anonymous.
One of my areas of interest as a software developer has always been security. The thing is there is really no "Unbreakable app". No matter how secure your application is, someone somewhere will be able to break. The whole idea of security is to limit the surface area for attack. Reduce the probability of your software ever getting hacked into. I will start with a very simple analogy of an app i was once hired to create a bot for.

Lesson 1:
Never ever ever implement your own security algorithm
Except your have a phd in mathematics and security. Its always better to use the popular and well tested security algorithms.
The thing about security is that you don't have an exclusive right to it.
Analogy:
Developer A was contracted for a job to build a mobile app to secure data on mobile devices. Developer A has been building applications for quiet sometime. He decides that he has the experience to implement his own security algorithm and uses this algorithm to secure the data within his app. The data on the app is the companies selling point. They sell the data to people and cant afford people have free access to it.

Best Approach:
It would be better for Developer A to implement security using a known algorithm like AES. The key should be kept on the server and be unique per client. This means that each client has their own key. So in case one key is compromised, its local to that specific client.
Also, he should have a way to identify the clients mobile device. UDID worked for a while, but right now UDID has become more compromised. Apple for a long time has been against the use of the device UDID and has actually blocked access to it in recent times.
Developer A can generate his own unique device identifier on the device. He may send a copy to the server or have a way for the server to know how to compute the identifier.

Waiting for comments to indicate interest. Positive comments.

I'm enjoying the lesson so please continue

seunthomas:

Except you have a phd in mathematics and security. Its always better to use the popular and well tested security algorithms.

Not even mathematics or general security, cryptography to be more specific and sometimes using the more popular ones may raise concerns because that means even the hacker probably has the opportunity to try and exploit it, e.g: Most people still use MD5 for password hashing when password_hash() is available because the former is more popular than the latter[php]

#following

I'm following.

Real Life Case Study
Study A: Apple
For so many years, i have been intrigued about icloud security. So i go ahead and start doing research on how to break icloud security. Currently as of today its practically impossible to bypass icloud security using any hacking tools. The only way that an icloud locked iphone can be activated is if apple unlocks it from their end (their are other ways that involve removing a chip from the device). Most of us may have heard the FBI VS Apple case. With the resources at the disposal of the FBI, they still needed to contact Apple. This is because, the data is stored by Apple and only if a proper and correct TLS handshake is achieved can the data be retrieved from the icloud servers. Even Apple internal staff cant access this data from their own end. Please note this method is not full proof but it creates so many constraints that only a very persistent attacker can compromise an I-device. They would need a lot of hardware and technical resources to do this.

Study B: Legal Company ESQ(Fictious Company)
Legal Company B used in house secuity algorithm for their app. Also the app was byte compiled within 5 mins, John Hackinton was able to reverse engineer the app and their in house algorithm. He had all their data in less than an hour.


So please never use self-written security algorithms. The best way to go about it is to adopt and use well tested and known public domain security alorithms.

Lesson 2: In the beginning was security.....
This is sometimes another issue in application development.

Most times we start developing an app and we decide to leave security for the last stage.

Then at that stage we are left with no choice but to implement a very weak security.

Wise develops start up their application development by putting in security considerations first.

If the application has sensitive data, then security must come in first.

You need to alight and possible list all the areas of attack on your application.

a. Does your application write to database?

b. Does the application access data from an unsecure source.

c. Do you implement SSL (Today using SSL must be the default for any application getting data from a webservice/api)?

d. Is the webserver/api open to DDOS/DOS(Distributed Denial of Service/Denial of Service)?

e. Can an intelligent attacker reverse engineer your application and reimplement your app?


You must consider all this and look for solutions and then build this solution into your app.

Its no longer wise to send unencrypted data over SSL. Even with SSL pinning, its still possible for Man in the middle attacks. So when sending sensitive data over a network, use SSL as well as encrypt the data on the client side.

seunthomas:
Lesson 2: In the beginning was security.....
This is sometimes another issue in application development.

Most times we start developing an app and we decide to leave security for the last stage.

Then at that stage we are left with no choice but to implement a very weak security.

Wise develops start up their application development by putting in security considerations first.

If the application has sensitive data, then security must come in first.

You need to alight and possible list all the areas of attack on your application.

a. Does your application write to database?

b. Does the application access data from an unsecure source.

c. Do you implement SSL (Today using SSL must be the default for any application getting data from a webservice/api)?

d. Is the webserver/api open to DDOS/DOS(Distributed Denial of Service/Denial of Service)?

e. Can an intelligent attacker reverse engineer your application and reimplement your app?


You must consider all this and look for solutions and then build this solution into your app.

Its no longer wise to send unencrypted data over SSL. Even with SSL pinning, its still possible for Man in the middle attacks. So when sending sensitive data over a network, use SSL as well as encrypt the data on the client side.

And also encrypt and filter on the server-side too to prevent attacks like SQL injection.

seunthomas:
Lesson 2: In the beginning was security.....
This is sometimes another issue in application development.

Most times we start developing an app and we decide to leave security for the last stage.

Then at that stage we are left with no choice but to implement a very weak security.

Wise develops start up their application development by putting in security considerations first.

If the application has sensitive data, then security must come in first.

You need to alight and possible list all the areas of attack on your application.

a. Does your application write to database?

b. Does the application access data from an unsecure source.

c. Do you implement SSL (Today using SSL must be the default for any application getting data from a webservice/api)?

d. Is the webserver/api open to DDOS/DOS(Distributed Denial of Service/Denial of Service)?

e. Can an intelligent attacker reverse engineer your application and reimplement your app?


You must consider all this and look for solutions and then build this solution into your app.

Its no longer wise to send unencrypted data over SSL. Even with SSL pinning, its still possible for Man in the middle attacks. So when sending sensitive data over a network, use SSL as well as encrypt the data on the client side.

I don't really get the DDOS part..... All servers are open to this attack

Also all Apps can be reverse Engineered.... there's no stopping it.... only difference is difficulty, but even at that, from my experience, the security on this is maxed out

So I'm thinking should we really bother about this unstoppable factors

FincoApps:


I don't really get the DDOS part..... All servers are open to this attack

Also all Apps can be reverse Engineered.... there's no stopping it.... only difference is difficulty, but even at that, from my experience, the security on this is maxed out

So I'm thinking should we really bother about this unstoppable factors

Yesterday, i took an app belonging to someone in this forum and reversed engineered it under 5mins.

He is also a top contributor here. He has some documents in the app which he encrypted with self-written encryption.

The security considerations in this thread is actually the default(basic) if you handling any form of important content.

Be it documents you are selling to people etc.

You can reverse engineer most apps but some apps are very difficult to reverse engineer. On android, use c/c++ to build very critical sections of your code. On IOS and windows, its more difficult to reverse engineer.

If you read my introduction in this thread "The thing is there is really no 'Unbreakable app'."

The concept of an 'Unbreakable app' does not exist.

But while some apps will take 5 mins to reverse engineer some may take 5 months and by that time the company using that app has moved on to something else.

Also DDOS and DOS are preventable and could be really limited. We have managed security companies that can help with that but if you want an internally developed solution then we have open source projects that can help out.


So i will continue with this thread later in the day. Anymore questions ??

seunthomas:


Yesterday, i took an app belonging to someone in this forum and reversed engineered it under 5mins.

He is also a top contributor here. He has some documents in the app which he encrypted with self-written encryption.

The security considerations in this thread is actually the default(basic) if you handling any form of important content.

Be it documents you are selling to people etc.

You can reverse engineer most apps but some apps are very difficult to reverse engineer. On android, use c/c++ to build very critical sections of your code. On IOS and windows, its more difficult to reverse engineer.

If you read my introduction in this thread "The thing is there is really no 'Unbreakable app'."

The concept of an 'Unbreakable app' does not exist.

But while some apps will take 5 mins to reverse engineer some may take 5 months and by that time the company using that app has moved on to something else.

Also DDOS and DOS are preventable and could be really limited. We have managed security companies that can help with that but if you want an internally developed solution then we have open source projects that can help out.


So i will continue with this thread later in the day. Anymore questions ??

Well while you are correct about this, I'm not really talking about decompiling the app itself.
What I meant is that the communication between your App and the server can always be reverse engineered and faked.

e. Can an intelligent attacker reverse engineer your application and reimplement your app?

ie, you can create your own version of the App and deceive the server by making it think requests are coming from the original App..... This was what I thought you meant when you said "reimplement your app" that's how all these 3rd party Instagrm, Fb, WhatsApp apps on BlackBerry work.... The explanation I gave is actually impossible to counter now but can still be made difficult like you said. I wouldn't bother too much about it

FincoApps:


I don't really get the DDOS part..... All servers are open to this attack

Also all Apps can be reverse Engineered.... there's no stopping it.... only difference is difficulty, but even at that, from my experience, the security on this is maxed out

So I'm thinking should we really bother about this unstoppable factors

For DDoS, the best approach is to have multiple relay servers so that when you're attacked another server can replace the attacked one, by the time they hit the second server the fault should have been detected by the engineers in the particular data center. People that use shared-hosting suffer the most due to lack of total control of the server.
I hope I spoke a little sense..

DanielTheGeek:


For DDoS, the best approach is to have multiple relay servers so that when you're attacked another server can replace the attacked one, by the time they hit the second server the fault should have been detected by the engineers in the particular data center. People that use shared-hosting suffer the most due to lack of total control of the server.
I hope I spoke a little sense..

Yeaaa alot actually

I'm so loving this
All our favourite badoos in one place
where's larisoft and dhtml18?

Actually there a number of ways to of foiling a DDOS attack. Multiple servers is the last resort. There are newer techniques of user request throttling that cant lower the frequency of requests to the server.
Lesson 3 starts tonight. Stay tuned.

following

seunthomas:
Actually there a number of ways to of foiling a DDOS attack. Multiple servers is the last resort. There are newer techniques of user request throttling that cant lower the frequency of requests to the server.
Lesson 3 starts tonight. Stay tuned.

Yeah, you're right...where did all these experience come from? What's your stack?

Lesson 3: Logging is in your friend
Although this is outside security concerns for an application.

But Logging the interactions on your application and having it saved in a central repository can help you better understand and attack and prevent it in future.

In most times large companies are hacked or their applications compromised, the first thing they do is to check the logs.

From the logs, they can identify the attack as well as how they compromised their systems.

In cases where there are no logs, such a company can not be able to prevent such and attack in the future.

seunthomas:
Lesson 3: Logging is in your friend
Although this is outside security concerns for an application.

But Logging the interactions on your application and having it saved in a central repository can help you better understand and attack and prevent it in future.

In most times large companies are hacked or their applications compromised, the first thing they do is to check the logs.

From the logs, they can identify the attack as well as how they compromised their systems.

In cases where there are no logs, such a company can not be able to prevent such and attack in the future.

I am following.

bros abeg come and continue this matter.

i think DOS and DDOS should not be the concern of developers as this should be handled by network and system admins where the app is hosted. it should be the job of server managers to detect and foil this vector of attack, plus most app frameworks have flood control techniques and user throttling to handle unusual high requests.

Good Job is really going on here. I have some questions Boss. As a mobile app developer -Android, i am a noob when it comes to security, and it bother me alot. i have a software that communicate with a rest service, and i dont want some hackers to abuse my Rest Api, lets say i have a php file that handles user login with an address like --http://www.example.com/rest/login.php?user=username&pass=password, someone can just reverse engineer my app, copy the url, paste it inside a browser and maybe grab the raw json that was meant to return to the client. How do i prevent this please? Sends token to server on every http request? How do i verify the token on the backend...i have a lot of questions....THANKS.

Interesting. . . . .

Nice job here...

A few contributions...
The developer should as well identify where data flows in and out of his app.
- data going into / out of the db
- data from external source like url
- data going to the ui as well

*validate against what you need; NOT what you do not need.
*treat every data not coming from you as invalid, sanitize and validate as appropriate...

hope this helps as well

lekropasky:
Good Job is really going on here. I have some questions Boss. As a mobile app developer -Android, i am a noob when it comes to security, and it bother me alot. i have a software that communicate with a rest service, and i dont want some hackers to abuse my Rest Api, lets say i have a php file that handles user login with an address like --http://www.example.com/rest/login.php?user=username&pass=password, someone can just reverse engineer my app, copy the url, paste it inside a browser and maybe grab the raw json that was meant to return to the client. How do i prevent this please? Sends token to server on every http request? How do i verify the token on the backend...i have a lot of questions....THANKS.

First of all, using POST request would be better and at least remove the pasting to browser option

Secondly, this issue you just posted is actually not possible to prevent because any determined hacker would be able to reverse Engineer it.... Even Fb, WhatsApp, Twitter, Instagram, Snapchat all cannot stop it... that's why You see apps like Inst10, Snap10, FaceBox... etc all available on BlackBerry

But some ways to make it difficult:

Doing some validations on the server to check the device the request is coming from

Doing some form of Key exchange For example, when a client opens the app, it securely get's an encrypted key and that key is sent with each other request made to the server - (Just a mild sample)

Encrypting the request itself so for example you have
var postData = {};
postData["userid"] = "daddy";
postData["password"] = "finco";
postData["key"] = key;

var request = someEncryptionFunction(postData);

Then send the request variable as your request... the server would then decrypt using a common key

There are more sophisticated ways but trust me, they can all be reverse engineered and to me it's not hard to reverse engineer the communication of Applications with their server

FincoApps:


First of all, using POST request would be better and at least remove the pasting to browser option

Secondly, this issue you just posted is actually not possible to prevent because any determined hacker would be able to reverse Engineer it.... Even Fb, WhatsApp, Twitter, Instagram, Snapchat all cannot stop it... that's why You see apps like Inst10, Snap10, FaceBox... etc all available on BlackBerry

But some ways to make it difficult:

Doing some validations on the server to check the device the request is coming from

Doing some form of Key exchange For example, when a client opens the app, it securely get's an encrypted key and that key is sent with each other request made to the server - (Just a mild sample)

Encrypting the request itself so for example you have
var postData = {};
postData["userid"] = "daddy";
postData["password"] = "finco";
postData["key"] = key;

var request = someEncryptionFunction(postData);

Then send the request variable as your request... the server would then decrypt using a common key

There are more sophisticated ways but trust me, they can all be reverse engineered and to me it's not hard to reverse engineer the communication of Applications with their server

YEAH, thanks bro. Yes, using post request can prevent the request from being made from a browser, but do you know there are apps that works on rooted phones, these apps can sniff all the network request going in-and-out of the particular phone, and a post request can be abuse by using/creating an html form that it action points to your url --<form action ='http://www.example.com/rest/login.php' method = 'POST'>....this form can contain maybe two hidden fields with the username and password as the name, values being the crazy guess they have made. What i am trying to let you understand is that, there is a way to know if a request is being manipulated i.e its not made/comes from your app and thats what am tryna figure out...i hope i make a little sense

lekropasky:
YEAH, thanks bro. Yes, using post request can prevent the request from being made from a browser, but do you know there are apps that works on rooted phones, these apps can sniff all the network request going in-and-out of the particular phone, and a post request can be abuse by using/creating an html form that it action points to your url --<form action ='http://www.example.com/rest/login.php' method = 'POST'>....this form can contain maybe two hidden fields with the username and password as the name, values being the crazy guess they have made. What i am trying to let you understand is that, there is a way to know if a request is being manipulated i.e its not made/comes from your app and thats what am tryna figure out...i hope i make a little sense

I do understand what you are saying....

If you do something similar to man in the Middle attack, you can redirect all requests going from your Phone to your computer and use a tool like Fiddler to analyse, understand or replay these requests....

No App I've touched has been able to survive this method... If the company cares about what you did, their Lawyers would write to you

If there's a way, then it has not been implemented yet, but if you do find a way, please let me know so I can test it too

lekropasky:
Good Job is really going on here. I have some questions Boss. As a mobile app developer -Android, i am a noob when it comes to security, and it bother me alot. i have a software that communicate with a rest service, and i dont want some hackers to abuse my Rest Api, lets say i have a php file that handles user login with an address like --http://www.example.com/rest/login.php?user=username&pass=password, someone can just reverse engineer my app, copy the url, paste it inside a browser and maybe grab the raw json that was meant to return to the client. How do i prevent this please? Sends token to server on every http request? How do i verify the token on the backend...i have a lot of questions....THANKS.

That is what the Oauth authorization framework is meant for, you validate apps by sending them to the Oauth server to validate the app_token and app_scope and make sure the user gave permission to that app/person trying to connect.

By password, I guess you mean the api_secret, you should pass them through Oauth first for initial validation. Get Oauth 2.0 https://oauth.net/2/ . Another thing is, your API doesn't look properly designed (if that's the way it is in production) instead of /rest/login.php... Something like /api/v1.0/users/all... makes more sense, but if your API is private you can hard-code the credentials na, this one is public "ashewo" API... let me know if you need me to explain further.

DanielTheGeek:


That is what the Oauth authorization framework is meant for, you validate apps by sending them to the Oauth server to validate the app_token and app_scope and make sure the user gave permission to that app/person trying to connect.

By password, I guess you mean the api_secret, you should pass them through Oauth first for initial validation. Get Oauth 2.0 https://oauth.net/2/ . Another thing is, your API doesn't look properly designed (if that's the way it is in production) instead of /rest/login.php... Something like /api/v1.0/users/all... makes more sense, but if your API is private you can hard-code the credentials na, this one is public "ashewo" API... let me know if you need me to explain further.

Hmm boss I slightly disagree about the purpose of OAuth. From what I understand, OAuth is an authentication protocol to protect the end users from inputting their details directly on any 3rd party App they are not sure of, then also the other things you said.

OAuth protects users by opening a web browser where the user then logs in directly on the website instead of the App itself and then the other permission process you mentioned and all takes place, this way, a developer like me that would love to store people's Facebook login details for example in my own server would not still be able to get their Password...

So OAuth is not really to guard against spoofing of an app but rather to protect the user.... For example, BlackBerry had some kinda agreement with Facebook before and that's why you can login to the BB Facebook App without going through the OAuth authentication... ie you login directly on the App.... And that's also why Facebook's official App on Android does not use OAuth

FincoApps:


Hmm boss I slightly disagree about the purpose of OAuth. From what I understand, OAuth is an authentication protocol to protect the end users from inputting their details directly on any 3rd party App they are not sure of, then also the other things you said.

OAuth protects users by opening a web browser where the user then logs in directly on the website instead of the App itself and th..

Thanks for pointing that out, but who are we protecting in the first place? The users right?
I think what he'll need will be something similar, since the requests will be coming from the software/app, he can add some sort of randomly generated encryption key that only the server can randomly decode due to a randomly generated unique unlock key used to decipher the key. Please take a little time to see how CodeIgniter's encryption library handles this. Still, this greatly limits the spoofing of your app but not completely, a smart person knows his way around.
So summary is: You generate a random string with a random unlock key and use it to verify the source of the request, decipher on the server side and fetch the required data and POST back in JSON, store the used keys in a database so spoofers can't re-use a key they sniffed.

I don't mind helping him implement it, maybe we should do it together and make it open-source, just maybe.

repeated

Also, @seunthomas already mentioned logging, it seems powerless but it can help you with a whole lot of information. Log every IP that connects to your server alongside the timestamp and other minor details, (there should be a way to know if the request was made from your app). At least, you know who frequently spoofs your app from the log.