I am in the process of developing website and an app (iOS and Android) that are supposed to communicate data over https. I don't want the app clients intercepting these server messages, but I'd like to decrypt that data inside the app itelf.
so: after request, encrypt message (say up to 400kb message) (1st encryption), send over https (ssl encryption) (2nd encryption).
upon receive decrypt ssl, on the client level decrypt scrambled message.
(I don't want some bots sniffing my db through https, in disguise of my app).
How do you think I should get around this problem ?
https is ok, I mean, but if someone is sending the requests instead of the app, the whole thing would be useless as I want to protect the DB data.
Any suggestions ? ideas ?
Thanks
All you need here is HTTPS/SSL with client authentication. Adding a second layer of encryption doesn't actually add any security. PKI authentication of the client does.
SSL client authentication will help, as EJP said, but it requires your app to contain an embedded private key, and if someone really wants your data, they can analyze your app and extract that key.
This isn't something you can solve completely: your server cannot reliably distinguish between the real client app, and a fake one designed by someone who reverse-engineered the real one to imitate it.
Depending on the app, you may be able to transfer some of the work to the server side. In other words, don't expose the raw data to the app, just expose the parts that the app is allowed to display. That way an attacker can't get anything by spoofing the app that they couldn't have gotten by just using the real one.
I actually came up with the idea to encrypt the request rather then the response.
this way a user can't spoof and send requests to the db.
I just thought that doing the encryption again might be doing too much for too little.
Related
I'm implementing 2FA on my app with phone number verification. As SMS are not free, I really need to ensure that a request to my server comes from my app and not from any third party http request launcher.
For this purpose, I thought about encrypting the http request with a key provided by my server within my app, and send that encrypted request. As my app is a binary (this is not applicable for web of course), I was thinking it would be difficult to see the encrypting method. The process would be the following :
my app asks my server a key
my server generates, stores and returns a random key
app encrypt the whole actual request with a "secret" method, depending on that key (secret = in binary so hardly readable)
app send to server the encrypted request + the key
The server sees if the key exists, and tries to decrypt the request. If it manages to decrypt, it proceed the request, and then remove the key from its storage so no one can use it anymore.
I don't see any to compromise this system, except if someone manage to read from apple/android binary app the encrypting system the app uses.
Do you think this can be a good process ? Do you see any way to compromise this system ? Is reading from a binary file is really difficult ?
I will start with the flaws in your design, from an android perspective, even if you have enabled pro-guard for your app, we can still decompile the app and trace back the api calls
If your server is not using HTTPS - its easy to trace the calls going
back to the backend server by routing through a proxy server like
charles proxy, and analysing the response, even if you are using
https its possible to install ssl certificates to trust the proxy and
get the response. Also by analyzing the outbound requests its
possible to extract the signed key from the app
Its easy to decompile an apk package and opening it in IDEs and
searching for the backend server url by inputting 'api' or
'http','https' keywords on the ide project search window
If you are storing the secrets in shared preferences or storage, it
can be read from the device ,if the attacker has root access to file
system.
then remove the key from its storage so no one can use it anymore.
For the above scenario, i will run the app and once it stores the key , i can change the permission to read only , so even if the app tries to remove it , it wont be deleted
You can use SSL-Pinning, and putting the keys in compiled libraries making it difficult for the attacker to decrypt the key, also you need to make sure that you don't create any other loop holes
You may also share the common key between app and server through alternate channel , like an email . Where the user once he registers for the App gets and Email with a QR code which once scanned will give the server key. The security of this approach is tied to the secure access of the email by authorized user.
You may them follow the standard approach of sending the encrypted request to server to verify the phone number , once done you may delete the data form your app storage.
I am considering installing SSL/TLS for my domain. There are two questions that have been bothering me:
Is there any scenario where a https connection can fallback to http? So, for e.g. if my ajax looks something like this
$.post("https://foo.com", function(){
});
Is there any chance this could change to
$.post("http://foo.com", function(){
});
and even if it does would my domain be still accesible at http://foo.com ?
Next I have read extensively about using SSL/TLS and from what I have read it seems to be fairly accurate to assume that if I have this enabled and even if I send the user credentials in plain text, it's still secure (There would be encryption with salt and everything on the server of course). To what extent is this true and would creating a hash on the client and then sending it over https be any more secure?
Update: If sending plaintext over SSL is secure enough, then what really is the point of using things like cnonce ? Isn't it just unnecessary overhead on the client?
No, HTTPS never falls back to HTTP automatically. It would take deliberate action by the user. If you're just going to a web page by putting its URL into the address bar, this is easy; for form submission it's harder.
Yes, sending plain text over SSL is fine. In fact, sending a hashed password doesn't really increase security much at all -- if someone manages to sniff the connection and gets the hashed password, that's all they need to be able to login to the site. It has one small advantage: if the user uses the same password at multiple sites, learning the hashed password for one site doesn't help them get into another site that uses a different (or no) hash. And it's not likely to be feasible to send salted hashes, since the client doesn't know the salt.
A cnonce adds an extra level of protection. If, somehow, someone manages to crack the SSL encryption, the cnonce prevents them from getting a usable password from it. This basically addresses the point I made above about why sending a hashed password doesn't help: what you need is something that changes from session to session, and a cnonce provides this.
See https://security.stackexchange.com/questions/3001/what-is-the-use-of-a-client-nonce
I am planning to implement API security in my REST application, Where i need work for authorization URL (on server PHP application) which will return a session token to client (mobile clients android, iphone, BB, wp7, wp8)requesting this url.
After looking for possible solutions i found these two perfect for my needs. but i am not able to decide on solution which will survive me on long runs.
Using RSA encryption with openssl for transferring user data to authorization URL (i am going with openssl just to stick with standard and secure method).
I have a hunch that it's possible to just use HTTPS to pass the user data and let OS handle encryption/decryption.
However, I am particularly inclined to first approach, since here client will not be able to make successful call to authorization url unless it has access to public key. But i am not sure about how well this approach will gel with all mobile clients.
Any help on this is much appreciated!..
You should be ok when sending the authentication URL over SSL. SSL will authenticate the server and make sure that the data is protected against eavesdropping and man in the middle attacks. The URL will then be send over this protected channel, so after verifying the URL, the server can determine that the client is indeed the right entity. The token can then be safely send to the client over the same SSL session
If you go with your own scheme you will have to setup your own key management scheme and protocol. This is extremely hard to get right. Your comment on having access on a public key is a good indication that you will fail. SSL is not perfect either, but it has had a lot of scrutiny, and chances of it failing out of the blue are slim.
In other words, choose #2 over #1.
So feel free to not only answer this question but to throw out suggestions or improvements. I've never put together a large scale web application before. Here's my thought process:
Persistence Layer: Standard Database (MySQL right now)
Business Logic Layer: REST-like structure (PHP, Java Servlets, etc...)
Presentation Layer: Web Browser, Android devices (application not browser), and others
The reason I selected this architecture is so that devices can devise their own custom UI's and tap into the REST-like functionality by using GET, POST, and what not to interact with the server.
Problem 1:
The problem is, how do you secure user's information? You can authenticate the user over an SSL connection and return a special HASH so that the user can manipulate their account but if someone is listening on the network, all they have to do is listen for a REST call and steal the HASH. One solution is that all REST-like calls have to be over SSL, but this causes another problem.
Problem 2:
If the REST procedures are in SSL, the browser has to use SSL for everything which from my understanding can be slow and cumbersome when unnecessary. Also, SOP makes it impossible to use SSL ajax calls to the REST procedures from an unsecure browser. HTTP and HTTPS are considered different origins even though its the same origin, different protocol.
Is this solution viable? How would I solve these two problems? Or possibly (probably) is there a better architecture I should look into for my web application. Thanks in advance for all suggestions.
If you want to secure the information you have to use SSL, since anybody can listen the network, and see the user information. If you want to secure the access, then use HTTP authentication RFC2617. Over SSL, Basic is secure enough, but if you don't want to use SSL for every request, Digest is the way to go:
your application can be stateless: i.e. more restful, easier load balancing, ...
the authentication token can hardly be reused if listen (no session hijacking)
almost every HTTP client (browser or lib) can use basic or digest HTTP authentication.
As it turns out, there is actually no great solution out there for this answer. You can either protect everything with SSL or devise your own home brew authentication system. A common method is to send the user a unique HASH, store the HASH in the database and in a cookie on the client's machine. Then only that user's IP, User-Agent, etc.. will be authenticated to that cookie.
So the answer is yes, the solution is viable. Extra security precautions will need to be maintained in order to disallow account hijacking. SSL for login will protected the password. A unique hash will allow the user to continue being authenticated without giving away their password to the account. Storing a large amount of information about the user such as IP, browser agent, etc... will disallow easy hijacking of an account.
I have Android app that talks to .net 2 webservice (IIS7) using http get and managed to make it run on https using self-signed server certificate (but not requiring client certificate).
I see all http traffic is encrypted and it looks secure.
Now what options would I have on how to authenticate client? For example, I like to block webservice access from internet explorer on PC.
Client-authenticated TLS handshake described here would be a way to go?
Then how can I accomplish that? Some advice or example will be appreciated.
Well, given that each user should authenticate anyhow, you probably want to setup some sort of per-user authentication strategy for a variety of reasons. First, given this might be a widely distributed app, having a single "gold master" authentication certificate or credentials will ultimately fail as someone will hack it -- either grabbing the cert or grabbing the account. And then what do you do? Second, its not particularly hard to handle. You can easily use ASP.NET membership to back it, and then take the credentials a number of ways depending on the nature of the service. Third, it is alot easier to manage than client certificates.