21–29 of 29 posts
I keep wondering: Browsers have been dealing with some of these issues for quite some time now, both for SSL purposes and password storage. They should agree on common interfaces to expose safe crypto functions to client code, so that users could be relatively sure that servers will never get, say, a plaintext password. Is it terribly hard? It would likely be safer than hamfisted attempts at JS cryptography which can…
I keep wondering: Browsers have been dealing with some of these issues for quite some time now, both for SSL purposes and password storage. They should agree on common interfaces to expose safe crypto functions to client code, so that users could be relatively sure that servers will never get, say, a plaintext password. Is it terribly hard? It would likely be safer than hamfisted attempts at JS cryptography which can…
What you describe already exists. It's called client certificates.
2. client certificate distribution is still a mess. At a minimum, there should be a standard way for servers to generate certificates and install them in the browser (with user visibility but without requiring user interaction).
Earlier quoted context omitted.
What you describe already exists. It's called client certificates.
1. client certificates only replace passwords, not arbitrary encrypted data. 2. client certificate distribution is still a mess. At a minimum, there should be a standard way for servers to generate certificates and install them in the browser (with user visibility but without requiring user interaction).
2) You mean something like keygen[1]? (yes, I know it was removed from the standard.)
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ke... (
It's interesting that the very security minded disable javascript in their browser for security reasons, which makes most client-side crypto not possible.
It's interesting that the very security minded disable javascript in their browser for security reasons, which makes most client-side crypto not possible.
Do they disable it globally or selectively enable it?
I keep wondering: Browsers have been dealing with some of these issues for quite some time now, both for SSL purposes and password storage. They should agree on common interfaces to expose safe crypto functions to client code, so that users could be relatively sure that servers will never get, say, a plaintext password. Is it terribly hard? It would likely be safer than hamfisted attempts at JS cryptography which can…
Unfortunately so far things are moving in the opposite direction. After Chrome dropped Java support it appears there's no cross-browser way to do reasonably reliable crypto right now.
It's interesting that the very security minded disable javascript in their browser for security reasons, which makes most client-side crypto not possible.
Imagine a client-side-encrypted version of google docs that always encrypts your document before sending it back to the google servers. Any time you visit the site google could send you a modified version of the site javascript (possibly at the request of security services) that just uploads the document without encrypting it first. Browsers currently have no way to prevent that or even notifying you that it's happening.
If you want to do client side crypto you need to do it in native apps. The web is just too technically limited to support building platforms on top of it that have different trust models.
It's interesting that the very security minded disable javascript in their browser for security reasons, which makes most client-side crypto not possible.
The people disabling javascript are also probably aware that javascript crypto is utterly pointless with the current browser security model. Javascript crypto aims to protect you from the server, but you must rely on the server sending javascript that actually does the encryption. When it can't protect you against the adversary it's design to protect you against then what is the point? Imagine a client-side-encrypted…
The project I am working on aims to facilitate these kinds of apps. It is a native app which have both a CLI interface and (used to before I broke it) an HTTP interface. The idea is that websites gets proxied through the app. All data gets stripped out and encrypted before being sent anywhere.
Websites must be aware that this is going to happen for them to work. Unaware sites won't work. All or nothing.
The project site is https://www.selectiveshare.com. I am currently working on a second project which uses the CLI interface. The HTTP interface will remain broken for some time.
Earlier quoted context omitted.
1. client certificates only replace passwords, not arbitrary encrypted data. 2. client certificate distribution is still a mess. At a minimum, there should be a standard way for servers to generate certificates and install them in the browser (with user visibility but without requiring user interaction).
1) The problem with that is trusting the code you download to actually encrypt the data. If it could be linked with the file upload button or some such functionality solely reliant on the browser to get right, it could work. 2) You mean something like keygen[1]? (yes, I know it was removed from the standard.) https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ke... (
2) Exactly. I don't follow the standard process these days, but it's sad that we're not really making any progress in such a critical area. We now have pretty progress bars, but we're still as vulnerable as 20 years ago.