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.
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 have a stateful php web application made in Symfony that uses cookies to keep alive the session of the logged user in the application(I have worked always like that, I'm really new in REST services).
I'm making a REST API using the business logic of this web application, so I can use it in different environments (Android at the moment).
In order to keep private the API, I follow the symfony cookbook(http://symfony.com/doc/current/cookbook/security/api_key_authentication.html), so the requests are served through a 'apikey' sent in header of every request.
At the moment, this 'apikey' is a dummy string hardcoded in my android code.
What I first thought to do with this 'apikey' is a login screen in Android that send to the API an user and password, those credential will be checked on the server side and if they are correct, send to the client a 'apikey'(based on those credentials) and then, somehow, store it in the client and then send it in header of every request of the API.
I'm misunderstanding something with this 'apikey' method? (probably yes, while I'm writting this it seems to me that this apikey is a more 'static' concept).
Isn't this idea a kind of 'stateful' that is against REST pattern? I mean, I keep stored something that is checked on every request.
What I want to achieve is to have a login in Android, check credentials in server side and then(if this check is ok) let the android app make calls to the API in a secure way...
How I should proceed then?
Thank you for your time!
I'm also learning such things with Android and Symfony. What i've come to understand is your API Key should be unique to every user, meaning that every user should have, as subscribed to your website, an API Key, which represents them. It will work like a unique login, except that using REST, you only need the API Key to be authentificated, instead of a login and a password.
In this case, your API Key should be hard to find. I guess you should use the user's ID and login, since they have to be both unique identifier, and make something out of it, like encrypting.
If you've learn more since, it'd be a pleasure to hear from you experience.
I've implemented the ApiKey "mode" in my Symfony web app.
From my perspective, after correct user connection (using login and password), you can generate a key resulting in the sha1 encryption of the concatation of any unique user info with the result of uniqid.
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..
This is more of a procedure question question than a code fault one so please be kind if I have posted in the wrong place.
I have successfully authenticated a gplus user client-side so the browser is holding the google id ready for me to use. I now want to post some data to my website with that id as the user id but i want to protect it meaning I don't want just anyone with someone else's gplus id to be able to post to my web app (it has to be the authenticated user at that time).
Should I install the php serverside sdk and use that? If so how do i merge the client-side data with that?
Thanks
You're absolutely right about wanting to get the ID in a secure manner to make it hard to impersonate. There are two main options, both properties of the authResult object that comes back to the sign in callback:
Send the 'code' to the server. This is part of the OAuth 2.0 flow, and can be exchanged on the server side for an access token. From that you can make API calls as the user, and retrieve the user ID and other details. You can be confident who the user is, as only Google could have generated that code. This would involve using one of the client libraries to handle the token exchange.
Use the id_token. This is a base64 encoded blob of JSON which includes the user ID (and email address if you requested the 'email' scope). What makes it secure is that it includes a cryptographic signature, which the server can verify, so it cannot be created by someone other than Google. The id token can be used to get the user ID, and so can be used for looking up the user on the server, but doesn't give access to make API calls. The benefit is that it only requires up to date certificates for verification which don't change that often, so most calls require no further network traffic from the server to verify the user.
Which you use is up to you, but both will require some code on the server. In general, if you don't need to call any Google APIs from the server, or are concerned about maximum login performance then use the id_token. There's a bit more about that sort of architecture here: http://www.riskcompletefailure.com/2013/11/client-server-authentication-with-id.html
You can even combine the two. The first time a user signs in (when they see the consent screen) the code exchange will return not just an access token (for making calls), but also a long-lived refresh token, which you can store securely in a database. If you store that, you can use the id_token to look up the user quickly, but still use the refresh token to help with API access.
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.