I have extensively researched SiteKey on behalf of a competitor bank, and can say with certainty; SiteKey is NOT an anti-phishing solution.
How it Works:
SiteKey is essentially a collection of functions that integrate with a merchant's existing login system and customer database to enhance the login process. It is designed to retrieve data from, and write data to, a user's computer, then compare this retrieved information with data contained in the merchant's customer database. As such, it is not actually performing website authentication. It is enhancing the merchant's existing login process by including additional image/message data, as well as a retrieved "device ID" that identifies the customer's computer. SiteKey stores this data with merchant's customer database and presents this stored information to the customer after they enter their normal Login ID and before they enter their Password.
SiteKey uses the merchant's existing customer Login IDs and integrates with the merchant's existing login system and customer database. Since one customer's login ID at one merchant may be already be in use by a different customer at a different merchant, SiteKey users will find themselves being required to (a) register for a login ID at every merchant they wished to authenticate, and (b) create different login IDs for different merchants if their desired login IDs were found to be already in use by someone else. Also, merchants who do not presently use a login system would be unable to implement SiteKey without first installing some form of a login system with an underlying customer database to store the login IDs and corresponding SiteKey data.
Security Issues:
Storing this image/message data within the merchant's customer database presents huge security issues since the secret image/message information is directly tied to the merchant's customer records. In the event of a data theft from ANY SiteKey-equipped merchant, ALL SiteKey-equipped merchants who use this solution would find themselves at risk because the customers of the victimized merchant may have registered with them as well. If they have, they would likely have registered the same SiteKey images and messages. Even if the customer's images and messages were different between merchants, the stored Device ID would be the same since it is the unique identifier for the customer's computer. This creates a common data thread between otherwise isolated and dissimilar merchant database records which a phisher could exploit.
As a solution to the problem of phishing, this type of site-by-site, data-driven approach is fundamentally flawed. The FDIC has determined that the problem of phishing results from a fundamental inability of website owners to authenticate themselves to their customers in such a way that cannot be replicated by phishers. The SiteKey approach can be replicated in its entirety by a phisher, targeting the common customers of all merchants who use SiteKey, using data stolen from just one careless SiteKey equipped merchant.
The purpose for the 3 challenge questions has to do with the fundamental structural problem of the SiteKey approach. SiteKey is dependent on retrieving a "Device ID" from, and writing it to, a user's computer. When Bank of America's customers enter their Login ID, the SiteKey functions attempt to retrieve this "Device ID" from, or write it to, the customer's computer. If successful, the bank then locates the customer record in their database and compares the retrieved Device ID with the Device ID stored in the customer database record. If they match, the bank proceeds to display the image data from the customer record to the customer and waits for their password.
If, however, a customer is logging in to their bank account from a different computer, or sitting behind a firewall that prohibits such interaction with their computer, or have turned off the ability to accept cookies, certificates, etc., then no Device ID will be retrieved by the bank website. In this case, the bank prompts the customer with one or more of the 3 chall
Slashdot Mirror
I have extensively researched SiteKey on behalf of a competitor bank, and can say with certainty; SiteKey is NOT an anti-phishing solution. How it Works: SiteKey is essentially a collection of functions that integrate with a merchant's existing login system and customer database to enhance the login process. It is designed to retrieve data from, and write data to, a user's computer, then compare this retrieved information with data contained in the merchant's customer database. As such, it is not actually performing website authentication. It is enhancing the merchant's existing login process by including additional image/message data, as well as a retrieved "device ID" that identifies the customer's computer. SiteKey stores this data with merchant's customer database and presents this stored information to the customer after they enter their normal Login ID and before they enter their Password. SiteKey uses the merchant's existing customer Login IDs and integrates with the merchant's existing login system and customer database. Since one customer's login ID at one merchant may be already be in use by a different customer at a different merchant, SiteKey users will find themselves being required to (a) register for a login ID at every merchant they wished to authenticate, and (b) create different login IDs for different merchants if their desired login IDs were found to be already in use by someone else. Also, merchants who do not presently use a login system would be unable to implement SiteKey without first installing some form of a login system with an underlying customer database to store the login IDs and corresponding SiteKey data. Security Issues: Storing this image/message data within the merchant's customer database presents huge security issues since the secret image/message information is directly tied to the merchant's customer records. In the event of a data theft from ANY SiteKey-equipped merchant, ALL SiteKey-equipped merchants who use this solution would find themselves at risk because the customers of the victimized merchant may have registered with them as well. If they have, they would likely have registered the same SiteKey images and messages. Even if the customer's images and messages were different between merchants, the stored Device ID would be the same since it is the unique identifier for the customer's computer. This creates a common data thread between otherwise isolated and dissimilar merchant database records which a phisher could exploit. As a solution to the problem of phishing, this type of site-by-site, data-driven approach is fundamentally flawed. The FDIC has determined that the problem of phishing results from a fundamental inability of website owners to authenticate themselves to their customers in such a way that cannot be replicated by phishers. The SiteKey approach can be replicated in its entirety by a phisher, targeting the common customers of all merchants who use SiteKey, using data stolen from just one careless SiteKey equipped merchant. The purpose for the 3 challenge questions has to do with the fundamental structural problem of the SiteKey approach. SiteKey is dependent on retrieving a "Device ID" from, and writing it to, a user's computer. When Bank of America's customers enter their Login ID, the SiteKey functions attempt to retrieve this "Device ID" from, or write it to, the customer's computer. If successful, the bank then locates the customer record in their database and compares the retrieved Device ID with the Device ID stored in the customer database record. If they match, the bank proceeds to display the image data from the customer record to the customer and waits for their password. If, however, a customer is logging in to their bank account from a different computer, or sitting behind a firewall that prohibits such interaction with their computer, or have turned off the ability to accept cookies, certificates, etc., then no Device ID will be retrieved by the bank website. In this case, the bank prompts the customer with one or more of the 3 chall