Pages: pp. 6-7
In IEEE Security & Privacy's Nov./Dec. issue, Simson L. Garfinkel argues that email-based identification and authentication (EBIA) should be considered as a replacement for PKI technology in settings that require online user authentication ("Email-Based Identification and Authentication: An Alternative to PKI," pp. 20—26).
In contrast to PKI, due to the low costs involved, many sites are deploying EBIA. The most common application is recovering lost passwords for Web sites (but the idea is the same for others): When registering on a site, new users provide a login name, a password, and an email address. If they forget the password later on, they can request that the site send them an email that contains a URL containing some unique random number, which points to the site. When users load this URL, the site authenticates them and allows them to reset the password.
While we wholeheartedly agree with Garfinkel's criticism of PKI systems, we want to rebut a few points about the EBIA scheme he outlined.
From page 23, "When an email address is used for verification, an address owner discovers that the verification is taking place…" This is not true. Most email clients still rely on unencrypted passwords or challenge—response protocols that are vulnerable to dictionary attacks. An attacker can sniff a POP account/ password pair, log into the email account shortly after the owner has finished reading his or her mail, and then request, receive, and delete EBIA authentication emails at will, and without leaving a trace.
As well, Garfinkel states on that same page, "EBIA enables a competitive market for identity and authentication services." Unfortunately, we are not that optimistic. Major security problems at some email providers' sites such as hotmail. com have not caused a noticeable user migration (see, for example, www.wired.com/news/technology/0,1282,52115,00.html). Likely reasons are that changing to a new address is inconvenient (all friends and business associates have to notified), or that users do not consider security an issue as long as they do not suffer from attacks themselves. But the empirical fact stands that the market has always been a bad regulatory force when it comes to IT security.
Also on page 23—"Because EBIA is a weaker form of identification than PKI, organizations that rely on it have strong incentives to create additional security measures"—the argument that less security causes more security might be, although strange, valid for psychological reasons. However, it is not clear whether it actually provides a security advantage of less security in the end. If risk-management procedures inconvenience users (such as creating a new email account once a month), the perceived risk could outweigh their advantages.
By basing security on an insecure infrastructure, EBIA silently relies on the security of several other protocols, for example, SMTP, POP3/ IMAP, HTTP, and DNS. In the long list of EBIA's shortcomings (page 25), the author does not mention the problems inherent to DNS. An attacker can take over a whole domain's email traffic by forging DNS MX [mail exchanger] replies or the mail servers' address records, and even decide for how long the domain's email is under his or her control by setting the expiration time. This attack allows for the creation of massive amounts of virtual users, or the hijacking of large numbers of existing users, and does not even require password sniffing.
On page 24, the author mentions "…roles and groups …are easy to implement with EBIA." As we understand the intended implementation, a group initiator is expected to simply publish the group's password to all members. Most security professionals advise against this practice for good reasons. For example, it is impossible to hold anyone responsible for what action occurs in the name of a group, because anyone might have used the email account. On the other hand, for more complex group authentication schemes, the same administrative overhead arises as with PKI.
Garfinkel neglects to include an address-revocation scheme. As he outlines EBIA in this article, he does not address problems with authentication data revocation. Assume that after an identity is bound to an email address, the identified owner loses control of that address. An attacker can subsequently impersonate the authenticatee by answering email using the stolen account. How would the authenticatee announce the loss of control to the authenticator? Obviously not by sending a "lost control over email@example.com" message from yet another address. This would let everybody run trivial denial-of-service attacks.
On page 25, Garfinkel asserts "Authentication should be based solely on the ability to click on an emailed link…" In so-called "phishing" attacks, attackers send emails with forged headers and embedded links, which point to Web sites disguised as those from eBay, PayPal, and so on, but in fact are under the attackers' control. This works well because very few users are familiar with URLs' technicalities, and because some browsers misrepresent the URL string. These attacks represent a serious threat to EBIA.
On that same page, Garfinkel states that, "Sites that initiate EBIA messages should digitally sign them." This means that PKI should be used to strengthen EBIA because EBIA security might not be enough on its own. Although not strictly circular reasoning (it is not the user that is required to register with a certificate authority but only the site maintainer), this idea mirrors and fuels our concerns outlined earlier.
He also states that "Customers are responsible" (page 26). The author quotes a PayPal statement making obvious a tendency of EBIA-enabled services to ensure that the risks are the customers'. This is a parallel to PKI, where even legally binding authentication schemes exist, probably one of the major incentives for suppliers. However, as EBIA is less secure and less expensive, it allows higher risk to move from the service to the customer at far lower costs. Unfortunately, the higher risk might roll back to the supplier eventually: There are digital signature laws for PKI's use, but laws supporting EBIA are not likely to be passed—the risks are so high that an authenticatee always can plausibly claim to be a victim of fraud, viruses, or hackers, even if that is untrue.
We believe that although it is certainly expedient to point out that high trust is currently placed in EBIA-style authentication mechanisms, a more critical analysis would be appropriate in the presence of the concerns we listed and in the article itself.
—Matthias Fischmann firstname.lastname@example.org, Humboldt University of Berlin
—Matthias Bauer email@example.com, University of Erlangen-Nürnberg
While Fischmann and Bauer make many good points regarding my article, I think that they misunderstand the spirit in which I wrote it. It's clear that there are many problems with EBIA: POP passwords can be sniffed, DNS can be subverted, and some email providers have had security problems. Nevertheless, many organizations continue to use EBIA as the standard means by which passwords used in e-commerce are reset. Given that it is widely in use, and that its use is expanding, it is incumbent on security professionals to identify the practice, propose guidelines for its use, and devise means by which the industry can transition to more secure techniques.
Fischmann and Bauer argue that there always has been a poor regulatory force when it comes to IT security. I suggest that the reverse is true. Security professionals often demand that organizations deploy security technologies that are far more expensive than is warranted. Cost can be in terms of direct costs or the impact on worker productivity. Time and again, organizations have shown that they are willing to live with higher risk than security professionals think wise. The fact that these companies still are in business leads me to believe that the companies were correct in the evaluation of their risk levels, and the security professionals were wrong.
Got comments? IEEE Security & Privacy welcomes all communications from its readers, whether to comment, make a point, or express an opinion on our pages or Web site. Letters might be edited for clarity and brevity. Please send your comments to lead editor Kathy Clark-Fisher at firstname.lastname@example.org.
To post your views with your peer, please visit us at our community forum.