Six-and-a-half degrees of seperation
Posted: August 14, 2008 Filed under: Internet, review Leave a comment »An interesting paper out of MSFT research lends new support to the six-degrees of separation meme.
Quick recap: the idea that on average every individual can be linked to any other by a chain of no more than 5 acquintances in between dates to the work of Stanley Milgram at Stanford in the 1970s. Milgram used an old fashioned communication network: the postal system aka “snail mail.” Subjects in the experiment were asked to deliver letters to individuals they knew only by name and geographic location. Surfer Bob in San Diego might be asked to deliver a letter to investment banker Alice in New York, by forwarding the letter to somebody that he suspects is closer to Alice. On average letters were passed on six times along the way to their final destination, hence the six-degrees concept which later became a Tony award-winning play on Broadway, later jumping to the big screen with Will Smith before achieving mainstream status as an online game featuring Kevin Bacon. Early part of this decade witnessed a surge of interest in studying so-called “small world graphs” which resulted in the publication of several books that poplarized the concept.
Six-degrees took a major hit in credibility when another researcher discovered in 2006 that 95% of the letters in the Milgram experiment had never reached their intended destination. One possible conclusion was that the social network was in fact, not the connected, small-diameter graph everyone imagined it to be. If 95% of the nodes had no routes between them that would paint a picture of a fragmented, disjoint society reminiscent of high school, broken up into cliques and tribes. Or it could have been that the subjects did not follow through, because sending letters takes up non-trivial amount of time.
Fast forward three decades and instant messaging has drastically lowered the overhead for communication. So the MSR group– which includes the designer of infamous Clippy– looked at the social network formed by users of MSN/Live Messenger. Specifically they studied the social graph implied by 30 billion messages sent among 240 million users in June 2006. If two people exchange messages, they are assumed to know each other. (There are situations when that is not true: for example there are spammers sending IM to random people. Also users may have more than on identity, so individuals do not map uniquely to nodes– this can distort paths because user Alice may be appears as contact on Bob’s personal IM account but not work IM account.) This is a much larger data set than Milgram’s original sample of <200 and crunching that would not have been possible without massive computing power. Finding the shortest-path between two people in a graph is very expensive and requires looking at all connections. There are some optimizations for doing this on all pairs of individuals but it is still a very expensive proposition on such a large dataset.
The result came close to vindicating the original idea: average distance between two IM users was right around 6.5 and 78% of users were seperated by less than seven links. In fact the slightly higher number would be expected because the instant messaging graph has a subset of all real world connections. First not everyone uses the Internet; the digital divide remains very much alive in the US. This has the effect of removing entire nodes from the graph; nodes that could have provided shorter conncetions between people. Similarly not all Internet users have instant messaging. Even two heavy Internet addicts may use different IM networks (one on AIM, the other on GMail for example) because interoperability is still not the norm in this space. The combined effect of these biases is to remove edges from the graph and “inflate” the distances.
cemp
New York Times badly confused on identity management
Posted: August 12, 2008 Filed under: identity, Internet, MSFT, oped, review, Security Leave a comment »Goodbye Passwords is that rare misstep form the otherwise consistently solid Digital Domain section in the Sunday NYT: confused, misinformed and way off base. Among the several muddled arguments, four of them stand out:
1. Equating OpenID to passwords.
“OpenID offers, at best, a little convenience, and ignores the security vulnerability inherent in the process of typing a password into someone else’s Web site.”
Minor factual error: actually the password is not being typed into a random website. It is supposed to be provided only to the website where the identity was originally created, not the website where it is being used. But the general difficulty of determining whether one indeed starting at the authentic site instead of a fraudulent replace– especially when the user has been sent there by the “someone else’s Web site” in question leads to the standard critique of OpenID as increasing phishing risks.
Major factual error: OpenID is a federation standard, not a new user authentication approach. It does not mandate passwords or any other scheme for verifying identity. Open ID 2.0 specification is loud and clear on this point:
“Methods of identifying authorized end users and obtaining approval to return an OpenID Authentication assertion are beyond the scope of this specification.”
That means the identity provider can choose to use good old-fashioned passwords, smart-cards, biometrics or experimental approaches such as reading tea-leaves to authenticate the user; OpenID is silent on this. In fact one of the more hyped extensions to the protocol, added at the urging of MSFT which has been desperately trying to promote CardSpace, is a way for signaling to websites that the user authenticated with credentials resistant to phishing– Infocards in the original vision that carved out this niche case, but also more generally strong authentication mechanisms such as PKI capable smart-cards.
2. Narrow definition of single sign-on:
OpenID promotes “Single Sign-On”: with it, logging on to one OpenID Web site with one password will grant entrance during that session to all Web sites that accept OpenID credentials.
In the most general sense, single sign-on refers to one identity being valid for accessing multiple systems. This is in contrast to the current state of affairs on the web: most websites have their own notions of user identities, requiring users to create a new account. Each account is valid at exactly one website and not recognized anywhere else. Single sign-on (“federation” using the fashionable term) is about merging these disconnected islands of identity such that the scope of an identity can extend beyond that one site.
Quick peek at the Wikipedia entry would have hinted that SSO is not tied to passwords. So it comes as surprise that a Microsoft architect is quoted as criticizing SSO. Cardspace is an instance of single sign-on: the vision calls for one identity held by the user’s machine to be usable for logging into any number of websites. Inside the enterprise, Active Directory is single sign-on because it allows the same credentials to be used for accessing everything from logging into a workstation with the three-finger salute to accessing email or HR systems.
3. Misconception that “information card” is a generic term-of-art as it relates to identity management. Information card, or infocard to use the original name for the technology before it was rebranded into CardSpace, is a particular proposal that defines specific formats and protocols for identity management. Writing about “the information cards” makes about as much sense as writing about “the Facebooks” and “the Googles.” Each is a specific incarnation of a general concept: a social networking site, a search engine and an identity management protocol.
4. No hint of the history of strong authentication or alternatives. A reader may walk away from this article with the impression no realistic alternatives to passwords existed until Cardspace magically burst on the scene. Basic fact checking would have unearthed some not entirely obscure facts: there is a concept of digital certificates dating back to the 1970s, leveraging the same brew of “hard to break cryptography” whose virtues are extolled in the article. Since late 1990s, digital certificates have been standardized by X509, a stable and widely implemented supported format. It would be a small jump from there to realize that the SSL protocol universally used for securing communications online has provisions for users to verify their identity with digital certificates and that many large organizations, including the United States Department of Defense have been depending on this capability for years.
This is not to say that there are not good points in the article. OpenID is a major distraction and duplication of effort precisely because it is a mediocre reinvention of the wheel, ignoring all the investments made towards deploying PKI on the web compliments of SSL and muddying the waters one more time just when there was a fighting chance that the industry might converge on a standard (SAML, far from perfect as it may be) as the underlying format for identity assertions. But it is a non-sequitur to argue that OpenID is doomed because of its dependence on passwords and inherent problems with single sign-on.
cemp
From 0wning DNS to 0wning SSL (2/2)
Posted: August 8, 2008 Filed under: Internet, oped, review, risks, Security Leave a comment »But SSL does have an Achilees heel: its trust model is anchored on the digital certificate used by the web server: the only proof that the website you are communicating with Bank of America (as opposed to an impostor in Estonia) is the fact that they have a digital certificate issued by Verisign claiming that this website indeed is www.bankofamerica.com.
The fragility of this model has been pointed out before. Verisign is not the only recognized certification authority; out of the box Windows ships with close to 100 CAs, all of them equivalent for trust purposes. Any one of them incorrectly issuing the Bank of America certificate to somebody else is enough to ruin any guarantees provided by the cryptography– it does no good to secure your traffic, when the person at the end of that encrypted channel is the bad guy. (Perhaps the biggest CA goof was Verisign issuing Microsoft code-signing certificate to impostors in 2001. The implications were much worse than for SSL certificates, but revocation has addressed the fall-out for the most part.) While MITM attacks against SSL due to incompetent CA practices have always been possible, the challenge of playing that messenger in between so far made this a low-likelihood attack vector. Owning DNS changes that.
More importantly– and this is Kaminsky’s main point regarding SSL– the certification process itself uses DNS. According to this version of the story, when the proud new owner of the domain www.acme.net wants a digital certificate, the CA consults DNS records to verify ownership. They might even ask the user to insert some DNS records or add a particular page to the website, as additional proof. All of these checks are trivially subverted if DNS is corrupt because all of them will be routed to servers controlled by the attacker. This means that while the existing Bank Of America certificate is safe and sound, the enterprising criminal will:
- Choose a moderaly incompetent CA
- Subvert DNS to confuse name resolution for that CA
- Pass the domain ownership checks made by the CA
- Obtain a new valid certificate in the name of Bank of America
- Subvert DNS resoution for an ISP
- MITM all of the users at that ISP by using the perfectly valid certificate from step #4
That, at least is the picture painted in the presentation. The critical details are certification steps used– not just by Verisign, Geotrust and other major CAs but every single one of the dozens of certification authorities recognized by IE and Firefox. Extended validation does not help for two reasons: on the usability front, users pay no attention to all the fancy eye-candy browsers waste on displaying EV status, as demonstrated nicely by The emperor’s new security indicators.. On the the implementation level, the browser grants exactly same privilege to regular certificates; embedded content for example can still be subverted using a vanilla cert while keeping the main page over EV.
If this attack does indeed work– and it is impossible to determine without consulting the certification practices for CAs– it shows a circularity in the security model. SSL/TLS are designed to survive exactly the type of mayhem created by DNS hijacking. It does not matter whether traffic is routed to the right website or the wrong one. When the protocol is implemented correctly and the certificate checks out, the user is supposed to be guaranteed that they are dealing with the legitimate website. (That is not much of a guarantee: if the certificate has errors, the protocol will detect it but until recent web browsers used to respond by displaying a cryptic warning that users simply ignored. Even when the certificate is validated correctly, that only proves the identity is what is stated in the URL– which may not be at all the same one that is in the user’s mental picture, to the delight of phishing syndicates everywhere.) Weak certification practices destroy even this glimmer of hope by placing critical faith in DNS to bootstrap a protocol that was purportedly designed to survive complete breakdown of all naming and routing infrastructure.
cemp
Vintage code, common hardware and value of backwards compatibility
Posted: July 17, 2008 Filed under: mobile, MSFT, review, software Leave a comment »A data point on the value of backwards compatibility. This is an area where MSFT is frequently slammed, for its insistence on favoring compatibility with past mistakes instead of throwing everything overboard to start over again– the way Apple has done with OS-X and later switching to Intel x86 chips.
Imagine having to demonstrate an application running on Windows Mobile to a crowded room full of security professionals. This code will not run on the emulator– and even if it did, emulation hardly makes for a compelling demo. “Code always wins” as the old MSFT adage goes and working code on an actual device is the golden standard. This is the predicament confronting the blogger next week. Slide decks are not a problem; they can run off a locally installed PowerPoint or OpenOffice instance (the import process still loses some details if the latest eye-candy from Office 2007 is used) or better yet run from the cloud-hosted Google Presently. Showing UI from the device is a different challenge.
Most phones can not project the view of their own display to an external monitor using a standard VGA, DVI or HDMI output. (Oddly enough a few can project other video over Bluetooth to specialized devices and there is nascent efforst to give phones projectors of their own.) Having a dedicated, fixed camera pointing at the phone was not an option in this setting. And since it is not possible for dozens of people to cluster around a single handset trying to get a peek at the tiny screen, one option is to capture static screenshots at relevant points and project these as part of the slide-deck.
Even that is non-trivial: there is no “print screen” functionality on Windows Mobile out of the box. One quick Google search finds several third-party substitutes, including a freeware version from Ilium software. Luckily the search results also unearthed a better solution. An entry on the Windows Embedded Blog dated November 2004 references a Remote Display application included as part of the Windows Mobile Power Toys. This is good news; power toys are officially unsupported applications typically written by MSFT developers on the side. According to the description Remote Display shows real-time view of the phone display mirrored on the desktop. Much better than static screen-shots and the audience can now follow along with the exact flow.
One problem: the Power Toys are dated December 2003. Supported operating systems on the download page include W2K SP3– long defunct– as well as “Windows Mobile 2002 based smart-phones.” In other words, this code is archaic. The MSI installed without a problem on Vista, even bearing a proper Authenticode signature to keep the inane UAC prompt happy about reporting the author. But the first attempt to run it with an HTC Diamond failed with an error message about unknown CPU type on the device. Not surprisingly 5 years after the code was written, the architecture of mobile devices, as well as the operating system MSFT is shipping to run on these devices had become unrecognizable under the assumptions the original author had made. Vista does not even have a separate Active Sync component, instead Mobile Device Center handles synchronization with phones.
But the README file provided plan B: the instructions described what to do for that particular error. The recommended fix was to manually find the correct binary over for the mobile device and copy it over. There were not exactly many choices either: Windows CE 3.0, CE 4.0 and smartphones based on CE 4.0. Each OS SKU had a corresponding array of architecture choices, including x86, MIPS and ARM4. As for the device? It is running Windows Mobile 6 on ARMv5i.
So it was a surprise that copying the ARM4 binary built for CE4 worked: Vista could mirror the device screen in real time. Even more impressively, Remote Display works both ways: clicking on the phone UI from the desktop PC actually sends the mouse clicks to the phone, allowing the phone to be driven by the full-size mouse and keyboard combination.
This is one of the rare cases where the insistence on backwards compatibility paid dividends. Not only did the ARM processor have to remain backwards compatible and run binaries compiled for an earlier version, but Windows Mobile itself had to evolve such that code written for earlier CE variants could run without any changes.
cemp
What is wrong with this UI?
Posted: March 13, 2008 Filed under: Internet, review, Security Leave a comment »Time-Warner New York / New Jersey proving that their website design is just as cutting edge as their service reliability. Below is a screen-shot from the password reset flow. In fairness this may not be TW: the website for online account payments appears to have been outsourced as evidenced by the URL. But then again getting your broadband service and possibly VoIP from a company without the inhouse expertise to build a payment processing website does not inspire confidence.)
What is the point of prompting for something that you have just printed on the same page? Because our customers need frequent practice with their copy/paste keyboard shortcuts.
cemp
Macbook Pro frustrations
Posted: March 13, 2008 Filed under: hardware, Internet, review Leave a comment »- Unreliable coming out of hibernation: occasionally a blank black screen after opening the laptop. Power button has no effect, as does the rest of the keyboard. Closing the lid, re-opening and then hitting power button brings back the unlock screen.
- It gets worse from there: occasionally the password prompt never appears, instead there is the endless spinning cursor suggesting the UI is blocked on something. The first attempt to unlock the screen by typing enter after the password has no effect: the dialog box remains, with the password highlighted this time. Pressing enter again– on the exact same masked password– unlocks the screen.
- Problems associating to draft 802.11N networks. There are general usability problems in connecting to any wireless network: the wireless icon that lists available networks is very slow to respond, has difficulty locating networks etc. Draft-N appears to pose particular problems because it will not automatically re-associate after coming out of hibernation– something it has no problem doing on ordinary B/G networks. Instead it prompts with the same question about joining a random open network because no trusted networks could be found. Maybe try harder next time?
- For that matter the entire user-experience around wireless needs tweaking. The top right-hand corner icon which opens the menu listing all detected access points is very slow. Occasionally the menu freezes, again suggesting that the code is getting stuck somewhere in the depths of the 802.11 stack.
- FileVault prompt during restart: informs the user each time that FileVault, the file-system encryption feature on OS-X, is taking up too much space, some of this can be reclaimed, proceed/cancel etc. “Reboot” means reboot without lame questions.
cemp
Email storage and a lump of coal
Posted: February 20, 2008 Filed under: environment, hardware, review, software Leave a comment »TreeHugger is not the first to notice that computing technology can have environmental impact and different “systems” can be greener than others. In an invited talk at Microsoft Research in 2004, Andrew Shapiro from the Berkman Center and author of The Control Revolution raised the question of whether Linux could be deemed more environmentally friendly because it ran on lower-end hardware that would not meet the base requirements for modern Windows SKUs. (He was polite enough not to answer this question given the audience.) Similarly it is widely acknowledged that data centers today are gated by cooling and power consumption– air conditioning being one of the prime resource hogs– and availability of power generation is a significant factor in selecting “hot-spot” locations for building them.
TreeHugger post frets over the cost of email storage and wonders whether deleting email will curb carbon emissions. Good intentions for sure but the calculation may have been slightly off base for several reasons. First the bad news: storage in large-scale services like the one cites in the article are replicated. There can’t be just one copy of the message sitting around. Try explaining to a user that you lost all of their vacation pictures because drive #3385 failed– the so-called “we blame Seagate” approach. That implies the figures are underestimating the true impact. That would be true only in a simplistic model where power consumption scales with amount of data stored. Transaction capacity is often the determining factor for data center design. If one million people are checking email at the same time, enough servers have to be up and running to process those requests with tolerable latency. That’s true even if everyone keeps an empty inbox.
Similarly different storage architectures can lead to very different resource consumption patterns. If drives are directly attached to server, then more storage means more servers even if the servers sit idle CPU-wise. If the service uses a storage array network (SAN) then only drives are being powered and not all the extra baggage that would come with a full-fledged server. This is similar to the difference between using a networked drive at home verses another general purpose PC for handling backups. Finally there is the storage corollary to Moore’s law: disk sizes increase, price drops and so does power consumption per GB. (Unfortunately there is also a storage corollary to Peterson’s principle which states that data expands so as to fill the drive available.) It’s true that less storage will achieve some reduction but the Treehugger article probably overestimates this by several orders of magnitude. And if hosted cloud service were comapred to storing the same amount of data at home, there would be no contest: those massive data-centers achieve economies of scale and corresponding eco-efficiency not available to the average consumer not living off-the-grid with solar panels.
cemp
NDSS, final day: “minding the gap”
Posted: February 18, 2008 Filed under: Internet, review, risks, Security Leave a comment »(Trying to write about the conference before the recollections fade.)
Dan Kaminsky was scheduled to be the invited speaker on Wednesday morning , tentatively titled “On breaking stuff” but he was held up by consulting work at IOActive. Fortunately for the conference program committee, Paul van Oorschot volunteered to give a talk on short-notice and the result was the highly engaging “Security and usability: mind the gap” presentation.
He first started with some anecdotal evidence on the sad state of affairs in what should have been the poster child for usable security: online banking. One of the largest banks in Canada promised to refund 100% of losses resulting from unauthorized transactions– provided the user lived up to their side of the agreement. This fine-print in the customer agreement (granted nobody pays attention to that) makes for entertaining reading:
- Select unique and not easy to guess password– and user will judge the quality of their password how? Windows Live ID has a password quality meter but this is far from being a standard feature.
- Sign-out, logoff, disconnect and close the browser when done (What is the difference between first two? Disconnect means yank the network cable?)
- Implement [sic] firewalls, a browser with 128-bit encryption and virus-scanning. As van Oorschot pointed out, the bank probably means “deploy” rather than “implement”– otherwise they would drastically narrow the potential customer base to developers with copious spare time for writing code from scratch for commodity purposes.
It only gets worse from there. The general pattern is promises of security and reassurance that damages will be covered in exchange for vague expectations of “secure behavior” form users who are often not in a position to accurately judge risks associated with their use of technology. Case in point: one study on malware found that 95% of users had heard of the word “spyware” and 70% banked online– yet some assumed that spyware was a good thing– 45% did not look at URLs and 35% could not explain what HTTPS meant. The status quo for online banking is not an isolated incident, as other case studies drawn from two recent publications van Oorschot coauthored:
- An evaluation of Tor/Vidalia/Privoxy for anonymous browsing, which concluded that Tor is not ready from prime-time use by a novice even with the supposedly user-friendly Vidalia UI. (Given its remarkably low bandwidth and high latency reminiscent of the early “world-wide-wait” days of dial up, you have to wonder if a usability study was necessary to reach that conclusion.)
- Usability study of two password managers with 26 non-technical users that found several problems, including situations where users falsely concluded a security feature was functioning when it was not– the very dangerous “false success” scenario. [Full disclousure: this blogger had reviewed and broke an earlier version of one, PwdHash.]
If poor usability is a security vulnerability as much as a flaw in a cryptographic protocol, what is the prescription? This is where the information security community is now wrestling with its collective conscience. van Oorschot made the frank observation that usability and HCI issues are routinely looked down upon by CS culture, not included in the traditional curriculum because they are easy/trivial and better left to “people who can’t write code” to sort out. He raised the possibility that we had it wrong all the time: cryptography is the easy bit, secure system implementation is far more challenging and the hardest task is building usable secure systems.
cemp
NDSS, day II: Virtualization and security panel
Posted: February 13, 2008 Filed under: Internet, review, risks, Security Leave a comment »The highly anticipated panel ended up taking a different turn. My colleague Tavis from Google could not attend, leaving DJ Capelis from UCSD as the only other skeptical voice to point out the risks from virtualization. (Recap: Last year Tavis found several problems in qemu, Virtual PC/Server and VMware virtualization platforms.) Intel was represented, and so was AMD with John Wiederhirn and Tal Garfinkel attended for VMware completing the viewpoints at the table: hardware, virtualization platform, security research.
Most of the discussion implicitly focused on the server consolidation scenario, without spelling out the other uses of virtualization. Briefly consolidation scenario is about replacing multiple physical machines by a single powerful box that runs a VM with the equivalent OS/software configuration for each PC displaced. It sounds like re-arranging deck chairs but in fact this is a major cost saving opportunity for enterprise IT departments. A single powerful, expensive server hosting N virtual machines is by far easier to maintain than N low-end servers each running a different configuration. And in the long run the cost of maintenance dominates the original purchase cost of the hardware. Full machine virtualization creates new opportunities because it allows very clean consolidation between applications that could not otherwise live on the same bare metal: for example a legacy W2K3 line-of-business app alongside a new W2K8 terminal server or even Linux and Windows coexisting side-by-side.
This is the most commercially viable market for virtualization. VMware has been leading the charge and MSFT giving chase with Virtual Server R2 and the upcoming hypervisor in W2K8. But focusing on it alone skewed the discussion, setting the stage for a predictable debate around trade-offs. Separate hardware is an isolation boundary: it keeps different applications from interfering with each other accidentally or by malicious logic. Virtualization is another one, as are operating system processes, BSD jails etc. Each one has an assurance level from security perspective or equivalently an attack surface. Server consolidation with a VMM involves changing the isolation boundary and creating new attack surface. There may be new channels for one VM to attack another when running on the same bare-metal, while separate boxes would have been confined to the network or shared storage etc. Quantifying that incremental risk and sharing opinions on whether it is a reasonable trade-off fueled much of the debate.
This is a comparison virtualization can not win on the single dimension of risk. Considering the extent VMs are used for malware research and quarantining untrusted code, it’s surprising that other applications were not considere. The flip-side of consolidation is sand-boxing: moving applications running in the same trust boundary to different VMs is a corresponding improvement– although the extent that it improve security is again debatable and dependent on the quality of implementation.
As a side note, the moderator raised a point about reduced customer choice: with individual machines one has a choice of different vendors to buy a network switch from. With the functionality of the switch subsumed in the software stack that choice goes away.
cemp
