I have an Android application and an in-app purchase.
I want to post the user_id s of the ones that purchase it to my remote database via a php file.
I know some clever users can listen to the network and see the address of my php service. They may even find out what variables I am sending.
I know how to encrypt user_id of course. I can do it either with RSA or AES. But I need to keep public key for RSA in the app.
Here is my question: A more clever attacker can easily get the public key and encrypt his user id and post to my web service. How do I prevent this scenario?
I have solved my problem. What i need is to do signature verification on the server side. I just need to send the signature and the signed data to my server.
No one can trick these data. They are coming directly from google.
Once the signature verification is complete I just added the user to my mysql table.
Related
Let's say I have a MySQL database with thousands of user accounts in it. These accounts contain lots of data, but for verification purposes, they each contain a username and a (hashed and salted) password. Now, when a user requests signing in, I will take a username and password from them, transfer it via WSS to a Node.js server then transfer it via HTTPS to a PHP file on another server. On that server I will look up the username in the MySQL database, and if I find an account, I will hash the password and see if it matches that username's password. If they both match, then I want the PHP file to create a "verification token" of sorts, save it (and associate it with the account verified) and send the token back to the Node.js server. I then want the Node.js server to send that token back to the client and for the client to save that token. Now the next time the user connects to the Node.js server via WSS, I want the client to check for an existing token, and if it exists I want it to send that token via WSS to the Node.js server, the Node.js server to send that via HTTPS to a PHP file, and that PHP file to see what account that token belongs to, and complete the sign in...
So I guess my first question would be: Is this a good model? Would this be a good idea, and would this be secure, or should I do this differently?
My second question is: What would be the best way to go about generating this token? Should it be completely random? Should it be a combination of letters+numbers? Should it be a hash of some random values? How should I go about the generation of this "token"?
To clarify, I'm not asking how to build a server or make requests or transfer data or anything of that sort, I'm merely asking what is the most secure way to generate a "token" that can be used as authentication to the same degree that a username+password can be used.
Thanks in advance! I'm sorry if this is a really stupid question.
I think you are describing a JWT. There are several packages implementing this in PHP.
I am developing an Ionic App which consumes data from a Laravel 5 RESTful API. All the connections are protected (GET, POST, etc.) by username/pass and user roles, except the user creation.
My first doubt about security is to disallow connections from outside the App, avoiding thousand of user creations, overloading our server resources.
My idea is, when an user installs the app and opens it for the first time, to create a secret token which will be sent in every connection. Then check the device UUID and the secret token to ensure this is an authorized app.
What do you think of securing the connections this way? There is a better idea?
You need to look a JWT (Jot) JSON web tokens, they will solve the security issue. This can contain user id and other data like access level. Not things like security information or card information.
When a user authenticates Laravel sends them back a JWT which you store in local or session storage this replaces backend sessions.
It is generated by the backend using the parts that can be decrypted by the frontend and using a secret key to encryt the signature, if any of it is tampered with it will fail and deny access.
Every request angular will append the token to the header using a request interceptor and Laravel middleware will decrypt it and allow access to the route they need or return a error code '404' maybe.
If after install this authentication layer you can limit usage at user level on the backend.
But this should sort most of your issues, it a bit of a change in thinking but it does work and it solves a lot of sessions issues you get with ajax calls and it make load balancing easier because all server are looking for a token it can manage.
I was also encountering the same problems. But after search in google for a while I came to the conclusion that you can put up several walls against hacker, but for someone who is hell bend on hacking your app(ninja hacker) will find ways to use your app in malicious ways.
I also came across various ways you can protect your backend server(after google). These step generally make it difficult to use your app maliciously.
You can encrypt strings url using some algorithm and use encrypted string in program ie. https:\google.com\ is encrypted into something like \h09ae\hff00\hebab\h.... then in program String url ="\h09ae\hff00\hebab\h.." This way someone decompiling the app can't find your server backend url. In this case you need to decrypt the string url before you can use it.
Send sensitive data using HTTPS and inside the body of the request
You can verify if request is coming from the device by using google token. For this you will have to use Google API Console. Refer this link for proper android tutorial on this topic.
Lastly, sign key used when you create your apk is unique and ensure that your apk is not tampered with. So generate hash key of your sign key before it is upload to google play and save it in your server and programmatically get hash value of sign key and send it with very request to your backend.
Hope is helps you..
I am writing mobile client for online store. I have written REST API for accessing data on the server. Now I need to authentificate the user.
I have read a lot about this,and came to the simple solution.
Firstly, when user run application first time, he must enter exactly password and login from online store account. In this case password somehow sent to the server and being checked, after that user gets response.
If everything is OK user receives access toke that can be used in the future to access private data. If not, get simple forbid message.
I have some questions here :
What the best way to send password and login for the first time, to get access token. Encrypt password with some algorithm and than send it over simple HTTP or establish HTTPS session and simply use this channel to transfer data over the net. In this case password don't have to be encrypted, use public/private keys provided by HTTPS ?
Is it okey to send this request as POST method over HTTPS, for example using next URL /api/v0/store/auth ? Or it is better to do this another way.
In all cases where HTTPS is used I need self-signed certificate ?
I would be grateful for any help. Thanks in advance.
1 - it is not true that passwords don't have to be encrypted on HTTPS. The best approach would be your server encrypting the plain password just received and then try to authenticate the user, generating a token. This token should only last during this connection.
2 - yes, post method is okay for authentication.
3 - you may use self-signed certificates but if you do the client will probably trigger an alert because it won't recognize your certificate. The correct way should be aquiring a SSL certificate from an authorized provider like VeriSign and others.
I would to implement a secure REST web service for a mobile app (using PHP).
The idea is to avoid the complexity of OAuth, so I've decided to use the HMAC approach.
I've read some articles like this.
Basically what I need to do is this:
[CLIENT] Before making an API request combine a bunch of data it will send (ie. the url params) and hash it with the private key assigned from the server (HASHED_KEY). This data is sent along with some sort of id/key which allows the server to identify who is the sender (ie. client id,or some sort of public id of the user, it does not matter, we'll call it USER_IDENTIFIER). So at the end we have a request URL with HASH_KEY+USER_IDENTIFIER (ie. mywebservice/users/list?hash=[HASH_KEY]&key=[USER_IDENTIFIER]).
[SERVER] Server receive this request, take (using USER_IDENTIFIER) the private key assigned to the user and HASH the same data hashed by client. If both hash keys (generated from client and generated from server) matches request can be trusted and executed.
(We can also avoid replay attacks and add some other security levels but that's the core).
My question is this:
My APIs should also allow user registration.
So there will be a call called /register_user where client should send at least desired username and password.
After that, server should reply with the private key (HASHED_KEY) client will use to encrypt all other requests.
So basically there is a flaw: this first communication is not secure.
How can I handle this?
My idea is to provide a private key for anonymous calls both on server and client which is used to encrypt data when I don't know yet the user identity. It will be used to secure both username+password while making registration call.
Is it okay? Any other solution?
i have two questions...both of them are about security issues on android app..
From my app are photos sent to my ftp server,so i need to have stored ftp,user and pass..what is the best way to to that? I am affraid that these values can be easily read from code by reverse engineering..i was thinking about shared preferences but i think it is not enouhg...or to send request to my server which returns pass to ftp server (this is part of second question:)
In app a communicate with php server (create order then in app biling and finally confirmation that order was already paid...i have to write secure communication between android and php..(now android send json data by post method to php server..so if somebody cinds out url and json format of data..he is could create ordef and confirm it)..in app is no login or registration process..i was thinking abou asymetric cryptography with public key on android and private key on server..or maybe SSL is a solution..i am very confused so any advices are welcome..
I dont know how to secure app whne reverse engineering of apk is possible..
Instead of using FTP create simple API for your application which allows to post an image. That would be better and more secure solution. Android has few built-in methods for HTTP POST requests.
SSL secures just communication between. Most of commonly known applications doesnt store password in files, just use API request to validate credentials and obtain token which will be used in future requests. You can set timeout for this token and create one token per device. This is much safier, because its easier to cancel token than to inform the user that the password was leaked :)
Use well-known solutions as mentioned public-private key with autentification tokens (token generated with private key + device specified data such as DeviceID etc). Do not store passwords, even encrypted ones.