Note: My Web pages are best viewed with style sheets enabled.
|
Note: My Web pages are best viewed with style sheets enabled. |
Unrated |
California Oaks State Bank finally fixed their Web site … sort of.
The user ID is still input on an unsecure page. However, the password is now input on a separate, secure page. This provides sufficient security to satisfy me.
9 May 2007
California Oaks State Bank was merged into California United Bank effective 1 January 2011.
29 January 2011
California United Bank was later merged into Pacific Western Bank in 2017. All Web pages of Pacific Western Bank — not merely the login — are secure. Nevertheless, I am keeping this Web page on my site as a warning to others that they should remain alert regarding the security of their online management of their finances.
2 April 2022
*** Begin Left Sidebar ***
No, this page is not secure; and there is no encryption. But California Oaks put this lock symbol next to its login to convince its depositors that their login is secure. Any good browser will indicate there is no security for this page and for California Oaks' page. The legend 128bit SSL Encryption that appears when a cursor is over the lock is meaningless, generated on the California Oaks pages by a script and not by any encryption capability.
*** End Left Sidebar ***
Late in September 2006, California Oaks State Bank — a small local bank in Ventura County, California — "upgraded" its Web site. The old site provided security for Web access to accounts. As described in my letter to the President of California Oaks, however, the new site is completely insecure for logging-in. My letter also describes why this is significant.
As my letter indicated, I attempted more than once to bring this problem privately to the attention of California Oaks. These attempts were unsuccessful in convincing anyone at the bank that they even had a problem. In general, most of the bank's employees to whom I talked did not even understand the concept of secure Web pages.
To summarize the problem with the revised Web site, a depositor's user ID and password are now transmitted from his or her computer to the bank's server without being encrypted. This means there is no protection against the ID and password being intercepted as they pass through various intermediate servers and routers (more than 12 such intermediaries between my PC and the bank, whose offices are less than 10 miles from my home). With a depositor's ID and password, a hacker can then change the E-mail address for the account and thus block messages from the bank to the depositor. A hacker can change the password on the account, locking the depositor out of Web access to the account and thus preventing the depositor from seeing unauthorized activity on that account. Most important, a hacker can then setup transfers and "Bill Pay" capabilities and then drain all the funds from the account. The fact that all these operations are performed through securely encrypted Web pages does not mitigate the lack of a secure login for reaching those secure pages.
The following is completely false with respect to inputting a user's ID and password. No encryption is used for transmitting the ID or password from the user's computer to the bank's server. Obscuring the password with asterisks merely hides it from the user but not from anyone intercepting the password along the Internet.
For your protection, our servers require the browser to connect at 128-bit encryption. Users will be unable access online banking functions at lesser encryption levels. This may require some end users to upgrade their browser to the stronger encryption level in order to access online banking functions. If your browser does not support 128-bit encryption, you will need to upgrade to a browser that does in order to continue to access secure pages of the website.
California Oaks State Bank, Security
All that means is that the backdoor is double locked while the front door is standing wide open.
My initial private communications to California Oaks were clearly the ethical way to handle the situation. Opinions are quite divided, however, on how to proceed when that action is unsuccessful. Following is my analysis of the two possible approaches: keep the information private or make a public disclosure.
| Keep Private | Public Disclosure |
|---|---|
| If the information is kept private, hackers and others with criminal intent will not know of the vulnerability unless they expend their own efforts to search for it. | Making the information public encourages those with criminal intent to target the vulnerability. |
| Keeping the information private prevents the bank's customers from knowing that they need to defend themselves against the risks of compromising their IDs and passwords. However, many of the bank's customers might not know how to respond if the information were public. | Making the information public informs the bank's customers that they are at risk of compromising their accounts. If the information is not publicly disclosed, greater damage might occur from that compromise before it is detected. |
| Keeping the information private may allow more time for criminals to access depositors' accounts without any detection. | Making the information public alerts depositors to watch for unauthorized Web-based account activity. |
| Keeping the information private reduces the incentive for the bank to correct the vulnerability or least reduces the bank's urgency in addressing the problem. | Making the information public pressures the bank into taking prompt action. If the problem cannot be quickly fixed, the bank might even act to shut-down its Web site to protect its customers. |
| Keeping the information private allows the bank to continue its false assertion that its Web site is completely secure. | The public has the right to know the truth about the security of the bank's Web site. |
After much thought, my conclusion was that — when information about a security vulnerability is given privately to those with the authority to correct the situation but they fail to act or even respond after the elapse of a reasonable amount of time — public disclosure is not only appropriate but also necessary for the public good. This is especially true when false claims of reliable, trustworthy security are made.
Having waited more than two weeks with neither a response to my letter nor any corrective measures at the California Oaks Web site — almost a month after I first tried to bring the problem to the attention of California Oaks employees — I decided that making a public disclosure of this security vulnerability would do more good for California Oaks' depositors than keeping it private. I could not leave unchallenged the false assertion regarding the security of the bank's Web site. The risks to the depositors were too great. Thus, I placed this page on my Web site.
However, I did find a work-around for the lack of security when logging-in. I remembered that other secure Web sites will sometimes provide an alternative page for logging-in if an invalid user ID or password is attempted. So I tried the user ID Garbage and the password xyz123abc. Lo and behold! A secure Web page appeared where I could try my ID and password again, this time using the real ones. This is really not the way a secure banking Web site should work. But if I want to access my account via the Web, this is the only way I can login securely.
29 October 2006
In an interview with Computerworld, H.D. Moore of the Metasploit Project also argues convincingly in favor of disclosure. In many cases, Moore asserts, withholding publicity about security flaws makes the public more vulnerable than keeping them secret, even if the publicity enables hostile actions using the flaws.
6 December 2006
On its home page, California Oaks State Bank indicates the Web site was designed by Goldleaf Technologies. On its "Security" page, the Bank indicates that "Internet firewall and network security technologies" were provided by Fidelity National Information Services. The situation I describe here can only lead to doubts about the competencies of those two firms.
30 December 2006
In response to a letter I wrote to Goldleaf Technologies, I received a phone call today from a manager at that firm. He agreed that the pages where depositors can login at the California Oaks State Bank Web site are not secure. However, he also asserted that the actual logins occur through a script that uses a secure, encrypted connection to the bank's server.
After that phone call, I then reviewed the coding for the California Oaks State Bank home page, which does not show the use of a secure connection for the script. I could not access the script itself. More than 30 years as a software test engineer left me with a skepticism about what developers tell me. In this case, I have no way to verify that the login does indeed occur through a secure, encrypted connection to the bank's server. (I did note that the page had 45 HTML errors. In other words, it is non-standard and not coded in accord with published specifications.)
We are repeatedly advised:
If California Oaks State Bank does use a secure, encrypted connection when someone logs-in to its server, the evidence is not there. We must either ignore the warnings of computer security experts, or else we must assume that the connection is not secure.
5 January 2007
