hashover-next

hashover-next copied to clipboard

In case passwords are disabled (or maybe the user doesn't even want to provide one) there should be a way for a user to edit his own comment.

My proposal is to enable comment editing but set a time limit like e.g. 5 minutes. (probably making it an enable/disable feature for those who maybe don't want it).

Rough idea:

• user without pass makes post
• a 5 min editing period is granted based off his current IP
• refresh the period with each new post

I think this would be really helpful and beneficial for user engagement.

This wasn't possible before the current login implementation, and might still require many changes to how logins are handled and quite possibly what information is stored to make such a feature possible.

But I like it.

Below is basically a note to myself. However, this should also serve to give you, and other people an idea of why this feature might take a while to properly implement.

Currently, all cookies, including those for logins, automatically expire a month after the user logged in. Subtracting from that a configurable amount of time should be easy. The only problem I see is the method in which the code stores the information necessary to allow temporary editing. Because, an attacker could easily allow themselves editing rights by simply setting their IP address to something random until they get editing rights, or if the authorization is done with cookies, than they could also set their local cookies to something random until they get editing rights that way.

There are two conditions that need to be met:

1. A randomly generated authorization token based on strong encryption needs to be stored.
2. Said authorization token needs to somehow carry information about how long its valid.

It would definitely be a big improvement.

From what I've been reading and as you mentioned, cookies are insecure if not run over https.

What's the alternative? Perhaps storing the information in an encrypted file on disk?

From what I've been reading and as you mentioned, cookies are insecure if not run over https.

What's the alternative? Perhaps storing the information in an encrypted file on disk?

Some information is already stored encrypted on disk, login tokens, e-mails and passwords, for example. The problem is with accessing that information.

You need something from the user to compare with the encrypted data. With logins for example, the user gives both a name and a password when they post a comment, that information is used to create a login token which is stored with their comment. When a user logs in, they get a cookie that holds this login token. When HashOver loads the comments, the login token cookie is compared to the one stored in their comments. If they match, they get the edit button and other login features.

This way an attacker can't know the information in the comments, but the attacker can get that information from the user's cookies or post data on plain HTTP.

The only way to get that functionality across multiple page loads is with cookies. There's no way to send something to HashOver without using either cookies or get/post data from a form, and both need to be sent over HTTPS to be secure. So cookies and post data are used where appropriate.

However, I'm not a security expert, if there is a better way to do this that I'm not aware of I would implement it immediately. I consider this one of the most important security related things to get right, and needs to be done before 2.0 would be considered anywhere near releasable.