Yngve Nysæter Pettersen

Posts tagged with "Usability"

W3C Web Security Context: User Interface Guidelines

Thursday, 24. July 2008, 19:46:13

The W3C's Web Security Context Working Group have just released the Last Call version of its "User Interface Guidelines" document, which is a set of recommendations for the security related UI in Web User Agents.

This specification deals with the trust decisions that users must make online, and with ways to support them in making safe and informed decisions where possible.

This document specifies user interactions with a goal toward making security usable, based on known best practice in this area. Subsequent testing of this specification will include conformance, interoperability, and usability testing.

If you want to comment on the document you are welcome to do so:

The W3C Membership and other interested parties are invited to review the document and send comments to public-usable-authentication@w3.org (with public archive) through 15 September 2008. We appreciate if comments follow these guidelines for writing good issues.

2 comments

Browser Usage: The unquestioned assumptions

Wednesday, 21. November 2007, 19:14:12

browser statistics, browser, economics, browser usage ...

One of the things you can't get away from when working for a browser vendor, unless you live in an unwired cave (which would make it difficult to work), and even if we occasionally do wonder about the accuracy, is usage statistics for your product.

I have an impression that some allow these statistics to guide their web site development, but I believe that relying overly much on such statistics when developing a web site can turn out to cause problems for the web site, not just for the web site's public image, but it could also be economically costly.

This article present what I think the problems are and why, and in general terms how to avoid them.

New^W NOT in Kestrel #3: As many warnings about weak temporary public keys

Monday, 22. October 2007, 15:00:52

Opera, Not In Kestrel, SSL, standards ...

The most important security pillar in SSL/TLS is the strength of the method used when agreeing on the encryption keys. If the method used for this is inherently weak, then it doesn't really matter how secure the rest of the encryption we are using really is.

The primary method used for this is the Public Key encryption methods, the most famous of which is RSA. These methods work by breaking the encryption key into two parts; one secret/private key and one public which is known by all (certificates are used to confirm who the public key belongs to). The relationship between these is that a message encrypted by one key can only be decrypted by the other. This means that anything encrypted with the private key can be read by everyone, but one will know that only the secret key could have created the message, and this property is used in digital signatures. Similarly a message encrypted with the public key can only be read using the private key to decrypt, and this is used in SSL/TLS to agree on the encryption keys used for the connection.

The security of this step depends on how difficult it is to break the encryption used to protect the encryption keys. For these methods breaking the private key means you can break all messages protected by it, and that when you have broken the key you can impersonate the owner. The difficulty of breaking an RSA key is generally determined by how long the key is. Given present technology, I estimate that the work doubles for every 25-30 bits that are added to the key length (as opposed to work doubling for every additional bit when attacking keys for a symmetric method, like AES). At present, 640 bit RSA keys have been broken in 5 months using less than 100 workstations, but even the commonly used 1024 bit keys are threatened now and are not recommended for messages that need to be secure past 2010. As a result, Opera will warn (and is the only browser that does) when these keys are shorter than 900 bits.

A way to make exposure of past messages more difficult is to change the key used to protect the messages very often. This means that there are more keys to break if you want access to all messages. With sufficiently strong private keys, massive attack becomes infeasible and even attacking a single key becomes impracticable.

In SSL/TLS these kind of rapidly changing keys are implemented using the Public Key method, also known as the Diffie-Hellman (DH) key agreement. The system most commonly works by having the server send a temporary (ephemeral) DH key (or DHE key) to the client, which then confirms the authenticity of the key by digitally signing it with its RSA key. The client then uses this DHE key to agree with the server on the encryption keys. Given that these keys are changed every few minutes there will be hundreds of keys used by a server every day, making the task of breaking the keys infeasible if the tasks take even a short time. But best of all, even if the RSA key of the site is broken, the attacker won't get the secret parts of the DHE keys. To be able to do this, they would have to break each key.

Given that the RSA and Diffie-Hellman algorithms are based on the same math, they are equally strong for a given key-size. This means that to provide the same level of security for a given connection as the RSA key, the DHE key has to be as long as the RSA keys. This is where an increasing number of secure servers fall short.

Both RSA and DHE secret key operations are very time consuming and therefore reduce the number of connections a server can handle. While most sites are using RSA keys that are sufficiently long, the fact that there are lots of DHE keys have led some vendors to mistakenly think that they can reduce the length of the DH keys so that more transactions can be performed. Most of these reduced keys are either 512 bits or 768 bits long (which Opera warns about), but I have actually seen servers sending 256(!) bit DHE keys (Hint: I estimate that these can be broken in minutes or hours).

What these vendors seem to forget is that not all attackers are interested in every transaction performed at a site. An attacker might just be interested in one individual visiting the site, and in such cases the size of the DHE key becomes significant. If the key is too short it may become economically feasible for the attacker to break the DHE key. This is why Opera also warns about weak DHE keys, which are shorter than 900 bits.

As reports about weak DHE keys seem to increase, I found it necessary to take a few steps to counter this problem.

The first step was to ask the TLS Work Group to specify clearer how these keys are created. In addition, specify what steps a client should take to ensure the DHE keys are adequately secure. This is currently being worked on for TLS 1.2.

The second step was to evaluate the size of the DHE key when we receive it. If the key is shorter than 1024 bits, we close down the connection after sending an Insufficient Security (71) fatal error to the server, and automatically try to establish a new connection where the DHE methods are listed as less preferred than they normally are. By doing this we will most likely be able to establish a sufficiently secure connection using the RSA-only methods instead. If the server still selects a DHE method, then a warning may be displayed if necessary. This extra round trip will usually not take extra time because it will be handled as part of our usual TLS feature testing of the server (watch this space for news about that). A known issue we are working to fix is that for mail servers where this dialog have been shown previously, this will not take effect until the second time you check email, and that the first attempt will fail.

The end result is that (normally) you will no longer see the weak public key warning, except if the site is using a weak key in the certificate. We can't do anything about the certificate keys because the size of that key is selected directly by the Webmaster. If you get any of those warnings, please notify the webmaster!

Further reading about crypto on Wikipedia:

Public Key Cryptography
RSA
Diffie-Hellman (DH)
SSL and TLS
About Keysizes

No comments

Low security sites, what to do about them?

Wednesday, 13. September 2006, 19:38:03

Security, Opera, browser, browsers ...

I've recently posted^1,2 about sites that are not using as strong encryption as they should. The sites may use weak encryption or mix secure and
unsecure content.

In many cases these sites expose their customers to the risk of their data being leaked, and several kinds of unsecure website practices may actually train the users in trusting unsecure sites, thus helping phishers.

What can we browser vendors do about such sites? Let's take a look at some of the possibilities, some realistic, some less so.

40/56 bit encryption and SSL v2

These encryption methods are now too weak to be trusted with anything. Yet some sites are still using them, in particular the 40/56 bit encryption. Opera 8 display a warning about these sites, and uses a level 1 padlock, and Opera 9, by default, does not support these encryption methods, and the same applies to IE7 for Vista. Effectively, newer browsers will not support these sites.

One option for us browser vendors is to remove the padlock for such sites, indicating that the site is not secure.

Weak certificate keys

Some sites, for some reason, chooses to create RSA keys that are just 512 bits long. These keys no longer provide any effective protection of the site, since (my estimate) they can be broken in two weeks, after which the encryption and integrity security of the site is completely broken, and attacker can do anything with the data without being detected.

Since Opera 8 we warned about such certificates. Before that we indicated their presence with a Level 1 padlock, and still do. In Opera 9 we also display a grey security toolbar, not a yellow one.

Another thing that can be done about these sites is, as above, to remove the padlock.

A more radical possibility could be to refuse access to sites with such weak keys. Perhaps TLS error code 71, "insufficient_security", could be used for this? Admittedly, it's description specifies it as a serverside error code, but I see no problem with a client using it.

Secure pages with unsecure content

Some sites use content from unsecure sites in their secure pages. Usually this is relatively benign; the content is "just" some advertisement or website tracker. Sometimes, however, the mixing becomes far more unsafe, as the unsecure content contains data revealing what you are doing or looking at, e.g. the unsecure images contain sensitive information, and in more serious cases the use of unsecure content actually *breaks* the security of the page. When the unsecure content is actually CSS or external Javascript files that modified by an attacker these files can be used to manipulate or even listen in on the website activity!

Opera has long been displaying an open padlock for these pages, perhaps what should be done is to remove the padlock altogether?

Other browsers display a prompt about such pages, but it can be disabled, and these browsers do not, at present, remove the padlock for such pages.

IE7 was supposed to actually block such unsecure content, but I was recently told that Microsoft had encountered [too many] sites that could not handle being blocked in that fashion, and had gone back to the IE6 modal dialog prompt. In my opinion, Microsoft should reconsider and stick with the blocking policy, even though it will break some sites, until they are fixed (if possible). Personally, I would like to change our policy to block such mixing.

Unsecure pages with secure content

Then you have the opposite secure/unsecure mixing, embedding secure content inside an unsecure page. In may cases this combination is also relatively benign, the secure components are just small images.

In other cases the combination is more problematic because the content may be a frame used to submit sensitive data, like credit card information. How does the user know that the data is transmitted securely? They don't unless they analyze the entire page.

No browser will display a padlock for these pages, since the main document is a HTTP page, not a HTTPS page, meaning that none of the usual "this is secure" indications are displayed.

In many cases the website "helps" the user determine that the site is "secure" by displaying padlock symbols and "this is a secure page" logos from the Certificate Authority. The problem with these symbols is that they are in the page, and the webmaster can put anything he or she wants in a page, including fake padlocks.

Why do sites do this? I think in many cases the webmaster either wants to save a few dollars on server capacity, because "everybody knows" secure connections cost a bit of computational resources (Bob Lord from the Mozilla team debunked this a while ago). In other cases it may just be that they do not think through the consequences, and in yet other cases the credit card transaction is performed by a third-party site, with another domain name, and they think the user should still see their domain name, not the payment site's domain name.

The consequence of this is that these sites acclimatize users to submitting sensitive data from unsecure pages. When people stop looking for the combination of the "https" and the padlock and instead just look for the website's logo (which can be, and of course often is, faked), they become incredibly vulnerable to phishing attacks.

Sites causing certificate warnings to be displayed

Certificate warnings can be displayed for a number of reasons:

Unknown issuer: In this case the browser does not know how to verify the certificate because it does not have all the certificates needed to link it to a certificate stored in its own repository of trusted root certificates. This means that we do not know if the certificate is actually a fake. It's like somebody saying they are a police officer, but not having the badge to prove it (Exercise for the student: How do you tell that the badge is real?).
Server name mismatch: Here the certificate can actually be verified, but it turns out to have been issued for another server, not the one to which the client is connecting. In most cases this is caused by a server administrator hosting several secure servers on the same server without buying a certificate naming each server. However, it can just as easily be a spoof website relying on you to accept the assurances that there is no problem and you can "just click accept". This is like a police officer with a real badge, and you are able to confirm that, but the badge is issued by another country. How do you know that this officer is authorized to act as a police officer in your country?
Expired certificates: In this case the certificate verifies OK, but the it is past it's "use before date". Like milk, driver's licences and passports, certificates can only be used within a certain period of time. For certificates this period is in part determined by how well the private key associated with the certificate can be protected by the owner, not just from external attacks, but internal ones as well. A server certificate is usually valid for a year or two, intermediate certificates usually less than 10 years, while root certificates, whose private keys are usually locked up so that several people are needed to access them, are usually valid for decades.

The common factor for all these is that when a certificate warning is displayed you essentially do not know who you are talking to if you decide to accept the certificate despite the warnings. Serious websites should not trigger warning messages.

All browsers display warnings about certificates such as the above. Additionally, Opera displays a padlock of level 1 when the user has manually accepted a certificate, but it is definitely a question of whether or not the padlock should be displayed in such cases at all.

Some browsers allow the user to permanently accept such certificates. I am not sure I like that capability, but that just might be a little bit too much "paranoia". In any case, I think such a bypass feature should be timelimited, perhaps 6 to 12 weeks, and only for the condition it was originally accepted. Such sites should also be consider low security sites.

Submitting sensitive data from an unsecure page to a secure server

Some sites, in particular some banks, have put their login forms on their unsecure frontpage. As I have mentioned before, this is not a secure arrangement because the user has no way to determine that the form is actually secure, and only does what the bank originally intended, in particular since an attacker can modify the page with the form while it is in transit.

As I mentioned in my earlier article browser vendors have a few options about what to do about such sites, with varying degrees of inconvenience for the user, ranging from unobtrusive warning indications, via warning dialogs to refusing to submit the information.

As mentioned above, one possibility of handling low security websites is to remove the padlock. One problem with this approach is that users that are already told to look for the "https" in the URL in addition to the padlock, or perhaps instead of the padlock. And by removing the level 1 (halfopen) padlock we risk that less serious webmasters will say "as long as you see 'https' at the start of the URL you are secure".

This means that we may need a way of indicating that "https" does not mean it is always secure (there are methods in SSL/TLS that only promises encryption with an anonymous server, and other methods that verifies who you are talking to, but does not provide any encryption; but both those options will result in warnings from Opera and a level 1 padlock).

Several methods are available:

Do not show the URL at all. I don't like this option at all. It may be that full URLs are "geeky", and that they may be difficult to understand for the layperson, but they give a much better way of finding out where you are than almost anything else.
Put a big red "X" over the "https" when the connection is not really secure, just use a red background, like has been proposed about phishing sites.
Change the "https" to "http(s)", at least in how the URL is presented in the address bar.
Use some other form of graphical indication

Personally I like the "http(s)" option since it is, at least in Opera, relatively easy to do this kind of display modification, and I certainly hope it would make those who look at the address bar stop and think. The main problem may be that it could be too subtle.

Whether or not any of these possibilities get implemented, or are practical, is an open question. Some of the more radical options cannot be implemented unless all the browser vendors agree to implement it.

10 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