I have two scenarios and want to know if each is secure or which risk there are.

Number One:

If the User has the edit Link (edit/[md5hash]) he can edit a post. The editkey (the hash) is in an form hidden field to tell the Controller Action which post is going to be edited.

The user could edit the value of that field, but would need other keys, to change other posts, wouldn't he?

Number Two:

When the user creates a post. A cookie with the name "post[id]" and the md5-edit-hash as value is set.

When a post is requested the controller checks if the edit-hash in that cookie (if it exists) is the same as in the post data.

It is unsafe if many people would share the browser and the cookies are not reseted, isn't it? Are there any other issues or any solutions to make it safer and better?

Thank You


I'm using Laravel 3 - a PHP Framwork Yes, I'm avoiding authentication for special reasons ;)

I could use any other hash method like SHA, if this would be a problem

The hash is generated from a timestamp + salt + postid + salt + authorname

  • 1
    Please provide more details about the platform and what you are trying to do. It sounds like you are trying to avoid authentication and session management? – Eric G May 1 '13 at 23:08

I don't see any resemblance of access control in either scenario. If you haven't been told this already: stop using md5! it is old, broken, and inefficient, use SHA-256 or just a simple cryptographic nonce.

In the first scenario if the attacker knows this magical "md5hash" then they will be able to always use this edit feature. How do you keep the user from obtaining this hash? How is this hash generated?

Scenario two seems even less secure, it is trivial to send an arbitrary post and cookie variable:

curl http://some_vulnerable_site.com/edit  --data "post[id]=1&hash=somevalue" --cookie "hash=somevalue"

All GET, POST, COOKIE, and HTTP header values are under the attackers control. A cookie should hold a session id, which references state about that user (a user id), which can be used to enforce access control to data.

If you want to know more about security, make sure you read the OWASP top 10. In terms of this post, you should read: OWASP A3- Broken Authentication and Session Management.

  • Thank you! @scenario2: When the attacker sets a cookie with a random value and uses this in the form, it won't work because the hash has to match the hash of the edited post. Or maybe I'm not unterstanding what you are trying to tell me – Bernd Strehl May 2 '13 at 0:00
  • @Strernd Why would the attacker not know this value? How is this value generated? – rook May 2 '13 at 0:20
  • Its generated from a timestamp + salt + postid + salt + authorname – Bernd Strehl May 2 '13 at 12:12
  • @Strernd edit your post, this is the most important piece if information you could have included. Now the real question is, how are you keeping this hash a secret if you don't have a session id? And if you have a session id, why not just use that to enforce access control? – rook May 2 '13 at 17:07
  • If i would require a session for the user to edit the post. He wouldn't be able to come back later and edit the post, when he lost the session. – Bernd Strehl May 3 '13 at 10:12

You are implying security by obscurity. That is this is a large random number that could not easily be guessed, and might take some time to brute force through. However, since you are hashing a value, the md5 value becomes more predictable - maybe tied to some known variables. Increased randomness is better, but it misses the point.

These types of values are sometimes used for email resets, support tickets, etc. When used this way they should be time restricted or for read only access. If you are going over HTTPS then it would be more difficult, but not improbable for an attacker to get this magic value (MiTM, loca attack, prediction attacks, etc.).

If you do not want to implement a full authentication system, you may want to consider a random hash + some type of pin per post. If the pin is not based upon the hash, then this is in some ways a per-page/edit password. However, you still have a lot of considerations and I would advise against creating your authentication system. If you do it wrong, you may end up exposing the credentials or making it easily bypassed.

Just because you have authentication doesn't mean you need to do an email verification, etc. It sounds like perhaps you are worried that your users do not want to be tracked or make the effort to setup an account, and that if they had to go through all of the authentication, they would just go use another service. You can do authentication like they do on hacker news, where you just create an account with a password, and its not tied to email.

In the long term I would recommend increasing the value proposition of your website so that users want to use real authentication. If its a privacy thing, let them use throw away email accounts or no email accounts at all. Even without accounts, its trivial to track individual users on a website.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.