Developers are users, too.

Jesper and Steve like to talk about “users just want to see the naked dancing pigs“.

What they mean is that when users have selected an action that they want to do, whether it’s looking at a purported picture of a naked celebrity, or getting rich by forwarding email to all of their friends, acquaintances and soon-to-be mortal enemies, those users are not going to let something like a security warning get in their way.

Different security professionals take different tacks on this – Bruce Schneier and Marcus Ranum seem to think that this means that you just can’t teach users. Jesper and I believe that this simply means you should try harder to educate users, and give them the information in a way they can understand and appreciate.

Jesper also likes to talk about NULL DACLs – not like an empty DACL, which rejects everyone’s attempt to access the protected resource, but a NULL DACL. If you set a NULL DACL on a file, it will allow everyone to have any access to the file.

Why on earth would you do that? Why wouldn’t you just want to use the default setting, which is appropriate for most uses?

I went through the documentation for SetNamedSecurityInfo, and found the reason:


[in] Pointer to the new DACL for the object. The SecurityInfo parameter must include the DACL_SECURITY_INFORMATION flag. The caller must have WRITE_DAC access to the object or be the owner of the object. If you are not setting the DACL, this parameter can be NULL.

 So, if you’re reading that with the intention of not setting the DACL, you read “The SecurityInfo parameter must include the DACL_SECURITY_INFORMATION flag”, so you set that, and then you read “If you are not setting the DACL, this parameter can be NULL”, so you set pDacl to be NULL.

When you look at your watch, you are asking it a question, and it’s usually “how long until…” or “how long since…”, and not “what time is it?” As a result, if someone asks you the time after you’ve just looked at your watch, you will generally have to look again in order to answer that question.

The same is true of documentation – developers will ask the documentation a question. They won’t read it as if it were a novel (okay, so I do, but then I’m a little freaky). Given the question “how do I use SetNamedSecurityInfo on a file without changing the DACL”, the immediate answer appears to be “by calling SetNamedSecurityInfo(…DACL_SECURITY_INFORMATION…,…,NULL,…);” – exactly the behaviour that Jesper calls out in his presentation “Is that App really safe?

So, developers are users too – they have their own naked dancing pigs as a goal, and they read only the minimum necessary to get them there. Just as a secure developer needs to consider the behaviour a user will have, and design the security dialogs accordingly, so too a technical writer needs to consider the behaviour a developer will have, and place security warnings close to the description of risky parameters.

Where’s Jesper


Jesper used to blog all the time.

Jesper used to travel the world, speaking and spreading the news about computer security.

Jesper has a new blog, but it’s been a long time since he’s put anything there.

So, where’s Jesper now?

He’s stopped traveling the world, that much I know, because his kids were starting to ask “when that strange man was going to come visit”.

I just wish I could think of a good explanation for why he’s not blogging.

Now, it’s ever the security professional’s concern that he or she might inadvertently publish something that will let the unscrupulous attack the systems under their protection, or that will cause customers to lack confidence in the security of those systems.

But that’s part of the job, and if you can’t be trusted to have a little discretion, then you’re in the wrong field. It’s also worth pointing out that a key tenet of security theory is to assume that your attackers have complete specifications of your systems, so anything you reveal should not harm a well-designed system’s security (unless you’re going to post your p@55w0rd).

Or perhaps he has nothing to blog about – maybe there’s nothing of interest going on in security in his current position, or maybe it’s all so bad that his company can’t risk him talking about anything related to security in case it scares customers away. I’m pretty certain that’s not the truth, but it is an obvious conclusion that you’re going to draw when you have no information on which to proceed.

No, I just can’t see that there are any good reasons that he isn’t blogging… anyone got any better ideas?

Soon all your privacy problems will be history

According to recent research, 49 million adults in the USA have been notified of breaches of data security that have exposed their private information to unauthorised recipients over the past three years.

At this rate, shortly we won’t need to worry about privacy and data protection, because everyone’s data will already have been made public.

The “Programmer Hubris” on this one?

Programmers and database designers should remember that the data they hold is not theirs. It is other people’s data, which they hold in trust for others.

Learn the humility to realise that the data you hold on other people is a valuable commodity to thieves and malcontents, and even more valuable to the people who are represented by it. You are a security guard for millions of dollars – don’t you think it’s worth putting this data in the equivalent of an armoured truck?

ChangePassword versus SetPassword

Writing a piece of code last night, I was struck by the thought that many developers I’ve worked with would not know why I use a ChangePassword function, instead of a SetPassword function.

The difference in use is simple – SetPassword requires one password (the new one), whereas ChangePassword requires two passwords (the old one, and the new one).

It would seem as if the obvious easy function to use is SetPassword, because you don’t need to prompt the user for the old password on the account.

But I avoid SetPassword unless there’s absolutely no alternative – why is that?

Because of all the secrets that a user may own – private keys for EFS encryption, for email identification, for server identification, etc.

Any secret like this is stored in the DPAPI store, which is encrypted using a key derived from the user’s current password.

If you use SetPassword, all the information is still in the DPAPI store, but the user no longer has access to it(*).

[The information is still there for a simple reason - if your use of SetPassword was to gain access to an account while its owner is away from work, you'll want to regain that data when the user comes back. You can do this by having him change his password from the new password back to his old password.]

This means that the user loses access to their encrypted files, loses the ability to identify themselves in email (and to decrypt messages sent to them), or if this is a server account, they lose the ability to start up an SSL-based server.

Using ChangePassword, by comparison, because it uses the existing password as a starting point, re-encrypts the DPAPI store with a key derived from the new password.

The other big advantage of a ChangePassword function is that it can be used by anyone, without administrative rights being required (subject to rights and policies, depending on the tool you’re using and the OS you’re on).

That sounds like a security violation, but isn’t – after all, if you know the user’s old password, you can log on as that user, and as long as the user is able to change his own password, there’s no functional difference between you logging on then changing your password, and changing your password from some other account by providing your old and new passwords.

Depending on the interface you’re using, these functions may not be called ChangePassword and SetPassword – for instance, in the Win32 API, the functions to use would be NetUserChangePassword and NetUserSetInfo.

(*)Not quite as simple as this – on a domain at Windows 2000 or later, you will find that a second copy of the DPAPI Master Key is stored in the domain controllers, encrypted using the DC’s private key. In the event of a SetPassword operation, the DPAPI Master Key is decrypted and re-encrypted with the new password, so you don’t lose any data. The same is sometimes true on workstations, depending on the version. Details are in KB article 309408)

Changing passwords on a service, part 2

In a comment to my earlier article, Scotty (a friend of mine from the mother country) asks:

Have you looked at passgen.exe from Jesper and Steve's book which would let you set a different password per machine (great for machines in different pools of risk) as well as making sure it was complex. Good tool.

Curiously enough, that's more or less the same question that Jesper asked me when he called while I was working through this problem.

Jesper's a good friend, and I'd hate to tell him that I loaned his book out to a colleague shortly after I bought it, and that I had completely forgot about the passgen utility. Fortunately, I didn't have to, because as it turns out, there are a few things passgen doesn't do that I need, and perhaps a few that it does that I don't need.

  1. The passwords in question are for a service that runs on multiple disparate machines, but all using the same domain account. They can't be random, they must be the same across all those machines (okay, so I don't have to use the -g option).
  2. Because these services access network resources using NTLM – which uses a hash of the password to identify the account – the services must be restarted after the password is changed. Stopping and starting them in sequence across a hundred servers would be far less efficient than doing so in parallel (but could be reasonably done).

But we're starting to get into a long batch file, and generally those are not so easy to debug. It's time to head to script.

Because I'm scripting, rather than using the command line or a batch file, I can afford to add a couple of behaviours, too:

  • Log errors to a file, or to screen, depending on whether you choose to redirect.
  • Automatically enumerate all services that use an account on each named server.
  • Prompt for the password without echoing it.
  • Wait for all services to stop before re-starting them (to avoid dependency issues).
  • Learn how to use WMI in script.

[That last point - learning how to do something you've never done before - is a powerful reason in itself to do something yourself even when there's a tool already available. Otherwise, use the tools that others provide, wherever possible.]

The attached script, svcpwchange.vbs, is what I have produced after a week's playing around. Let me know what you think.

As with the advisories in Jesper's Passgen tool, the stop and restart won't work properly for services that run in a shared process. The tool also won't restart services that are dependent on the service whose password you are changing – unless they use the same password. One other thing that passgen does that my script doesn't, is to actually change the password on the account itself – you'll need to do that before you run this script! [Exercise for the reader - add the code to set the password.]

Microsoft gets opener every day

Wow – who would have thought that Microsoft and Novell were partnering up to offer not just technical interoperability but licence and legal interoperability between Windows and Linux?

Ray Noorda's only been dead a month – is he turning in his grave already?

The technical parts of this agreement cover virtualisation – to run Linux apps on Windows, and Windows apps on Linux; Management by Web Services – so you don't have to have a pair of machines just to manage your server room; and Document Format Compatibility, so you can use whatever Office Suite floats your particular boat, and share documents with the guy down the hall who uses the stuff from the other religion.

The legal part of this agreement is probably the one that's going to cause most excitement (because the technical parts were fairly readily available already), in that Microsoft promises not to sue SUSE Linux users, and Novell promises not to sue Windows users, for any patent violations between Windows and Linux.

Also, Microsoft will not assert its patents against individual noncommercial open source developers, or against individual contributors to SUSE Linux. How cool is that?

My Take: I think this comes as a relatively obvious result of the battles between Microsoft and Linux with cries of "we might just sue your customers, so people better not buy your software" – if you scare everyone away from the field, nobody benefits. This way, two rivals get to boost each other's sales.


You have to love it.

And you want to be the first in your field to think of it.

What is an MVP?

As a Microsoft MVP (Most Valuable Professional), I’ve occasionally found that people have no idea what that means.

Here are some of the suggestions I’ve heard from others:

  • A corporate ‘shill’, paid secretly in order to say good things about Microsoft.
  • An ‘evangelist’ for Microsoft.
  • Someone who’s crazy enough to work for Microsoft on their spare time for free.
  • A person seduced by free trinkets and toys to market on behalf of Microsoft.
  • An ‘astroturf’ campaign (an artificial ‘grassroots’ campaign) designed to persuade people that ordinary users support Microsoft.
  • It’s a test you can take, like MCP or MCSE.
  • It’s a programme you buy into, like the Microsoft Certified Partner programme.

Well, it’s none of these things, but it can look like any number of them.

If it’s confusing, don’t worry – many times, even Microsoft staff get it wrong, and act as if we’re on some kind of retainer.

MVP is an award. As such, it is given for past behaviour.

MVPs are not slavishly devoted to Microsoft – one of them is, to my knowledge, a Linux / Unix fan, and got his MVP award based partly on displaying his knowledge of interoperating those systems with Windows.

There’s no test to be an MVP – and no criteria.

The general requirements are this:

  • Be neutral-to-positive towards Microsoft overall (I mean, really, would you award anyone who consistently slags off your products?)
  • Demonstrate a persistent ability to voluntarily help the community of Microsoft customers.

That’s pretty much it.

Oh, and you have to be over 18, because some of the award is access to NDA material, so you have to be legally able to sign the NDA.

I’ve heard of only a handful of people who have “tried to become an MVP” and succeeded, and they generally were not re-awarded.

More common by far, and the way most MVPs feel, is that you would be doing this stuff anyway, because you enjoy helping others and learning from the experience.

The award makes you feel less like ditching the “helping the community” hat the first time someone calls you in the middle of the night demanding free support because they don’t want to pay Microsoft for a support call, and by the way, their entire corporate structure is about to collapse unless you can fix their problem.

The award also puts you in contact with numerous other people who feel and act the same way you do – learning by teaching, helping yourself by helping others.

It’s by no means a recompense for the service that MVPs do, nor is it a bribe to make us talk nice (MVPs are often the most accurately targeted and vocal critics of Microsoft’s failings).

It’s a recognition that we are helpful to you.

Don’t surf from your dev box either

I’ve always scoffed some at reports of vulnerabilities in Visual Studio.

After all, how many ways is a developer likely to get attacked through Visual Studio?

Through loading and executing malicious code – don’t fetch code from people you don’t trust, and don’t run code that you don’t review first.

Through debugging malicious code – don’t try that trick on a machine that you aren’t going to wipe afterwards.

etc, etc.

Quite frankly, a developer should be smarter, technically speaking, than most users, so he or she should be harder to attack. Also, developers (for various reasons) generally have to wipe and re-install their systems on a regular and frequent basis – every six months or so.

But this bug – in an ActiveX control that’s installed with Visual Studio, and may be accessible to Internet Explorer, where it’s exploited by malicious web sites, that’s something that has me reminding all the developers I work with:

A development machine is like a server – you shouldn’t be surfing from it, and if you are using a web browser, it should be to visit sites that contain documentation and source code only. Turn off all “active content” options in your browsers on your development machines.

Partly, though, this is a bit of a rant against ActiveX controls – so many get installed by so many different products, and they all seem to want to make themselves available for scripting by web sites visited by Internet Explorer.

I guess it comes down to Programmer Hubris – that developers are convinced that their ActiveX control will be the way to achieve an action, whether on the web, in an application, or as a kind of shared library. And then we have to bring out the kill-bits.

Whenever you consider writing a shared component, or a network-capable program, remember that you’re only one half of the programming team.

The other half of your team are intent on perverting your code to their purposes.

And they’re really good at doing so.

And they outnumber you.

And they can take far longer to get their half to work.

And it doesn’t have to be as solid, or as stable.

You have to be better – or you have to admit that you shouldn’t (yet) be writing the shared component, or the network-capable program.