Does expiring passwords really help security?

Change is Easy
Originally uploaded by dawn_perry

I've heard a lot of arguments as to why expiring passwords likely won't help. Here's a few:

• It's easy to install malware on a machine, so the new password will be sniffed just like the old.
  
• It costs more: frequent password changes result in more forgotten passwords and support desk calls.
  
• It irritates users, who will then feel less motivated to implement to other security measures.
  
• Constantly forcing people to think of new, memorable passwords leads to cognitive shortcuts like password-Sep, password-Oct, password-Nov...
  

And yet, many organizations continue to force regular password changes in order to improve security. But what if that's not what's really happening? Three researchers from the University of North Carolina at Chapel Hill have unveiled what they claim to be the first large-scale study on password expiration, and they found it wanting.

They focus especially on the idea that consecutive passwords will be related, and build a system which could try a variety of transforms such as changing which letter was uppercase, duplicating letters/numbers/symbols, and even "leet" translation (eg: raven becomes r@v3n). The implications of their results are fairly clear and potentially disturbing for those who thought password changing was providing extra security in the case of a breach:

• With offline attacks: "On average, roughly 41% of passwords can be broken from an old password in under 3 seconds."
  
• With online attacks: "An average of 13% of accounts can be broken (with cer- tainty) in 5 online guesses, and 18% can be broken in 10 guesses."
  
• "As we expand our consideration to other types of transform trees, we would not be surprised to see these success rates jump significantly."
  

In essence, they've shown that changing passwords doesn't provide nearly as much security as system designers had hoped, and they suggest we abandon the practice rather than continue to annoy users with a policy that has been proven ineffective.

No Website Left Behind: Are We Making Web Security Only For The Elite?

This is an annotated version of my presentation at W2SP 2010, since I realized my slides by themselves are missing a lot of the story. The full paper is available from the conference website and I should be putting up an HTML version shortly.



Hi, I'm Terri, and I'm here to talk about whether we're excluding some very important people when it comes to web security.

The first thing you need to know is that...



And of course you knew that, because we all know the Internet is actually run by cats.



... and we all know that cats aren't programmers; they're artists.



Seriously, though, many of the people who do web design professionally are artists, not programmers. You can see this through the job titles used and other services offered by many web design firms.



And then there's all the people who make pages but aren't professionals. Cat blogs, community sports team sites, small church websites, etc. are often made by non-professionals.



And in many ways, it's fantastic that all these people can make web pages. Web 2.0! Sharing! Communication! But the problem is that web security is designed for programmers.



So, for the purposes of visualization, let's pretend that a web page is like a car...



Thus we can imagine web security issues like cross-site scripting and cross-site request forgery are sort of like getting gremlins in your engine.



With this analogy in mind, let's look at some of the best tools we have for fixing websites:



The big one is safer programming practices. You take your existing website, and replace it with a new, gremlin-proof one. This is pretty programming-intensive, much like you'd need some serious mechanic skills to replace your entire car engine.

Then there's tainting or data flow analysis, which allows you to trace the path of the gremlins through your engine...



But once you've done that, you still have to patch the code so that the gremlins can't cause problems. Programming!



We've got known exploit detection, such as web application vulnerability scanners and web application firewalls. They tell you exactly where and what kind of gremlins you have.



But while they might protect you for a time, best practice still says you should fix your code.



And then there's the cool mashup protections which help you fix your code to provide isolation between components so that the gremlins can't breed in your engine. But they mostly involve a lot of coding to implement.



Even the language of security is heavily oriented towards programmers. The documentation for Mozilla CSP even includes set theory notation! Not exactly friendly for artists.



Some of the organizations that do the best job of communicating (web) security flaws tend to be intimidating to non-programmers, and really send the message “If you're not a programmer, this isn't for you.” This is not the message we want to send!



Because non-programmers really do need security.



The web is a big target, and attackers aren't limiting themselves to big sites – automated attacks make it worthwhile to compromise even smaller targets. Lots of attackers are interested in sending spam, SEO, evading blacklists, etc. all of which can utilize smaller sites. And the attacks aren't always where you'd expect: Did you know your Facebook account is currently worth more on the black market than your credit card?



But if you're thinking “So, we just let the designers design and handle security at the programming layer below,” you're missing two important points:

First, smaller sites may not have anyone who can handle security, period.

And second, the design of a page actually affects the security of a page. For example, if you put an advertisement on a page with a form, you've just given that advertiser or advertising server access to your user's data. Programming under the hood can't fix that; it's done on the client side. A lot of “small” sites will use a variety of cut-and-paste code that they found elsewhere, increasing their risks even though they may not realize it.



So... that's not terribly good. What can we do about it?



Before we propose any solutions, we need to keep in mind that the cost/benefit ratio for smaller sites may be very different from what we expect. Users will reject security advice if it's more costly to implement than their risks are. And for non-technical site creators, the cost of learning security may be months of additional time, personnel, and money spent on training. Whereas how much risk is there of your community sports team website getting compromised? It may not be clear, and it may not be easy to translate into dollars.



So the first thing we can do is provide a more secure environment. The same origin policy already provides some basic protection to websites, and it's something designers just accept as part of the web infrastructure.

When I put together these slides, I didn't have any other ideas of what to do, but I've now seen a presentation that suggested some security restrictions that would have minimal impact on the top 100,000 websites but could improve security. (The paper is titled “On the Incoherencies in Web Browser Access Control Policies”)

It'd be really handy if graphical tools like Dreamweaver could generate secure mashups. I even talked to some students from the University of Virginia who are working on small policy additions to Ruby on Rails that could provide security – we need more work like this!



Education is also a big deal: people won't bother with better security if they don't understand the risks, and they won't fix problems correctly if they don't understand the solutions. But we have to be really careful to provide materials that make sense to the target audience of designers, and that are sufficiently short that they don't cause the costs of learning to exceed the risks.

You know how the EFF has done a great job distilling the complex privacy issues in Facebook and explaining them to the general public? We need materials like that for web security as well as privacy.



Another way we can help is by providing something akin to website first aid. If you fall and skin your knee, you know enough to wash out the wound, maybe put a bandage on it. You don't need to be a doctor to help your daughter if she trips in the playground. But right now you need to be a website surgeon to handle any security!

There's already some neat things out there: The Origin: header provides protections against XSRF with minimal effort. I worked on a system called SOMA which provided additional controls over includes in websites. But the risk is in letting these minimal interventions get too huge to be useful for average websites. I'm not a huge fan of Mozilla CSP because it's getting just too big for a quick fix. We need to put a lot of thought into optimizing policy and other solutions use for common cases and less into flexibility for unlikely edge issues.



And of course, it'd make our lives a lot easier if we could provide more separation between security and design so that design choices wouldn't necessarily compromise your security.



If we had more separation between security and design of web pages, we could offload security to others. For example, the person in an organization who may care most about security are your systems administrators, because they're the ones who get woken at 4am if something goes wrong, and they're the ones who have to clean up the mess.

We may even want to consider offloading security to the users: they're the ones whose data is most at risk, and they're willing to install virus scanners and even NoScript to try to protect themselves: surely we could do better there.

And finally, there's always the option of hiring outside security experts. The costs currently are prohibitive for smaller sites, but if basic security were easier, maybe we could make this more reasonable.

One thing I've been working on is a visual system for defining security policy, so it can be integrated with design tools and so security can be articulated in a language designers already understand. I'd be happy to talk more about it if you're curious.

In conclusion, while we're doing some good work in web security, we're really limiting our impact if we don't reach out to the broader range of folk who create web pages. Making web security all sound complex, time consuming and hard at all levels may be great for our job security, but it isn't the best way to go about actually making the web safer for the world!



Edit: Although I was unaware of this when I wrote the paper whose title is used in this blog post, apparently "No Website Left Behind" is trademarked by Cenzic.

Bank being sued for teaching customers bad security habits

After mentioning in a previous post that banks are now suing customers who get robbed, here's a lawsuit going the other way: Comerica Phish Foiled 2-Factor Protection.

A metals supply company in Michigan is suing its bank for poor security practices after a successful phishing attack against an employee allowed thieves to steal more than half a million dollars last year.

The short version is that the bank regularly sent customers emails where they were required to click a link and then enter their password on that site in order to update a security certificate. Unfortunately, priming people to do this also makes them easy marks for phishing attacks which often... have users click a link to go somewhere that looks like their bank site, then enter their password. Awkward.

Read the details here (or scroll down on that site to see the lawsuit and initial response from the bank).

Credit card companies covering their asse(t)s

Exactly whose security does your credit card company have in mind? Here's a hint: It's probably not yours.

I often use Mastercard SecureCode as an example of a usability failure in online security: in order to order plane tickets where SecureCode is used, I found I had to disable many of the browser security measures I have in place for regular browsing. So, that time when I'm making an expensive transaction is thus the time when I'm at most risk... Not exactly trust-inspiring, is it?

But Steven J. Murdoch and Ross Anderson of Cambridge do more than just complain about "Verified by VISA” and “MasterCard SecureCode.” They presented a detailed analysis of the '3-D Secure' card protocol. Check out the abstract:

Abstract. Banks worldwide are starting to authenticate online card transactions using the ‘3-D Secure’ protocol, which is branded as Verified by Visa and MasterCard SecureCode. This has been partly driven by the sharp increase in online fraud that followed the deployment of EMV smart cards for cardholder-present payments in Europe and elsewhere. 3-D Secure has so far escaped academic scrutiny; yet it might be a textbook example of how not to design an authentication protocol. It ignores good design principles and has significant vulnerabilities, some of which are already being exploited. Also, it provides a fascinating lesson in security economics. While other single sign-on schemes such as OpenID, InfoCard and Liberty came up with decent technology they got the economics wrong, and their schemes have not been adopted. 3-D Secure has lousy technology, but got the economics right (at least for banks and merchants); it now boasts hundreds of millions of accounts. We suggest a path towards more robust authentication that is technologically sound and where the economics would work for banks, merchants and customers – given a gentle regulatory nudge.

So, basically, 3-D Secure provides economic security rather than technical security -- but not for you, the customer. It's providing extra security for the banks by passing the buck.

This is hardly the only way in which the banks protect themselves above the consumer. Take a look at Security and Usability: The Gap in Real-World Online Banking for some fascinating insight into what your bank thinks you should do to be secure online, and how few people do these things in practice. And this is especially worrisome now that, as Mannan anticipated in that paper in 2007, banks have started suing their customers when breaches occur.

I'll be really curious to see if this paper about 3-D Secure manages to make changes in industry or government legislation. Amusingly, this paper about how insecure they are makes me feel more secure -- at least if a bank sues me because someone's stolen my money, I'll have more evidence to claim in court that the bank wasn't trying hard enough to protect me.

Wait, did that look like that before?

Wait a second... In a previous post, I noted that gmail just quietly downgraded to HTML if you didn't have JavaScript turned on. But today, I noticed this message:



They could use a small fix to their formatting (ie: don't let the poor text jam into the side of the box like that -- I had to grab some of the surrounding window so this screenshot would be legible) but this is strangely more helpful than it was before.

Why the difference?

Well, much as I like to believe someone at Google saw my comments and made the change, I'm not quite arrogant enough to believe that's true. Although I suppose it could be -- there's a lot of Google people out there, and for all I know they've got something that scans Blogger for mentions of their products. It would be a clever, if time-consuming, way to find out what the public really thinks.

Err, I digress. Self-centred worldviews aside, I'd guess it more likely that this message has always been there, and I just missed it last time because of my NoScript configuration.

Why do I find this interesting? Well, I'm currently working on a theory that users will be more safe if they can disable JavaScript that they don't really need to run the page. This is the theory underlying NoScript, and it has some face validity. But if users start running only some JavaScript, what is this going to do to the usability of the web? My current answer is that if you leave JavaScript off entirely, you're going to turn some pages into a usability nightmare, where things will just not work (more on this later). But these different error messages based on my various setups indicate to me that you may have these usability problems even if you have partial JavaScript. In fact, the usability problems may be much worse because the page won't know to generate an appropriate error message!

I don't know how to solve this problem yet, but I guess that's what makes this research!

The web without JavaScript. Part 2: Black Holes and Revelations

As I implied in Part 1, while sites do sometimes provide helpful error messages related to JavaScript, often as not they just behave strangely.

Perhaps the most common issue I've seen is missing content. The things I notice most often are missing ads and missing video. Sometimes, it's nice and obvious that there's a missing element on the page:


Many pages leave very obvious spaces for their ads, and when they're filled with blank space, it's fairly obvious that there's a problem.

The videos are less obvious, however:

There's a video in there. Really. Normally, it would appear right below the header, so the page would look more like this:


There you can see the video loading in the big black box. But how would you tell that the previous page had anything missing? The page has nicely moved the text up, leaving no trace that there should be something there. In the case of the missing video, there are usually only a few clues:

1. The page looks abnormally short (there isn't much text)
   
2. I'm expecting a video on the page, and it's not there.
   
3. I happen to check the JavaScript list from NoScript and notice something that looks like video.* or sounds like a domain that might host video.
   

Usually, the winning clue is #2, since a friend will send me a link and mention that it's a video, or the comments on the page will talk about the video, or sometimes the text itself will tip me off by what it says.

And often, you'll see both missing spaces and the lack thereof on the same page. The page featured below would normally have both an ad and a video:


Could you tell there was a video on this page? You can see the blank space for an advertisement, but the text automatically moves up so you can't tell that the page with the video looks like this:



That's the video in bright yellow at the bottom there.

But it gets even more fun when you've changed which sites are JavaScript disabled in NoScript. Check out that same site with all the JavaScript disabled:

They're pretty smart! If they can tell that JavaScript is disabled (ie: I've disabled it for the main site) then they both provide the helpful error text AND they provide a ad, showing that you don't really need JavaScript to do it. Unfortunately, my weird way of disabling some JavaScript but not others had limited their ability to do damage control on the page I was trying to break. Interesting...

Next up in this series: Sites that have more than a few holes, and sites that just don't work without their JavaScript!

What does the web look like without JavaScript? Part 1: Error Messages

So what does the web look like without JavaScript? This post focuses on the error messages you see when you decide to ditch the JavaScript, but the sad reality is that although some sites will give you warnings, this is hardly the norm. Still, it's worth looking at what you might see...

Without JavaScript, occasionally the web looks like this:


That's a nice big red error message indicating that there's no JavaScript. Simple, clear, informative, lets you know where to go for help, or even lets you use the website for things that don't require JavaScript.

In a similar vein, you sometimes get error messages like this one:



I find it hilarious that it first tells me that JavaScript is turned off, then tells me what to in the event that JavaScript redirection isn't working... even though if I saw this page at all, JavaScript redirection won't work. But maybe I'm too easily amused.

Anyhow, similarly, it lets you know in nice big red letters what the issue is and how to fix it. Good good.

But this isn't the norm among pages. Sometimes, you get error messages more like this one:



Well, it could be JavaScript, or maybe something else is wrong. Here's how to get Flash player! Err, that's almost helpful. I can see a lot of people reinstalling Flash player and assuming it was broken when JavaScript is the real culprit.

Also, although it's fairly clear where the error message is when you've got a nice little page fragment like this, it's pretty easy to miss that black text on a page with lots of black text and little images and video responses and so on and so on. Especially if you're looking at a video site where really, you're scanning the page for the big video window and mentally blocking out all the text, which you know isn't what you came to the page to see.

And then there's the not-quite-an-error message route:



Okay, so I know that the reason gmail is showing in basic HTML is that I don't have JavaScript enabled, because I've been out messing with it. But if you, say, sat down at my computer and tried to log in to gmail, you'd be asking me why it looks so funny on the mac. Or at least, that's how the friends who've tried to use my laptop reacted when I left things like this.

I do love how Google automatically downgrades when possible (and it does this with a lot of services) but sometimes it might be worth letting people know why you're seeing the reduced interface. This is really apparent if you use Google maps, which only gives driving directions (no maps!) if you have JavaScript disabled and search for one address to another instead of a single address. Very confusing if you're not the one who disabled JavaScript, or you did it because of some unrelated thing and didn't realise it was going to break the web.

But it's still better than no error message at all combined with pages that just don't work, which seems to be very common. Stay tuned for more broken pages!