Holy Cow.

Hackers on Tuesday hijacked the Web site CheckFree.com, one of the largest online bill payment companies, redirecting an unknown number of visitors to a Web address that tried to install malicious software on visitors' computers, the company said today.

And secondly:

It appears hackers were able to hijack the company's Web sites by stealing the user name and password needed to make account changes at the Web site of Network Solutions, CheckFree's domain registrar. Susan Wade, a spokeswoman for the Herndon, Va., based registrar, said that at around 12:30 a.m. Dec. 2, someone logged in using the company's credentials and changed the address of CheckFree's authoritative domain name system (DNS) servers to point CheckFree site visitors to the Internet address in the Ukraine. DNS servers serve as a kind of phone book for Internet traffic, translating human-friendly Web site names into numeric Internet addresses that are easier for computers to handle.

"Someone got access to [CheckFree's] account credentials and was able to log in," Wade said. "There was no breach in our system."

Way to CYA and leave the customer hanging. Does Network Solutions offer a strong authentication method to prevent such an attack? I would think that Checkfree could afford to pay extra for it.

Third, this also could have been thwarted if Checkfree offered some form of mutual https authentication for their site. Their users would not have been redirected.

Update

Security Fix also points to a post about US Bank's billpay site which is here currently outputs some kind of config dump.

Ben Laurie and Eric Sachs from Google's security team have published an article on the Usability of Stronger Authentication Options. This is a very interesting document and it's great to see the large internet players focus on security. Unfortunately, in their list of strong authentication methods they do not include software tokens, which seems to me to be a pretty big oversight. Of course, I'm a bit biased. Here are my thoughts on Ben & Eric's concerns:

Portability
As more and more data moves "to cloud services," and as users access that data with more devices (desktops, laptops, mobile phones, Tivos, Apple TVs, Playstations, etc.), the need for users to access their data from any device grows. However, while passwords are easy to use on nearly any device, the same is not true for some stronger authentication options such as software & hardware certificates. Thus websites which have deployed strong auth mechanisms have had more success by allowing users to use a more portable mechanism for stronger authentication such as hardware OTPs or mobile phones. Unfortunately those more portable options tend to provide less security then the less portable options. Even beyond the security, though, there is another usability problem.

I'm not sure what "more portable options tend to provide less security then the less portable options" means. I know that logging from un-trusted systems is less secure. So if they are referring to a coffee shop kiosk, yes, but that's not the fault of two-factor authentication. To me, portability means having it with you. WiKID accommodates this by allowing users to have more than one token for the same account. We can do this without a loss of security because we use public key cryptography. So a user can have a token on their PC, Blackberry and Tivo or whatever (Tivos not currently supported :).

Repeat Usage
Both consumer websites and enterprises that have deployed hardware OTPs or mobile phone authentication to users have encountered relatively consistent feedback that those devices become annoying after repeated usage. The task of logging in with such a device is much more cumbersome then using the browser's password autofill feature. One approach is to force users to login to a new machine using a stronger authentication mechanisms (OTP/certificate/etc.), but then to learn the HTTP Request details of that computer, and set a Cookie on the user's computer. For future login requests, those HTTP Request details and Cookies (usually in addition to a password) can be used to identify the user rather than requiring them to use a stronger authentication mechanism every time.

Security and usability are always seen as trade-offs. We try though! I think embedding two-factor authentication in the browser is a big help. Our much neglected Firefox extension (looking for some javascript contributors) uses semantic web technologies to start WiKID on pages that require one-time passcodes. We can also copy the OTP into the clipboad. Our mutual https authentication, in addition to thwarting network-based MITM attacks, launches the browser to the correct website for the user and pastes the OTP into the clipboard.

Provisioning
Nearly all the strong authentication mechanism require the users to go through some provisioning process. If a phone is used, then all the user needs to do is go through a one-time process of associating the phone with their account. On the other hand, hardware devices generally require the user to purchase the device, and then it needs to be physically mailed to them.

User provisioning must be secure or there is no security in a system. Also keep in mind that if you use a cell phone, then you are in some way relying on the security of the cell phone companies' security and they may have different incentives than you. Software tokens are probably somewhere between hardware tokens and a phone call. Users need to install software, but, at least with WiKID, provisioning can be automated based on some existing trusted information. This process can also be done securely across enterprises across the internet. For example, users could add a token via a webpage on their intranet using Active Directory credentials for a WiKID server run in the cloud for an Google Apps for your Domain. The transactions between the intranet page and the WiKID server are encrypted via SSL.

Rich Client Apps
Most installed software (desktop apps, mobile downloads, etc.) have built in code for displaying login boxes to collect a username/password, and they usually do not work with these different strong authentication mechanism. Google has published one option for how to address this using standards such as OAuth, but it requires a number of changes to how the software talks to the web servers. Of course, for websites that do not provide rich client apps, this is not a problem.

Software tokens are great for rich client applications, because they can be embedded. It is pretty trivial to embed WiKID's open source J2SE token into rich client applications, and since it's open source, it can be ported to other languages too. Online Banking Solutions has embedded WiKID in their corporate banking products creating a product that is incredibly easy to use and secure. They have made provisioning dead simple, they are using mutual https authentication and they are providing single sign-on capabilities to reduce the "repeat usage" issue.

The article also mentions malware:

One thing to note is that while these approaches can be used to more strongly authenticate the user, the rise of malware means that even after the user has been authenticated, there may be software on their machine that monitors for web sessions the user creates after logging in, and then performs actions at that site such as transferring money. Unfortunately protecting against that type of malware is much more difficult both for the end-user, and the website. However both problems (authentication and malware) need to be addressed, and in many cases they can be addressed separately.

With a picture.