An authentication token as part of a URL

I had a hard time picking a title for this post, so I’d better get straight to the problem and explain it with an example. Suppose we have a comment system and want every writer to be able to edit their comment later. We don’t want writers to have to log in or register anywhere, so we need to work out how to authenticate them.

Possible scenarios

A password for each comment

1. The writer creates a comment and enters a password for it, or has one generated.
2. When they try to edit the comment, the writer has to enter the password.

The drawback is obvious. The writer has to remember 
a password for every comment unless they choose the same password everywhere. We could change the system like this.

1. The writer creates a comment.
2. The writer receives a URL for editing the comment, including the password.
3. When they want to edit, they use that URL.

The URL, or rather the GET request, would of course use HTTPS. For example: 
https://server/editComment.foo?commentId=1&pass=bflmpsvz. HTTPS secures the connection,
but the password is still plainly visible in the browser’s address bar.
It would be better to get the password out of the URL.

Part of the URL as an authentication token

1. The writer creates a comment.
2. The writer receives a URL with an authentication token for editing.
3. When they want to edit, they use that URL.

Again we assume the GET request itself goes over a secure connection. The trick 
 is that the URL is unique and takes time to crack. The server ensures the generated URL is unique and could proceed, for example, as follows.

1. The server takes the comment identifier.
2. It modifies the comment identifier using a constant, for instance by swapping the first and last characters.
3. It runs the modified identifier through a symmetric cipher.
4. It puts the encrypted identifier into the URL using Base64.

The resulting URL might look like this: https://server/editComment.foo?hoo=U9j5SVoEynNKsj4f1XQLVQ. When an edit request comes in, the procedure is reversed. The advantage is that simply changing the URL won’t accomplish anything, and someone trying to break it would need brute force. The disadvantage is that the writer won’t remember a URL made this way, though neither will, for example, someone walking past in an internet café.