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

[Matt Power <mhpower () MIT EDU>]

>         ... More sites simply need to start using HTTP Basic
> Access Authentication. ...
> 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 ...

Using HTTP Basic Authentication in this way is a disservice to a
customer because it, in practice, forces him to leave a valuable
static password in the process memory of his web browser. The password
may be revealed to unauthorized persons in a number of circumstances:

  -- the web browser may be running on Unix and die (e.g., due to a
     segmentation fault) leading to a core file. It is likely that the
     character sequence corresponding to the static password will
     occur somewhere in the core file. The core file may be written
     to a local disk and might have permissions allowing it to be read
     by other local users. Alternatively, the core file may be written
     over an unencrypted distributed filesystem (e.g., NFS) and its
     contents may thus be readable by network sniffers.

  -- the client machine might be compromised some time after the
     password is typed, and the intruder can then retrieve the password
     from the web-browser process memory by using pcat or gcore. The
     intruder may also find the password in the machine's swap space.
     In some cases (e.g., when the intrusion is detected promptly)
     this threat is much more significant than the threat that the
     intruder will retain access until the next time the password is
     typed (and thereby be able to steal the password as it is typed).

If the web-browser process memory instead contains a credential that's
applicable only to the current session, and does not contain a static
password, then the risks associated with process-memory compromise are
typically much smaller. For example, this transitory credential might
automatically become recognized as invalid by the server if it is not
presented for a long time, the server might conceivably consider the
credential valid only if it is presented in a TCP connection from a
particular IP address, etc. Also, an intruder who has captured a
static password can try using that password to log into other
accounts, and this is likely to be effective since many users neglect
to choose different passwords for each of their web-site and
machine-login accounts. Sending a captured transitory credential to
another unrelated web site is just about guaranteed to be useless.

It is of course true that some passwords that are typed into a web
browser in order to obtain a transitory credential will linger in
process memory for a long time. However, there is no strong need for
that to happen: the web browser could, for example, overwrite all
buffers used for form input with zeros at some appropriate time. With
Basic Authentication, however, the web browser needs to maintain
either the plaintext password or its (just as valuable) base64
representation in process memory for a long time, since otherwise the
web browser can't resend the required authentication data.

I reported a related problem to Netscape on 3 August 2000, but did not
receive a reply (admittedly, their problem-report mechanism
http://help.netscape.com/forms/bug-security.html required me to
explicitly agree that I wouldn't receive a reply). The reported
problem (which still exists in at least Netscape Communicator 4.75 on
Red Hat Linux 6.2 i386) was that a password typed for Basic
Authentication to an https site remains in process memory even if the
user aborts the login attempt at the authorization-retry window. If
anyone wants a copy of the full report that I sent to Netscape about
that, please send me e-mail and I'll make it available.

Matt Power
mhpower () mit edu