- From: <bugzilla@jessica.w3.org>
- Date: Tue, 01 Feb 2011 01:38:19 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11912 --- Comment #5 from Jeremy <jeremy@blazonco.com> 2011-02-01 01:38:17 UTC --- (In reply to comment #4) > > Instead of transmitting the secret itself on every request. Why is that any > better? > That's what I'm trying to explain. I guess "better" is subjective, but the fewer levels of indirection that exist between what the user agent's secret and the actual secret, the more confident you can be that you are dealing with someone who has really provided the actual secret. If the user agent's secret is the actual secret, then you have minimized the indirection. To rephrase: if the user agent has sent the correct credentials, there is NO WAY that the user has not provided those credentials. If the user agent sends a session ID for a session in which someone has previously provided the correct credentials, then there IS a way that the user (of the current request) didn't provide those credentials. That's what I mean by 100% certain. > > It, or a hash of it, must be stored on the server so that the user can be > authenticated. You could store only a hash, but you could also store only a > hash of the cookie if you like. The only difference I see is that a cookie can > be invalidated without changing the underlying secret, so using a long-lived > cookie means a MITM won't be able to recover the actual password unless they > happen to be present on the rare occasions when it's sent. A MITM could > recover the password on every request if it's sent on every request. > SSL means this isn't a problem. Unless SSL is broken, in which case we have sure got a lot of bigger worries. > If you send the secret itself, the user could have merely stolen the secret. Sure, but we can't really consider it our responsibility to prevent the user from sharing their credentials. But we can do everything in our power to make sure that someone else isn't able to access the application as Joe User without his involvement. > I really can't see any attack against cookies that can't be carried out against > the system you describe by an attacker with the same capabilities. > > > If we're talking about a typical web application as you say, anyone with access > to the filesystem of the application server can almost certainly access the > database server anyway, one way or another. Web applications are typically > only secured against attackers outside the local network. (Of course, there > are surely some web apps that are atypical in this respect.) > This is exactly my point. This is a matter of opinion, but I think that what you describe above is somewhat irresponsible. If you have important data that should not be revealed to people that don't have valid credentials to your application, then it is not sufficient to secure only against the internet. Each tier of the application must also be secured against the others. > > In what typical (your word) web application would you log into the *database* > with the *user's* credentials? > Why do you suppose that user credentials and database credentials must be distinct? If an application user is also a database user (which makes logical sense, because in a way your application is merely a front-end for the database), then each user can even be assigned the appropriate privileges in the database to prevent that user from harming or stealing the data of other users. Now if Joe User does become the victim of social engineering, the hacker that stole his credentials will only be able to harm Joe User and not my entire userbase. And maybe Joe will learn something about trusting e-mails from the Official European Lottery. > > In my opinion, if an attacker gains access to your application servers, they're > generally going to be able to do enough evil things that trying to prevent them > from also accessing your database is fairly pointless. Again, this is a matter of opinion, and we are now decidedly off-topic in discussing security best practices rather than the HTML5 specification. But if a hacker somehow gains read access to my code or configuration (which is not outside the realm of possibility), I don't think he should be able to do evil things or log into my database. If the hacker gets write access to my code, then yes, I am pretty well hosed. But it's the developer's responsibility to close as many of these doors as possible, and connection strings are one such door (and sessions stored on disk are another). Since we're getting off-topic, let me just summarize the purpose of my proposal: 1. HTTP authentication is part of the HTTP standard and is fully RESTful, which session-based authentication is not. 2. I assert that HTTP authentication is useful and engenders good security practices, though not everyone agrees with this assertion. 3. HTTP authentication is missing a few key features which could be addressed in the HTML5 standard, which would make it nearly perfect. This could be accomplished without changing the existing HTTP authentication spec. Now, at the risk of further debate, let me ask: If by some miracle my proposal were accepted, and a year from now it were easily possible to use HTTP authentication (either basic or digest) and retain your nice-looking login forms and logout buttons, would you continue to use session-based authentication instead? If so, why? You would probably be able to eliminate sessions entirely from a large portion of your work and have fully RESTful web applications. What is it about cookies that make them better for authentication other than the fact that they currently have the features that would be addressed by my proposal? Jeremy -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Tuesday, 1 February 2011 01:38:21 UTC