Yngve Nysæter Pettersen

Posts tagged with "banks"

New Cookie and Cache Internet-Drafts

Monday, 9. July 2007, 17:53:14

I've just submitted updated versions of my HTTP Cookie and Cache related Internet-Drafts to the IETF.

I've covered the background for these drafts previously in these articles: Cookie-1, Cookie-2, Cache Context.

If you have comments, suggestions, corrections, etc., feel free to discuss them here, or directly with me. General discussion of the proposal should take place on the IETF's HTTP Work Group mailing list.

In a couple of days the drafts should become available in the IETF Internet-Draft repository at these locations:

draft-pettersen-dns-cookie-validate-02.txt

draft-pettersen-subtld-structure-02.txt

draft-pettersen-cookie-v2-01.txt

draft-pettersen-cache-context-01.txt

Archive copies can be found here:

draft-pettersen-dns-cookie-validate-02.txt

draft-pettersen-subtld-structure-02.txt

draft-pettersen-cookie-v2-01.txt

draft-pettersen-cache-context-01.txt

No comments

(51)2-bit banks

Friday, 15. June 2007, 15:54:01

factorization, browser, protocols, on-line banking ...

It shouldn't come as a surprise to anyone who is familiar with my opinions on encryption strength that I do not hold 512 bit RSA encryption keys in high regard. To put it mildly.

Unfortunately, I continue to be disappointed by the many sites using such weak keys. But I am even more disappointed by the fact that it turns out there are banks that are still using these keys.

Recently I have become aware of two banks/financial services that are using such weak keys:

The Israeli Bank Hapoalim's US branch (International site)
Halifax UK's branded credit card site (e.g. used by Amazon UK MasterCard)

Both of these sites are, as of June 15th, 2007, still using 512 bit RSA keys, and have been doing so for about a year, at least.

I have tried to contact these banks yesterday evening and today, but have so far gotten no response (and I also had trouble submitting the comments to the Israeli bank), and to Amazon UK, who answered quickly that they would forward the information internally.

The problem with 512 bit RSA keys is that an attacker, using (almost literally) a handful of computers, can break them in a couple of weeks, at most.

And when an RSA key is broken the attacker can do a lot of things:

He can read all previous traffic with the site if he have recorded it (if the site uses Ephemeral Diffie-Hellman keys, then those keys must be broken instead).
If he is able to intercept current traffic to the site, he can pretend to be the site and read all the data passing back and forth between the site and the users.
If he is able to pretend to be the site, he can also change the information on the fly, if he wants too.

There is absolutely no way to detect any of these attacks through the SSL/TLS protocol, because the sanctity of the site's secret private key is the fundamental pillar of the protocol. That key is used to agree upon the encryption keys that are used to protect the rest of the
communication.

10 years ago, 512 bit RSA was the highest level of encryption the US government permitted foreign users of US manufactured servers and browsers to use, except for financial services, who could use 1024 bit RSA keys, or better. It was widely assumed that the reason for this limit was that the US government could break 512 bit RSA keys relatively fast. The restriction was lifted in 1999/2000.

The proficiency of RSA key breaking is, as I mentioned a couple of weeks ago, rapidly increasing. At present general 640 bit RSA keys can be broken in 5 months using just 100 computers. But recently a special 1020 bit number was factored (the difficulty of factoring large numbers is what provides RSA with its security) in about 11 months using the same amount of computing power. That means that 1024 bit RSA keys are fast approaching their "consume by" date, if it hasn't already been passed.

Today, I would strongly recommend that secure websites, in particular financial sites, should use 2048 bit RSA keys.

The days of 1024 bit RSA keys are numbered: 1296 days, at most. (See the countdown for the up to date number, on the frontpage).

Update, June 18: Halifax has responded that they are in the process of upgrading the server certificate.

6 comments

"Secure" bank logins?

Friday, 2. June 2006, 18:06:42

Security, SSL, TLS, privacy ...

George Ou over at ZDNet has recently been engaged in a one-man crusade against banks that let users log in to their on-line banking services directly from front pages with no security, for the sake of user convenience. This means that the login form is placed on a HTTP page, while submitting to an HTTPS URL.

Why is that bad?

The thing about unsecure pages is that they are ... unsecure. You do not know that you are on the right website, there is no secure certificate vouching for the identity, there is no encryption and no integrity checks of the received content. That means that anyone can modify the page, in fact somebody can take over your DNS server and serve you a completely fake page, and there is no way to find out it is happening!

That the pages can undetectably be modified means that an attacker could send anything you enter into the form (such as your account name and password) to another server, and then just send you on to the real secure site, and you would be completely unaware that you were just phished.

This practice has not just irritated me for a long time. Eric Lawrence of Microsoft called it "Critical Mistake #1" in an IE Blog posting a year ago.

So what can be done about this?

Several options are available:

Evangelism, like what George Ou is doing
User education
Browser security warnings

Evangelism is a long uphill battle, in particular when you are up against the "Everybody is doing it"-argument. However, there are good examples of banks who get the point, at least in Europe. Several Norwegian banks, such as Norway's largest, DNB Nor, are using SSL for their entire sites, even their public advertisements and information pages.

User education is important and one should definitely get people to look for the padlock and check other information, such as the information in Opera's security toolbar. Work is being done to make such information more readily available to users. But, as with evangelism, this is going to take time.

What can the browsers do?

There are several options available, although as far as I am aware, none of them are currently being developed, and all of them are going to annoy users and usability experts alike.

Refuse to submit HTTP to HTTPS forms. This option is too extreme to be considered realistic. It also does not necessarily stop the attacker from getting the data.
Warn before submitting a form from HTTP to HTTPS, similar to what we already do with HTTPS to HTTP form submits. This would require the user to click OK, and would not just be annoying, it would also help train the user in clicking OK on all dialogs. It also cannot stop the attacker from getting the data, although that problem might be avoided if the dialog was triggered when you enter the password field.
Inform the user about the problem, e.g. with a tooltip, just as he or she places the cursor in the password field. This has the benefit of not being too annoying, and it also does not require the user to click OK in a dialog. It may be a bit too unobtrusive, but I think it could be a good starting point. Another benefit is that the user gets the warning before typing the password, which means that an attacker has not yet had an opportunity to see it. A drawback is that we cannot use this method to warn about credit card fields.
Print a warning in the error console. This will be completely unobtrusive, but also far too invisible as most users would not see it. It could however be used in combination with the tooltip to provide more information.
Reduce the security level of the target page. Opera is already using a "weakest link" security-level indicator which displays "level 0" if unsecure content is mixed with secure (and in 9.0 the security toolbar will be gray in such cases). In cases where a form is submitted from an unsecure page to a secure server, we could consider lowering the security level to zero for the entire document. As many people don't really look at the padlock this might be a bit too subtle, but I think it could be using in connection with some of the other suggestions.

In my opinion the most realistic way to inform the user would be to use the tooltip, in combination with the error console and the security level, as those do not annoy the user too much, while informing the user that there is a potential problem on the site.

Some of these actions, such as the warning dialogs, would not really be effective unless all the browsers implemented them, because of the inconvenience they would be causing.

A general problem is that we cannot give such warnings when the information is gathered by a Java or Flash applet.

What can you do as a user?

You can decide not to use login forms for secure services placed on unsecure servers, and to let the banks and other sites relying on sensitive information know that you want them to fix their login systems. Unless these sites get actual negative feedback on their unsecure practices, they will continue to use the convenience excuse.

What do you think?

15 comments