Bugtraq mailing list archives
Re: Intacct.com: Multiple bugs at financial services company
From: Alan DeKok <aland () STRIKER OTTAWA ON CA>
Date: Wed, 6 Sep 2000 13:34:27 -0400
"Chris L. Mason" <cmason () UNIXZONE COM> wrote:
I think there's a solution to this "problem" that is far too often overlooked. More sites simply need to start using HTTP Basic Access Authentication.
HTTP Basic Access Authentication is broken in many respects. The passwords are effectively sent over the wire in the *clear*.
The beauty of this method of authentication is that the username and password are not just sent once, but are actually sent with *every* single request (for html, form submission, even image files.)
And the web server re-authenticates them every time. Without some form of persistent state (e.g. cookies), it has no other choice. This re-authentication imposes an additional load on the web server, and on any underlying authentication mechanism. e.g. RedHat's pam_pwdb, which can take *seconds* to perform a getpwnam() call on a large /etc/passwd file.
So what advantages does this provide?
Not a lot.
You don't need session management in the first place!
There is implicit session management taking place.
What advantages does this provide your customers? 1. It's easy to use and more secure.
Clear-text passwords aren't much more secure than any other broken method of "authentication". Some systems require authentication to access web pages, but the actual content of those pages is public. In that case, SSL + Basic Digest Authentication + Cookie is sufficient for authentication. The username/password is sent via an SSL connection, so it's secure. A cookie is set over that connection, and the user is re-directed to insecure pages. The insecure pages then verify the cookie for each request. The cookie SHOULD contain information about the user and their IP address, and when the cookie expires. While the cookie is just as visible to network sniffing as an HTTP Basic Authentication password, it's a lot more difficult for an attacker to use that cookie to gain access to access-controlled pages. At the most, one particular session can be hijacked via spoofing the TCP connection and stealing the cookie. But this attack does not affect other sessions. That's a key requirement of many secure-session protocols: Breaking one session MUST NOT affect the security of other sessions. HTTP Basic Authentication does not satisfy this requirement.
2. Users can bookmark pages *within* a site and return to them and still be properly authenticated. With fake login/logout paradigms forced on the user this isn't possible. Use the web the way it's supposed to be used!
Cookies also allow that to be done.
5. Load-balancing and other schemes are simplified. With complex session- and key-management it can be difficult to spread load across a group of systems. Since HTTP Basic Access Authentication is stateless, you don't care anymore which server a user goes to. Each subsequent request can go to a completely different server and everything will still work. This makes things much easier meaning it can be cheaper, faster, and more reliable.
A similar argument can be made for well-constructed cookies.
The only real argument I've ever heard against using this method of authentication is that you can't force the client to time-out after a certain period (10 minutes, etc.) Well, guess what, you're just deceiving yourself if you think you can. Remember that: THE CLIENT IS *UNTRUSTED*!!!
The timeout information can be encoded in a cookie, too. The server can then verify that the cookie is out of date, deny access, and ask "pretty-please" for the client to delete the cookie. If the client doesn't delete the cookie, they *still* can't gain access, as the cookie itself contains information about when it expires. e.g. cookie = MD5(secret + MD5(secret + expiry + client-IP + client-ID)) + expiry + client-id Where '+' is string concatenation. The secret is local to the web server(s), and should change often. The MD5 operations with the secret ties the cookie to that particular session, expiry time, and client ID.
The point is you can never control what the client will do. What if they just write their password on a yellow sticky and put it on their monitor? Anyone walking by could use it then!
There's obviously little that can be done on the server end to prevent these type of security breaches.
I wish companies would focus on providing services as secure as possible at their end. You only control *your* systems, so focus on securing *them*. I think if you consider the benefits to yourselves and your customers it should be obvious which architecture is better.
i.e. Don't trust input from the client, unless you've validated it yourself. HTTP Basic Authentication is a nice suggestion, but as a security solution, it's not much better than having written passwords on notes stuck to your monitor. Using one-time passwords with Basic Authentication makes a lot more sense. If implemented properly, cookies *can* lower the risk of untrusted users gaining access. But it takes some thought to come up with a method for setting and structuring the cookie, which satisfies both the usability and security concerns. Alan DeKok.
Current thread:
- Re: Intacct.com: Multiple bugs at financial services company Nagi Prabhu (Sep 05)
- Re: Intacct.com: Multiple bugs at financial services company Jeffrey W. Baker (Sep 05)
- Re: Intacct.com: Multiple bugs at financial services company Chris L. Mason (Sep 06)
- Re: Intacct.com: Multiple bugs at financial services company Peter W (Sep 06)
- Re: Intacct.com: Multiple bugs at financial services company Alan DeKok (Sep 06)
- Re: Intacct.com: Multiple bugs at financial services company Andrew Pimlott (Sep 06)
- Re: Intacct.com: Multiple bugs at financial services company Aaron Bentley (Sep 06)
- Re: Intacct.com: Multiple bugs at financial services company Rob Mayoff (Sep 06)
- Re: Intacct.com: Multiple bugs at financial services company Matt Power (Sep 06)
- Re: Intacct.com: Multiple bugs at financial services company Chris L. Mason (Sep 06)
- Re: Intacct.com: Multiple bugs at financial services company Ryan Russell (Sep 05)
- <Possible follow-ups>
- Re: Intacct.com: Multiple bugs at financial services company Smith, Eric V. (Sep 07)
- Re: Intacct.com: Multiple bugs at financial services company Jeffrey W. Baker (Sep 05)