Skip to content
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

Implement auto-passwords mode #222

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

CyberShadow
Copy link
Contributor

@CyberShadow CyberShadow commented Mar 5, 2018

This mode is automatically enabled iff:

  • The password field is disabled
  • Normal login is disabled
  • Automatic login is enabled

In this mode, the login hash cookie acts as the only needed
authentication. It is assigned automatically when the user posts
something for the first time, and allows them to redact all comments made
while still in possession of said cookie.

Fixes #212.

Soft dependency on #220 to allow disabling the password field via the administration panel.

This mode is automatically enabled iff:

- The password field is disabled
- Normal login is disabled
- Automatic login is enabled

In this mode, the login hash cookie acts as the only needed
authentication. It is assigned automatically when the user posts
something for the first time, and allows them to redact all comments made
while still in possession of said cookie.
@jacobwb
Copy link
Owner

jacobwb commented Nov 16, 2019

@Ace2213

Unfortunately, no.

Not only is this a new feature, which aren't being considered for 2.0, but it also introduces a major security problem that the code (to the best of my memory) makes no effort to prevent. This being the permanence of the random login token, which allows an attacker infinite time to generate a matching token via a rainbow table lookup or even bruteforce. If they can guess the token they have complete access to the comment including the email address, and they would be able to edit the comment to replace it with SPAM or defamatory language.

The reason this commit is relatively small, is because this feature is planned for a future release, as such most of the functionality to allow it already exists in the code. However, because of the security implications of such a feature, I have not implemented it. Mainly because I have not thought of a logical way to solve the underlying problem. That is, a way to make the randomly generated login token temporary or more difficult to guess without a significant performance impact.

I should probably close this request, but I also like to keep it open to remind myself to implement this feature. And now with this explanation of the problem, perhaps more people will suggest ways to fix the issues I have with the approach.

@CyberShadow
Copy link
Contributor Author

This being the permanence of the random login token, which allows an attacker infinite time to generate a matching token via a rainbow table lookup or even bruteforce.

Following this logic we should stop using public-key cryptography, because it's "possible" to brute-force a private key from the public key?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Implicit passwords/sessions
2 participants