The authorization cookie has neither the secure flag or http flag set.
i.e. If you could get the client to redirect to http://paste.sh it would send the full auth cookie in the (now unencrypted) headers. (Man-in-the-middle can then use the cookie.)
Edit: For anyone checking, the cookie is only set upon the first edit.
The worst issue with JS cryptography is that it's almost always pointless, as it is here. Your users can't trust that you'll protect their secrets, because any coercive adversary who would ordinarily operate by copying those secrets off the server directly will instead simply force you to host a backdoor that breaks the crypto.
That's the worst problem with JS crypto, but we haven't enumerated all of the problems on this thread, nor does my (old) post on our website do so either.
> How can you do that without SSL? And if you have SSL, why do you need Javascript crypto? Just use the SSL.
This article does not seem to be fully geared towards crypto that is supposed to happen in the client and then never touch the server. In this case all the code is served over HTTPS and the browser does in fact have a CSPRNG (window.crypto) now. Still the article raises a lot of good points.
i.e. If you could get the client to redirect to http://paste.sh it would send the full auth cookie in the (now unencrypted) headers. (Man-in-the-middle can then use the cookie.)
Edit: For anyone checking, the cookie is only set upon the first edit.