An “insecurity feature” is a product feature that looks like it provides security, but really doesn’t. Insecurity features can make you less secure, because they trick you into trusting something of value to a product that can’t properly protect it.
A classic example is the “Password to Modify” feature of Microsoft Word, as revealed recently on BugTraq by Thorsten Delbrouck-Konetzko. This feature allows a document’s author to establish a password that must be entered before the document can be modified. That would be a pretty useful feature – if Word actually provided it. But as Mr. Delbrouck-Konetzko revealed, it is easy for anybody to modify such a file without knowing the password. In other words, Password to Modify is an insecurity feature.
The flaw that caused this is pretty easy to understand. Word implemented the Password to Modify feature by storing the hash of the password at a special place in the Word document file. The problem was that there was nothing to connect the stored password-hash with the rest of the file, so there was nothing to stop somebody from moving a hashed password from one Word file to another. So suppose Alice created a file and put the password “A” on it. Bob could create his own file with password “B” and then copy his password into Alice’s file; then Bob could modify Alice’s file (since it contained his password, which he knew). For extra style points, when Bob was done he could copy Alice’s password back into the modified file.
Microsoft responded to this report by issuing a bulletin helpfully explaining that the feature was never really meant to provide security. The bulletin contains such statements as this:
Not all features that are found on the Security tab are designed to help make your documents and files more secure.
Unfortunately, Word’s user interface doesn’t do much of anything to help users distinguish insecurity features from real security features. For example, here is the relevant dialog box from my copy of Word 2000:
I’ve outlined the relevant area in red. The box on the left lets you establish a password to open the file; that’s a real security feature. The box on the right lets you establish a password to modify the file; that’s an insecurity feature. Nothing in the user interfaces tells you that the features provide very different levels of protection.
There’s another lesson here, in the fact that such an obvious problem exists in a popular Microsoft product, despite Microsoft’s recent focus on security, and despite all of the genuine security experts who work there. This flaw reflects a bad decision made by some non-expert programmer or manager a long time ago, a decision that has persisted for so long, one assumes, through sheer inattention and inertia. And it’s not only Microsoft who failed to notice this for so long. Any good cryptographer, on hearing a description of what the Password to Modify feature supposedly did, should have been very suspicious. The problem was there to see for a long time; but apparently nobody looked.
Eszter: I said “economically efficient” because I was responding to an economics-based critique. Truthful reporting of the strength of security tools is efficient in other senses, too.
Not to get off topic, but why are you calling it “economically efficient” per se? What is it about it that is economic as opposed to efficient in a different way? Couldn’t it be “socially efficient”? The concern may not be economic in nature, no? I just didn’t follow that part.
Ed wrote: Recall my definition of “insecurity feature”: “a product feature that looks like it provides security, but really doesn’t.”
My primary problem with this definition is that it is not useful. Nearly all product features fit it.
While it may be easy for multiple people to agree that the example Word feature is busted, you’ll have a lot of trouble using Ed’s definition to make meaningful comparisons to other features, because rational people can argue about the application of the definition.
As an example, using Ed’s definition, I think one can make a good case that users have an unrealistic expectation of security around SSL transactions with commercial web sites.
Maybe we need a little check box next to this
“feature” that states:
[] Use Secure Feature
[] Use Secure Feature Which Really Isn’t Secure
🙂
….Software just is too difficult..no?
Cypherpunk say, “I don’t see any way to implement “password to modify” securely.” I don’t see any way to do it either. I was hinting at that (too cryptically, I guess) in my original post when I wrote that “Any good cryptographer, on hearing a description of what the Password to Modify feature supposedly did, should have been very suspicious.”
You can provide securely a similar feature that lets you check whether a particular version of the document was created (or endorsed) by somebody who knew a particular password. The feature lets someone “stamp” a file as authorized, using a particular password, in such a way that anybody who knows the password can verify the stamp. (Cryptogeeks: you create the stamp by MACing the file’s contents with a key derived from the password. A public-key solution would be slightly more functional, but would have to depend on implausible assumptions about the availability of PKI.)
I agree with Cypherpunk that a weak security mechanism sometimes makes sense, when that is all the threat model requires.
The problem, in cases like this, is that it is the customer who decides when the mechanism will be used, and it is only the customer who knows what his threat model requires.
If you implement a weak mechanism, and tell the customer it’s weak, then the customer can make good (i.e., economically efficient) decisions about when to use the mechanism. But if you lead the customer to believe that the weak mechanism is really strong, then the customer will make bad (i.e. economically inefficient) decisions.
Recall my definition of “insecurity feature”: “a product feature that looks like it provides security, but really doesn’t.” Weak mechanisms are not necessarily insecurity features. To make something an insecurity feature, you also have to misinform customers about how much protection the feature provides.
When vendors provide security tools, they maximize the tools’ value to customers by giving customers accurate information about the strength of those tools. I believe it’s in the long-term economic interest of vendors to provide accurate information.
I don’t see any way to implement “password to modify” securely. You want to let anyone open the file, but only someone who knows the password can modify it. The problem is that an attacker could simply copy the text of the file into his own newly created file, make whatever modifications he wanted, and then save his new file (optionally using the “password to modify” feature in case this sets some flag for the reader that says “this file is unmodified”).
Like DRM of audio and video data, this is a feature that can’t be provided with perfect security, and for the same reason. Does that mean it is useless? This seems to be an all too common conclusion.
Instead of this black and white attitude, consider a more nuanced analysis. Any security feature has to be evaluated in the context of a threat model. And it may be very reasonable in some cases to provide a feature that will not be secure against an attacker who downloads special hacking tools from the net, but will prevent ordinary users from (perhaps accidentally) bypassing restrictions.
I recently performed an internal security review of one of our company’s products, and it had a feature just like this – password protection which was accomplished by storing a hash. It was stupid, it was weak, we all complained about it – but the feature was demanded by one of our big customers. Everyone knew that there was no “real” security provided against a determined attacker, but it was good enough for what we needed, which was to defeat a casual attempt to get past the security. The data protected wasn’t that sensitive and so the security was adequate given the threat model we had.
There’s a quote attributed to the original Cypherpunk, Eric Hughes: “All crypto is economics”. He meant that the point of crypto, or any security measure, is to increase the cost of an attack. That is true for both high security and low security measures, including your so-called insecurity features. All are designed to increase costs. Security is not a boolean attribute. There are shades of gray, levels of security, and your analysis should reflect that.
I agree with most everything Steve says.
I pointed to this particular flaw as an example. I didn’t mean to imply that this flaw, by itself, is a big deal.
And the problem is not the mere existence of a feature that offers weak protection. The real problem is that the user ends up misinformed about how much protection he actually gets if he uses that feature. That’s why I showed the dialog box that fails to point out a difference between two features that offer very different levels of protection.
I agree especially that the problem is one of management culture. People will always make mistakes, but a more security-aware culture catches more mistakes before they can harm users.
There’s no doubt that Microsoft is changing its culture with respect to security, or at least trying to do so, because of the market forces Steve mentions. Even if the cultural transformation is a complete success, it will take a long time to undo the mistakes of the past.
The history of security culture at Microsoft is pretty typical of the industry as a whole. In the bad old days, vendors gave lip service to security but rarely did much. Now they take it more seriously, treating security as an important factor in their decisionmaking. But it’s hard to undo the mistakes of the past — they’re hard to find now, and fixing the ones you do find causes compatibility headaches.
The crucial question is this: how much will Microsoft’s (and the industry’s) new security emphasis actually improve customers’ security? I don’t think anybody knows the answer.
I mis-typed a word in my last post, and I wanted to correct it. As long as I’m typing more, I’ll add one last thought.
I meant to say that Microsoft didn’tbelieve in building secure products rather than doesn’t. I don’t mean by this that Microsoft has found religion about security features! When Microsoft started losing customer sales to security features, management immediately started changing their attitude about the features. Before that, evidence was a meager that the market wouldn’t wait out a significant enough change.
Microsoft will always take a corporate advantageous position on security features. They’re making billions of dollars a month on the products laced with “insecurity features”. Microsoft is a predictable machine. Hit them where it hurts and Pavlov’s dog responds to the whack on the nose.
This “insecurity feature” was well known at Microsoft and has always been known. Many of the insecurity features are not designed to protect “things” from attackers, but to protect these “things” from children or unsophisticated users. Another example of one of these well known insecurity features is the password that “protects” the content ratings section in Internet Explorer. Yet another example is the password that “encrypts” and “protects” PST files.
To a large degree, every one of the security features in Windows could be considered an “insecurity feature” by Ed’s definition (or lack thereof). The TCB of the OS itself stores data in such a way to make it easily accessible to an attacker with physical access to the machine. Linux isn’t much better, if better at all.
I strongly disagree that one can conclude that allowing non-experts at Microsoft to make decisions about product features is the problem. My experience with the security experts at Microsoft is that they have been less than creative at developing workable solutions to the security problems that users face. However, I don’t fault the security experts for this.
The root problem is, despite marketing hype, Microsoft doesn’t believe in building secure products. It was a fundamental principle of daily work for a long time in that environment. By the time it became obvious that security features were important, they had an installed base hanging over their head. Since sales haven’t really suffered too much, I would say they’ve handled the shift in market forces about as well as any monopoly in the past.
Complaining about this Word feature as a serious problem seems like a waste of everyone’s time. Point it out as yet another piece of evidence that Microsoft needs to change its attitude, but let’s not go overboard with lofty conclusions about mistaken management practices. The problem isn’t the individual managers at Microsoft are making bad decisions. The problem is that the leadership and the culture that developed at Microsoft over the past 30 years tells them to make the decisions that security experts don’t like.
Hmm, sounds a lot like what Bruce Schneier calls “security theater” in Beyond Fear.
It’s been my experience that just using the “Fast Save” feature can often encrypt a file quite nicely, but no decryption options are offered.
Presumably “Password to Open” actually encrypts the file. I know that older versions of Word used a quite weak algorithm that could be cracked on a regular PC. Hopefully more recent version use something more robust.
According to Microsoft’s bulletin, “Password to Open” is implemented differently, by encrypting the whole file with an encryption key derived from the password. If so, then you really do need the password to open the file.
Why is “Password to open” real security? Assuming “password to open” is implemented similarly, couldn’t one easily copy over your own “open” password the the appropriate chunk of the Word document and then open the “password-protected” file? I suppose there is the mild annoyance that you have to modify the file to do that (where as legitimate opening will not), but since copies are easy I don’t see how this protects the file’s contents.