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.

Thanks, I'd meant to set Strict-Transport-Security to solve that, now done.

See also: http://www.matasano.com/articles/javascript-cryptography/

I linked to that from https://paste.sh/about -- creating pastes only works on browsers with crypto.getRandomValues (or with the command line client).

Okay, there are still issues with the JS environment but this does eliminate one of the worst issues IMO

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.

It's open source and can be self hosted. With proper SSL would you still consider it pointless in that case?

Yes.

I wouldn't call it pointless, I think it's better than not having it at all.

> 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.

looks alot like https://ezcrypt.it/ though I do like options..

so that is pasting the key within the url? so when you contact a page anyone sniffing the net knows the key? are you serious?

Did you read the about section?

The fragment is never sent to the server.

you are right, this falls back in "normal" crypto-as-js security considerations.