Skip to content

Implement auto-passwords mode#222

Open
CyberShadow wants to merge 1 commit into
jacobwb:masterfrom
CyberShadow:autopasswords
Open

Implement auto-passwords mode#222
CyberShadow wants to merge 1 commit into
jacobwb:masterfrom
CyberShadow:autopasswords

Conversation

@CyberShadow
Copy link
Copy Markdown
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.
@CyberShadow CyberShadow mentioned this pull request Jun 12, 2019
@jacobwb
Copy link
Copy Markdown
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
Copy Markdown
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