Is my bank's login encrypted?

[Belrix]

Here’s my bank’s front page.

There’s no “https” in the URL, there’s no little lock icon in my browser’s status bar.

There’s a graphic of a little lock on the login section on the left bar but nothing I see via the browser info seems to indicate this account login is encrypted.

Can you have a partially encrypted page now?

-B

[c_goat]

@Belrix

Here’s my bank’s front page.

There’s no “https” in the URL, there’s no little lock icon in my browser’s status bar.

There’s a graphic of a little lock on the login section on the left bar but nothing I see via the browser info seems to indicate this account login is encrypted.

Can you have a partially encrypted page now?

-B

Yes, the login information is encrypted. If you look at the HTML source for the page, you’ll see the following:

form method=“post” name=“loginActionForm” action=“https://www.efirstbank.com/redirect/redirect.do”

Basically, that tells your browser to submit the information you enter into the box to the secure site listed under action. Since it’s an https address there, your browser will encrypt the login information before sending it.

[Reply]

Even if the actual login info is encrypted, this site is not really secure because the entrance page is not using HTTPS.

Without a certificate identifying/authenticating the front page, any compromised system between your computer and their system can present you with a fake front page.

For example, if you’re using a public wifi hotspot, the guy who owns the router can redirect efirstbank.com to his own website that looks exactly the same but sends him the info instead of your bank. I think this is what they call a “man-in-the-middle” attack coupled with something like “DNS redirection” or some mumbo jumbo like that.

Instead, bookmark the secure login page you get when you fail to enter a username and password:
https://www.efirstbank.com/ibank1/logonFromHomeAction.do

And use that to access the bank every time. But more importantly, check your bank’s policies and find out if you’re liable for unauthorized charges – and see if the same thing applies to online banking.

[Rysto]

You make a good point, Reply, but unless one actually checks the certificate to ensure that it’s issued to the correct organization(and I would be willing to be that few do; I certainly don’t) it’s a moot point.

[Richard_Pearse]

If you click on that little padlock icon beside the login form you are taken to a page that says this:

We are committed to safeguarding your personal information online to keep it secure and confidential.

When you sign in to Internet Banking from the FirstBank web site, your user ID and password are sent over the Internet from your computer to ours using Secure Socket Layer (SSL) technology. SSL encrypts your personal information before it leaves your computer, ensuring that no one else can read it.

That page also contains this link, Additional Internet Banking Security Information.

[Reply]

@Rysto

You make a good point, Reply, but unless one actually checks the certificate to ensure that it’s issued to the correct organization(and I would be willing to be that few do; I certainly don’t) it’s a moot point.

Isn’t the certificate assigned to a particular domain name? I thought that the certificate issuer (e.g. Verisign) links a particular certificate/public key to a particular domain name and, presumably, Verisign wouldn’t give out certificates for majorbank.com to just anyone asking for it – so essentially, I thought that Verisign does the identity check for us. Even if Joe Conartist has a valid cert, he shouldn’t be able to use it with any domain except the one it was assigned to… or am I misunderstanding how this all works?

Of course, even if that’s the case, a different question altogether is whether you want to trust the certificate authorities.

[Reply]

@1920s Style "Death Ray"

If you click on that little padlock icon beside the login form you are taken to a page that says this:

"We are committed to safeguarding your personal information online to keep it secure and confidential.

When you sign in to Internet Banking from the FirstBank web site, your user ID and password are sent over the Internet from your computer to ours using Secure Socket Layer (SSL) technology. SSL encrypts your personal information before it leaves your computer, ensuring that no one else can read it."

That page also contains this link, Additional Internet Banking Security Information.

Bah. That’s just marketing speak. Any website can CLAIM to be secure and confidential, but whether they actually ARE is a different question. What matters here is how they actually implement their security – something that’s not easy to determine – and whether their liability policies reflect their confidence. If their policymakers don’t trust their own systems to be safe enough, you shouldn’t either. It’s your money, after all.

[ed]

@Reply

Any website can CLAIM to be secure and confidential, but whether they actually ARE is a different question.

The other thing to realize is that while they are using SSL and a valid cert, it’s only accomplishing half of what it’s meant to (encrypting the data). The other half (identifying the host as legitimate) has been rendered moot in this case, because you can only tell if the cert is trusted after submitting your data, which makes it pretty pointless.

But the data is encrypted between your browser and their webserver at least.

[ftg]

For an example of a “genuine” certificate on a fake banking site read [this article](Mountain America credit union).

It’s a nasty 'Net world out there. I’m glad people like the OP are concerned.

[Reply]

@ftg

For an example of a “genuine” certificate on a fake banking site read [this article](Mountain America credit union).

It’s a nasty 'Net world out there. I’m glad people like the OP are concerned.

Can you post that link again, please? I don’t think it worked.

[ftg]

Sorry, let’s try that again:

http://www.windowsitpro.com/windowspaulthurrott/Article/ArticleID/49482/windowspaulthurrott_49482.html

Note the statement:

“But, taking things a huge step further, the phishing Web site also had a SSL certificate issue[d] by Equifax.”

[Reply]

@ftg

Sorry, let’s try that again:

IT Pro

Note the statement:

“But, taking things a huge step further, the phishing Web site also had a SSL certificate issue[d] by Equifax.”

If I understood this attack correctly, it wasn’t actually all that bad. This is what I THINK happened:

1. Mountain America, a small credit union, had a website somewhere on the web… possibly at www.mtnamerica.org (I’m not sure what their website was back then).

2. A phisher registered another similar domain, mountain-america.net, and got a valid SSL certificate for it.

3. The phisher sent out emails claiming to be from Mountain America but actually pointing to the website in #2.

4. People believed that mountain-america.net belonged to Mountain America Credit Union, although it was actually the phisher’s website. They went there and presumably submitted some personal info.

---

If that’s indeed what happened, the scam – like most others – only exploited people’s lack of knowledge and/or caution. There was no technical attack involved.

Anybody can register any available .com/.net/.org domain name (barring trademark issues) and that’s exactly what the phisher did. Then he easily got a SSL cert for it because the regular certificate validation process doesn’t care who you are or what organization you belong to; it only wants to make sure you own the domain you’re getting a certificate for.

On the other hand, what would really be bad is if somebody managed to get an SSL cert for a domain which already had one – like if the phisher in this case got a duplicate certificate for the official www.mtnamerica.org site. Then a man-in-the-middle attack would be entirely possible. But this is what we pay the certificate authorities to keep track of and prevent, and hopefully they’re doing their jobs.

[ftg]

Some more links:

The Washington Post: Breaking News, World, US, DC News and Analysis

SANS Internet Storm Center

Reply:

Then he easily got a SSL cert for it because the regular certificate validation process doesn’t care who you are or what organization you belong to; it only wants to make sure you own the domain you’re getting a certificate for.

Reread the original ariticle and the extra links. The rules on SSL certs are quite strict. It’s the enforcement that is a joke.

There was also some folks who got an official SSL cert identifying them as MicroSoft (!) not too long ago, but I haven’t found a link yet.

[Reply]

@ftg

Some more links:

http://blog.washingtonpost.com/securityfix/2006/02/the_new_face_of_phishing_1.html

SANS Internet Storm Center

Reply:

Reread the original ariticle and the extra links. The rules on SSL certs are quite strict. It’s the enforcement that is a joke.

There was also some folks who got an official SSL cert identifying them as MicroSoft (!) not too long ago, but I haven’t found a link yet.

I think there are different levels of authentication:
http://www.adacom.com/Products_Services/PKI%20%20Authentication/Client_Certificates/Class_1_2_3_Certificates.aspx

But they don’t really do anything because:

1. Browsers don’t really care about the classes. A site is either “padlock secure” or it’s not, regardless of how authenticated the domain, individual, or organization is.

2. Even if users cared enough to look at the certificate details, it doesn’t really help the situation. For one thing, as you suggest, CAs can sometimes mess up. But even if they don’t mess up, the highest level of authentication only verifies that the domain belongs to a valid organization of a given name. It can’t prove that the organization is the one the user thinks it is. Multiple organizations can share the same name as long as they’re not in the same industry, right? So all a phisher would have to do is start an organization of the same name in another field. Users would be hard-pressed to determine the difference between Acme Inc. and Acme Co.

So, practically speaking, that part of the authentication scheme is essentially worthless. The domain authentication portion, however, is still useful – as long as the domain name itself doesn’t fall into the wrong hands.