[16621] in bugtraq
Re: Intacct.com: Multiple bugs at financial services company
daemon@ATHENA.MIT.EDU (Alan DeKok)
Wed Sep 6 20:15:37 2000
Message-Id: <200009061734.NAA30113@cpu1751.adsl.bellglobal.com>
Date: Wed, 6 Sep 2000 13:34:27 -0400
Reply-To: Alan DeKok <aland@STRIKER.OTTAWA.ON.CA>
From: Alan DeKok <aland@STRIKER.OTTAWA.ON.CA>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: Your message of "Wed, 06 Sep 2000 07:48:01 EDT."
<20000906074800.A10422@unixzone.com>
"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.
