NoPlainText: One time, browser-encrypted messaging(noplaintext.com) |
NoPlainText: One time, browser-encrypted messaging(noplaintext.com) |
Generated by Math.random()? (According to MDN, that's seeded from the current time...)
Update: Another problem is that there is no message authentication. The server can flip individual bits within the message.
Update: Also, obviously, we have to trust noplaintext.com to send us an uncompromised web page.
But wait! View source!
<script type="text/javascript" async="" src="https://ssl.google-analytics.com/ga.js></script>;
We also have to trust Google, specifically google-analytics.com not to steal the message.
<script type="text/javascript" src="https://crypto-js.googlecode.com/files/2.5.3-crypto-sha1-hma...;
AHHHHHHHHHHHH!
We also have to trust whoever controls the crypto-js project and the people running googlecode.com.
And every router between them and googlecode.com (or whatever that resolves to in their DNS situation!)
Please enable Javascript to use NoPlaintext.
Javascript is an integral part of modern websites and is very easy to enable.
- No ads (= no revenue if you rely on ads and get paid per mille)
- No analytics (frustrating when your site is being used in all sorts of interesting ways but your information is limited to log files)
- No behavior layer (great, another intentionally crippled client). You can bring up graceful degradation but I'm fairly positive that trend came as a result of spotty JS support. That era of spotty JS support has mostly come to an end, at least as far as default configurations are concerned.
From the perspective of many (most?) of the sites you'll visit, js-disabled clients are merely leeches. Like bots silently hitting your server logs, slurping up your content for who knows why. (Unless you're otherwise creating content for them, such as posting on HN -- or a paying customer.)
Just my point of view, but I'm willing to bet that other creators feel the same way.
I used to be a no-script user too for a time, and while I stopped using it because it became too inconvenient, I think it's everyone's prerogative to decide whether or not a site can track them or show them ads. It might be annoying for sites whose only means of monetization is ads, but again, the web is free and that's just the nature of the beast.
HN: http://news.ycombinator.com/item?id=2935220 Direct link: http://www.matasano.com/articles/javascript-cryptography/
For instance, I am considering a service at the moment which would involve people uploading confidential information. The uploads will be fairly large, so a lot of bandwidth will be required (optimistically assuming it gets traction.) One architecture I am considering is a small dedicated HTTPS server which provides a self-contained webpage-plus-JS program to encrypt the upload and send it for storage on Amazon S3. Then I will pull the results off Amazon and decrypt them on a machine which is not even connected to the network. The advantage to this architecture is that it will scale arbitrarily but require me to secure only relatively modest dedicated resources, despite being used for transmission of confidential information. Because it uses a dedicated HTTPS server serving a self-contained page doing all the crypto, it avoids tptacek's objections to JS crypto in the browser (E.g., the server can provide the random seed in the JS itself, HTTPS prevents MITM attacks, etc.)
I'ts also unclear to me how the encryption scheme is working here. I don't see how it's impossible for the server to decrypt the message when it is sending you everything you need to decrypt it when you click the link. Am I missing something?
Also, from what I understand, the system requires total trust in the provider's servers to do their job. That is no different than trusting that an anonymous email provider is doing their job (not storing logs, etc) and there's a proven market for that (I think).
Yes, the idea is simply to avoid having the sensitive data stored somewhere forever, like on their gmail account. Obviously if you think you have a 3rd party listening in on your on-going conversation, you need something more secure.
I don't know about your second point.
Native crypto clients don't have this particular vulnerability.
The target seems to be people who were previously just emailing their confidential info. And though trust is an issue, people happily trust anonymous emailers, commercial encryption providers (where source is not available), etc.
We still require a trusted third party here.
>>I think it's everyone's prerogative to decide whether or not a site can track them or show them ads
Or even work properly. (I felt that was important to include too since it's a big deal.)
Now I'm not a huge 'graceful degradation' advocate by any means, since a lot of sites (or 'apps' rather) would become totally useless without js, but all those no-script users decided to block javascript for a reason and they know very well what blocking javascript will entail, so I see no reason to be condescending towards them or give them anything more than a simple reminder/value-proposition so that they can turn js on for our sites.
We're probably on the same page, I just think the case against people who block javascript is overstated; these users are a minority, and they can evaluate it on their own whether your site's functionality is worth enabling javascript for.
I am not following you. If they send you the code, can't you inspect it? And if you vet it, where's the concern for the MITM attack? You already have the code.
> Native crypto clients don't have this particular vulnerability.
Isn't it exactly the same? You have to download the code at some point.
Native crypto clients don't arbitrarily download code from several domains every time you turn on your app.
Even so, I would argue that it's fair to say that this pushes it along a continuum towards less secure, not that it is "broken".