certificate names
When it comes to preventing users from entering their data into fake websites, the main defense people always rely upon is user training. We’ve tried for years to train users to always look for the little lock icon that indicates the site is using SSL. Now we’re starting to train them to look for the EV cert. Browser makers have gotten much better about making it more difficult for a user to bypass certificate errors. One of the biggest mistakes an entity can make is accidentally training their users for bad behavior, such as accepting certificate errors. Unfortunately, that is exactly what many people are doing. Many times someone will buy a certificate with their main www domain – for example www.bankofamerica.com, and forget about the domain bankofamerica.com. While the difference may seem trivial, any user that enters https://bankofamerica.com into their browser will be met with a certificate error, which they will ultimately have to accept if they want to continue. This is bad practice all around.
To prove my point, I decided to look at the 10 largest banks in the US and discovered that four of the ten exhibited this flaw. (Bank of NY Mellon does not seem to have a login on their main domain, and therefore don’t utilize SSL period). One would think that for a large financial institution like one of these, getting a multiple domain certificate would be a simple task, but apparently they never thought to do it. In the mean time, they’re training their users for poor security practices.
| JP Morgan Chase | good |
| Bank of America | Error |
| Wells Fargo | good |
| Citigroup | Error |
| PNC Bank | Error |
| HSBC | Good |
| Bank of NY Mellon | N/A* |
| US Bankcorp |
Error |
| Suntrust Bank | good |
| State Street Corp | good |
Tags: banks, certificates, disclosing, end users, transparency