- From: <bugzilla@jessica.w3.org>
- Date: Fri, 04 Mar 2011 02:27:57 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11912 --- Comment #14 from Aryeh Gregor <Simetrical+w3cbug@gmail.com> 2011-03-04 02:27:57 UTC --- (In reply to comment #13) > 1. For the spoofing attack, now I just have to figure out where you store the > key. Or are you generating a new key on each request? No matter how many > levels of indirection you put between me and the stored session key, I can > still get to it. There is simply no way to make it impossible; only really > hard. No, you just use the same key. If the attacker gets the key, so what? They still don't have anything useful until they get a cookie, and the server doesn't store the cookies. If they get the key plus also the contents of an HTTP request, they get that specific user's password, but that problem occurs in your scheme too. > 2. You're still storing your database credentials using this mechanism. No, you're not. The application server only stores the key, which is useless without the cookie. It throws away the cookie as soon as it gets it and stores no info related to it, just like with username/password in HTTP auth. The cookie here isn't used as a key into some kind of session info storage, it contains the actual login info in encrypted form. Actually, for that matter, you could dispense with the encryption. Just have the cookie contain the username and password in plaintext. This is precisely equivalent in security to HTTP auth on a protocol level, because precisely the same information is included in every request. With the username and password included in the request, the web server needs to store no auth info at all. -- 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 Friday, 4 March 2011 02:28:00 UTC