dionysiac
Joined 17 years ago
Joined 17 years ago
I know that systems such as OpenID and others perform authentication directly between the user and thetrusted provider (google, facebook, twitter, etc), and that the site ends up with a one-time token that confirms the user's identity. The site requesting authentication never gets the actual password to the openID account, which makes this approach viable in a technical security sense.
But here's the thing: general users are getting used to entering their centralized credentials to perform actions on untrusted sites. Technical users understand the design. We can confirm that, yes, TwitScoop does indeed direct us to twitter.com/oauth/... (no HTTPS, but that's another story).
Regular users posting a comment on a blog, though, don't see any difference between giving their credentials to a trusted Google login site and entering their credentials into some form on a blog.
If, for example, logging in with Facebook credentials becomes common, it would be trivial to create a rogue blog which collects login information. Fill it with a few incendiary posts, possibly create an official-looking Facebook login page that doesn't display its URL, and it would be possible to capture quite a few sets of credentials.
# time find / -maxdepth 3 -perm -7 -type d -print
/tmp
/var/tmp
real 0m0.034s
user 0m0.005s
sys 0m0.028s
This was run on a pretty anemic VPS. Might have to up the depth to 4 if it doesn't return anything, but IMO that's pretty unlikely. find / -maxdepth 3 -perm -7 -type d -print
and tweak as needed.Many people consuming alcohol are doing so for similar reasons.
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.
This.