I am trying to add webauthn to my web app, and I want to securely store a private key with the credential data. The methods I have found for storing data with a credential are: hmac-secret extension, large blob extension, CredentialsContainer.store() . Which, if any, of these methods can securely store data on/with the authenticator? Are there better ways of doing it?
CredentialsContainer.store is not pertinent for public-key credentials: they are never stored, only created. (You can store other types of credentials, like passwords, but the title says "WebAuthn" so I'll stick to that topic.)
The hmac-secret extension (exposed as the prf extension at the WebAuthn level) allows an arbitrary number of secrets to be derived using a PRF like HMAC. This is currently behind chrome://flags/#enable-experimental-web-platform-features but will have the greatest degree of support in security keys and will be supported by Android devices in the coming months. This is intended to be the answer to your question but is not
The credBlob extension allows a small, fixed amount of data to be stored with a credential. It was not originally intended for secrets, however. Only newer security key will support this.
The largeBlob extension is for storing a KB or two of data with a credential, usually a certificate for that key. This will have the least security key support.
Probably none of those options currently work in Safari, however.
Related
Making localStorage and/or IndexedDB data offline permanent?
Is it possible to make localStorage and/or IndexedDB offline data permanent?
I am planning to make a completely offline HTML5 app and want the data to never get deleted, unless and otherwise the user knowingly does so.
I do not want the data to be deleted even after the app is closed, system is shutdown.
...want the data to never get deleted, unless and otherwise the user
knowingly does so.
The Storage API allow requesting a "persistent" permission for your origin. If granted, the semantics are that the data stored in certain APIs (local storage, Indexed DB, Cache, etc) is preserved until an explicit user action (like clearing storage), which appears to match your needs.
Documentation:
https://developer.mozilla.org/en-US/docs/Web/API/StorageManager/persist
Note that this is a new web platform API. It was recently added to Firefox (57) and Chrome (55), but is not present in Edge or Safari. Also note that Chrome does not currently show prompts for this permission request; it uses heuristics about the web app to determine if the request should be granted or not rather than asking the user to make the decision.
The specification is at: https://storage.spec.whatwg.org
The spec gives a background on how storage could work in browsers, i.e. by default an origin's data is "best effort", meaning preserved until the browser needs to clear it (due to space constraints, etc). The actual behavior of browsers varies significantly.
I am newbie in using Streaming Server. we are evaluating EvoStream Media Server to stream HLS stream with AES128 encryption.
I have few queries on AES 128. I have search through google but no luck
When doing HLS with VOD(Video on Demand) , Evostream creates chunks of segments along with m3u8 index file that contains all information including key and IV vectors.
#EXT-X-KEY:METHOD=AES-128,URI="2015-06-25T11-20-18.key",IV=0x0360f11b211ef025d7f72c41d58e0a2d
My question if when i play this file in html5 media player and debug it using F12, i can easily get the key and IV used to encrypt the file. Then what is kind of security AES provide if anyone can get those key and IV vector to decrypt the data.
Please any one have some knowledge over it, please share ...
The key seems to be in yet another file:
URI="2015-06-25T11-20-18.key"
2015-06-25T11-20-18.key is only a reference to the key, not the key itself.
So you need to control access to the file and only make it available to persons that are allowed to play the video.
The answer to your question is that HLS with AES-128 provides transport security making it difficult for someone to capture your content in a man-in-the-middle scenario. It doesn't provide DRM.
You are supposed to change the keys every 3-4 hours and the IV every 50 Mb of data and serve the keys over HTTPS and not plain HTTP.
See Serving Key Files Securely Over HTTPS on the Apple Developer site.
The first thing, that you have to keep in mind when dealing with content protection, is the fact that there is no perfect solution. There is no solution to guarantee you that only the audiences that you intended will be able to watch the video. All the protection schemes make it harder for the others to steal it but not impossible. Here are some of your options:
AES-128 encryption - you have to take special care to protect the key. Once the key "leaks" then anyone will be able to decode the video with some effort. The advantage is that's this method is simple and supported by the multitude of players.
SAMPLE-AES encryption - again you have to take care of the key. But even if it "leaks" one would need a specialized software to decode the video as it's not trivial. The disadvantage is that not all players support this method.
use DRM - DRM solutions are very expensive and require effort for integration and specialized players. But they provide the most protection.
There is no silver bullet. It depends on you needs and the level of protection you need. Don't forget that after all even the most advanced encryption scheme is not protected against simple things like screen capturing for example.
In normal case or a general use case
1. You can continue to use AES-128 as the encryption mechanism
2. Use HTTPS to provide the transport security.
3. Use token/cookie to authorize the user
(The cookie/token should be sent to the key server and the key server validates it before delivering the key)
Above 3 steps provide you the content protection, transport protection and to authorize users.
To answer your second question,
Authorized users with right tokens will be able to download the contents and keys to decrypt it. (There are plenty of tools to do it) you need a custom client to avoid that and html5 supported browsers cannot stop that.
I want to save a filesystem entry from chrome.fileSystem.chooseEntry to chrome.local.storage, as suggested here: unlimited file storage in chrome app.
Is this safe? Could another unwanted user/app look at chromes localstorage and change the value of the entry key I set in my app? Or is chrome.local.storage sandboxed just like app filesystem?
localStorage is protected from access by javascript in pages in other domains, similar to the way that cookies are protected. So, javascript access is only allowed from pages within the same domain.
Neither has robust security measures from being accessed outside the browser by external applications.
Whether that is safe enough or not is not something we could say as you haven't fully described the security needs of this particular element of your application. You would have to judge what is safe enough.
I wouldn't store my banking passwords in localStorage. But, I'm fine with storing application preferences there. The wide gamut between those two options depends entirely on the specifics of the situation.
I have an extension where users maintain a list of links. It would be nice to have this data synchronized between computers (at work and at home). What are the possible solutions?
Chrome has extension synchronization option but I am not sure if it synchronizes data or not (I would be surprised if yes). Even if it does, not everyone would want all their other extensions be synced.
I can store my links in a special bookmark folder and use built-in bookmark synchronization, but in this case all bookmarks would be synchronized too (not all users would want that either I think).
Any external sites I can use? Something easy to use and linked to a google account?
(I don't want to build my own site for this)
Edit: As of Chrome 20 and above you can use chrome.storage module to save to the cloud.
chrome.experimental.storage.sync.set({'settingAlwaysOn': true}, function() {
console.log('Saved option in the cloud');
});
Before Chrome 20
You're right, the Chrome Sync for extensions options (in settings) does not synchronize extension data. The only way to synchronize those data is through a third party.
Since you ruled out the usage of Bookmarks, which makes sense if users don't want bookmarks to be synchronized.
Everytime you persist data through storage (Web SQL Storage, localStorage, IndexDB), you grab that object, and serialize it into JSON (via JSON.stringify), and you send it to some online service such as Google Docs.
That would be quite tricky for Web SQL Storage and IndexDB, you would have to do your own importer and exporter. For localStorage it is pretty simple, since its a key/value pair.
It requires some work to link it to a Google Account (such as Docs) you would have to use OAuth and do the plumbing to connect your extension to the service. Once your connected, it is not that difficult to maintain the state.
Good luck :)
Chrome 20 supports chrome.storage.sync API. It seems to fit your requirements perfectly.
It is impossible to identify a user or request as unique since duping is trivial.
However, there are a handful of methods that, combined, can hamper cheating attempts and give a user quasi-unique status.
I know of the following:
IP Address - store the IP address of each visitor in a database of some sort
Can be faked
Multiple computers/users can have the same address
Users with dynamic IP addresses (some ISP issue them)
Cookie tracking - store a cookie per visitor. Visitors that don't have it are considered "unique"
Can be faked
Cookies can be blocked or cleared via browser
Are there more ways to track non-authorized (non-login, non-authentication) website visitors?
There are actually many ways you can detect a "unique" user. Many of these methods are used by our marketing friends. It get's even easier when you have plugins enabled such as Java, Flash etc.
Currently my favorite presentation of cookie based tracking is evercookie (http://samy.pl/evercookie/). It creates a "permanent" cookie via multiple storage mechanisms, the average user is not able to flush, specifically it uses:
Standard HTTP Cookies
Local Shared Objects (Flash Cookies)
Silverlight Isolated Storage
Storing cookies in RGB values of
auto-generated, force-cached PNGs
using HTML5 Canvas tag to read pixels
(cookies) back out
Storing cookies in Web History
Storing cookies in HTTP ETags
Storing cookies in Web cache
window.name caching
Internet Explorer userData storage
HTML5 Session Storage
HTML5 Local Storage
HTML5 Global Storage
HTML5 Database Storage via SQLite
I can't remember the URL, but there is also a site which tells you how "anonymous" you are based on everything it can gather from your web browser: What plugins you have loaded, what version, what language, screensize, ... Then you can leverage the plugins I was talking about earlier (Flash, Java, ...) to find out even more about the user. I'll edit this post when I find the page whcih showed you "how unique you are" or maybe somebody knows »» actually it looks as if every user is in a way unique!
--EDIT--
Found the page I was talking about: Panopticlick - "How Unique and trackable is your browser".
It collects stuff like User Agent, HTTP_ACCEPT headers, Browser Plugins, Time Zone, Screen Size and Depth, System Fonts (via Java?), Cookies...
My result: Your browser fingerprint appears to be unique among the 1,221,154 tested so far.
Panopticlick has a quite refined method for checking for unique users using fingerprinting. Apart from IP-adress and user-agent it used things like timezone, screen resolution, fonts installed on the system and plugins installed in the browser etc, so it comes up with a very distinct ID for each and every user without storing anything in their computers. False negatives (finding two different users with the exact same fingerprint) are very rare.
A problem with that approach is that it can yield some false positive, i.e. it considers the same user to be a new one if they've installed a new font for example. If this is ok or not depends on your application I suppose.
Yes, it's impossible to tell anonymous visitors apart with 100% certainty. The best that you can do is to gather the information that you have, and try to tell as many visitors apart as you can.
There is one more piece of infomration that you can use:
Browser string
It's not unique, but in combination with the other information it increases the resolution.
If you need to tell the visitors apart with 100% certainty, then you need to make them log in.
There is no sure-fire way to achieve this, in my view. Of your options, cookies are the most likely to yield a reasonably realistic number. NATing and proxy servers can mask the IP addresses of a large number of users, and dynamic IP address allocation will confuse the results for a lot of others
Have you considered using e.g Google Analytics or similar? They do unique visitor tracking as part of their service, and they probably have a lot more money to throw at finding heuristic solutions to this problem than you or I. Just a thought!