Skip navigation.

Implementer's notes

What might get caught in the gears under the hood?

Posts tagged with "on-line banking"

(51)2-bit banks

, , , ...

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:



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.

Introducing Cache Contexts, or: Why the browser does not know you are logged out

, , , ...

One of the Opera features I often see mentioned as "good" is our history navigation where you can navigate back and forwards in the history very quickly, and without making any revalidation/refetches of the content from the server.

This is made possible by our adherence to the principle stated in RFC 2616 (HTTP 1.1) section 13.13 about history list navigation.

13.13 History Lists

[...]History mechanisms and caches are different. In particular history mechanisms SHOULD NOT try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved.

By default, an expiration time does not apply to history mechanisms. If the entity is still in storage, a history mechanism SHOULD display it even if the entity has expired, unless the user has specifically configured the agent to refresh expired history documents.[...]



Unfortunately, now and then (such as just last week) there's somebody reporting this as a bug or even a "security issue". They are in particular using the Security Issue tag when the navigation happens on a site handling sensitive data, such as online banking, after the user has logged out.

Well, I can understand that online banking sites and other sites handling sensitive information do not want the client to show information retrieved from the site while the user was logged in, after the user has logged out. It's just that they forget a simple fact, inherent in HTTP: The browser does not know the user has (been) logged out, and currently there is no way for the browser to find out!

Somebody will probably now say "but cookies/no-cache/must-revalidate can be used for that". Not really. Let's look at each of these options:

  • Cookies: More precisely known as "HTTP State Management Cookies" are used to keep information about what is going on with respect to a given client and user. However, the browser does not know anything about what a cookie means, it just stores it, and sends it back to the server(s) that are supposed to receive it. That a cookie is deleted (such as during logout) does not mean anything special to the client, and in fact a site need not delete a cookie to mark a user as logged out, it can just change a flag in its own database, without telling the browser.

  • no-cache: This Cache-Control response directive may very well be the most misunderstood parameter in all of HTTP, quite likely because of its name, and its use in requests. There seems to be a significant belief that a client must never store a document served with this flag, or produce it as a result of clicking on a link. That is not the function of this directive. RFC 2616 sec. 14.9.1 states:

    no-cache

    [...] a cache MUST NOT use the response to satisfy a subsequent request without successful revalidation with the origin server. [...]


    This only means that when you click on a link, the client must first ask the server "Has this been modified since I loaded it?", and if the server says "No, it is not modified", then it may show it to you.

    This does not apply to history navigation, because "no-cache" defines the "expiration time" of the web page, nothing else.

  • must-revalidate: If "no-cache" is the most misunderstood parameter, "must-revalidate" may well be the most abused. According to RFC 2616 section 14.9.4:

    must-revalidate

    [...] When the must-revalidate directive is present in a response received by a cache, that cache MUST NOT use the entry after it becomes stale to respond to a subsequent request without first revalidating it with the origin server. [...]



    Opera may not quite follow the letter of this specification, but that is because of how the directive will normally be used. We treat this directive's presence as an indication that 1) the resource is expired (same as with "no-cache") and 2) during history navigation of secure sites a web page is revalidated before it is displayed to the user.

    You probably noticed the "secure site" condition. The reason for this is the aforementioned abuse of the "must-revalidate" directive. Quite a lot of sites (I have personally seen a lot of PHP powered Wikis with this problem) are sending the cache-directive combination "no-cache, no-store, must-revalidate", which to Opera means "check every time the user asks for it, even during history navigation, and do not store it on disk, only in RAM while we have it".

    What this means is that when you visit such as site (and all the directives are obeyed), then the browser will ask the server to validate the content (even statics) of each page (in some cases even images) every time, which results in very slow navigation. When we introduced "must-revalidate" the forums overflowed with "slow navigation" posts, and long-time Opera supporter non-troppo actually had to patch his Opera Wiki server to keep the problem at bay.

    This abuse is the reason why must-revalidate is only obeyed for secure sites.


As indicated above, some web service providers consider failure to revalidate after logout to be a potential vulnerability for their system. This has caused them to invest quite a lot of effort into ensuring that the browser behaves as they want it to. They have not just used the above mentioned cache directives, but also various scripting technologies.

The major drawback of all the current systems is that they will most often increase traffic to the website using them, thus increasing the load on the servers, which means that to stay operative they need even more servers, which means higher cost of operating the site.

All of it (trouble, wasted money, complaints, etc.) because they are not able to tell the browser that the user has been logged out.

So, how can this be solved in a more economic and predictable manner?

A solution should have the following requirements:

  • The user should be able to navigate history as normal while logged in, no revalidation should take place.
  • Already loaded resources should not be refetched unless the proper functioning of the site requires it (for example, the account page should display the current amounts when the user click on a link going to the accounts summary page)
  • When the user is logged out, all sensitive documents should be removed, and if they are still in history, they should be revalidated with the server before being displayed to the user.

This set of requirements indicates that the server should have a way to tell the browser

  1. That a page is part of the sensitive document group.
  2. When the user is logged out (or should be logged out).


I've recently written, and submitted to the IETF, a document describing a system that tries to solve these problems: Cache Contexts.

In this new system the server uses a Cache Context directive to tell the browser that the document(s) served are part of a specific group of documents, a "context", and when the context has ended its usefulness, the server can discard it, which will also tell the browser that the documents in the context should no longer be displayed to the user, unless they have been confirmed by the server.

The server can tell the client how long it should let the documents in the context live, and it may also connect the lifetime of a context to the lifetime of a cookie; when the cookie is deleted, all the documents in the context are deleted, too.

These are just some of the features offered by Cache Contexts.

If you are interested, it will be available from the IETF's Internet Draft repository in a couple of days. If you cannot wait, a copy of it can be found here.

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.

draft-pettersen-cache-context-00.txt

"Secure" bank logins?

, , , ...

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?
December 2009
S M T W T F S
November 2009January 2010
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31