|
|
|
|
|
by dionysiac
5747 days ago
|
|
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. |
|