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
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
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
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
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
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.