Re:Security researchers 'destroy' Microsoft ASP.NET security
by dionysiac on Friday September 17, 2010 @05:22PM
(#1702882)
Storing something like a username in client-side data and then trusting its accuracy is effectively delegating your authentication outside you circle of control. Saying that encryption will make this magically secure is like saying encryption makes for effective DRM - eventually it will be compromised and you will have a systemic problem.
Storing, say, a username and a password hash in your encrypted cookie is at least as secure as direct authentication at each page load; even if they break your encryption they still have to know the admin's password.
Start with the assumption that the locks you use for security will fail, and ask "how will this break?" If we take the encryption out of the picture, do we trust the client to log in as root (or similar) with just a username and no password? The lock in question (as I understand it) is failing for an unrelated (information disclosure) reason. The design decision to lean so hard on the lock is what makes this such an issue.
There are cases where having sensitive information in a cookie makes sense. In a web farm, for example. A session store that serves a farm of web servers is harder to set up and maintain than having clients send information back in a cookie. If it's properly encrypted, then this shouldn't be a problem. (Signed cookies are also good for this scenario, if it's okay for the data to be seen by others)
Am I wrong?
EDIT: Here's a good thread on how to ensure data on client cookies hasn't been tampered with: http://news.ycombinator.com/item?id=1687826