Deprecate the ability to encrypt posts

[cipherself]

It appears that there's an option to encrypt posts using a password, I suggest that this option should be deprecated for a number of reasons:

• The encryption algorithm used is RC4, which has been declared insecure for a while and should not be used. [1][2][3] Also, no MAC is used which makes it vulnerable to a bit flipping attack.
• When using cryptography, it's highly advised to use an implementation that was written by experts and reviewed by multiple ones as opposed to "Rolling your own". [4]
• JavaScript cryptography is bad. [5]

I've also quickly skimmed a couple other static site generators, namely (Jekyll, Hyde, Hakyll and Frozen-flask) and I don't think they offer an option to encrypt posts.

[1] http://blogs.technet.com/b/srd/archive/2013/11/12/security-advisory-2868725-recommendation-to-disable-rc4.aspx
[2] http://www.wisdom.weizmann.ac.il/~itsik/RC4/rc4.html
[3] https://tools.ietf.org/html/draft-ietf-tls-prohibiting-rc4-01
[4] http://security.stackexchange.com/a/18198
[5] http://matasano.com/articles/javascript-cryptography/

[Kwpolska]

We are aware of the issues connected with this misfeature. It was (probably) inspired by WordPress, which has the comfort of being able to do it with dynamic pages and a database.

Putting up some big and scary warnings now. One day, the thing should be disabled altogether.

[felixfontein]

I have some comments on that:

• First, avoiding RC4 is good. But also in crypto, there's not only black and white, and depending on what you use it for, RC4 can still be fine. Especially if you get rid of the first thousands of bytes of the output stream (at least there is no open knowledge on how to attack RC4 then).
• Second, while it is indeed true not to roll own implementations, I don't see how that applies to Nikola. RC4 is used in a standard (even though bad, since the stream is used from the beginning) way.
• Third, while JavaScript crypto is not a good idea, it depends a lot on in which contexts it is used. In the way it is used in Nikola, I doubt there is a problem for most cases. In particular, there's no alternative to doing JavaScript crypto if you don't want to add extra burden to the site's visitor (like using external programs or installing special browser plugins).

So instead of deprecating the feature, I'd suggest to:

• add a warning that this feature should not be used for sensitive data (which Kwpolska already did);
• replace RC4 by another stream cipher or at least skip the first thousands of bytes from the output stream;
• use a MAC.

Cheers,
Felix

[Kwpolska]

The password feature is, among others, a proof-of-concept feature that is probably not very popular among our users.

Introduced here: http://ralsina.me/weblog/posts/the-password-is-password-follow-the-link-to-see-what-i-mean.html

I found a total of two actual posts using this feature all over the Internet. (not posting links here for the safety of those people)

[felixfontein]

In that case, deprecating it seems fine, and leaving improving the thing (by using another cipher, such as ChaCha20, and some kind of MAC) to later in case there's more interest in using the feature.

[ralsina]

There is no way to implement this in a safe and secure manner, specially since you'd need to find two implementations of whatever crypto system you prefer, one in JS and one in Python, which are mutually inteligible and both safe.

OTOH this is meant for things like "use this password to read this review, it has spoilers" rather than "here are the diagrams to my secret terror weapon, don't tell anyone".

The feature not being in other SSGs is hardly important, and as long as it breaks nothing (and it doesn't) I don't see why it needs removing. Unless you actually use it, it will do nothing to your output.

[ralsina]

OTOOH I could reimplement this as a restructured text directive which is niftier and would allow it to be a plugin cleanly.

[devurandom]

I found a total of two actual posts using this feature all over the Internet. (not posting links here for the safety of those people)

I tried to use it once. I think to create two views of my blog, for different groups of people. It did not work out very well for some reason, so I removed the pages instead.

I think initially I tried it also for general access control, but then ran into some kind of wall. Thus I went with HTTP Basic authentication instead. I manage it through (manually set up) Mercurial post-receive hooks. The result looks a lot more technical and ugly than an in-page password field might, is not very nice to setup, but it was ok for my usecase.

[toolforger]

For hiding spoilers, people should simply use white-on-white text and tell users to mark the spoilerish part of the page.
Javascript is going to sit badly with security-aware visitors, and Nikola is designed to allow more security in the net after all (though I'll admit that's visitor security, and Nikola is about server security, so that's not a killer criterion).