Dan Kaminsky's Blog

Today’s imports from my Illustrious Past(TM) center around the surprisingly difficult process of file deletion. While much more difficult than “computer whizzes on teevee” make it seem, there’s quite a few things that make deletion of data extraordinarily difficult–and this is before “owner distrust” systems start getting deployed en masse.

Yes folks, it’s hard enough to delete something even when your hardware is not actively conspiring against you.

1. Thoughts On Secure Deletion in 2001: Part One and Part Two.
2. On The Nature Of Data Shredding: A possible implementation strategy for a reasonably effective data shredder is mentioned.

Napster is under pretty serious attack by the 9th Circuit, but is apparently only being held liable for its directory–they refuse to force Napster to examine actual content. The most interesting response comes from the Consumer Electronics Association, which essentially makes its money by adding features Hollywood didn’t realize they could charge for.

I’ve got more to say on all that, but for now, I’m just putting up three docu ments:

1. Cryptography Doesn’t Save Napster, and the War Over Parodies. A post to Jim Griffin’s Pho list that semi-repudiates a consistent urban legend about the power of crypto–and asks the question: What if the only Britney Spears song you could find on Napster was of her singing about silicone implants? Would it matter? 
2. Passfaces: An Intriguing Way To Authenticate. I’m actually impressed. I started writing a pretty extensive rebuttal to this technology, only to find out it actually worked pretty well! Amazing when people actually test their technology before deploying it! 
3. BugTRAQ– Re: Security hole in Win2K’s FTP server What makes a security hole a security hole? An older post which attempts to analyze this question. 

Mental note: Never, ever, design a website in a propietary development environment again. I finally grok the genuine clue behind XML: EXPLICIT STATE. No more “oh, that’s that way because it’s the 839th bit with two NULLs” before it. No more “it’s that way because the operation eighty cycles ago was a NOP.” Forget eXtensible, or eXtreme, or whatever. XML is explicit, headache free state management.

Why do I say all this? Because I’m presently going through some ridiculous hacks to extract the structure out of data formatted by NetObjects Fusion. So far, the best method seems to be:

• Use lynx -dump -nolist to create a reasonably legible text version of my documents. It’s not as utterly beautiful as links, which has suffered for no other reason than its homonymous with lynx, but it’s got a dump mode which I haven’t hacked into links yet.
• Use txt2html to intelli gently extract the structure that lynx found from the original “fused” document into reasonably simple HTML.
• If necessary, use html2txt to convert back into text, and use the RAW mode David gave me to automatically emit a paragraph tag any time two carriage returns are detected in sequence.
• Manually add the various images, boldfaces, italicizations, and preformatting tags as needed.

This is of course, as they say in the industry, a ridiculous hack that barely has enough elegance to be mentioned in public, but it works. And in the end…that’s more than some people can say(sigh).

RealFaces (http://www.realuser.com) is actually surprisingly cool. I began writing a point by point rebuttal to the effectiveness of their technology, until I finally decided to take a few minutes to try it out.

I’m impressed. Their documentation (what little there is) is positively awful from a technical point of view; you can practically taste the various layers of refinement in their design. They tested this stuff alot, and obviously went back to the drawing board at least a few times. What’s interesting is that your password isn’t just one face of nine, it’s all nine faces acting in concert to remind you which specific one you’re supposed to remember. The faces are probably computer generated using face amalgamation mechanisms, considering they possess a surprising degree of explicit diversity–there’s always one and only one person who’s black, who has a specific curve in their hair, who has “extra bright teeth”, and so on.

>From an entropic point of view, five rounds of 1/9 selection without any apparent ability to test passwords round by round (a failure in round 2 still offers the opportunity to try rounds three through five, and the server rather than the client does the authentication) gives a little under sixteen bits of entropy–59K possible passwords. Their ActiveX control doesn’t function under Opera, and might not under Netscape, which limits its deployability.

Their biggest issue is that it’s likely more difficult to remember large sets of passfaces–remember, the advantage that you *can’t* write them down is also a heck of a disadvantage if you’d have multiple sets of authenticating material. RealUser’s solution is to have all public sites centrally authenticate through it, which of course generates a single point of failure–remember when PassPort (Hotmail’s central authentication server) lost its DNS, and half of Microsoft’s sites no longer worked? Imagine if nobody could log in…anywhere.

Overall, it’s pretty interesting technology. There’s conceivably weaknesses if they’re using only certain faces as “key faces”, if repeated properties always rule out a few of the people, or if the “correct face” is always downloaded first by the client. But those are implementation flaws. The core technological flaws–from inadequate differentiation between option faces to the fact that random “peers” would eventually differentiate themselves from a static keyface–have been addressed nicely. The one thing I’m particularly concerned about is cultural bias…but dealing with that problem is actually amazingly harder than you’d think.

I can see why Dyson invested. The technology isn’t perfect, but it is…interesting. Much, much more compelling than I expected it to be.

From: “Dan Kaminsky” <dankamin@cisco.com> To: “Jon Winters” <winters@obscurasite.com>; “Whitney Broussard” <Whitney@smmmusiclaw.com> Cc: <pho@onehouse.com>; <hardware@obscurasite.com> Subject: Pho: Cryptography Doesn’t Save Napster, and The War Over Parodies Date: Monday, February 12, 2001 6:55 PM

> If the IP is _music_ and the encrypted file is _noise_ then you’re in the > clear.

A couple people have been talking about how cryptography is a magic salve for Napster.

It’s not even close.

The entire concept of Napster is that anyone can play the music, with absolutely no difficulty. Transfers are anonymous; there’s no way to know that the person you’re giving the data to isn’t an enforcement agent. If a peer can play it, so can the warden. If a peer can decrypt it, so can the warden.

And if the warden *can’t* decrypt it…don’t look for the peer to. Now, if peers aren’t anonymous, you actually have something–the Aimster model actually does something, because you can differentiate the warden from your peers. But Napster has no ability to differentiate.

After an extended hiatus, I’m finally taking the effort to update the DoxPara Research website. Since last update, I’ve become much more focused on issues surrounding cryptography, information security, and much more. I’m in the process of migrating content into this new infrastructure; archives of my public writings should be available shortly.

I of course have to thank my housemate, the inimitable David Weekly. Beyond managing to be one hell of a hacker, MP3 Guru, and overall most-connected-geek-on-the-planet(trust me), David has singlehandedly revived doxpara.com through the wonders of PHP.

Some further information about what I’ve been up to: I work at Cisco Systems nowadays; it’s a fascinating and very supportive environment to say the least. I was published in Ryan Russell’s “Hack Proofing Your Network: Internet Tradecraft”, where I wrote extensively on the theory and structure of Identity Spoofing attacks. If all goes well, I’ll be speaking at SANS 2001 about ridiculously cool ways to use OpenSSH. Past that…well, I’ll update the site as it happens.

To the best of my knowledge, Peter Guttman(sp?) has demonstrated for years now that there is no form of over-writing which makes any substantial difference to the ability to recover previously written data from a computer hard disk.

Guttman’s paper, “Secure Deletion of Data from Magnetic and Solid-State Memory” (available at http://www.cs.auckland.ac.nz/~pgut001/secure_del.html ) has become something of a classic, and for good reason: It’s absolutely fascinating reading, describing in detail what most of us suspected and some of us never imagined.

The paper, however, is five years old, and quite frankly needs to be understood in that context.

Now, I’m *not* saying that Guttman’s points are flawed, just that it’s likely that the mechanisms used to recover data from 300 Megabyte drives probably don’t scale to 80 Gigabyte disks using GMR(Gigantic Magnetoresistance) technology. The extra surface area and analog bit density used to divine past generations of data has almost certainly been exploited in the 16x explosion in data density since Guttman’s paper was written.

My *guess*, however, is that as drive densities have increased, the requirements for more and more advanced error correction(to increase yields on platters with miniscule deformities) has led to greater redundancy and increased platter space to entirely redundant–and reconstructable–information

Furthermore, it’s impossible that drive scanning technology hasn’t advanced in sync with drive capacity–the bottom line is, somebody needed to design the sensors to work out the kinks from each generation of disk. Companies like OnTrack(who, incidentally, worked very well for me) have made rather successful businesses of proven what’s gone is not necessarily gone.

LAW: We talk faster than we write, and we read faster than we listen.

COROLLARY: We shout out known commands faster than we can click them, but we visually absorb available commands faster than we can hear them.

CAVEAT: We can write with more detail than we can speak. We can listen with more comprehension than we can read.

EDUCATIONAL EXAMPLE: Go tell some random person to do something on a computer. Don’t do it yourself. Don’t let them know in advance what you want them to do. Notice how fast you realize they’re screwing up. Notice how slow it is for you to correct them. Notice how slow it is for them to absorb your corrections. Notice how fast you sit down and do it yourself.

CONCLUSION: The ideal interface will likely have us speaking at computers, with them shooting responses back as fast as the eye can absorb.

Forward: It is unfortunately common practice that applications which allow users to remember their passwords as a convenience rarely encrypt them but instead opt to simply obfuscate them.

Actually, it’s an unfortunately (verging on ridiculously) common practice to think that there’s any difference between encoding a password using a fixed algorithm and “encrypting” a password using a fixed key.

There isn’t one.

This is easily provable in terms of mere simplicity. How hard is it to reverse engineer the instructions a binary executes to implement some homebrew obfuscation? Reasonably doable, but it’s definitely at least a bit of work–much more work than just tracing the application opening up some file “c:\sekret.key” that happens to be the 168 bit Triple-DES key that’ll decrypt its password database.

So does that mean that 3DES is less secure than some homebrew? No. It means 3DES is being misused. Badly.

Any system that attempts to verify a password by comparing the password plaintext supplied against the correct password plaintext has already lost. No matter how many obfuscations and contortions it goes through, it can never escape the fact that the system itself must have permanently available access to the password plaintext. Encrypting the password with 3DES means nothing; the decryption key for the password is as functionally open as code for the executable running the home brew system. (Indeed, as we saw above, since the secrecy is distilled rather than hidden in binary code, it’s actually *easier* to rip off passwords when they’re 3DES encrypted!)

[Replying to Bob Kline]

> Microsoft has introduced a security hole in the FTP server on Windows > 2000 Professional.

Surprisingly enough, this is true. It’s just not a hole for the reasons you might think it is.

> The properties panel for the service has controls > for specifying “accept” or “deny” lists, and the online help explains > how to use these controls to explicitly prohibit specific hosts from > connecting to the service, or restrict access to an enumerated set of > hosts. What the online help does not explain is that this security > functionality has been turned off for the Professional version of > Windows 2000.

Yes, but the most important fact is that it’s *obviously* been turned off. What you wrote above implies that I could set up an entire filter configuration like the documentation tells me I can, and then because it’s Windows 2000 Professional, it’ll silently fail. This was enough of a concern for me that I actually tested out the configuration, which, as others have commented, “merely” manifests itself as greyed out tabs.

Greying out advanced functionality that’s only available in more advanced versions is a tried and true tactic among shareware authors, though I don’t remember the last time I saw it in an actual professional package(i.e. PhotoStyler doesn’t “hint” about Photoshop’s advanced features). It’s not unheard of, and in and of itself, it’s not a security issue.