Tales from the Crypto

More proof that crypto is harder than it needs to be.

I went looking today for a definitive statement on what purposes a certificate needs when it is created for an SMTP server that uses STARTTLS (I'm still looking, but I'm pretty certain I know what it needs).  I came across this gem of a piece from the Mac OS X guide to SSL:

The CSR and key are generated in the current directory, in a file called newreq.pem. When you enter:

cat newreq.pem

the system displays the file, which looks something like this:

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,21F13B37A796482C

XIY0c7gnv0BpVKkOqXIiqpyONx8xqW67wghzDlKyoOZt9NDcl9wF9jnddODwv9ZU
A1UECxMPT25saW5lIFNlcnZpY2VzMRowGAYDVQQDExF3d3cuZm9yd2FyZC5jby56 
YTBaMA0GCSqGSIb3DQEBAQUAA0kAMEYCQQDT5oxxeBWu5WLHD/G4BJ+PobiC9d7S 
6pDvAjuyC+dPAnL0d91tXdm2j190D1kgDoSp5ZyGSgwJh2V7diuuPlHDAgEDoAAw 
DQYJKoZIhvcNAQEEBQADQQBf8ZHIu4H8ik2vZQngXh8v+iGnAXD1AvUjuDPCWzFu 
QxS2zwfKG1u+YqS1c2v5ecBgqW78DQLvxMkpYU8+xge7vDeoYKE14w==
-----END RSA PRIVATE KEY-----

-----BEGIN CERTIFICATE REQUEST-----
MIIBPTCB6AIBADCBhDELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw 
ZTESMBAGA1UEBxMJQ2FwZSBUb3duMRQwEgYDVQQKEwtPcHBvcnR1bml0aTEYMBYG 
A1UECxMPT25saW5lIFNlcnZpY2VzMRowGAYDVQQDExF3d3cuZm9yd2FyZC5jby56 
YTBaMA0GCSqGSIb3DQEBAQUAA0kAMEYCQQDT5oxxeBWu5WLHD/G4BJ+PobiC9d7S 
6pDvAjuyC+dPAnL0d91tXdm2j190D1kgDoSp5ZyGSgwJh2V7diuuPlHDAgEDoAAw 
DQYJKoZIhvcNAQEEBQADQQBf8ZHIu4H8ik2vZQngXh8v+iGnAXD1AvUjuDPCWzFu 
pRUR8Z0wiJBeaqiuvTDnTFMz6oCq6htdH7/tvKhh
-----END CERTIFICATE REQUEST-----

Now, you can take this CSR to a Certificate Authority (CA) such as Thawte and Verisign. Using the CSR, you can purchase an SSL certificate from one of these CAs, and then use it to authenticate your email server.

Okay, so they just said that you should take the PEM file above to your CA, as the CSR?

That's bad.

Why's it bad?

Because that's not just the CSR, it also holds the private key.  Think of the private keys as being your internal organs - nobody gets to have them while you're still alive.

Sure, it's encrypted, but did you really want to take the chance that the guys with all that cryptographic experience?

The Certificate Request, for the record, is exactly that portion between "-----BEGIN CERTIFICATE REQUEST-----" and "-----END CERTIFICATE REQUEST-----" - that's the part (along with those two markers) that you should send to the CA.

This is pretty entertaining, but it doesn't beat the training guides for Mirosoft's Windows 2000 Official Curriculum course, which read "Alice encrypts a message using Bob's private key".  If Alice has access to Bob's private key, they should be able to share secret messages at the breakfast table without encryption.

Vista - new accounts will not be administrators!

I say "yay" to this post from David Cross:

"We have subsequently made the decision that in [Windows Vista] Beta 2, secondary user accounts will be standard users by default."

As he says, it kind of gives the wrong message when you're asked to enter the names of a half-dozen people to be created in your system, and they all get to be administrators of the system.  I installed Windows XP SP2 recently on my new laptop, and was more than a little dismayed that I couldn't actually install it without entering a name of a user who then became an instant administrator.

Quite frankly, I'd be happy if installing my OS, I get one account created, called "Administrator", with a blank or hard-to-guess password (blank for home, where physical access is an appropriate security limiter; hard-to-guess for work, where anyone and everyone can walk in).

My next step after installation is usually to join my domain - and I don't want any local (non-domain) users beyond the administrator.  I only have to go through and delete their profiles ... which you do through the User Profile tool, not by "RD /S /Q \Documents and settings\username".

[Yes, I could join the domain as part of my installation, but I prefer to leave network cables unplugged until after installation is complete - these days, that's an unnecessary superstition, but it used to be that the firewall wasn't configured on by default.]

New hardening guides arrive early for April Fools' Day.

Microsoft released a downloadable document today that discusses how to harden your Windows 98 and NT 4.0 systems.

It seems a little early for April Fools' Day, so I opened it up and took a look.

It's a 109-page document full of honest and useful advice for those of you in the untenable position of having to secure a network with components that date from the last century.

It could do with a little proof-reading ("The Security Configuration Manager is available from the Microsoft FTP server at http://microsoft.com/ntserver/techresources/security/securconfig.asp" - how is "http://" the start of an FTP server location?), but a quick skim through suggests that this is a good starting document for anyone who has to work with these older systems.

My only gripe on this initial read is that the suggestion to readers that their first step should be to try all means possible to upgrade these systems should have been in huge type, bold, and ideally a fetching shade of red to draw people's attention to it.

The danger of publishing guides like these is that people will assume that their presence means that these systems can continue to be used, and are sufficiently secure for corporate use.

The danger of not publishing guides like these, however, is that people will assume that their absence means that these systems are already sufficiently secure for corporate use.

Just as abstinence programmes do little-to-nothing to counter teen pregnancy and sexually-transmitted diseases, so too a security program should be willing to say "Windows 98 and NT 4.0 are no longer supported by their vendor, and are not secure for today's corporate environment," but follow this up with "Here's what you can do to make them more secure, if you find your enterprise in bed with these systems, and you cannot prevent what naturally occurs."

Usual disclaimers apply: read the list of hardening methods, and their reasons for being, and assess the risks and benefits of each before choosing to apply or discard them.

Remember RFC 1925:

"With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead."

More on the ActiveX behaviour change

Driving into work this morning (yes, I usually take the bus, but when there's no space at the Park & Ride, it becomes a No Park & No Ride), I had a realisation about the ActiveX behaviour change that's coming up.

Maybe it's been brought about as a result of a patent lawsuit, but think on this... maybe it has a beneficial effect on security!

If it takes one more click to actually interact with an ActiveX popup or an advert than it does to close it with the big red X in the top right-hand corner, users will gravitate to that easier option.

Just test the thing and get on with it.

Microsoft's Mike Nash has just stated that, although April 11's patch to IE will include the updated behaviour change made necessary by the Eolas lawsuit, because people outside of Microsoft are concerned that they haven't had a chance to test it enough on their LOB (line-of-business) applications, there will be an option to disable the behaviour change.

Message to corporate America:

Would you just test the thing and get on with it, please?

The behaviour change is simple, and has relatively minor effects.  It's irritating chiefly in that it is a) so unnecessary, and b) more awkward and counter-intuitive than the behaviour Eolas claims is "non-obvious" and therefore patentable (leaving aside the issue of prior art).

And for those looking for explanations of why Microsoft is choosing to code around the feature that Eolas' patent obscures, I'd point to recent patent cases such as the Blackberry / NTP settlement, where (I'm paraphrasing, I apologise if I get the legal terminology wrong) even after the USPTO said that NTP's patent was invalid and would be revoked, the judge in the case ruled that NTP's patent needed to be upheld, and that Blackberry (RIM, actually) should either settle with NTP to NTP's tune, or turn off their service.

So, even if Microsoft believes they'll win in the Eolas patent suit, they have to do what they can to lessen the intervening damage.

Microsoft's new password collector.

Sorry, did I say that out loud?

No, it's not really a password collector.

Probably.

What I'm talking about is a new tool from Microsoft that aims to tell you when a password is "Weak", "Medium", "Strong" or "Best".

Try it for yourself - see that "This is my password." is "BEST", and "Cz!r4Tz" is "Weak".

From that comparison, it's obvious that this tool is only a guideline, and probably that's all it can be - but you might want to try it on your users.  At the very least, many weak passwords will be shown to them as being weak.

Security koan #2

[Apologies if anyone finds the stereotype of the 'wiley Irishman' to be offensive. This story exists in many different forms, in many different cultures.]

Paddy works at a construction site.  Every night, he leaves his work, wheeling a wheelbarrow and a tarpaulin (canvas cloth covering the wheelbarrow) out past the security guard.

One night the security guard comes to him and says "Paddy, every night I see you wheel that wheelbarrow out of here, and I'm sure you must be stealing something.  Every so often, I stop you, I lift up the tarpaulin, and I see nothing's in the wheelbarrow.  Somehow you've figured out which nights I'm going to search you for stolen gear.

"Now, it's my last night on the job, I'm retiring tomorrow, and I don't feel I owe my old bosses anything, so I'm not going to tell on you - but for my own sanity, I've got to know!

"What are you stealing from the job-site?"

Paddy motions the guard close, and whispers in his ear.

"Wheelbarrows, and tarpaulins."

Flatten and pave; or don't get infected.

Bitzie puts up a link to Jesper's article describing the more academic side of this debate, that says the only thing you can do with an infected machine is to flatten and pave (i.e. delete everything, wipe the drive, and reinstall a new operating system, applications, etc).

This is great advice in theory, and it certainly is the only way to 99.99% guarantee that you have a machine free from infection.

Woah, wait, did you just say "99.99%"? Shouldn't that be 100%?

No, because there's always the possibility of a BIOS-infecting virus - what, you think that only Award, Phoenix get to write BIOS code? There's PGP and Microsoft, who wouldn't be able to get efficient and reliable whole-disk encryption going without it.

Then there's the whole idea of the Virtual Rootkit, which emulates your installed OS from itself, so that even reinstalling from scratch won't wipe it out, because you're installing into a hosted environment, not the real PC.

So, maybe that's 99.5% guaranteed if you do the flatten and pave approach to virus recovery.

Oh, but maybe you bought your machine from an OEM - I bought a laptop from Compaq (more gripes about this later) recently, and its only option for system recovery is a recovery partition.  Uh... who's to say I can't infect the recovery partition while I'm infecting the main body of the system?

Okay, let's reduce that to, oh, 98% guaranteed safe.

Then, of course, my computer is of no use without my data. Let's hope none of that is infected with macro viruses, buffer-overflows or other data-borne infections. The more recent (and therefore more useful) my backup, the more likely that it's going to contain litter created by the virus.

Better make that 95%.

Hmm... looks like we're heading for the same sort of recovery rate as if we just install a tool and try to remove the virus and its detritus.

Jesper can't be this wrong - I've met the man, and he's smart. Almost painfully so - you actually have to think while talking to him.

So I go back and I re-read the column. Carefully. Out loud (remind me to tell you about the tech-support teddy bear some day).

Here's the good part...

"You can’t trust any data copied from a compromised system. Once an attacker gets into a system, all the data on it may be modified. In the best-case scenario, copying data off a compromised system and putting it on a clean system will give you potentially untrustworthy data. In the worst-case scenario, you may actually have copied a back door hidden in the data."

"You may not be able to trust your latest backup. How can you tell when the original attack took place? The event logs cannot be trusted to tell you. Without that knowledge, your latest backup is useless. It may be a backup that includes all the back doors currently on the system."

Woah - Jesper's saying that you can't trust your backups... any backups, although he just mentions the latest one (as he says, "how can you tell when the original attack took place?").

What this article is really saying is that there is no way to make sure an infected system is clean, short of deleting all your applications and all your data, and typing the data back in by hand. As he says, it may be quicker to simply update your resume and leave.

I don't think Jesper hammered this point home clearly enough.

If you want a clean system, you have two choices:

1. After discovering an infected machine, wipe the machine and lose all your applications, data, backups and do the same to any machines with which the infected one communicated or shared data.
2. Don't get infected in the first place - patch when patches become available; protect against common routes of infection; run IPS (Intrusion Prevention Systems); be smart about what you do; run as administrator only when you absolutely can't avoid it.

The reality (and if you are a business computer user, I hope you already spotted this) is that at some point, the risk of possibly being infected is outweighed by the cost of the data and productivity loss that's caused by the flatten and pave.

So, the risk analysis view says that you do what you can to avoid getting infected, and when you detect an infection, you pick and choose very carefully what parts of your data you trust.

Error 0x80005000 and DirectoryEntry in .NET

So I've got a project that requires I write a web app that checks against Active Directory (an ADAM instance, as it happens).

It doesn't seem to work, for the longest time.

I've got my server's address set out, I remember to use the "Distinguished Name" format of the user name, and I have the right password.  I've selected the right AuthenticationType, and I still get an exception:

"Unknown exception (0x8000500)".

Here's the code that failed:

I just couldn't see anything wrong.

I'll come back and edit this post later with the answer...

EDIT...

Okay, so nobody else saw the answer either - that makes me feel better.

The answer is simply that I put "ldap://" at the start of the adamServer string.  The protocol specifier is case-sensitive.

Who thought that one up?  Is "ldap" really different from "LDAP"?  How?  To what protocol does "LDAP" refer, if not to "ldap"?

So there's your answer - the string should have been "LDAP://servername:389/DC=example,DC=com" - elements in the string other than "LDAP" are all case-insensitive.

Security Through Obscurity

It's long been held that "Security Through Obscurity" is no security at all.

Okay, so that's not exactly true, because of course your password only works because it's secret - obscured from others; your private key only works because it's secret; etc,etc.

But these are all "exceptions that prove the rule" in a real sense - they are strings that you make up, or numbers that you choose randomly - and the knowledge that one password or one private key is little better than another is a part of the public review of the algorithms in question.

There are, unfortunately, many other examples of Security Through Obscurity that people don't realise they are using.

"My operating system / application has far fewer bug reports than yours, so therefore it's more secure," is the example that keeps popping into my mind.

Your OS / app may very well be more secure than my choice, but if the only argument you have can be satisfied by the axiom that "more hackers attack this than any other target", that's not a winning argument.

Recent Apple vulnerabilities showed this - one vulnerability appeared, got some news coverage, and suddenly it was (a very brief) open season on Apple.

If you want to convince me that I have a long-term chance of security success in your environment, you have to tell me why it's:

• technically superior - there are proven useful roadblocks in your environment, that my environment doesn't have (and that I may need).
• procedurally superior - that the developers and providers of your environment have documented and enacted processes that turn flaws around faster and better than the developers and providers of my environment.
• culturally superior - your environment is habitually operated and written for in a manner that mine is not (a.k.a. "Unix users never run as root, Windows users always do")

These items are ranked in order of value - a technical superiority will last and last, a procedural superiority is likely to be detected before it changes for the worse, and cultural superiority relies on groups of people continuing to behave the way they do - if we could rely on that, Wayne Newton would still be on top of the hit parade.

Then you also have to persuade me that I can get the a better job done, with any re-tooling and re-training costs subtracted from the benefit you allege to provide.

Is that exploit code showing your biggest threat?

Roger Grimes has a new article in his InfoWorld Security Adviser column - "Compiling exploit code: a network-security must."

He has some good advice about how to handle exploit code:

• carefully, and with much scepticism - "many exploits don’t work as advertised"
• on a separate machine - "many networks contain defenses that offset the exploit’s attack vector"

I really do doubt the benefits of this one, though: "testing exploit code gives you a sexy demonstration that can be used to convince team members and management about the value of your computer security defenses".

If your colleagues and management are that unconvinced of the value of security that they need you to take out a system or two in order to believe that you're doing your job, then surely that's the biggest security concern in your company - that none of the staff you need to support your efforts believe that better security is necessary.

I'd add one note of scepticism to the search for exploits - often the 'exploits' do little more than appear dangerous while executing ordinary behaviours.  Anyone who's seen a web page that supposedly scans your hard drive and returns it to you, while doing nothing more scary than a link to file://c:/ will know what I mean.  Sometimes, though, they're more subtle, such as the demonstrations that you can make Visual Studio run code simply by opening a project file.  That's as designed, but it certainly sounds scary.

Blue Screens and Dump Files.

Blue Screens and crash dumps - I have a love-hate relationship with them.  On the one hand, they're an unequivocal statement that something is going wrong and needs to be fixed, and on the other hand, they kill all the work you were doing, and nobody pays attention to them anyway.

That latter part is an issue that needs fixing.  Every time I've heard complaints to the effect of "Windows is so unstable; my machine blue-screens on me twice a day", I ask the simple question: "What do you do with the blue-screen error?"

The answer is always "I ignore it and reboot".

Well, no wonder your machine keeps crashing, then.

A blue-screen is an invitation to investigate and remove a source of error in your computer system.  Whether you investigate it yourself, or bring someone else in to do it for you, it's vitally important that you do something with it.  [At the very least, use the Dr Watson service to report it to Microsoft - yours may be a common problem that they have already investigated and fixed.]

Usually, you can type the hex error code (including the "0x" at the front) into http://support.microsoft.com and get a few potentially useful answers.  You can also look at the list of device drivers that are suspected as the cause of the failure, and go get updated drivers or ask the device manufacturer for support.  All this without touching a debugger.

Internet Explorer ActiveX behaviour change coming. Surprised?

Back in February of this year, Microsoft announced that, as the result of a court-case loss, they would be issuing a download that changes the behaviour of Internet Explorer.

The behaviour change is briefly described by saying that most ActiveX controls will need to be clicked on to "activate" them before you can interact with them (pressing buttons, typing, drawing, that kind of thing).

Many people are scared of this change - mostly people who haven't tried it; it's not a huge effect.

The 'surprise' to many is that the behaviour will be hitting the Automatic Updates round on or before April 11 of this year (next Patch Tuesday).  Some are even going so far as to state that this is because Microsoft wants users to be irritated en masse, so that the judge in the patent dispute will rule more in Microsoft's favour, or the plaintiff will reduce the amount for which they are willing to settle.  [My personal take is that Microsoft isn't going to pay potentially unnecessary damages until the case has run its course and they have reached a final outcome.]

Me, I think it's kind of obvious that this change has to happen.  Here's my reasoning:

1. As many in the press have noticed, it's a relatively common thing to have an update to Internet Explorer in the security updates for any month.
2. All Internet Explorer security patches to date have been cumulative - that is, they include all of the previous security patches.
3. If Microsoft's patent dispute is like any other similar case (the Sun JVM dispute, for instance), they are allowed to continue to host existing downloads, but must not create new downloads or distributions that contain infringing code.
4. The chance that a previous patch includes no infringing code is pretty close to zero (how many security patches involve embedded objects?  Quite a number, I'd guess)

So, all told, I think we were lucky not to have had this behaviour pushed in the security patches in March, and we should have expected it (and tested it with our users for usability and compatibility) for some time now.

In case we're about to lose context, remember that what we're talking about is a patent on placing an active object into a browser window (when Microsoft was already using Object Linking and Embedding to do this in other apps) without having to click on the object to make it active.  For this <sarcasm>stunning and insightful leap of innovation</sarcasm>, the plaintiffs are looking for over half a billion dollars in damages.  Even taking into account Microsoft's legendarily deep pockets, and their historic penchant for "borrowing" other people's ideas without giving them credit, I have a real trouble seeing the plaintiffs' side of the story.

"Full Disclosure" and the vendor.

Many of my MVP friends have been posting about the sheer irresponsibility of recent disclosures of IE bugs.

This is one of those things where you have to admire the religious zeal of the 'full disclosure' advocates.

"The fact that we know about a vulnerability means that the bad guys probably already know about it." they cry. "So, we're going to publicly release full details of it, to guarantee that they do."  [I'm paraphrasing here, this is not a direct quote from anyone]

And while they're at it, of course, they spend no time whatsoever bothering to tell the developers of the original code, so that they might offer workarounds, detection hints, or, heaven forfend, an actual fix.

So, developers have to subscribe to Butgraq, Full-Disclosure, NeoHapsis, FrSirt, Secunia, and a dozen other mailing lists, and delete mail about thousands of other products, on the off-chance that today might be the day that their own product is mentioned.

[And then, about 80% of the time, the developer has to point out that the "strong likelihood of remote execution" described in the original post is more akin to "we couldn't figure out how to make it do remote execution, but if we said that, we'd sound like idiots, and our bug report would just be a bug report, not a s00per-d00per vulnerability exploit".]

Maybe the IE flaw is exploitable... maybe it isn't.  But given a road-map on how to trigger the flaw, those who would like to see an exploit (the spammers, the criminals, the virus writers...) are likely to find it before Microsoft has a chance to define the flaw, design a fix, code the fix, test the fix, review the fix, put it out for beta test to ensure that it doesn't kill common LOB ("Line of Business") apps, build a patch vehicle for the fix, test the patch vehicle, write up the announcement, get it approved by communications and legal, and then eventually distribute the patch.

Then, after Microsoft has done all that, we, the users, get to spend a day or two analysing the fix, testing it against our own applications for compatibility, roll it out to a small number of users for further testing, analyse the results of those tests (and rule out those people whose machines were going to die anyway the next time they rebooted, but blamed it on the patch instead), and then roll it out to all of our users.

Full public disclosure without vendor notification had its day - and maybe it still has a purpose, but only when vendors steadfastly refuse to communicate about security flaws, which is a rarity for vendors today.  If you are going to disclose a weakness to the world, for the world to attack, you have a social duty to initially give the world a chance - and some time - to address the weakness.  The first point of fix is the supplier of the product with the weakness in, and this is where you should take your vulnerability report first.

What mind-set does security require?

So, I'm reading my copy of Information Security Magazine, when I read an article by Jay Heiser about "Military Madness".  Go read it yourself - I'll wait.

The article amused me particularly because my boss and one or two of my co-workers came out of the military.

I don't think the business mind-set really always helps all that much, either, sadly.

The most glaring examples are the "your data is now ours, and we can sell it to whomever" issues that have been plaguing various credit card processing companies for some time.

Where I work, in health-insurance, I've found the safest position to occupy is to view the member's data as belonging to the member, and held
in trust by us solely for the purpose of doing business on behalf of that member.

I think that a lot can be achieved simply by re-coupling benefit and loss, or risk.  Take credit cards, for instance, where the benefit accrues to the banks, and the loss accrues to the vendor and rarely to the customer.

Vendors can't tell credit card companies that they're going to go to an all-cash basis, and they won't get far by telling customers that their credit cards are too risky to take.  So, the banks cleverly lump all of the risk with the group least able to manage it - while at the same time making commercials that imply that identity theft is all the fault of those nasty vendors.

There's no feedback within the credit card system that allows or encourages it to self-strengthen.  Any strengthening measures are imposed from outside, such as the US law that limits a card-holder's liability to $50 - but even this is short-sighted, as it does not offer any protection to the merchant, who gets charged on the transaction coming in, the cost of any goods they send out as a result, a second charge on the refunding of the money to the card-holder, and often a $25 "chargeback fee" for having the temerity to accept the credit card in the first place, despite not having any reliable way to verify that the card is in the possession of the card-holder.

Coming soon: the Microsoft Virtual Rootkit

And yes, because it's a Microsoft Research paper, they had to point out that they could achieve exactly the same result against a Linux box.

Obviously, the best way to detect such a rootkit is to note its rather unwieldy effect on performance (but would that be necessarily always so?), along with a detection routine that runs outside of the regular boot process (i.e. edit CMOS boot settings to boot from removable media, and boot a read-only known-clean OS with up-to-date detection tools).  Sadly, the bootable read-only known-clean OS with detection tools is not something you can make from a Microsoft OS without skirting dangerously close to licence violations, or by paying through the nose for a licence for XP Embedded, which comes with Windows PE, and is designed for OEMs to build an installation experience for Windows.

It would be nice if a licence for any Windows operating system also included a licence to create bootable DVD-Rs containing the user's choice of recovery tools on a Windows PE subsystem.

The Virtual Rootkit has been covered at eWeak, where there's a lovely TalkBack entry:

"Microsoft cannot seem to make its product impervious to malware attacks so the next best thing is to ensure that it nearest competitor, Linux/Open-source, is similarly vulnerable."

Uh... Yeah. Microsoft did that. Right. :-)

Sadly, the Computer Science answer is that any modern computer (aside from Quantum computers) can be emulated by a finite Turing Machine, and it's a piece of cake to implement a finite Turing Machine on a modern computer. As such, any modern computer may emulate any other modern computer; the only limits are accuracy of emulation, and performance of the emulated OS.

Quantum Computers may be an exception... possibly.

Betas - not for general consumption.

A Susan Bradley blog post today reminded me once again that people are treating beta test versions of software as if they are production-ready.

Sadly, when "beta test" is too long for inclusion, the word "test" gets dropped, instead of the word "beta".

Most people would be well aware that a "test" version of software would be inappropriate for regular use, but relatively few are aware of what "beta" means.

It's a Greek letter, and as the second letter in the Greek alphabet (alpha-beta, you get the picture), it's the second part of the process in testing a piece of software.

Alpha testing is the first part, when you first have a more-or-less complete version of the software to test, and you run it through a bunch of internal tests to see that it does more or less what you designed it to do.

Beta testing follows, where you give the application to regular users to see whether it works properly for them.

Beta software has been known to wipe out entire operating system installations, and is generally unsupported.  Choosing whether or not to run a beta test version of software is an exercise in risk management.  Don't engage in it blindly.

Just last week, we wiped out a colleague's system by trying to enable BitLocker in Vista.  You need to pass certain requirements in order for BitLocker for work, and the only way we could see to test for those requirements was to enable BitLocker and see if it worked.  It worked in one respect - the drive was encrypted - but in another, important, respect (reading the encryption key off a thumb-drive), it failed.

Programmer Hubris - I don't run your software all the time.

Not only don't I run your software all the time, but actually I run it about once every couple of weeks.

So why on earth does your software run all the time?

Okay, so this particular complaint is about Sun's Java, which I use once every two weeks, to sign my timesheet so that I can get paid.  It stays memory resident even after I close the web browser that took me to the page.  But the complaint could equally well be made against RealPlayer (or whatever it's called this week), which likes to remain in my system tray (down by the clock) even though I view .RAM files about once every two or three months.

Maybe Java and RealPlayer occupy very small amounts of memory, but when you combine them with every other program whose developers assumed that everyone would be using their software 24x7, you wind up with a lot of memory used by a lot of programs that are all plodding along unused, but stealing a little time here, a little network resource there, and a bucket of memory.

Every now and again, I rebel, and remove a bunch of applications that I rarely use.  But then, "rarely" comes around and I have to reinstall because there's a persentation I want to hear in RealPlayer, or an algorithm demonstration in Java.  Then I have to uninstall again (and reboot) if I don't want to waste my resources.

Return Quickbooks for Refund

I was going to title this post "Microsoft Representative Says to Return Quickbooks for Refund".  Then I thought to myself:

"Oh, Jesper's going to be so mad with me for that tagline."

Sorry, Jesper.

I'd probably also upset Steve Riley, who works a lot with Jesper, and gets irritated when Microsoft reps are badly misquoted, or when writers conflate an otherwise succinct message in order to demonise Microsoft.

Jesper didn't actually say to return Quickbooks for a refund, and he wasn't specifically, directly, referring to Quickbooks when he said:

"Two related issues usually come up at about this point in the conversation. The first one is that some application requires at least Power User privilege. If that application is not an inherently administrative one it is broken. Period. Return it for a refund or a fixed version."

But, as you can see from http://www.threatcode.com, despite years of being prodded by Security MVPs and CPAs alike that Quickbooks shouldn't be an admin-only product (what system administration task does it do?  NONE!), Quickbooks remains solidly in the "Administrator or Power User" camp.  At one point, a tech support rep at the company "responsible" even claimed that this was a good thing, because it meant that only trusted people were doing your accounts.

As a developer myself, it looks strikingly similar to "we didn't want to have to do the hard work of figuring out how to share files across users without writing to files in the Program Files directory tree".

Me, I trust my accountant to do my accounts; but I don't trust my network admin to do my accounts, nor do I trust my accountant to administer my network.

So, my network admin has administrator privileges, and my accountant has the key to my filing cabinet.  I'll be upset if I find that they're sharing them.

What you can do with your finger

I was reading an article just the other day about attacks on the Microsoft Fingerprint Reader, that contained the important reminder that this isn't a security device, it's a convenience device; that it should not be used as credentials for logging on to a corporate system.

I've maintained on several occasions that a fingerprint is a claim of identity, and falls far short of being a proof of identity.  It also has the interesting property that you can't revoke it and issue a new one if it has been exploited, making it of limited use as a credential.

So, what can you do with a fingerprint?

Well, there are some identity-related uses I can think of.

Suppose you are in a busy hospital, with a number of terminals spread around the place.  Accessing these terminals for private information should require strong credentials.  But what about public information?

Does, say, a nurse occasionally need to verify the usual dosage for Tylenol?  Would a doctor find it convenient to search for phone numbers of specialists whose work he has previously approved of?  I'd say that's likely - and each person will have their own favoured subset of public information, and starting point(s) for looking at it.

For such public information, of course, it would be great to walk up to a terminal, press your finger against the print reader, and have your chosen view on that information be rapidly displayed.

What other uses can you think of, where a false match would not reveal sensitive or private information, or provide privileged access to systems, but where a relatively good rate of true matches makes a system easier and quicker to use?