I would like to play videos inside an IOS web view with Cordova.
Videos must be available only inside this app.
I don't have any domain to restrict access, because it's a web view inside a native app.
Is there a way to use HTTPS with Javascript to authenticate with an API token, then play each video with this token?
Can anyone provide a specific script example to do the job?
It is not possible to do this in such a way that someone could not break it because an attacker could install a man-in-the-middle server with a certificate created using their own certificate authority and then sniff the data and use it outside the application.
However you could make it more difficult, by creating "single use" keys that you send to the device using the notification service every time a key is used, you invalidate it and create a new key for the next use. This would mean that someone trying to get around the system would find it very difficult to have more than one client using the content at any given time.
Given that that is the best you can do, why not simply have users authenticate themselves and not allow multiple sessions to be active for the same user?
Related
TLDR: All I want to do is secure my cloud function in Parse so that it only accepts requests from my iOS app. How can I do that?
Longer version:
I recently got started with using Parse for a client side app I'm building using a Google API.
Before using Parse, my issue was that the Google API calls from my app were not secure. I tried a Man in the middle attack on my app, and I was able to successfully get the bundle id and app id (Google claims some form of security is achieved by ensuring that the call is from the correct bundle id that you can specify on their console). So despite using SSL, seems like it was easy to get this information. Now this Google API is paid, so someone could easily abuse my key when I release my app and raise my bills.
I was anyways also thinking of doing some lightweight work in the backend, so I figured to use Parse. Now the call to the Google API is done in Cloud Code. But a new problem I'm facing is how to secure calls to the Cloud function I've defined in Parse? The Parse App ID and Client Key aren't secure at all.
All of Parse's blogs keep talking about creating users and defining ACLs etc. But in my case, there is no data in my Parse app and there is no user per se. It simply calls the Google API and returns the result. All I want to do is secure my cloud function so that it only accepts requests from my iOS app. How can I do that?
The inherent security risk here is that any key you store in your app is vulnerable, for that reason encryption is also vulnerable. My recommendation is to use the automatic user in Parse on your iOS app, you could even throttle excessive requests/abuse by a single user. By creating and using a user you are able to gain the benefits of ACL which appears the best security option available in Parse currently. At that point you send the automatic user in your cloud code request and verify it's a valid iOS user.
Is it possible to accept paypal payment directly inside an iOS App (i don't mean via the Paypal iOS app, but my own app) without having our own server to validate the return token? I think it is possible with a javascript button inside a webview, but can it be a native iOS function?
You could do it... but it would involve enormous risk. The reason is that you would have to store your credentials inside the app and then make the call directly. Anyone could then extract the credentials and start using them for their benefit (i.e. MassPay themselves from your account).
The only way to ensure they don't get your credentials is to keep them server-side, where the client has no access to them.
Currently I am using a modified script to upload videos. I have taken the following example as a basis:
https://github.com/youtube/api-samples/blob/master/php/resumable_upload.php
This script uses browser based oauth flow.
Could you please tell me if it is possible to allow other users to upload videos to my channel without making them the channel managers? So that they could use my auth token.
If yes - how can it be inplemented?
Yes, that is definitely possible. You need to design an application that is capable of the following:
Authenticate the channel the videos shall be uploaded to via OAuth. As DalmTo said, you need to save the tokens. Whoever has the tokens has access to the channel.
Since your application has access to the channel by now, it (and therefore you) can decide what to upload. That means that you are responsible for granting or denying a specific user the right to upload something.
In order to do so, you could again use OAuth or any other method you like (e.g. you can use your backend accounts).
In other words, a user has to identify towards your application. Your application can then decide to take the user's content and upload it to the channel.
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.