Re: Intacct.com: Multiple bugs at financial services company

[Peter W <peterw () USA NET>]

At 7:48am Sep 6, 2000, Chris L. Mason 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.

> The user only sees the pop-up box once, because the browser caches
> this username and password, but only for the session.  If you exit and
> restart the browser you will be prompted to re-enter it.

Not true. The newer browsers are happy to cache user/password info after
exiting; whatever you may think of forcing re-authentication, Basic does
not guarantee this after the browser or even OS has been restarted.

> You don't need session management in the first place!  This means your code
> can be dramatically simplified. Authentication can happen at a higher
> level meaning CGI or other programs won't even be allowed to run until the
> authentication happens.

Who's to say non-Basic auth/session isn't implemented within the httpd?

> 1.  It's easy to use and more secure.

IFF you have a simple flat address space for usernames & static passwords.
With a hierarchical username space or more complex authentication methods
than unchanging passwords, it works poorly, if at all.

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

Not true. Your points #3 and #4 are dupes of this one, and also false. Not
using Basic auth does not imply or require URL mangling.

> 5.  Load-balancing and other schemes are simplified.

"other schemes"? Like what? Cookie-based auth lets me use the same
authentication information at different server names, which Basic does
not. It lets me provide authentication information to a single, more
trusted site (ala Kerberos) and only provide a temporary, random,
inherently meaningless ticket to other servers.

> 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*!!!

Which is why session timeouts must be enforced on the server side. Anyone
using set-cookie expiration headers to force session termination is making
a tactical mistake.

Another benefit of cookie-based auth is that sites can use SSL to protect
logins without having to serve every piece of content via SSL. The login
event issues an authentication token that is meaningless to the client but
meaningful to the backend servers. On a highly trafficked site, the
CPU savings of limiting the amount of https traffic can be significant.

Cookie-based systems also make possible (I'd better call the IP lawyers
now) things like "spot checks": issue more than one token. At random
times, or when something seems suspect (e.g., client network address
changes), flag the session as suspect and redirect the user's request to
the login server. The spot check token had been set only for a certain
path on the login server which has very, very well vetted code (and
therefore, hopefully, is not vulnerable to cross-site scripting). If the
login server sees a correct value for the spot check, it unflags the
session and sends the user back to the URL they requested. Subsequent
requests to the regular servers are denied until the login server approves
the spot check. Too many spot check failures and the session is
invalidated[0] on the server side. Etc.

Here's another idea for you Webmail providers, whom we love so much. Two
cookies, two server names. MAINCOOKIE on mainserver.exmaple.com only goes
to that exact server, and mainserver.example.com only displays VERY
carefully scrubbed data (e.g. system menus, pages with HTML completely
escaped, unexpected characters removed, etc.). READCOOKIE is set by
mainserver.example.com for the purpose of reading, and is scoped for
".example.com". When a user clicks on a link to read a message, that link
goes to something like
 mainserver.exmaple.com/readcookie?msg=12345
which sees MAINCOOKIE, creates and sets a new, random READCOOKIE that
uniquely identifies the user and the message, and then redirects to
 readserver.example.com/readmessage
which parses READCOOKIE, verifies, and displays the mail message. If some
hostile Javascript sneaked in to the mail message, that code would only
have access to READCOOKIE. So it could only be used to call the URL on
readserver that would display that same message, so the gain for the black
hat is pretty much nil. Might expose some identities, e.g. associate
"whistleblower () freemail example org" with "poorhonestgal () example net", but
even that could be fixed if the /readmessage app invalidated the
READCOOKIE as soon as it processed the request. There. Zero gain. And we
can process the original webmail login over SSL for safety but display
mail over http for performance.

I don't mean to discount the significant problem that cross-site scripting
can pose to cookie-based Web "sessions", but Basic auth is NOT clearly
better than cookies. Basic auth over https can be quite good. Basic auth
over cleartext HTTP is risky. Cookie mechanisms are only as good as their
designs, and the anti-cross-site-scripting measures employed on the
appropriate servers.

-Peter

[0] When I talk about invalisating something, I mean on the server side.
Keep the cookie as long as you'd like; at some point (timeout, deliberate
logout, security problem) the server will refuse to honor it.