Good on you for having a list of known weaknesses, but here's the one that really makes this completely unsafe:
The server dictates what's run on the page, and thus can access the plaintext data in any way it sees fit. The trust model is fundamentally broken in client-side crypto of this nature.
Edit with two more thoughts: 1) Even if you trust the person running the service, how much do you trust the other users (who may be using stored XSS to compromise your data)? How much do you trust the hosting service behind it, if there is one? 2) Am I the only one that finds it massively irresponsible to not have a huge flashing "DO NOT TRUST THIS UNTIL IT'S BATTLE HARDENED" sign over it? This goes for just about every project of this nature.
Edit with a final thought: Most of the time, we think in terms of "relative goodness". A good car is better than a bad car, but a bad car is still better than no car at all. This logic completely breaks when it comes to crypto. Simply put, bad crypto (and bad implementations) when released on the world put lives at risk. This should be taken seriously.
It's one thing to build a project for learning (and please, please do!) but cover every friggin' surface you can with disclaimers.
Do you believe there is zero value to client-side JavaScript crypto?
There's a spectrum between "unencrypted webpage loaded over cafe WiFi" and "locally compiled open-source application". You don't always need the latter.
EDIT: Say you're using a web app that encrypts your data on the client. All the executable assets (html, js, css) are static and hosted on a CDN over HTTPS. The app stores your encrypted data to another server. Even if that server is compromised, it's still impossible to access your data without also compromising the CDN (assuming a correct implementation of the crypto and no XSS vulnerabilities, of course).
EDIT2: It would be interesting if you could sign a bundle of static assets that the browser could verify. Maybe as part of the HTML5 app cache. Like a lightweight version of a Chrome app. Add on a restrictive Content Security Policy and it sounds pretty good to me.
If you're that paranoid, you shouldn't be using a hosted service at all. There could be a guy right outside your house intercepting your cable line and filtering all traffic to and from cryptonote.org and routing it to his own instance of the app. That doesn't mean that cryptonote is responsible for that happening.
Thanks, and that is absolutely true. That's why it's open source: I want people to host their own version if they don't trust me https://github.com/alainmeier/cryptonote
Hm, yes, added a warning message, good idea. As for your other thoughts, I completely agree. It's a work-in-progress and I figured the best way to figure out what's wrong is to learn from others.
Edit: Also added a link to that discussion next to Nadim's post.
I made something similar (except the one-time view part) not too long ago just to experiment with storing the base64 encoded message into the URL. It also has an option to add a key, which uses a javascript implementation of blowfish.
Since the message is stored within the URL, there's no backend needed, though that means the message needs to be short since most modern browsers can only support up to about 2000 characters in the URL and the messages can generate a long base64 string rather quickly.
Why is the password stored in plain text "for now"? What is so hard about running bcrypt or pbkdf2 against the password before storing it in the database?
There are a lot of single view self destruct sites, but I wanted to make a new one because I wanted to let people host their own instead of relying on the site provider.
[+] [-] daeken|13 years ago|reply
The server dictates what's run on the page, and thus can access the plaintext data in any way it sees fit. The trust model is fundamentally broken in client-side crypto of this nature.
Edit with two more thoughts: 1) Even if you trust the person running the service, how much do you trust the other users (who may be using stored XSS to compromise your data)? How much do you trust the hosting service behind it, if there is one? 2) Am I the only one that finds it massively irresponsible to not have a huge flashing "DO NOT TRUST THIS UNTIL IT'S BATTLE HARDENED" sign over it? This goes for just about every project of this nature.
Edit with a final thought: Most of the time, we think in terms of "relative goodness". A good car is better than a bad car, but a bad car is still better than no car at all. This logic completely breaks when it comes to crypto. Simply put, bad crypto (and bad implementations) when released on the world put lives at risk. This should be taken seriously.
It's one thing to build a project for learning (and please, please do!) but cover every friggin' surface you can with disclaimers.
[+] [-] tlrobinson|13 years ago|reply
There's a spectrum between "unencrypted webpage loaded over cafe WiFi" and "locally compiled open-source application". You don't always need the latter.
EDIT: Say you're using a web app that encrypts your data on the client. All the executable assets (html, js, css) are static and hosted on a CDN over HTTPS. The app stores your encrypted data to another server. Even if that server is compromised, it's still impossible to access your data without also compromising the CDN (assuming a correct implementation of the crypto and no XSS vulnerabilities, of course).
EDIT2: It would be interesting if you could sign a bundle of static assets that the browser could verify. Maybe as part of the HTML5 app cache. Like a lightweight version of a Chrome app. Add on a restrictive Content Security Policy and it sounds pretty good to me.
[+] [-] rmrfrmrf|13 years ago|reply
[+] [-] alainmeier|13 years ago|reply
[+] [-] alainmeier|13 years ago|reply
Edit: Also added a link to that discussion next to Nadim's post.
[+] [-] alfg|13 years ago|reply
I made something similar (except the one-time view part) not too long ago just to experiment with storing the base64 encoded message into the URL. It also has an option to add a key, which uses a javascript implementation of blowfish.
http://alfg.co/jot
https://github.com/alfg/jot
Since the message is stored within the URL, there's no backend needed, though that means the message needs to be short since most modern browsers can only support up to about 2000 characters in the URL and the messages can generate a long base64 string rather quickly.
[+] [-] alainmeier|13 years ago|reply
[+] [-] jhorman|13 years ago|reply
message[pre_encryption]
with my unencrypted message in the POST data?
[+] [-] alainmeier|13 years ago|reply
Edit: fixed. If anybody thinks of anything else, please let me know. This is as much of a learning exercise as anything for me.
[+] [-] manish_gill|13 years ago|reply
I created a similar web application in Django as part of a College minor project last year. Best part was implementing the AES algorithm ourselves. :D
[+] [-] tptacek|13 years ago|reply
[+] [-] lawnchair_larry|13 years ago|reply
[+] [-] deepdog|13 years ago|reply
[+] [-] alainmeier|13 years ago|reply
[+] [-] ryandetzel|13 years ago|reply
[+] [-] alainmeier|13 years ago|reply