I'm working on an app that has PHP classes to connect to the web server for login and other database transactions, and SQLite serves as a local db to store user credentials.
I'm not sure if the SQLite maintains the user session or not but it keeps the login status until the user clicks on the logout button.
How would I implement the session(or something) so that the user can make other database transactions based on the user ID throughout the states?
Some say to establish session in PHP and other say to use preferences.
What would be the best solution for me?
Maybe I shouldn't ask that but, well, are your webservices RESTful or not ?
If they are, I read a lot of discussions about not keeping user sessions on the server, but instead authenticate user at each request (using his credentials or more secured authorization systems).
Otherwise, yes, you can just create PHP sessions server-side when a user is authenticating. You store the session in a specific table, containing a fk_user_id field, and you send back the session_id to the client application (android app in your case) once the authentication process is over. Then the session_id is stored (in user-preferences for example), and sent along with each request in order to retrieve who is asking data, thanks to the sessions table and its fk_user_id field.
Related
I am integrating log in in my app. There is a requirement for log in without internet connection. Means first time when user gets login there will be a web service call for log in authentication but next time the web service call should not be needed it should authenticate from local db of device. First time on log in response I am saving user credentials in local db (means device db using sqlite) and for rest of the attempts I am matching credentials from local db for authentication. For authentication, password is a plan text in local db and I am matching plan passwords. It this good idea/approach to match password as a plan text or I am supposed to be using any encryption? If encryption is required so why is it needed so. I mean when db file is stored internally no one can fetch password.So why encryption is needed?
Never ever store passwords in plain text anywhere. Event when it's local and nobody has access to it.
The better approach is storing it using a hashing algorithm along with salt so the if password is leaked somewhere, no harm should come of it.
You can then hash the input password with the same algorithm and verify it with one you have previously stored.
Here are some links to get you started on hashing:
https://crackstation.net/hashing-security.htm
http://howtodoinjava.com/security/how-to-generate-secure-password-hash-md5-sha-pbkdf2-bcrypt-examples/
Which of the following ways is better to allow user to login once and avoid logging in again on next app launch?
1) Store just UserID and then just every time fetch data from server and load profile? (Problem: userID can be manipulated in SharedPreferences so user can easily hijack other users identity)
2) Store username and password in SharedPreferences then just auth user on every app launch and get users data from server? (Is this safe enough? )
3) On first login from device - store deviceID in online database and store userID in SharedPreferences, then on every app launch compare deviceID's and if matches = Fetch data and login automatically or if not matching = request login again?
Is there any better way perhaps? I would like to avoid using SQLite as for my app I have no need for database, my app is online MySQL database related and it's constantly communicating with it rather than having local database.
You could also send back a large meaningless id (such as a GUID) from the server on login. The server would store it in a list of valid login credentials. Store it on the phone also and send it back to the server for authentication. There would be no way to forge an id since it cannot be derived from any other information, and the chances of guessing one would be miniscule.
1) and 2) should never be done as it compromises on the security and any one with read/write privileges can easily view the sensitive information.
3) could work but not with the device id since that can also be manipulated on rooting. I would suggest you use the userid+password+deviceid to generate a hash and store that in your database. Consequently whenever you make any calls to your server use this hash to authenticate the user.
About fetching the data you need not do it every time. If the data is not very sensitive you can store it in your shared preferences and use it to reduce the network calls. You can use this to show the screen which opens on first time usage and consequently fetch additional data by making a network request. It would also not interfere with the user experience
I'm building an android app that needs to authenticate with a php service. My current approach is when the user initially logs in, a unique id is generated using uniqid(). This uid is then stored in a table on the database along with their username.The user is then passed back this uid.
Subsequently all further requests to the server will send the the uid and their username, which will be then checked in the database to authenticate the user.
Is this approach OK? or are their massive security holes that I am missing?
A few problems here. For one uniqid() is almost entirely made up of a timestamp and there for very predictable. Instead of just reinventing the wheel you should just use PHP's session_start(). If for some reason you can't use PHP's sessions, then generate a session id using session_id().
Other problems, if your application suffers from sql injection then an attacker can pull the session id out of the database and just login. The reason why passwords are hashed is to slow down an attacker after the database has been compromised, if the attacker has the session id then he doesn't have to crack a password hash to login. (You are hashing passwords right...) One option is to use MySQL's aes_encrypt() on the stored session id's.
Im using MySQL with PDO PHP scripts to maintain a user database and a highscore database.
When a user obtains a new highscore in the Android app, I send it to the server:
https://domain.com/phpscript.php?user=username&newhighscore=highscore
In here username and highscore are variables. Every web browser can access this url. If anyone decompiles my app they will know where my database is located and they can fake their highscore. Obfuscation and encryption for the url is probably not an option since they can always be reversed.
Is there any way I can protect these URLS so ONLY my Android app can access these pages, and not just any browser?
If a call to https://domain.com/phpscript.php?user=username&newhighscore=highscore is all you need to update the highscore for a user, you are in deep sh*t.
You need some sort of authentication - which is what you might mean with "ONLY my Android app can access these pages", here are a few ideas:
On first start of you app call another script to facilitate exchange of some token. Store this token in your app and in your server-sided DB and use it as a verification token, e.g. https://domain.com/phpscript.php?user=username&newhighscore=highscore&salt=abc&auth=xyz with abc being a random salt and xyz something like hash(encrypt("user=username&newhighscore=highscore",key=token,iv=salt)+salt)
use the phone ID as part of the authentication scheme
I need some advise.
I have a mobile application (Android) and a WebService for it.
When application starts first time - user does some registration process. Then he has a username(Unique). The server give the user a unique userId for internal purposes.
In some features of the application - the user sends requests to the webservice that needs the UserId.
I thought to sends for these request the username and not the userId - meaning that the application will never have the internal userIds, always send the username and the webservice will find the userId itself..... Guess it is better for security issues, disadvantage is that it takes more time in the server side.
Any ideas?
Comments?
For me it makes more since to store both in the android application and use the userid to make requests. I'm not aware of any unsecure aspects of sending the userid. If anything it seems less secure to accept a username because anyone has access to the list of usernames and if they found the service endpoint could possible figure out how to send it someone else's username and retrive info. The userid on the other hand is hidden from the users.