My Samsung Gear (Tizen 2.4, Web App) application makes use of several paid APIs which are protected with secret access tokens.
At the moment I simply have those tokens inside a js file, this does not feel like a safe way to store sensitive information.
What is the recommended way to store this kind of information.
The documentation mentions a key manager:
https://developer.tizen.org/ko/development/api-references/web-application?redirect=/dev-guide/3.0.0/org.tizen.web.apireference/html/device_api/wearable/tizen/keymanager.html&langredirect=1
But I think the watch user has access to that? Which is exactly what I try to avoid.
Inside the config file, I can set some preferences, which I can then fetch with the preferences API. Is this secure? Or is this information extractable as well?
I was wondering what the safest way to store senstive app information (such as usernames, passwords, tokens, keys, ...), to which the watch user should in no way have access to, is to put inside a gear app. Or is the code assured to be protected in the compiled WGT file?
Or is the code assured to be protected in the compiled WGT file?
There is a feature of encrypting Encryption available in Tizen applications. It protects html, js and css files after installation on the device. Maybe you can use it to somehow protect some sensitive data, but please notice that encryption happen during installation on the device - not during wgt file creation.
Related
I have a static website developed through 11ty (Node based SSG), which contains a Contact form that sends a request to a nodemailer API with the data. Both are hosted on Render, as a Static Website and Web Service respectively, and they share a basic auth password which I've stored in each project as an environmental variable.
The Web Service accesses the variables just fine. However, the static website's event presents me with the error in the title "process" isn't defined, as in "process.env.VARIABLE_NAME" which is how I'm accessing them. I tried including a secret .env file in the project with the same key and including dotenv in the project, but no change.
I assume the nature of the static site is making it so the environmental variable isn't being processed/applied somehow. What possible steps could I be missing here?
EDIT: Although it seems it might be possible for me to do this through methods such as command line arguments (which then get injected into the code during the build process), that wouldn't work for my case since the password had to be secret in the generated source files. The dotenv package didn't work in my case. Finally, I've opted to discard this password-based authentication instead and simply use honeypot fields to prevent spam and CORS Origin headers in the API to control request source.
Your static site is running in a different context than your web service (which acts like a server). Since your static site is run from a users browser, it does not understand node-specific functionality like loading files or accessing your process environment.
Adding your password to your static site would also create a security risk, because a user could just see your password, take it, and run their own requests without any security your site may have.
A usual approach to this would be to create an API of your own that takes in a request from your static site and talks to the API directly or a technology stack that takes the page rendering to a server (like ServerSideRendering). This way, YOUR system takes care of calling the API while your users requests are restricted.
In HTML5, is it possible to create a localstorage that is accessible only to a single webpage?
I am currently experimenting with possibilities of writing self-contained single-page applications, and whether it is possible for users to host them themselves, e.g. on their Dropbox (which has some basic webhosting capabilities for public files) or by running a minimal webserver on localhost.
A user may then start such HTML Applications from various sources in his local server / Dropbox, or be asked to open one from another users Dropbox.
Since all these pages would be served from the same origin (currently https://dl.dropboxusercontent.com), they would all share a single localStorage, which may both interfere with the functionality if names clash, and leak data; E.g. such a page may want to store the authentication token for accessing the users Dropbox account in localStorage, but then any other such "App" would be able to steal the token.
I have to say here, that I am new to HTML5, and may very well be stretching the intended scope of usage here, as I keep running into limitations due to basic websecurity concepts like the same-origin policy – especially when opening a HTML file from a local drive through a file:// uri.
The core intent is allowing users to host their own custom apps in a manner that works across their mobile and desktop devices, by utilizing their existing webservice subscriptions for both hosting and data synchronization rather than moving their data to yet another service.
As stated here, localStorage is scoped by protocol, domain and port, nothing else.
And with this, even by prefixing each localStorage key by a unique page token (i.e. localStorage.set('page1.' + key)), it wouldn't avoid another page from getting those info, so no simple way to avoid information leak.
You can use unique page identifier (or even url) as a key for encryption of stored data. In theory.
I'm looking for the correct, secure way to store credentials for a third party API in an Outlook add-in. This overview of the different storage options only says not to store credentials in Settings, but not where to put them, so I assumed the RoamingSettings would be okay. Then I ran into this page with information about RoamingSettings, where it says that is not the right location either.
The question then becomes: What is the right place? Should I build my own storage solution and store/encrypt the credentials in a file or cookie? That does not feel very secure either, since we are talking about what is basically a web app running in an Iframe.
I assume you cannot implement another authorization scheme (token based, cookies etc.) for your API and you are stuck with Basic Authentication and its issues. If you are using ASP.NET, with all the samples available it could be very easy to add another authentication scheme that is more adapted to web clients (such as Office web add-ins).
Having said that, for me your best option is to use HTML5 storage or cookie storage (if not implemented by browser) to store your credentials.
The fact that the app is iFramed is not really a big deal. Those storages (HTML5: sessionStorage/localStorage) rely on domains separation which means that the storage slots where you will put the credentials will not be be visible by other apps, even those living on the parent iFrame.
You may also consider the fact that you may serve the web add-ins and the apis from the same domain. They are both web applications!
You can do what Outlook itself does for its POP3/SMTP/IMAP4 passwords - use CredRead / CredWrite Windows API functions. The data can only be decrypted under the local Windows account used to encrypt the data, so it cannot be take to a different machine and decrypted.
I don't think you can access these functions from JavaScript. This is for an OWA addin, not the Outlook application, is it?
I am using twitter oAuth in a app, each time of app starts asking for authorisation, but I want a single time authentication to use timeline and other things for that I want to store access tokens, How is it possible.
Thanks in advance..! :)
I use localStorage for this. There's a simple guide with samples here: http://www.smashingmagazine.com/2010/10/11/local-storage-and-how-to-use-it/
On other platforms (Android), I wouldn't recommend this since the app's sandbox can be easily compromised on some devices. On BB10 though, the app file can't be obtained by rooting the device (since it is secure) and the sandbox can't be compromised. If you're extra worried about security, run the token through an algorithm to 'encrypt' the token before saving it to localStorage. Since the code in your app can't be compromised (again, secure platform), that algorithm is safe and secret.
Also, BB10 affords you 25 MB of space in localStorage, which makes it a really nice container for dynamic things. Local Storage will persist when you close the app and open it.
Again, this is not a best practice for all platforms, since on some platforms the app or it's sandbox can be compromised such that someone could get your API keys or tokens just by extracting your app file. But it should be safe on BB10.
Good luck!
John
Note, response is my own and is not endorsed by my employer.
I'm building a JS client for a set of REST WebServices. The client will be delivered as an embeddable iframe, which should load JS scripts based on user options (license profile, user admin options, etc.)
I wonder what's the most effective and efficient pattern to do that.
At now I have a single "bootstrap" script, which includes the other scripts. I could create the bootstrap script code dynamically (server side), to make it load only the set of scripts required by the user configuration. Anyway those scripts would be publicly available, even if the services are not enabled for certain users... IMHO that's not a good solution.
On the other hand, how to control the access to static javascipt files on a public folder?
I want to avoid to serve javascript code though my code. It would be an expensive overload for the application!
Mmm... I'm a bit confused...
Giovanni
In general, if you wish to control access to a resource based on a business requirement (licenses, user profiles etc) you have no choice but to route all requests for that resource through your application.
However, since you are you are sending the files to the client there is no guarantee that anyone in possession of the scripts is currently authorized or authenticated (license may have expired, etc). As such, you cannot infer that a request to your web services is valid based on the fact that a consumer knows how to call your web service.
There should be very little to lose in making the scripts publicly accessible (since there should be nothing that you wish to kept secret in them). So, in answer to your question, I would suggest authenticating and authorizing any requests at the web service level and allowing the javascript files to be publicly accessible.