The Password: A Thing of the Past?
Gates, Bill

(Editor's Note: Last week Bill Gates, chairman and chief software architect of Microsoft Corp., Redmond, Wash., addressed RSA Conference 2006 in San Jose, Calif. In his remarks, he called for a more secure digital future, where interconnected networks worldwide allow people and businesses to work across a multitude of devices, products, services and organizations, with greater confidence in the security of their experiences; and suggested that new security measures could make the password a thing of the past. Below are excerpts of his comments.)

I want to start off talking about the vision of how we see the industry coming together and really delivering the broad trustworthy environment that we all need for computing.

Why is this important? Well, the move towards digital approaches in everything we do is accelerating. Whether it's medical records, tax records, buying and selling, scientific data, important communications, including national security; all of these things more and more are using the Internet.

And this has become such a critical infrastructure for productivity, for reliability, for privacy that the dreams we have can only be realized if we not only build secure approaches but make those easy to administer and make it so the users understand exactly what to expect: how will their information be used, how often can they expect the system to be working totally on their behalf.

And so that means a lot of invention, a lot of improvement from where we are today. I think we're making progress, but it's a very big challenge to make sure security is not the thing that holds us back.

So what would the industry have to fulfill this? Well, I think there are four key things, each one of which I'll dive into: the trust ecosystem, an ability to engineer for security, simple approach so that the models are quite clear, and finally, fundamentally secure platforms where the capabilities really are designed in, in a way that you don't have to pay much attention to them.

So the first and I think a crucial element is this trust ecosystem. What is the trust ecosystem? Well, we have code, we have devices, we have users. And all of those things have certain characteristics. Users are members of groups; when somebody authenticates themselves, it's based on a secret that was provided to them by somebody else. And so we have chains of trust, not just a simple single level, but many levels of indirection taking place.

What we need here is an ability to track those trust relationships, to be able to grant permissions, and to be able to revoke those trust relationships, to develop reputation over time; if a piece of code is not behaving appropriately, it should be marked that way and therefore blocked from being used on different systems. If a problem comes up on something that was trusted, you should be able to make sure that it's no longer running, even if it's gotten out very broadly…

...So let's move to the second piece, engineering for security. Again, this is an element that there's no ability to get around. There will be portions of code in the system that act on your behalf to perform an operation, and those pieces of code have to be written reliably, reliably in a way so that even if somebody malicious is putting in an extremely long answer that wasn't expected or trying to fool the input to put in a sequel screen where it was just supposed to be a literal, the code has to operate as expected.


Now, one of the architectural techniques that we can do is to make sure that the portion of the code that has to be correct is much, much smaller than it is today. Today, virtually all the code has the privilege to do various things. And so, for example, say you have code that's just parsing a file; that code which is doing that parsing, in fact, you know very well that it's not supposed to go off and read files or transmit information. And so you can take that code and run it in a process so that even if somebody manages to make the parser break, the kind of operations they can do are very, very limited…

…The third, you can say, is pretty much commonsense, but if you look at the security systems that are out there today, we don't achieve this, and this is the idea of simplicity. How many different software products do people have to think about, how many different user interfaces do they have to see, how many different audit logs do they have to go through in order to see exactly what happened and try and track down the source of an activity?
Today, whether it's end users or developers or IT professionals, the number of firms and products and screens, things they have to know is probably an order of magnitude than it can be in order to have these systems be administered very, very effectively…

…Finally, and some people might have expected me to start with this, but another key element is fundamentally secure platforms; that is, you can't layer on top of the system elements that really make something secure in terms of being able to track, keep it up to date; you just get too much of a mismatch between the elements and so that's not going to work.

What are some key elements of fundamentally secure? Well, the first is isolation. If you go back historically and say why were computer systems largely secure, it wasn't because people wrote better code-in fact, they had none of the proof tools and scanning tools and the rich things that we do today; those systems were secure because they were isolated, there wasn't an Internet pipe that allowed arbitrary packets to come in and see what code paths might have flaws in them…

…Another weak link is in authentication. Today, we're using password systems, and password systems simply won't cut it; in fact, they're very quickly becoming the weak link. This year, there was a significant rise in phishing attacks where sites that pretended to be legitimate would get somebody to enter their password and then be able to use that to create exploitive financial transactions.

And so we need to move to multifactor authentication. A lot of that will be a smart-card-type approach where you have challenge/response, you don't have a single secret that you're passing to the other person so they can actually have that and reuse it. It's a significant change and that needs to be built down into the system itself.

We need to use policy base controls so that somebody managing systems, instead of picking system by system, can say users of this group are allowed do to these things, not allowed to do these things, making those management tools very, very simple.

And finally, the ability to track what went on, have very quick recovery because you have checkpoints that allow you to restore data, restore system state, those are very big things. And that kind of checkpointing simple restoration, it won't work as something done outside the system, it's got to be built-in to provide a fundamentally secure platform…

…Let's talk about simplicity. I'd be the first to say that some steps have been taken here, but if there is an area that we absolutely need to do dramatically better, this would be it. The number of screens that you have to get involved in, the number of places you have to go to find out what went on are still too high, and more integration of the design is part of the way we'll deal with that.


For end users we will have this year a thing called OneCare built into Vista, we have a dramatic improvement in the SecurityCenter, and we have this new idea of "InfoCard." This is the idea that you don't always want to present all your information, you'll have different cards, cards that just give your location, cards that are more secure that give your credit card, and cards that you would protect very carefully and even have a pin for every use of it where you might authorize access to your medical information.

And so thinking of those different cards really has gotten people understanding that there are different types of authentication, and even in those authentication steps, in some cases you need a level of indirection so that you can have privacy even as you're doing those authorization steps.

A lot of governments around the world are looking at issuing smart cards, and now they understand that there needs to be many of these "InfoCards" on there to deal with the different scenarios that users are involved in. And the user interface for this is actually built in to the next version of Windows and the Internet Explorer.

For IT professionals it's all about making simple group policy statements work in a very broad way, combining the work that's done on the directory and the policy things today with security. Security and management are not really two separate things; you want to have an architect that allows for lots of extensibility, lots of plug-ins, third party products that you want to bring that user interface back together into one simple place that works for the IT person.

Let me wrap up by talking about the need to focus as an industry on each of these four areas, to continue to make progress. After all, the opponent in this case, the person that's trying to invade these systems for financial gain, is not standing still. For every improvement we make they look for additional vulnerabilities, and so the idea that we have to improve, really improve broadly in a consistent way with tools that allow for broad adoption of these things I think is extremely important.

In terms of the trust ecosystem, there are some key elements. The move to smart cards, the idea of the "InfoCards" that have different pieces of information that can be stored in different places, the support for the protocols that have come out of the standards process there that make it possible for people who are writing service type applications to not have to duplicate any of that security code, so a lot of adoption there. We're really just at the beginning of the trust ecosystem that is very, very fundamental. Even federation today, most companies are not doing that, and if you look under the covers, there's a lot of insecure activity, a lot of lost productivity because that's not in place.

Secure development practices, having code written at the highest level, sharing the code that does have security attributes, knowing whether you have the expertise internally or you need external review to make sure that that's done well, and having the tools themselves be better and better to reduce the amount of code that people have to write, that's very important.

Simplicity: A lot of ways to measure this, and that's one of the things that we're really getting better at is looking at how many of those screens ought to be in systems to see if people aren't setting these things up the right way, it must have been that we made it too complex to do it that way. Updating was a great example of that. We had tools for updating, but the actual adoption of those, if you go back two years ago, was at about the 15 percent level. That one we've made enough progress that now we're achieving about 80 percent of people are doing the right type of regular updates; obviously we want to get that to 100 percent because updating is just one element of making sure there's no widespread attacks.

And finally, the fundamentally secure platforms, a lot of work to go in on that.