Following a story we published last week about a widespread e-mail vulnerability involving weak cryptographic keys, system administrators at many companies around the world began to check their DNS records to make sure that the DKIM keys they were using to authenticate their e-mail were at least 1,024 bits in length – the recommended standard for secure authentication of e-mail.

No doubt, if they found they were using substandard keys – at lengths of 384 bits, 512 bits, and 768 bits – they replaced those keys with stronger ones to secure their corporate business e-mail.

But according to one researcher who contacted us after the story ran, these companies may be overlooking one problem – third-party e-mailers who are responsible for sending out marketing newsletters and other communication to customers on their behalf. In fact, one e-mail marketing company, which thought it had fixed the problem a year ago, had left US Bank, Capital One, Walmart, TD Ameritrade, TiVo and others open to easy spoofing.

A company may fix the problem with DKIM keys they generated themselves, but forget that third-party e-mailers also have to fix the keys they use to send e-mail on the company's behalf. Oftentimes, the e-mailer will generate its own DKIM key to send such correspondence, and system administrators may or may not be aware of these or be able to delete them from their DNS records without causing problems for the e-mailer.

The researcher, who asked us to use his hacker handle "Quincy Robertson," uncovered the DKIM problem with third-party e-mailers last year after another researcher named John Graham-Cumming found that Facebook was using a weak DKIM key in 2010.

Facebook fixed its DKIM key after Graham-Cumming notified the company, but Robertson began wondering if other companies might have the same problem. After doing a little research, he found that a number of large companies – banks, retailers and investment firms among them – were all using the exact same weak key – a 384-bit key – to authenticate their e-mail. He thought this was odd until he traced the key back to a third-party e-mailer called Epsilon Interactive.

In Sept. 2011, Robertson contacted CERT, at Carnegie Mellon University, to report the problem, and CERT reached out to Epsilon on his behalf.

"I didn't want to anger Epsilon's lawyers directly," Robertson says, referring to the longstanding issue that many security researchers have when they try to disclose vulnerabilities and the affected company either reports the researcher to law enforcement or sends the researcher a threatening legal letter.

In this case, Epsilon did the right thing after being contacted by US CERT and promptly re-issued 1,024-bit keys for the e-mail it was sending out on behalf of its clients.

But after our story ran last week, Robertson checked the DNS records for domains belonging to a number of Epsilon's customers, and found that many of them still had the old 384-bit key in their DNS records, along with the stronger 1,024-bit key.

As mathematician Zachary Harris explained in our first DKIM story, as long as a weak DKIM key remains in a DNS record – even if a company is no longer using it to authenticate its e-mail – a hacker can still use the weaker key to spoof e-mail and send it out as if it came from that company. In Epsilon's case, the problem was exacerbated by the fact that the e-mailer had used the same DKIM "master" key for all of its customers, reducing the amount of work a hacker would have to do to spoof their e-mail.

"It took somewhere around five hours to break it on my quad-core system at home using publicly available software (Msieve, factmsieve, and GGNFS)," Robertson says.

"There are some tedious format conversions needed to get the factorization results turned into a private key," he says, but notes that he created a fully automated script to do this, which will generate the private key for a company, using the company's domain name and DKIM selector.

Among the Epsilon customers that still had the 384-bit key in the DNS records of some of their subdomains were: US Bank, Barclays, Capitol One, Scottrade, TD Ameritrade, Walmart, Disney, Marriott, Ritz-Carlton, the American Automobile Association, Walmart, the Home Shopping Network, TiVo and Pizza Hut.

Quinn Jalli, senior vice president of marketing technology for Epsilon, acknowledged the issue and said his team was in the process of cleaning out the old keys from DNS records.

"We did not know that was the issue," he told Wired. "It wasn't an act of negligence. Removing them would have been fairly simple. But we did not know that leaving the keys would create that vulnerability."

Epsilon Interactive isn't alone in believing that generating a new key solved their DKIM security issue. One large company, who was among the list of corporations that mathematician Zachary Harris identified in our previous story as having a weak DKIM key, also appears to have overlooked the third-party e-mailer issue.

After our story ran, someone with the company contacted Wired to say that Harris was wrong and that it didn't have a DKIM issue because the company never used DKIM to authenticate its e-mail. But Harris was insistent that the company did have a problem, and after some back-and-forth, the company realized that the subdomains that were using the weak key Harris found were actually used by a third-party e-mailer to deliver some of the company's customer communication, such as alerts and other correspondence. The third-party e-mailer was using a 768-bit key to authenticate e-mail sent on behalf of its client, and that key was still in the company's DNS record, where Harris found it. It wasn't the weakest key Harris found, but still lower than the recommended 1,024-bit standard.

The problem lies with DKIM keys (DomainKeys Identified Mail). DKIM involves a cryptographic key that domains use to sign e-mail originating from them – or passing through them – to validate to a recipient that the domain in the header information on an e-mail is correct and that the correspondence indeed came from the stated domain. When e-mail arrives at its destination, the receiving server can look up the public key through the sender’s DNS records and verify the validity of the signature.

For security reasons, the DKIM standard calls for using keys that are at least 1,024 bits in length. But many companies still use keys that are 384 bits, 512 bits, and 768 bits.

“A 384-bit key I can factor on my laptop in 24 hours,” Harris explained to Wired previously. “The 512-bit keys I can factor in about 72 hours using Amazon Web Services for $75. And I did do a number of those. Then there are the 768-bit keys. Those are not factorable by a normal person like me with my resources alone. But the government of Iran probably could, or a large group with sufficient computing resources could pull it off.”

A hacker who cracks a DKIM key can use it to send out phishing attacks to victims to trick them into believing that a fake e-mail is actually a legitimate e-mail from their bank or another trusted party. Such phishing attacks can be used to trick users into handing over the login credentials to their bank or e-mail account.

Robertson discussed the issue earlier this year at the HOPE hacker conference in New York. "DomainKeys Identified Mail (DKIM) is the most effective, widely deployed e-mail forgery countermeasure available today ... if implemented correctly," he noted in the description of his talk. But "many of the world’s largest and most trusted companies, including some of those driving the standard, have fatally flawed deployments ... [that] can be exploited to achieve the holy grail of e-mail forgery."

UPDATE 10.31.12: To clarify which CERT organization Robertson had contacted to report the vulnerability.