I am trying to develop my first PhoneGap application, using MVC.NET to serve the JSON to the application. I am though in doubt how I can secure the controllers on my MVC.NET application so only PhoneGap applications can post to my server.
I e.g. have a settings controller where the user can update his/her settings, but how would I make sure that no one tampers with it?
I had plans to use the deviceID as the userid, so the user doesn't have to create an account to login, but does this rule out the possibility to make it secure, since I don't Authenticate the user?
You need to use the same sort of authentication/authorization/security mechanisms that you would for any other web site. This means that authorization information shouldn't be passed in the clear (use SSL, encrypted cookies). You should choose authentication information that is difficult to guess or impersonate (user id/reasonable password; I'm guessing device id might be less secure if it's broadcast regularly). You could store this information on the phone, but with varying levels of security, i.e., if someone gets physical access to the phone it's likely that they would be able to access the credentials you store.
You might want to look at the security wiki for more detail/information: http://wiki.phonegap.com/w/page/43660891/Security
Related
I'm developing an iOS app that uses Cognito User Pools / Federated Identities, Mobile Analytics, and S3 to manage various features of the app, and recently I have become concerned for the security of these features. I already use IAM roles to control the services unauthenticated vs authenticated users have access to, but most of these services use strings (e.g. user pool app client id or user pool app client secret for User Pools, or app id for Mobile Analytics) to give the app access to that service.
What are the best practices to securely store these strings on the device to be used when necessary? Is it even necessary to secure these strings since the app is using IAM roles?
If it is necessary to securely store the strings, I have read that using the CommonCrypto library to encrypt strings before putting them in the keychain is best, but I'm not sure what key to use for encryption since my user needs unauthenticated access to those services. Any advice would be tremendously helpful.
This is a common problem to any mobile app. If someone really wants to, it's not difficult to decompile the app and scrape the keys from it. It's great that you are using IAM roles to restrict feature usage. This will limit the blast radius of attackers, but not necessarily prevent them.
Wth user pools you also get a globally unique identifier which can be used with IAM to restrict what S3 you can use key pre-fixes (which act similar to folders) to limit the objects that users can access to pre-fixes with their unique identifier. You can refer to https://mobile.awsblog.com/post/Tx1OSMBRHZVM9V0/Understanding-Amazon-Cognito-Authentication-Part-3-Roles-and-Policies (Using user pools as the provider, which will use the identity id as the prefix). Depending on how you structure your app you could use this so each user can only modify their own objects. I don't think Analytics has any way of restricting like this... because it wouldn't really make sense for it.
As far as securing your ID's there are things you can do to help mitigate, but there is no fool proof way to prevent someone taking it. You could for instance have the app make a call to your server for the ID... but then an attacker could just call the server. You could encrypt it, which might make it more difficult for an attacker to get, but you have to keep the key somewhere and if the app could get it so could someone who decompiles the app. Unless your app users get some sort of password from outside the app and put it in there isn't a complete way to lock it against attackers.
Hope this helps.
Note: This is the first time I'm trying to implement a social login API, so thanks for bearing with me and helping me out!
I am developing a web application and I have a login and registration system already developed. Now, I am thinking of adding Facebook and Google+ login - with a backend. I went through their docs and other tutorials and they require to implement considerably a lot of things.
But, since I have a registration system already, I thought of doing something like this:
Have the social login buttons on the login page.
When the user clicks on a social login button and authorizes the app, the user data is returned from Google+, for example.
Now, instead of proceeding with the OAuth procedure like getting the user ID, secret ID and contacting their server from my server for token verification and getting data, is it possible to just use the data returned (after the user authorizes) and do the normal registration with the registration system that I already have?
These are the advantages that I see in doing this:
No need of extra code or database fields like token ID, etc.
User can add a password to their account whenever they want and login to the site or access their account by logging in through Facebook or Google+ given that they use the same email ID.
It's enough to use the social login providers' API once - the first time the user logs in (which technically registers the user to the site).
I know the advantages are the same when following the full OAuth2 implementation, but what difference does it make?
Now my questions are:
Is it OK to cut short on the social login as mentioned above?
Will I be losing any obvious advantage doing so (given that I already have a registration system in place)?
If yes, is anyone else cutting short on the flow in their website?
The system proposed by you has certain flaws, especially security related flaw. I would give you to the point answer:
You will send data from client after getting it from google+ or other provider and use your registration process implicitly.
This approach is wrong as I myself as an attacker can send you the data from google+ using my clientid for an app. Will you register or login using the info I am sending? I can pretend to be anyone in your system if you do that.
Is it OK to cut short on the social login as mentioned above?
Will I be losing any obvious advantage doing so (given that I already have a registration system in place)?
If yes, is anyone else cutting short on the flow in their website?
No. (see the reason above).
No. You won't be losing advantage as you already have system in place. Most of the sites have a system in place for normal registration. They give oauth login by leveraging it. Some will say that the password is cumbersome or such, but all famous sites provide login and password including SO.
Now the question comes, how to simplify the oauth system given that you already have a system in place.
I recommend this(I would assume Google as a provider) flow with things starting with dot are what you need to do:
You have a Google login button.
User click on Google Button.
The User is redirected to the Google site.
The user gives you permission.
Google redirects and give you a token.
You can now send info and token to your server. (You need to send only token as backend will get info. Otherwise, a user with valid google+ token for your website can send you any info).
Backend verify token and match that "aud" is equal to your client id. Or it can happen via a library. You will need to give only your client id.
Backend get profile info from token in case of Google+(Name, email) while verifying which you can store as part of your registration process or login process if that email already exists. You can store google id of user also. This is useful as some provider like fb don't always provide email for every account. (For some fb don't give email but for majority of cases it give you the email.)
Backend send back session info or jwt token or any other time bounded process which tells that the user is login.
Your user can login via email also. If he isn't already registered then, then he will need to register. Otherwise, using forget, he can set password or from accounts settings he can set password.
You also need to be careful if the same user is connecting via a different provider, he need to have the same account in your system which you can handle via email.
Kevin,
Authentication is a complex procedure involving lot of measures to ensure security. Hence Web-application/ App developers, delegate this critical piece of work to Identity providers like Google, Microsoft, Facebook etc. These Identity providers are trusted by the app developers and more importantly the consumers trust them too.
Why do app developers provide third party/ social logins? Because, it gives the users of the app some advantages.
They don't have to create new account with the app and remember the new set of credentials. Instead they can use the same credentials they are using with the Identity provider, to gain access to the app. This is huge.
They don't have to trust the app completely, means how the sensitive information like passwords, security questions are handled in the app, as they are not providing any sensitive information directly on the app. Only needed public information is fed to the app from the Identity provider. This is huge too.
No need to worry about the system compromise and leak of sensitive information as all Open ID providers have better security policies in place. This gives consumers a high degree of confidence when using your system through third party logins.
"All the advantages you mentioned will be great for the app developers
at the cost of disadvantages to the consumers of the app."
Lets put the consumer disadvantages on the side and look at the advantages you mentioned:
No need of extra code or database fields like token ID, etc.
You still need code/setup to validate your own tokens. You have to add more logic to verify the external tokens, but the consumers will have the advantage of using the external providers like they are in any other application.
User can add a password to their account whenever they want and login to the site or access their account by logging in through Facebook or Google+ given that they use the same email ID.
This is little confusing as users may choose external provider, so they don't have to remember a new password. Also, the account validation process is different if you use external login vs id/password login. If you are willing to provide both, then you already have the system in place, to verify the account for external logins. Then your first advantage is void and you are better of using Open ID spec.
It's enough to use the social login providers' API once - the first time the user logs in (which technically registers the user to the site).
This approach adds confusion to the flow for consumers. They expect to see a login screen from third party provider for authentication (when they click on google+ or FB), but instead they see your login screen.
Instead of cut short approach, it would be worth to use the complete flow. You might add more logic to handle the token verification with external providers, but, actual complex logic of token validation is delegated to the external providers. This adds no confusion to the end user and they can trust your application easily through social id providers. Even though, users can authenticate through social Id providers, it is always a best practice to have the profile object of that user in your system (without the sensitive information like password).
Since you have your own registration process in place, this may not be a huge advantage. But, please look into the open source implementation of any of the Security Token Service (STS) providers, to see if you can borrow some of the features for validation external providers.
Please let me know if you have any questions.
Thank you,
Soma.
ok, I've spent 2 hours googling on what it is & how to use it in a web-application! but no success.
Most of the links talk about scanning codes or entering some key in the GoogleAuthenticar mobile app and it'll return changing verification codes every 30 seconds.
Few things :
The webapplication has it's own login. That means users don't login using Google into the webapp.
If an attacker gets the user's password, he sees the QRcode as the next-step, which he can scan directly with the GoogleAuthenticator app in his mobile (as far as it appears to me). How is it tied to user's mobile only ?
In various sites, it mentions a shared secret between user & server, that means at the time of signup, we provide the user the shared-secret, which he can use in her mobile GoogleAuthenticator app and then use it while reading the QR code ?
In the above case, how to proceed if the secret is lost or forgotten by the user ? Use forget secret to send the secret again to user's email ?
I am confused about how can it be implemented in a fashion when it's a non-google non-android application!
All I get is that, it's just a concept asking for our own implementation with some help from the source-code of the GoogleAuthenticator. Please correct me ?
What I think is the solution is that, we have to write our own mobile-app, just like this guy mentioned here, although I'm still not sure how will the secret between the mobile-app and the server will be unique with each installation of that app such that it identifies a particular user only or is there any way to write our own app and use GoogleAuthenticator mobile app without having Google-login in our webapp ?
Google Authenticator (the mobile application) implements the Time-based One-time Password Algorithm. In the scenario you are asking about, two-factor authentication would work as follows:
The user generates a one-time password to be validated by a server application.
The server would verify the password using the procedure detailed by the TOTP algorithm.
The password generation on the user device can be performed by any application implementing TOTP which has been "configured" for your user account. Configured here means having shared a secret with the server, as you mention yourself in the question.
Now, trying to answer your questions:
The fact your application uses its own set of user credentials or Google's has no direct effect on two-factor authentication. No matter what these credentials are, you need a way to identify your user (the username) in order to be able to proceed to the validation of its TOTP password, because you need to know who the user is. Said another way: using TOTP and using the Google Authenticator application does not imply having to use Google credentials on your site.
I'm not sure I understand correctly. The configuration of the Google Authenticator app for each account is performed only once. If an attacker is sitting right behind your back and takes a photo of your screen while you configure Google Authenticator, then yes, he'd be able to configure its own application with your credentials reading the same barcode you're using. Nevertheless, he'd also need your credentials (proper) in order to perform the login and then provide the one-time TOTP password. Anyway, this is a security problem which stems from how the user improperly handles its own credentials and you could be subject to similar problems no matter the technology you use. To make an imperfect metaphor, it's like asking "if the user leaves the pin card with the codes on the table, an attacker sees it and steals a photo of it, could it use them?". Sure, he could.
Yes, reading the barcode is one of the ways you can configure the application and sharing the secret between the client application and the server. You can use other means, such as entering the key manually into the application, but using the QR code is quicker and much less error prone. You won't even need to generate the QR code, because you could use Google's Web APIs as I explained in the blog post you were reading when you asked me to answer this question. In fact, the Java server side library described there uses the Google Web API's and returns you an URL for the user to check out and read its own QR. If you want to build your own QR logic, go on, but there's no compelling reason you should do that if you're eligible to use Google's APIs (which is something you should check anyway).
If the secret is lost it depends on your own policy, if it's your own application. First of all, you should invalidate the old secret immediately upon user notification. Then, you could use the scratch codes you may have given the user upon creation of the TOTP secret to verify his own identity. If he has lost the scratch codes too, you'd probably want to fall back to some other ways to verify his identity such as using some kind of backup information in his account (backup telephone numbers, security questions, etc.). Once the user identity is verified according to your standards, you would issue a new credential and would begin from the start: that is, reconfiguring the Google Authenticator using a new QR and/or a new secret key.
To summarise: yes, you can use the Google Authenticator application as your client front-end if you want to: there's no need to build another one. The only thing which you should into account is that Google Authenticator uses 30-second windows in its TOTP implementation: the server side logic verifying the TOTP password will have to use the same window size (which is, IIRC, the standard value proposed by the TOTP RFC).
I'm trying to work out the best architecture for a couple of apps I'm developing.
In both apps I want to utilise google/twitter/LinkedIn/etc to provide authentication of a users identity. The app is composed of an iOS app which has an option to send data to a server which I'm writing in node.js.
I want to utilise either OAuth or OpenId to handle identifying a user against the above servers so that I don't have to put in an authentication system of my own. In other words, allowing users to re-use their ids when choosing to upload data.
I should also note that apart from identifying a user, obtaining a name and email address, I have not intention of using any of their APIs at this time.
I think I have two options:
Place the Authorisation code in the iOS client and transmit some sort of key to the server with the data which it can then verify.
Keep the iOS client fairly dumb, and handle authorisation from the node server.
I'd probably prefer the second option because it means I could centralise authentication and be able to support a web site as well. That's my current theory.
Can anyone who has done something like this give me some pointers as to the pros and cons, OAuth or OpenId, or links to some examples?
In our previous app we opted for a combination of the two approaches. We wanted to centralize our user data on our server in the event we needed to make future API calls on those services. We also wanted the native oAuth experience for the user on the client. Ie: on Android and iOS, the developer can have single sign-on / authorization run through the native Facebook app (if available), vs. popping-up a webview that serves the 'Approve' dialog. It's a better user experience in my opinion. Also for Twitter, the oAuth process may require a PIN code to be entered in the callback which should probably be handled on the client side.
You can pass the access token retrieved by the client to the server for storage and later use if you intend on making additional API calls on these services, provided you expect the token to be long-lived (ie: offline-access permission on FB).
In any case this is mostly a user experience decision.
I asked various questions about my problem (here and here) and I also asked in the #oauth & #openid freenode's channel on IRC. (this is note an "UP" question, it's an other problem)
I'll sum up my project configuration : Anyone will have the possibility to create an app that can use my API. To start, I'll work on my API and a Web based app, but the documentation about the API will be public. It's a bit like Twitter API.
The problem I face is how can I be sure which user is using the API (to retrieve his personal data, like your tweets), even if the User is using an app that I don't know who make it (again, like twitter and all the apps around).
I googled a lot and with the help of the previous answers given, I took a look at OAuth.
As far as I understood the way OAuth works, here how :
A user visit an app that use my API (web, mobile, whatever)
The apps redirect the user to the API for the authentication (I'll use OpenId) and the authorization (OAuth). This is a bit odd since the API will have a web interface for the login and the authorization (I suppose this is how it works since Twitter do that)
The API redirect the connected user to the app, with some tokens. In these tokens, there is a token representing the user that the app must store in order to indicate to the API which user is using it currently (Am I correct?)
So far, everything goes well. But what I can't figure it out, is when the user quit the app and goes again : how the app can remember the user is the one that used it before ?
(Before some of you bring me the cookie answer, I'll remark this is a simple example, it would be the same if the user clear his cookies, format his computer or change its computer.)
The only solution I can find, is when an unauthenticated user (without a remembering cookie for example) goes to the app, the app redirect him again to the API to authenticate himself, but this time, the user won't have to re-allow the app (authorization) since it already did it. The API will then return the user to the app to allow him to play with this.
Is this the proper & secure way to do it ?
The #OAuth IRC channel told me about the new protocol, WebID, but this is currently in pre-draft mode and I don't want to use something that will change continuously in the future :/
Thank you very much for your help!
Short answer: OAuth results in an authenticated access token. That access token is tied to ONE user. And as long as the access token is valid. The third application can do whatever the API allows the access token to do.
Long answer:
The thing with OAuth is that it does not "Log in" a user. OAuth gives third party applications what is called access tokens which can be used to access data on behalf of a user whether he/she is logged in or not.
Many services restrict their access tokens. Twitter for example issues two types of access tokens, read-only, and read/write. But there is no concept of logging in to use APIs. While an access token is valid, a third party application can access the user's data, and change things without a user's explicit interaction.
Most API providers have functionality to revoke access tokens. That is what happens when you in twitter look at your Connections page . See the revoke access links?
Personally I love the OAuth approach. As an API provider, you can control what access tokens are allowed to do, and the user can kill bad applications from using his/her resources. OAuth is secure as far as authentication goes. Third party applications do not get hold of user's passwords. But once authenticated they can do whatever your API allows.
if we take a look at how Twitter works, I think the missing point is an other layer to the project: The Official website:
The thing is, when you want to allow any 3rd party application to use Twitter, this application redirect you to the OAuth page of the Twitter API, IF you are connected, but if you aren't, it redirect you to the login page, which is located at http://api.twitter.com/login
(I don't know if keeping the api in api.twitter.com for loging an user, instead of just twitter.com is correct, but this is just semantics)
So, the workflow would be:
A user goes to a 3rd party application (like a website)
This third party redirect the user to the API for Authorization
The API redirect the User to the website for Authentication first
The official website redirect the User to the OpenId provider (or Facebook connect)
The Authentication is made (via multiple requests)
The website redirect the user to the API after he's successfully authenticated
The user allow/disallow the permissions asked by the 3rd party apps
The API returns to the 3rd party apps.
The User can now use (or not) the application.
This implementation have 2 problems:
Every time an User ins't authenticated (cleared it's cookies, connect himself from an other computer, etc), he will have to go through the Authentication method, by being redirected to the Official website and then being redirected to the 3rd party application (the API would be transparent, since it has already allowed the application to access his data).
All those layers would certainly lost the User on the Authentication process with too many redirections.
A possible solution would be to store the user's access_token, for example in the case of a mobile app, but with a pure html/css/js oriented app, this isn't possible. A login/password in the 3rd party web application that would match the user to the access_token of the API would be an other solution, like Seesmic (I think), but this is just useless (for us, not Seesmic) : the idea of not having the user's password become useless.
This is a possible explanation but I would require more details on how this is possible and your thought about that solution. Would it work?
(I added this as an answer since it's an (incomplete and not so sure, I agree) one.