How do all these mobile apps login users? I did a lot of research and read tutorials but I can't find a definitive answer...
I created an API for my Codeigniter web app using Phil Sturgeon's REST server. Now I need to create a mobile app (for Android and ios) that works with remote data from my web server. (I decided to build my app with Appcelerator.)
My goal is to allow users to log in from my mobile app and make CRUD operations via the REST server API. The API uses HTTP digest access authentication but I'm concerned about security because it sends a username and password over HTTP. Is there a more secure way to authenticated users?
After a user is logged in how will they perform CRUD operations without logging in again?
Security is a matter of trade-offs. You need to answer several question.
How much pain can I put the user through to protect the content?
How valuable is the protected content?
What are the consequences of breached security?
Unless you are storing banking information, confidential/personal information, or the content can be irrevocably altered/deleted, HTTPS with digest authentication are fine.
NOTE: digest does not transmit passwords.
Related
At the moment, my app (Android and UWP) uses Azure Easy Tables. To upload/update/delete items in the easy table, a user has to be authenticated. But I only want them to be able to authenticate in the app.
Is there a way to restrict this authentication process to only accept authentication requests coming from my apps?
There's really no reliable way to authenticate your client. You can use and validate an application key as documented here, but if you're shipping your application with that information, those wouldn't be difficult to extract.
Alternatives are available (different ways to "fingerprint" your app) and while make it a bit more difficult for other clients to use your API, but none of them are foolproof.
Properly authenticating and authorizing the user is sufficient to guarantee that data is only accessible by users with the required permissions, but there's not a way to absolutely guarantee this is done from your client.
As the figure below, did you enable the App Service Authentication option of the Authentication / Authorization tab of your Mobile App to ON and with non-anonymous authenticate way on Azure portal?
If not, please enable it to protect your Mobile App backend endpoints which include Easy Table, and you need to do the more authentication for calling your Mobile App backend. Please see the details at here.
Users sign up in my platform from the mobile app (Android & iOS). Once they have completed a form, I do a RESTful call to my server with the username and password and an API key.
https://api.example.com/v1/users/register
I assume that the API key is not protected since it is embedded in the app, so anyone can actually make that RESTful call and register as many users as they want.
How can I protect this call so that users can sign up ONLY from the mobile app? How do other apps (e.g. Facebook, Twitter,...) solve this problem?
How can I protect this call so that users can sign up ONLY from the
mobile app? How do other apps (e.g. Facebook, Twitter,...) solve this
problem?
There is no way to restrict your RESTful call just for mobile phones. Anybody could emulate that call impersonating a device manipulating headers or whatever. The only way to face this problem is to have a good security protocol design between your app and your backend.
As you mentioned, Facebook and other big companies do not store any API Key since the beginning in their app, instead they allow users to sign up through a website or mobile setting up specific user credentials. These signing ups are protected agains massive registration attacks using anti-bot techniques both from client (CAPTCHA) and server side (source IP + timings). Once those credentials are created and authenticated, their endpoint will return a client specific token which would be valid to make further REST API calls, and only this very user will be authorized to use that token for a limited period of time. One typical approach nowadays is to use Oauth 2.0 as you can see in many public API specifications like: Paypal, Twitter, Facebook, etc. I suggest to research other famous REST API specifications, you can learn a lot from them.
Almost all of known techniques mentioned before like CAPTCHA, server side checks and so on could be defeated by a hacker. However, if you still want to add some additional barriers to avoid unlimited user accounts, one good idea can be to add two-step verification process to verify an account. Unless this process is finished correctly, the user won't be able to use your backend API (apart from the one to authorize the account). Thus, a user may be able to create a few accounts with different phone numbers, but never an unlimited amount of them.
I think you have to devise a flow like reCAPTCHA. Its documentation may give you a hint.
My web server has a REST API. I need to add user authentication to my app, and my thought process behind it is this:
Get the user's username and password from the app form
Encrypt the password and Base64 encode both the username and password
Send the data to the REST API over HTTPS
Web server verifies credentials, returns errors or success
Is this secure? I see a lot of mentions of OAuth2. What is it? What does it do better than my process?
The fact that you used the word "encrypt" for the users password instead of "hash" demonstrates you have fairly limited knowledge about this. This will almost certainly result in you messing up your authentication procedures somewhere along the line and put your users private information at risk.
A really important point about OAuth2 is that it can be used with many existing third party providers (Google, Facebook, Twitter, etc) with minimal effort from you.
You don't need to do anything to store credentials or even authenticate users. The third party takes cares of all of this and simply provides the client with a token (long random string) which is then passed to your server. Your server then talks to the third-party server to make sure the token is valid (and gain any info you need, like the users' name, email address or other information).
You really should consider using it if you can. The big companies put a lot of effort into securing their authentication methods and you gain all of that by making use of it.
A final nice point is that users don't need to create and remember credentials for (yet) another account.
Google has some docs to get you started and includes an OAuth playground to test how it works in practise.
A very basic explanation of OAuth2 is that the user will log into your system, with it encrypting both username and password before sending it, then if it gets authenticated, it will send back a token to the user.
Thereafter, whenever the user tries to contact the web server, it will send this token along with each API call. This is how it makes sure that non-authenticated people can't access your web server.
So basically your current method includes parts of the OAuth2 standard, but not the most important part (The token).
In your situation, how would you stop non-authenticated people from accessing your web server? If the project is small, then the risk of this is not that large.. But for larger companies, this is a real threat that needs to be dealt with.
You should really try to understand the difference between encryption and hashing before providing an authentication portal for your users. There are many different hashing algorithms you can use. I've personally used BCrypt in the past and I have a related SO Question about it as well. You can find implementations of pretty much all the popular algorithms in pretty much all the major high level languages these days.
Obviously if you don't want to do all that you can use an OAuth provider, who will take care of all the hard bits like storing the passwords securely, protecting the database and all the other security aspects for you. There are many reliable OAuth providers, Google, Facebook, Yahoo, etc. etc.
One thing to bear in mind would be the environment in which your app is hosted. OAuth does depend on having a connection available to the OAuth provider's servers every time a user wants to access your app. So, if you are behind a corporate firewall or similar which may block access to websites like Facebook, this might be a big problem.
I personally prefer token based authentication for my API projects. If you're not familiar with token based authentication you can read this SO Question and this link.
The general concept behind a
token-based authentication system is
simple. Allow users to enter their
username and password in order to
obtain a token which allows them to
fetch a specific resource - without
using their username and password.
Once their token has been obtained,
the user can offer the token - which
offers access to a specific resource
for a time period - to the remote
site.
I am developing an app which uses couchDB. When the user opens the app, it will prompt him to enter username and password.
Now my problem is how will I check user authentication in couchDB, I mean how to check if the user is existing user or new user from couch server.
Is there is any secure way for user authentication in CouchDB?
I have to disagree with DHK's answer: the CouchDB _users database is a fine way to do user authentication. You're not managing users in code (which is indeed a bad practice); CouchDB handles all the password salting/hashing/etc. automatically for you. The only thing you need to add is SSL (HTTPS) so that the password isn't sent in the clear. This is a feature, not a bug, since that's what HTTPS was designed for.
I wrote a blog post about CouchDB which talks a lot about authentication, and if you just want to quickly get up and running, this rough draft of a PouchDB plugin shows you how to do simple signup/login/logout operations with CouchDB (look at the code; it's super easy).
The only difference between how that plugin works and how you'll do it on Android is that you can't use cookies. You'll use basic HTTP authentication (https://user:password#mycouch.com:5984), which again is fine as long as you're using SSL. CouchDB has docs on SSL, or you can just put an Nginx proxy in front of it (my preferred solution).
You really should not use the couchDB users as users in your app.
It's also bad practice to store login and database server details in code in your application.
I would setup an API to your couchdb, that shields any passwords from the user but other than that is a pretty transparent API just passing through the views/etc to the actual couchDB instance.
Users would have to authenticate against this API which may in turn use some "api user" data stored in your couchdb to validate that they are genuine, and if not reject the requests.
So I have this ASP.NET MVC 4 web app that behaves pretty much like a web service. The client sends a request, the web service returns a JSON object. Now I'm to the point in which I have to authenticate my users from an Android app. What is the proper way to do this on the client side since I no longer have a web browser to store cookies for me to authenticate with the server. SSL is already taken care of.
I have been thinking of several straight forward ways to authenticate but I'm concerned about having some security vulnerability that I might not be aware of.
Is it OK for me to store the user credentials (username and password) in a SQLite database on the Android phone where the app is installed, and then send those credentials along with every request to the server to authenticate? (I'm thinking of hashing the password before storing it in the database, of course).
Is this approach not safe? How do other apps usually authenticate with their services: like eBay, Facebook and such?
Data saved in the private storage are relatively secure (on a non rooted device at least). This include :
sqlite databases (if not made worldreadable)
SharedPreferences
If you want a better integration with the account manager (e.g. to have the account listed in the device's settings), you can write an AccountAuthenticator. See Creating a Custom Account Type or Write your own Android Authenticator. Not sure about eBay and Facebook, but that's what Firefox Sync and Evernote for example do.
You can use OAuth 2 - many tutorials and implementations are readily available.