Steve Riley on Security : passwords

Passgen tool from my book

Steve Riley — Mon, 29 Sep 2008 23:42:29 GMT

Way back in 2005, Jesper Johannson and I wrote Protect Your Windows Network. It’s still available, and although its product set is now somewhat dated (Windows XP and Server 2003), much of the practical advice about security policies, social engineering, security dependencies, and how to think about security remains relevant. That’s because we strove to write something more lasting than a simple configuration guide.

On the CD-ROM accompanying the book we included a tool called Passgen. In the book, we recommended that you maintain separate passwords on every local administrator and service account in your enterprise. This is, of course, almost impossible to manage without something to automate it for you. That’s what Passgen does. The tool generates unique passwords based on known input (an identifier and passphrase you define), sets those passwords remotely, and allows you to retrieve them later.

For a while Jesper maintained a web site for the book, running on a server in his house. His ISP changed policies and made it impractical to continue running the site. But because the tool is still so useful, I’ve put a copy in my SkyDrive—look in the “Passgen” folder.

Also, note that I’ve put a new section in the right-side column, “Resources for you.” Here’s where I’ll keep links to bits and pieces that many of you will find relevant and interesting.

Update. A few readers have informed me that the SHA-1 hash printed in the README.DOC doesn’t match the actual hash of passgen.exe. Jesper made a few changes and recompiled the tool. The correct hash is now:

fa19722348e9e0603f24c0ef9fc715010403bcfa

I’ve updated the README file with the new hash. Also, passgen.exe has a digital signature, and you can check its details if you’d like.

Password policies. Once again.

Steve Riley — Wed, 05 Sep 2007 01:14:00 GMT

Recently in the newsgroups (news:microsoft.public.security, to be specific) the question of password polices and the out-of-box defaults came up. The poster lamented a number of things: that Microsoft doesn't enable account lockout by default, that we don't have a built-in mechanism for automatically disabling unused accounts, that the 42-day default expiration is troublesome. Here's my response; figured that it would make for a useful blog post, too.

Account lockouts

Account lockout is a poor substitute for good passwords -- and is one of the most expensive security features you can use. Let's think about this by considering the threat. What threat does account lockout (attempt to) mitigate? Password guessing. How can you make password guessing attacks become useless for an attacker? Two ways: implement lockouts or use good (meaning long) passwords.

Consider the first choice, account lockouts. The typical cost to an organization to reset locked accounts is US$75 per help desk call. In a medium or large organization, this can become a very high monthly maintenance cost. In nearly all instances, the call results from users locking themselves out (too many vodka tonics on the plane, maybe?), not users encountering locked out accounts because some bad guy was trying to guess passwords. Account lockouts have one more -- very bad -- problem: they create opportunities for bad guys to conduct denial-of-service attacks against accounts or entire domains! Even if you use a timed unlock of, say, 15 minutes, then the attacker can write his script to churn through thousands of bogus logon attempts every 15 minutes 2 seconds. So, contrary to the claim, enabling this setting actually can have significant impact on usability.

Account lockout is there for people who absolutely need it. But I can't think of any instance where this is true. Instead, have a policy that requires simple passwords at least 15 characters long. Forget about complexity rules that force people to write down passwords. A simple 15-character passphrase (think short sentence) is easy to remember, quick to type, and far stronger than any short complex password. A passphrase like this will withstand any kind of automated password attack, including those based on rainbow tables. And you can even use a method that helps you remember unique phrases for each site, if you wish:

web mail: "my dog and i got the mail"
shopping: "my dog and i bought some stuff"
office: "my dog and i went to work"

This is why we disable account lockout by default. There are much better -- and much less expensive -- ways to mitigate the threat.

Disabling unused accounts

You're right, there's no built-in method to automatically disable unused accounts. A variety of third-party products can provide you with this functionality. I suspect some of them might be free, perhaps simple scripts even. I tried searching on "automatically disable unused accounts" and saw a few hits that looked promising. This particular function, however, rightly belongs in the HR process. A number of customers I've spoken with have automated the account creation/disablement/deletion process, incorporating it into HR systems. When a new user is hired, the account is created; when the user departs, the account is disabled; some time later, it's deleted. The HR systems take care of this, not domain or enterprise administrators. I wrote more about this subject in "When you say goodbye to an employee."

Password expiration

Password expiration is an important setting for everyone. It mitigates two threats: employees sharing passwords and bad guys discovering passwords. Because we can eliminate the second threat using long simple passphrases as I described above, then we have only one remaining threat: password sharing. Your estimation of how prevalent this threat is in your environment will guide you toward choosing an expiration time that works for you. 42 days is a reasonable default; our own corpnet uses 70 days. My experience with most customers shows that password sharing isn't a problem. So for those who do enforce long simple passphrases, I suggest that a reasonable default for expiration is 120 days.

Windows begins notifying you 14 days before your password expires. You can change this time period through group policy. I was in a similar situation recently. Last month my domain password expired while I was in Australia for TechEd there. I could continue to log on to my laptop with cached credentials, but couldn't use Outlook Web Access or RPC+HTTP of course. So I connected to a Terminal Server computer we have on the Internet, logged on there, and changed my password.

Why administrative passwords will never be like nuclear missile launchers

Steve Riley — Tue, 21 Nov 2006 13:16:22 GMT

During the past few months many people have lamented that Windows lacks a nuclear missile style control option for administrator passwords. Surely you've read about or seen photographs of missile silos where two operators, separated by a distance greater than the span of a single human's arms, must each simultaneously turn a key in a switch to launch a missile. Such a fail-safe is important when considering missile launches: presumably a nation can't thus be committed to global thermonuclear war on the deranged whims of a single raving lunatic.

At first glance, it seems reasonable to allow for similar control over domain and enterprise administrator accounts. A while back I wrote about the fundamental requirement of trust in administrators; missile control-style passwords (is there some official term for this?) might lessen the requirement for such trust, goes the thinking. Well, I'm not convinced that the logic that works for missile silos extends to administrator passwords. Let's examine the differences.

It works for missile silos because the fail-safe is tuned to the characteristics of its environment. It takes two keys, each of which must be rotated simultaneously, and they're separated by around ten feet or so: therefore, two humans absolutely are required. To accidentally or intentionally launch a missile when not under orders, both people must be either equally stupid or equally insane -- and in the second case, also equally trust that each is, in fact, a criminal, rather than one acting as a double agent attempting to entrap the other. Furthermore, both operators perform the function in full view of a whole lot of government staff and military officers. The environment and the fail-safe work together to keep the deadly missiles in the ground. Another important aspect is this: the silo and its control system are designed by and operated by the same entity, the government.

Now compare that to a domain controller. Let's say that it's possible to enable a feature that requires entering two passwords. Where would you do this? A logon screen with two password entry fields lacks both physical and human separation: one person could enter both passwords if he or she knew them. It's no better with smartcards -- again, one person could insert both cards into the readers. Replicating a silo-like environment using a pair of computers isn't the answer, because unlike the silos and their control systems, Microsoft designs Windows but you operate it. The fail-safe works for the silos because of the required physical separation. Microsoft can't dictate, and certainly can't enforce, that you have two domain controllers, separated by at least ten feet. Not everyone can afford all the necessary hardware; plus, think of the demands that would place on space and power in a data center. And besides, even with separated domain controllers, a malicious admin need only to enter the first password or insert the first smartcard in one computer then wheel over to the other one and enter the second password or smarcard there. I'm not sure there's a way to check for simultaneous credential entry.

Separation and delegation of administrative duties is, of course, a good and important concept, one that we'll continue to refine throughout the operating system. There's a lot of power granted to administrators right now, this power we will help you segregate among multiple roles (humans) in your organization. But because of the nature of computer systems, any human granted a particular bit of administrative power must be trusted with that power. Computer systems and the data they store, process, and protect aren't silos; applying silo-style security is the wrong approach to mitigating security risk.

Security myths and passwords

Steve Riley — Sun, 30 Apr 2006 19:07:00 GMT

I like this a lot.

http://www.cerias.purdue.edu/weblogs/spaf/general/post-30/

In the practice of security we have accumulated a number of “rules of thumb” that many people accept without careful consideration. Some of these get included in policies, and thus may get propagated to environments they were not meant to address. It is also the case that as technology changes, the underlying (and unstated) assumptions underlying these bits of conventional wisdom also change. The result is a stale policy that may no longer be effective…or possibly even dangerous.

Policies requiring regular password changes (e.g., monthly) are an example of exactly this form of infosec folk wisdom.

From a high-level perspective, let me observe that one problem with any widespread change policy is that it fails to take into account the various threats and other defenses that may be in place. Policies should always be based on a sound understanding of risks, vulnerabilities, and defenses. “Best practice” is intended as a default policy for those who don’t have the necessary data or training to do a reasonable risk assessment.

What do YOU need out of two-factor authentication?

Steve Riley — Fri, 21 Apr 2006 01:37:00 GMT

Two-factor authentication continues to grow in popularity and emerge as a security requirement for many people I meet with. At Microsoft, we use smartcards internally for VPN access right now; soon we'll be requiring smartcards for domain logon, too.

We are also looking at ways to require two-factor authentication for web-based services, like Outlook Web Access, published SharePoint servers, and other bits in our extranet. I love smartcards, and it's Microsoft's preferred product direction and corporate IT approach. But here we encounter a problem with them: most public workstations (kiosks, Internet cafes) don't have smartcard readers. So how do we require two-factor authentication when the infrastructure can't support it?

Ideally, my answer would be: too bad. Public workstations are too great a risk. No self-respecting organization would ever allow access to corporate resources from unknown machines, right? What possible business justification would ever permit exposure to such risk?

A lot, it turns out. Any organization (Microsoft included) that permits access to corporate resources, like OWA, is making a risk statement, whether they know it or not. That statement is this: "Our business activities require access to certain resources from any device, anywhere, at any time. We accept the risks associated with this because the value to the business is determined to be higher."

But just like us, many organizations are starting to become wary of these risks. Two-factor authentication can help to mitigate some, but not all, of them. The choice, then, is which kind of two-factor authentication to use? If smartcards won't work because readers aren't yet ubiquitous (they will someday -- remember, once upon a time a mouse was a rarity), what's left to choose? (I wish we'd include smartcard readers in every box of Windows we ship, just like we included mice in Office.)

Some form of token card with a one-time password is generally the option, with RSA SecurID being the most popular. Lately I've been reading about VeriSign's Unified Authentication product -- a number of you have mentioned your success with it, and you like that it integrates natively into Active Directly without requiring a separate authentication infrastructure (unlike SecurID, which requires an ACE/Server). I would like to play with this myself someday (hint hint).

I want to hear from you, though. What do you need from a two-factor authentication mechanism? What are your requirements? Have you used the products currently on the market? What do you like or not like? What do you want to see done differently? Would you like for Microsoft to develop something, or do you prefer to rely on partners?

Tell me what you think. Our IT department is engaged in a lot of research here; I'd like to know what you've learned in your research and through your experience, too. Post a comment here or email me if you'd prefer to remain private. Either way, I'd really like to get a good body of customer thinking on this. Thanks!

It's me, and here's my proof: why identity and authentication must remain distinct

Steve Riley — Thu, 16 Feb 2006 20:41:00 GMT

My February Security Management column is posted:

http://www.microsoft.com/technet/community/columns/secmgmt/sm0206.mspx

No matter what kinds of technological or procedural advancements occur, certain principles of computer science will remain -- especially those concerning information security. I’ve noticed lately that, among all the competing claims of security vendors that their latest shiny box will solve all your security woes, a basic understanding of computer science fundamentals is missing. Because good computer science never loses importance, and because knowing the science can help you choose products and develop processes, from time to time I will cover such topics in this column. This month I’d like to explore the concepts of identity, authentication, and authorization, to help you understand their important distinctions, and to help guard you against the increasingly common tendency to combine the first two.