Date: 2000/10/25 20:08:32
This report is also available in PostScript.
The Bank One Online Banking service uses an insecure method of storing customer banking information, which puts customers' credit card numbers at risk of exposure. Access control to customer accounts also appears to be lacking. The risks that we discuss here are not theoretical; these are real problems that must be addressed immediately.
Storage of this information on the client side is insecure and the cookie is inappropriately protected against accidental transmission in the clear.
On machines where multiple users share the same browser profile, such access is trivial.
Another related attack works just like this, except instead of having access to the local disk, the attacker has access to the same network as the target and the user's cookies file is stored on a ``network drive'', or remote filesystem. In such a case, the sensitive information is likely to be transmitted across the network between the client and the remote filesystem's server in the clear. Thus, even though the cookie itself is transmitted over an encrypted channel (namely TLS  or its predecessor, SSL ), the action of writing that cookie to disk causes the data to be transmitted across the local network in the clear.
Obviously, any user with administrative access to the filesystem (or its backups) would have the ability to read the sensitive information as well.
Additionally, one precaution that could be used is not. Cookies can be tagged as ``secure'', which means that the client will not transmit the cookie to the server unless the connection is encrypted. The cookie with this account information is clearly designed to operate only where the session is encrypted, so that the account number will not be sent over the Internet in the clear. However, the flag that would prevent the browser from sending the cookie in the clear is not set. Thus, any connection to any site in the bankoneonline.com domain where the URL contains the string ``/logon'' will cause the browser to send the cookie to the server, whether the session is encrypted or not.
To use the cookie to impersonate the user, an attacker will also need to supply a personal identification number (PIN). With fewer than 10,000 possible combinations, the probability of guessing the proper PIN needed to access the account is not low enough to make such an attack unlikely to yield results. (Although the PIN is four digits long, certain sequences are disallowed, thus reducing the number of possible combinations.) That is, if an attacker were to collect 10,000 cookies, the odds are in his favor that he would guess one PIN from that lot correctly on the first guess. The more attempts he gets, the better his odds are.
In the case where the account number is used as a credit card or debit card, an attacker has an even easier time, since the only other information that the attacker will need to abuse the card in many cases is an expiration date. (Some abuses can take place without knowing the correct expiration date, but in the general case, the correct expiration date will be needed to make a purchase.) If credit cards are only active for three years at a time and the granularity of expiration dates is one month, then the attacker has a one in 36 (12 months times three years) chance of guessing the correct expiration date on the first try. Again, the more guesses he gets, the better his odds are.
Given the potential value of account access or use of a credit or debit card to an attacker, odds like this are completely insufficient for protecting the security of users. The risk here is very real and it must be addressed immediately.
For the long term, user authentication for account information access must be made more robust. This almost certainly means decreased convenience, at the very least in the form of longer PINs. However, given the fact that the cost of fraud is borne by the financial system's customers, insistence on convenience far above security will result in higher costs and greater hassle in dealing with abuses of this information. Dismissing security concerns is only in the interest of attackers.
Cookies used to store state information must be made completely unusable outside of the scope of the application in which they're used. That is, a user ID token in a cookie should not be connected to information that can be used to impersonate the holder of that cookie.
Cookies intended to be transmitted only in an encrypted channel should be marked as ``secure'', which will prevent the client from sending the token in the clear. Although one could argue that the server is under the control of the issuer of the cookie and thus able to be guaranteed never to be transmitted in the clear, failing to take advantage of available precautions is poor security practice, particularly when this results in a single point of failure.
Computing, particularly mainstream commodity computing, has been driven by the credo ``more features, faster, cheaper''. This optimization is completely inappropriate for Internet-based applications, particularly in cases where failure can result in such severe consequences.
We strongly suggest that designers and implementors of systems consider the failures discussed here to learn from these mistakes and to avoid making them again.
This document was generated using the LaTeX2HTML translator Version 97.1 (release) (July 13th, 1997)
Copyright © 1993, 1994, 1995, 1996, 1997, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
The command line arguments were:
latex2html -split 0 -no_navigation -show_section_numbers bankone-online.
The translation was initiated by Matt Curtin on 10/25/2000