Programmers are, by nature, a very arrogant bunch. We know this – and it comes from the nature of what we do. In our own little world inside the computer, we are a god.
For this reason (and perhaps a few others), it becomes very easy for us to forget to think outside of our little world, and remember that we are also acting as servant to the people that own the box we’re writing our software for.
This is particularly true of developers of off-the-shelf software, who spend next to no time actually dealing with the people that use, or will use, their programs.
So, I’m going to start a topic on the arrogance of developers.
My first example is multiple – Real Networks, Apple Quicktime, and several other programs insist on placing their icons on the system tray – down in the bottom right-hand corner, with the clock.
Now, if these were just icons, that would not be such a bad thing – after all, your system is littered with icons that represent shortcuts, data files, executables, and so on.
Unfortunately, the icons in the system tray are special. Each one represents a running program. Each one is placed there by a programmer who believes that his or her program is so important to all users that it should remain permanently running.
Me, I play a Quicktime Movie, or a Real Audio file, about once every couple of months. It can be a month or more before I notice that the icon is on my system tray, taking up time, communicating who knows what, and exposing goodness knows how many application-related flaws to the Internet.
So, a plea to developers – unless your software positively requires to be run all the time in all its possible installation modes, make it go away when I’m done using it.
No offence, but I’m just not that into your program.
[I was going to title this “PATRIOT – Piddling Around The Real Issues Of Terrorism”, but I figured that’d be a little too inflammatory.]
The other day, I was listening to good-old-fashioned talk radio, and something the host said surprised me. He was blathering about how Democrats wanted to make friends with terrorists.
It sounds really stupid when you put it in those terms, but yes – that’s essentially the approach that has to happen. Like a pyramid scheme, the terrorists at the top feed hatred down, and get power back up the chain. While that feed of hatred is accepted by their “down-line”, the feed of power up the line continues. You don’t stop terrorism by making friends with the guys at the top, you stop terrorism by making nice to the guys at the bottom; you remove the power-base by making it difficult for people to hate you.
So, how does that remotely connect to the usual topic of this blog, computer security? Like this:
Vendors [think Microsoft, but it also applies to small vendors like me] face this sort of behaviour, on a smaller level, when it comes to vulnerability reports. Rightly or not, there’s a whole pile of hatred built up among some security researchers against vendors, initially because over the years vendors have ignored and dismissed vulnerability reports on a regular basis. As a result, those researchers believe that the only way they can cause vendors to fix their vulnerabilities is to publicly shame the vendors by posting vulnerability announcements in public without first contacting the vendor.
I’m really not trying to suggest that vulnerability researchers are akin to terrorists. They’re akin to an oppressed and misunderstood minority, some members of which have been known to engage in acts which are inadvertently destructive.
Microsoft and others have been reaching out of late to vulnerability researchers, introducing them to the processes that a vendor must take when receiving a vulnerability report, and before a patch or official bulletin can be released. Some researchers are still adamant that immediate public disclosure is the only acceptable way; others have been brought over to what I think is the correct way of thinking – that it helps protect the users if the first evidence that exists in public is a bulletin and a patch.
The security industry gets regularly excited by the idea of a “zero-day exploit” – a piece of malware that exploits a vulnerability from the moment that the vulnerability is first reported. I think it’s about time we got excited about every release of a “zero-day patch”.
How many different classifications of document should you have?
The answer: two.
Documents should be “public” or “private”.
Public documents need not necessarily be published public documents, but contain information that is not important to keep from the public. By fact, any document that has been published is already public, no matter what you’d like it to be.
Private documents should be attached to an explicit or implicit list of people who are entitled to view them, and there should be policies, procedures, practices and phreakin’ ACLs in place to make sure that their privacy is not broken.
Can you think of a document secrecy category that isn’t covered by this?
So, I started my new job last week.
I spent much of the first week trying to stop the “message waiting” light from flashing. I knew what I had to do – call the voice-mail system, listen to all the old messages and dump them.
So, I press the button for voice-mail and get an alternating tone. What does that mean? Does it mean I’m in the voice mail system? Does it mean “enter your password”? I have no idea, so I enter my password, and it makes a different beep, so maybe that means “no, wrong password”.
I go to the “self-help” page, and the “phone training” pages. They disagree as to which is the default password. Great.
Now I have to do the thing I hate – I have to call the help-desk. So I call, and I let them know what the problem is. I give them my email account and all the other information that they need.
Finally, I come into work after the weekend, and I think I’ve figured it out. I leave the voice-mail button alone, and dial the voice-mail extension by hand. This time, it says something like “welcome to the voice-mail system, please enter your password”.
Seventeen messages later, fifteen of which are from before I started at the company, I reach the cracker. A message from the help-desk, telling me that maybe my voice-mail button isn’t programmed yet, and detailing the default password. They end by telling me “if you are still unable to access your voice-mail, please call the help-desk”.
I call the help-desk in return, and suggest that when people are having trouble with the phone system, that the phone system is not necessarily the best method of contacting them.
Okay, so we should all be well aware as to what a fingerprint is – it’s the pattern of ridges on most people’s fingers that get left in smudges on glass doors.
What can it be used for?
The question arises as I look at my Microsoft Fingerprint Reader, and try to explain why a fingerprint reader is purposely disabled from authenticating an account to a domain.
Let’s first get into what is needed to log on to a system. In computer science terms, you need a claim of identity, and you need one or more pieces of evidence, that together will suffice as proof of identity.
Think of the bank ATM as an example – your debit card is the claim of identity (because it contains your account number), and it’s also a piece of evidence (because you cannot use the ATM without the card). Your PIN is a second form of evidence; with the card and your PIN, you claim and prove your identity for the purposes of the ATM’s operations.
Logging on to a domain is similar – you provide a username, which is a claim of identity, and you provide a password, which is the evidence used as proof of identity.
What differentiates a claim of identity from a proof of identity? That’s a little subtle.
A claim of identity is any information that uniquely identifies a person, or a role, or an identity, such that it can be used by the computer to look up that identity. Your ATM card is a claim of identity, because it contains the account number(s) to which you are allowed access, in a form that the ATM can use to supply as your identifier to your bank.
A proof of identity is made up of one or more pieces of evidence that can be relied on to demonstrate that the claimed identity is matched by the person or process presenting themselves for identification. It’s “something you are, something you have, or something you know.” The evidence should consist of items which, in conjunction with one another, can only be presented by the authorised user(s) whose identity is being claimed.
So, what is a fingerprint?
Is it a proof of identity?
Not as far as the Microsoft Fingerprint Reader (or any other low-resolution fingerprint reader) is concerned. Give me a couple of warm gummy bears, a freezer, five minutes, and the use of your finger, and I can produce a replica “finger” that will authenticate to the reader. What’s more, if someone can give me a glass door you’ve pushed open, or a cup or glass that you’ve held, within a couple of hours I can make as many gummy fingers as I need, that will all authenticate as you on any low-resolution reader. [I won’t go into the process here]. In more grisly methods, I don’t even have to go to all that effort.
Higher-quality fingerprint readers will look for a finger’s warmth (yeah, a warm gummy bear will beat you there), or pulse, translucency, capillary patterns, or other features that are supposedly only going to be present in a real finger attached to a live human, but those are expensive.
So, because this fingerprint reader is a basic one, to it, a fingerprint alone is not evidence sufficient for a proof of identity – combined with a guard manning the station, trained to check for gummy bears and severed fingers, and who can deny suspicious attempts, it may be enough, but that’s not its designed method of operation.
Is a fingerprint, then, a claim of identity?
Not in general, no. The fingerprint can be matched against stored fingerprints to see how closely it matches, but the fingerprint alone is not capable of generating the user ID, which is what you’d want. The fingerprint has to be almost exhaustively matched – this is why cops on TV seem to spend days getting a fingerprint match. It is very quick to say “here are two fingerprints, do they match” (which would be evidence of identity), but extremely slow to say “here’s a fingerprint, whose is it?”
Then there’s the issue of uniqueness.
I’ve searched and I’ve searched, and I’m surprised to find that there are as many as zero good scientific reviews of large fingerprint databases to check for uniqueness. So, when a “fingerprint expert” testifies that the fingerprint found at a crime scene matches the defendant, and the defendant only, they’re relying on a guess that hasn’t been reliably tested, and which has been proven false (or at least, badly collected and analysed) on some celebrated occasions:
[Note that these are culled from a very quick search of only one news agency’s recent output.]
Obviously, a fingerprint can be used to refute identity, in much the same way as “the suspect had red hair” will refute the identity of a suspect who does not have red hair, but there’s still significant doubt in my mind as to whether it can be relied upon in any way to prove identity – not without extra layers of evidence to increase the reliability.
Use other, more reliable, measurable, and provable means to protect your networks. Passwords – strong passwords – will serve you far better than a low-resolution fingerprint reader.
I don’t know how I missed this story when it first appeared, but apparently the country of Nigeria is so upset with its well-earned reputation as the source of an unfeasibly large number of fraudulent spams, that they are now trying to enact a law that would cause spammers, phishers, fraudsters, child pornographers, and terrorists to spend six months to five years in jail, and pay the equivalent of $77 – $7700 in fines. Oh, and the government could seize any profits made from the schemes in question.
Having seen how badly our own (USA) attempts to “curtail spam” with laws that do nothing of the sort have gone, I wish the Nigerians the best of luck.
Here’s a theme you’ll have heard from me a dozen times if you’ve been following my Usenet traffic:
“When I buy software, or music, or videos, I want to buy the content, not just the plastic it comes on.”
What do I mean by this?
Simply that I don’t want to find myself restricted as to what I can do with the software, music, videos, etc. If I buy a DVD, I want to be able to watch it on my choice of device, in my choice of country, and (if necessary) in my choice of format.
With the recent news of Sony’s unpleasant intrusion into home computers (or this link for an American version), it’s a reminder for me to say this again – my computer is my computer, and I’ll thank you – any of you – to leave me to decide and actively accept what software to install on it.
Yes, Sony may include a licence on their CDs – but who reads them? Who even expects that an audio CD (not a software title) will install software on their machine?
The key point to my mind is that I, the system administrator on my home computer, cannot hope to maintain the security and reliability of my system if I cannot know when software is installed, and be able to remove what software I choose to no longer be there. If Mark Russinovich, a hugely capable developer, cannot remove the software from his system without losing access to parts of his system, what hope do the rest of us have?
Digital Rights Management, or DRM, is frequently put forward by music companies as the next best thing since sliced bread. It’s not, and it’s not even remotely appropriate for home use, or for preventing privacy.
DRM works in exactly one scenario: when the owner of the rights also controls the behaviour of those subject to DRM. That almost always means “work”, where the rights owner can discipline, and eventually terminate, those that refuse to respect the DRM restrictions on content. To attempt to apply it to home use, where there is no such control, is to ignore that basic limitation of DRM.
And, quite frankly, it’s insulting. I don’t feel like pulling out the “innocent until proven guilty” argument in its entirety, but as a legal and honest purchaser of all manner of electronic content, I feel insulted that I am then limited as to my use – not merely limited as to illegal copying and distribution, but limited as to what should be legal – copying for my own use in different devices.
I believe in this so strongly that I have made sure that the software I sell is controlled by those who pay for it. You can move our software from one machine to another, and we ask only that you use no more copies than you have paid for. We assume that we can trust our legitimate customers. We put a few limits into the freely-distributed version, only because if we don’t, nobody buys (trust us, we’ve tried). Even the honest need a few reminders some times.
Three years ago, just before Thanksgiving, I went in for a relatively routine (if rather uncomfortable) surgery.
While I was under anaesthesia, the doctor found, and excised a “stage I seminoma”. For those of you unfamiliar with Lance Armstrong, that’s early testicular cancer.
Since that time, I’ve had radiation therapy (curiously, at the same time that the movie of “The Incredible Hulk” was being advertised on TV), a couple more surgeries, and several more doctor visits, blood-draws, and CT-Scans. The end result is very much worth it – I’m cancer-free, and have been for three years.
The peculiar aspect is the most frequent response I get from others:
“You don’t look old enough for cancer.”
That’s flattering, to be sure, but testicular cancer is usually found in men between the ages of 25 to 35. As such, I was on the upper end of the age range, and I was lucky that my tumour was found before it had spread. Testicular cancer is particularly fast-spreading, but if caught early, can be treated with a minimum of radiation. In the vast majority of cases, this (and monitoring) kills the cancer with no remission.
During my radiation treatment, I initially lost weight, then gained it (and a little more) as I kept snacking to fend off the mild nausea. I lost hair from the affected area – a rectangle roughly from my belly-button up to the base of my rib cage (and a matching rectangle on the back – X-rays go right through you!) And… that’s it.
Yes, that’s the limit of the uncomfortable aspect of the treatment.
For those of you worried about asking the awkward and embarrassing question, let me assure you that you can “fly with one engine” just as well as with two. [Testicular cancer travels “up” rather than “across”.]
I like to tell people you can check as often as you like, and as fast as you like, but you need to make sure you check yourself.
Sure, the treatment may be embarrassing, and I know there are parts of it that still irritate me. But nobody ever died of embarrassment.
So you want to protect your TCP application’s traffic?
You’ve been writing network code for a while, using TCP, and you’ve faced the bugbears of reliability and performance, but now you’re looking for a real challenge.
You want to secure your network traffic; you want to securely authenticate the server and maybe even the client.
Or perhaps your users are simply screaming for the protection of SSL, even if they don’t know what that means, but because “everyone else has it”.
There are obviously several reasons you might have to use SSL to protect your network traffic – and over the next few blog entries, I’m going to advise you on how you might add SSL to your client or server, and what benefits you’ll get from doing so.
I’m going to start with a brief run-down of what SSL can provide, in its most common configuration. There are some pedants that will tell you all about using Diffie-Hellman (DH) key exchange, so that noone needs a certificate, or a NULL encryption cipher, so that you can read the SSL-wrapped communication, but neither of those apply in the general case that we’re going to talk about. When you have finished reading this set of columns, you’ll be able to take an HTTP client or server and turn it into HTTPS, or an FTP client or server, and make it support FTPS.
So, to begin, here’s a list of what SSL gives you over and above what you already have with your TCP application.
Now, here’s a list of some interesting changes that SSL makes to your TCP traffic:
Until next time, happy coding!