New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecate the ability to encrypt posts #1547

Closed
muattiyah opened this Issue Dec 23, 2014 · 8 comments

Comments

Projects
None yet
6 participants
@muattiyah
Contributor

muattiyah commented Dec 23, 2014

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

This comment has been minimized.

Show comment
Hide comment
@Kwpolska

Kwpolska Dec 23, 2014

Member

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.

Member

Kwpolska commented Dec 23, 2014

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.

@Kwpolska Kwpolska closed this in 82ae756 Dec 23, 2014

@felixfontein

This comment has been minimized.

Show comment
Hide comment
@felixfontein

felixfontein Dec 23, 2014

Contributor

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

Contributor

felixfontein commented Dec 23, 2014

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

This comment has been minimized.

Show comment
Hide comment
@Kwpolska

Kwpolska Dec 23, 2014

Member

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)

Member

Kwpolska commented Dec 23, 2014

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

This comment has been minimized.

Show comment
Hide comment
@felixfontein

felixfontein Dec 23, 2014

Contributor

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.

Contributor

felixfontein commented Dec 23, 2014

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

This comment has been minimized.

Show comment
Hide comment
@ralsina

ralsina Jan 2, 2015

Member

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.

Member

ralsina commented Jan 2, 2015

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

This comment has been minimized.

Show comment
Hide comment
@ralsina

ralsina Jan 2, 2015

Member

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

Member

ralsina commented Jan 2, 2015

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

@devurandom

This comment has been minimized.

Show comment
Hide comment
@devurandom

devurandom Jan 15, 2015

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.

devurandom commented Jan 15, 2015

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

This comment has been minimized.

Show comment
Hide comment
@toolforger

toolforger Feb 27, 2015

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

toolforger commented Feb 27, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment