I am looking to protect the code of my Firefox extension because it has server calls in it that no would be a security risk if someone could make them outside of the extension. Any suggestions on how to encrypt it?
This is basically impossible. You want to give executable code to an untrusted client that has "secret" calls in it, yet not let the client know the secrets? How, then, is it going to execute the code?
At some point, it must be decrypted. Which means the client has everything it needs to perform the decryption, which means a user can do it, and build a malicious version of your extension.
The only choice you have is to redesign such that vulnerable services are not publically exposed.
If it's going to be executed on the client side, with no reliable secret, then basically you've definitely got a security vulnerability.
It's hard to suggest ways round this without knowing a bit more about your extension. An obvious suggestion would be to request a username/password, authenticate (over HTTPS) with the server and receive a time-limited token, and then present that token with the "dodgy" request. That won't stop anyone with the right username and password though...
You could use xauth, which is a variant of OAuth designed to solve this type of problem. Twitter uses xauth: http://dev.twitter.com/pages/xauth
Additionally, you could obfuscate your Javascript code, or even write it in C (as a NPAPI plugin).
Related
We are using Go server side code to interact with Google Ads REST API.
Namely, we authenticate it with help of "golang.org/x/oauth2" and
"golang.org/x/oauth2"packages.
In May (and recently again) we've got a email from Google regarding deprecation
Out-of-band flow, essentially rewording of this
one.
But additionally to common information, Google email listed account, which we
are using to authenticate, as being used in OOB flow and going to be blocked.
We checked our sources and available sources of mentioned packages but was not
able to find redirect URIs which are said to be used for OOB flow as one of
those:
redirect_uri=urn:ietf:wg:oauth:2.0:oob
urn:ietf:wg:oauth:2.0:oob:auto
oob
We explicitly use http://localhost in our code and long-live refresh token
(which seems never expires).
We also tried to use tcpdump to monitor our API calls, but was not able to
learn much from it, because calls are made via https and, therefore, encrypted.
We considered to use man-in-the-middle kind of proxy like
https://www.charlesproxy.com/, but haven't tried it yet, because it become
non-free and because of complexity of setup.
We tried to log our requests to API endpoint with custom RoundTripper, but
have not spotted anything suspicious. It seems that we're using refresh token
only and exchange of code to refresh token just never happen in the code.
Because of this, we don't think that further logging or monitoring with
decrypting https packages may help (but we open to suggestions how to do it better).
Finally, we decided to create a new OAuth 2 Client in the Google console with
fresh set of client id, client secret and refresh token. We obtained a new
refresh token with oauth2l and replaced
credentials in our configuration. But still, we are not sure that new account
will not be blocked by Google due OOB deprication, because seemingly it looks
the same as old one.
Questions:
Why may Google mark our account as OOB?
How can we ensure that newly created account will not be blocked?
Same here.
I find out an answer, that says "Desktop" type of Credentials uses OOB by default. Probably you need to create new Credentials with type "Web"
As an authentication, the application (Service-X) uses a third-party internal service (Service-Y), in which all the information about the employees is stored. All internal services of the company use SSO.
How to implement the ability to log in to Service-X if Service-Y is unavailable? (If I have already been authenticated in Service-X before this).
The remember-me feature that comes with Spring Security might be what you're looking for.
However, there are still quite a few limitations to this. If your cookies are wiped upon closing the browser, which is quite common in a lot of big companies, this won't work. Other than by the session cookie, you can't safely remember the user. You absolutely require Service-Y to be available to identify the user if his cookies have been cleared or have expired.
The main selling point of OAuth2 is that you sign in using Service-Y without Service-X knowing your username/password (unless the username is transmitted through the scope), so while you could ask the user to provide a password on the first time he signs in Service-X using Service-Y in case Service-Y goes down, which would potentially patch your issue, I really do not recommend it because it somewhat defeats the purpose of OAuth2.
Now, if you do take that suggestion despite me not recommending it, you should make sure that Service-X checks that Service-Y is down before allowing the user to sign in using the password he provided for Service-X.
Best case scenario, if your browser cookies aren't cleaned, go for the remember-me feature. I suggest you read the following: http://www.baeldung.com/spring-security-oauth2-remember-me
Something seems to elude me with regard to xAPI. I am going to try and keep this really simple.(and maybe even stupid)
What I understand to be true...
Any Tin Can implemented content can be launched with a launcher.
The launcher is provides endpoint and auth information
The endpoint DOES NOT have to be an LRS. It can be a script which then passed to the final endpoint, which is an LRS.
The LRS, in this case private SCORM Cloud(sandbox), cannot receive statements without basic auth.
What I need to know...
Does the LRS generate OAuth tokens?
How would someone pass the statement from Captivate, Storyline, lectora files to a the TinCan_PHP for handling secure connectioni to the LRS?
Why would I use TinCan.JS, when the basic auth information is easily broadcasted to the end user, which could then be used to cause harm to the LRS?
Am I completely off track?
Thanks a lot...
Just some clarifications for future users on your understanding...
A launcher may provide endpoint and auth, that is one scenario and is probably based on the launch guidelines that came out with the 0.9 spec. There are other ways to handle the handshake, for instance how cmi5 does so (which isn't necessarily any more secure other than the fact that the credentials can only be requested once and are intentionally denied certain privileges such as voiding of statements).
I would consider your "script" a 'non-conformant' LRS in that it is receiving statements (in the form of xAPI requests), but doesn't provide full LRS conformance. SCORM Cloud's LRS can't receive statements without some authentication, but you are correct basic is preferred because OAuth there doesn't make much sense for production.
For the questions...
Yes, the LRS generates OAuth tokens, but for the most common approach the content has to have an already established relationship with that LRS and the OAuth based account has to be on the LRS (or a system the LRS is tightly coupled with, like an LMS) not with some OAuth provider in the wild (meaning you can't use accounts on Twitter, or Facebook, or Google, etc. which is the part that is often confusing for people).
They wouldn't, those products all already support direct communication to an LRS via the launch guidelines (Basic Auth), any system they are communicating with has to have at least enough LRS functionality to support them which includes the State API besides the Statements API.
TinCanJS in and of itself isn't a browser only solution, there are people running it on the server side so the language is really a separate issue. It is also possible to use TinCanJS outside the common launch paradigm, and in such situations it is possible that the user has an individual credential with the LRS in question (or a system that is coupled with the LRS) and they enter it themselves. A bookmarklet is a good example application.
The bottom line with all sets of credentials is to make sure your application is conversing with the LRS over https in which case the credential used isn't in the open, then check with the LRS provider to see if it is possible to use credentials that are short lived and have limited permissions. There is little "harm" that can be done to a properly implemented LRS short of voiding of statements or overwriting (deleting) of stored documents, both of which can be limited when using a proper permissions scheme and limited credential.
To answer your question, yes you are completely off track! :-)
If you're sending statements from a javascript based e-learning course to somewhere, then than connection is inherently not secure. Adding another (secure or otherwise) link in the chain after that insecure connection doesn't add to your security. You may as well send the xAPI statements directly to the LRS.
You may as well use Basic HTTP authentication too. Firstly, that's what all the authoring tools support, so you kind of have to. Secondly, using OAuth instead of Basic Auth for client side connections is like using a key lock instead of a combination lock and then leaving the key under mat. A key lock (OAuth) might be more theoretically secure than a combination lock (Basic Auth) but not in practice if you leave the key under the doormat (embedded in your client side code).
See this SO question answer for three options of what you can do about xAPI authentication security.
And just for the sake of completeness: yes, in the case of OAuth the LRS generates the tokens. See the xAPI spec for the most up to date details.
I hope I am not being to dense but I don't know how to use phpoidc. I have downloaded phpoidc from https://bitbucket.org/PEOFIAMP/phpoidc. I have followed the instructions in the INSTALL file. Now that it it supposedly installed, how do I use it? There does not seem to be any documentation on this.
I just want to set up simple user authentication on my site. I am running CodeIgniter 3.0 rc. I primarily want to allow login with google accounts.
Are you talking about the OP side or RP side?
OP side should be quite self-explanatory as it is a stand alone thing.
RP side needs integration to your application.
The phpRp is just a sample implementation that uses these libraries.
What it does is to create an OpenID Connect request and process the call back to see validate the response. Then, typically, an application needs to associate the iss and sub in the ID Token to a local account: you need a mapping table for it. Once you are done with that, create a session and off you go.
Can anyone tell me how I could go about authenticating with the various OAuth login mechanisms on the internets (Twitter, Facebook) so that I can run scripts against these services.
As an example, right now when I use Facebook data I goto graph.facebook.com and copy paste the access key from the URL. Obviously this is a bad approach, it has sufficed for now, but is not really an option anymore :)
I've checked out the documentation on the facebook site in particular which requests that I use a callback urL and so on. I'd like to be able to make a call from a ruby script which requests the OAuth token instead.
Is this even possible?
P.s This would be using my own credentials.
Yes, it is possible. http://developers.facebook.com/docs/authentication/ "Authenticating as an Application" section.
You can get the Access Token using a web redirection, and then store it to perform further offline operations. Some APIs need explicit user scope permission to do that.