Welcome to Orcmid's Lair, the playground for family connections, pastimes, and scholarly vocation -- the collected professional and recreational work of Dennis E. Hamilton

Associated Blogs
 
Millennia Antica: The Kiln Sitter's Diary
 
nfoWorks: Pursuing Harmony
 
Numbering Peano
 
Orcmid's Live Hideout
 
Prof. von Clueless in the Blunder Dome

nfoCentrale Associated Sites
 
DMA: The Document Management Alliance
 
DMware: Document Management Interoperability Exchange
 
Millennia Antica Pottery
 
The Miser Project
 
nfoWare: Information Processing Technology
 
nfoWorks: Tools for Document Interoperability
 
NuovoDoc: Design for Document System Interoperability
 
ODMA Interoperability Exchange
 
Orcmid's Lair
 
TROST: Open-System Trustworthiness

Document-Security Theater: When the Key is More Valuable than the Lock

[update 2010-02-13T18:01Z  I think one reason folks turn up their noses at MD5 hashes in these applications is the fact that MD5 collisions have been found, suggesting that it may be possible to discover different undisguised passwords that have the same disguising hash-code.  (That the colliding undisguised keys are unlikely to be plaintext that anyone could successfully enter at a keyboard is not considered.)  Similarly, there are demonstrations of SHA1 collisions, so folks want to start using SHA256 and even stronger hash-encoded disguises.

[The problem with all this is that the possibility of a collision has nothing to do with keeping the original password secret.  Even worse, the kind of lock I’m talking about doesn’t need knowledge of any password whatsoever, so finding a collision for the same disguised-password value is irrelevant and a complete waste of time, even in perpetuating a deception.  (For interesting deceptions, it is easier and more fruitful to hack an open-source document processor to allow back doors for that purpose). 

[That reports of hash-code collision successes inspire fear that these document-change protections are now compromised is yet-another consequence of it all being theater in the first place.   These protections have always been compromised, and moving to XML-based documents has made the vulnerability trivial to exploit.  All else is illusion.]

In a Nutshell

I’ve been noticing for at least the past year that there is an obsession with increasing the strength of hashing functions that disguise the passwords needed to protect documents against certain changes.  I’m not talking about protection against the electronic document being readable and viewable, just being changed.  This has come up in the maintenance of the standards for XML-based office documents, both ODF and OOXML. 

The problem with these efforts is they don’t make the particular “protection” any stronger.  Change-protection “locks” on documents encoded in XML are easier to pick than the cheapo lock on a teen-ager’s diary.   You merely need the hacker equivalent of a paper clip.  Someone has to be determined in order to do this, but it is not difficult and a knowledgeable youngster (the teen-ager’s kid brother) can do it.

Put simply, the effort to strengthen these document-change protection locks by improving the disguising of the key that must be matched is misguided because

• The lock is no better
    
• It is foolish to use any kind of key (in the case of electronic documents, a digital password) that may happen to be more valuable than the lock it “protects”
   

Improving these lock protections establishes the appearance that it accomplishes something (else why do it and add it to a list of improvements).  But to knowingly give assent to such a charade raises professional-ethics concerns for me.   I would hope that it is an ethical concern for all of us who have some responsibility for the impression that is given by making such “improvements,” especially when it is simply pandering to the requirements of those who are mistaken in the belief that more must be better in this particular case.

What’s the Story?

When people talk about wanting greater cryptographic security around those change-protection locks, what is it that the cryptography is protecting? 

The basic approach is to invest more computational effort in making a cryptographically-formed disguise (a “hash”) of the password that serves as the digital key to the lock, not the lock itself.  Going from a technique known as MD5 to SHA1 is one stage of greater complexity.  Going from SHA1 to SHA256 would be another, one that there is now clamoring for.  Whatever the level of encryption (hashing) sophistication, the disguised version is stored right in the document, with the expectation that office-document software won’t release the protection unless an user submits a password that hashes to the same disguised form. 

In the case of XML-based documents, the protection is as easy to overcome as it always was.   The only element that appears to have increased protection is the password that is the key to the lock, even though the key isn’t really needed if someone is simply interested in overcoming the protection.

If the key is so valuable, why is it being used this way?  It’s disguised form (that cryptographic hash code) is as easy to recover from the document as the lock is to overcome.   In fact, it can be misappropriated and used on a different document without even knowing the password that it disguises.  It can even be removed (releasing  the lock), the document altered, and the lock then restored with the same disguised key put back in place.  And in no case is it necessary to know the password that the disguised form goes with.  Such a maneuver could be used to deceive the key-holder that their password has been compromised.  It could even be used to claim that the key-holder created the changed document or another one.   Any of these deceptions should be quite successful against someone who has naive faith in the “security” of the document change-protection mechanism.

If the key is so valuable, is there really any improved safety in using stronger cryptographic technology to keep it hidden?  I don’t think so.  Not only does it really not strengthen the lock, It can be attacked the same way that hash-coded password disguises are always attacked.  By successfully guessing the password using a plaintext attack system. 

Although it takes a little longer to repeatedly test the hashing of guesses when a stronger hashing method is used, there is no hurry.  Once the disguised password is in an attacker’s possession, there is more than enough time to try plaintext guesses against it, over and over again.  After all, the document owner is likely to believe that the key must be held indefinitely in case it is needed to ever unlock the document protection to permit changes.   Of course, this attack is only interesting to an attacker who believes that learning the password will assist in obtaining something more valuable (including carrying out a deception that demonstrating appearing to demonstrate knowledge of the password would facilitate).

Having thought about this for a while, I have concluded that it would be better to use randomly-created password-disguises directly and never remember them, since it is not difficult to open the lock without one.   It would also frustrate a plaintext attack in infuriating ways.  I’m surprised that there are not simple utilities around to remove and then recreate randomly-keyed locks on such documents already. That way, there is no secret to be divulged by anyone attacking the disguise, because it doesn’t disguise anything anybody is remotely-likely to have as a password.

Hmm …

---

I’ve been sitting on this for some time.  Lately, I’ve though of doing a little screen-shots demonstration of how easy it is to overcome and then replace protection with the original or a new disguised password (such as a random disguise that probably has no discoverable plaintext to attack).

I was prompted to post this first part by a tweet from James Clark, leading me to this great June 19, 2008 Ben Adita blog post, “Don’t Hash Secrets.”  Note that some of the improvements that Adita mentions (using a “salt” in particular) are not that difficult, although they do prevent use of a pre-hashed dictionary of lots of likely passwords.  The salt has to be known, along with the disguised hash though, so it just makes a plaintext attack harder, not impossible.  Also, the use of HMAC doesn’t accomplish much when the only data to hash is the undisguised password.  Whether it is worth the effort of a concerted attack simply depends on what an attacker believes is the value of the secret password.  The best precaution is to use worthless passwords.

The reason I am confident about randomly-created password disguises is that there is a lot of predictable structure in the computer-stored plaintext password that the hash-code is derived from.   Randomly created strings of bits that can be checked to ensure such predictability is lacking won’t be data that is can be enterable into the computer as plaintext.  Hash that.  Or just use the random bits as the disguise on the good chance there’s no discoverable plaintext that hashes to it anyhow.  Even if there is discovery of a plaintext, it has nothing whatsoever to do with the user who set protection on the document.

[update 2010-02-13T19:29 Emphasized that a deceiver need only appear to know the password, not actually have discovered it, with that sufficient to accomplish some exploit or even deceive someone into disclosing the password.
 update 2010-02-13T18:10 I added the connection to fears over MD5 and SHA1 collision prospects to the misdirection that this theater perpetuates.  I also took the opportunity to tweak some (but surely not all) ill-chosen phrasings.]

posted by orcmid at 2/12/2010 09:12:00 PM