Mutual Authentication
Up one level2005/10/31
Happy Halloween: WiKID releases HTTPS Mutual Authentication System
Happy Halloween!
WiKID is pleased to announce the alpha release of a major feature upgrade under the GPL featuring a cryptographic method of mutual authentication for web sites:
WiKID-2.1: SOMETHING_WiKID_THIS_WAY_COMES
It is being released as a patch to the 2.01 server release. The system works this way: Each WiKID domain can now include a 'registered URL' field and a hash of that website's SSL certificate. When a user wants to log onto a secure web site, they start the WiKID token and enter their PIN. The PIN is encrypted and sent to the WiKID server along with a one-time use AES key and the registered URL. The server responds with a hash of the website's SSL certificate. The token client fetches the SSL certificate of the website and compares it the hash. If the hashes don't match, the user gets a warning message along with the OTP. If they match, the user is presented with registered URL and the passcode. On supported systems, the token client will launch the default browser to the registered URL.
We are currently seeking testers for this early release. You do not need to set up a WiKID server to test. We have set up a WiKID server for you. Testers will need to download the latest J2SE WiKID token from sourceforge. Testing information can be found on the sourceforge forums
Most one-time-password systems suffer from man-in-the-middle attacks primarily due to difficulties users have with validating SSL certificates. The goal of this release is to validate certificates for the end user, providing an SSH-esque security for web-enabled applications such as online banking.
WiKID is pleased to announce the alpha release of a major feature upgrade under the GPL featuring a cryptographic method of mutual authentication for web sites:
WiKID-2.1: SOMETHING_WiKID_THIS_WAY_COMES
It is being released as a patch to the 2.01 server release. The system works this way: Each WiKID domain can now include a 'registered URL' field and a hash of that website's SSL certificate. When a user wants to log onto a secure web site, they start the WiKID token and enter their PIN. The PIN is encrypted and sent to the WiKID server along with a one-time use AES key and the registered URL. The server responds with a hash of the website's SSL certificate. The token client fetches the SSL certificate of the website and compares it the hash. If the hashes don't match, the user gets a warning message along with the OTP. If they match, the user is presented with registered URL and the passcode. On supported systems, the token client will launch the default browser to the registered URL.
We are currently seeking testers for this early release. You do not need to set up a WiKID server to test. We have set up a WiKID server for you. Testers will need to download the latest J2SE WiKID token from sourceforge. Testing information can be found on the sourceforge forums
Most one-time-password systems suffer from man-in-the-middle attacks primarily due to difficulties users have with validating SSL certificates. The goal of this release is to validate certificates for the end user, providing an SSH-esque security for web-enabled applications such as online banking.
- Category(s)
- WiKID
- Mutual Authentication
- The URL to Trackback this entry is:
- http://www.wikid.com/WiKIDBlog/69/tbping
2005/11/03
Focusing on things you can control
The blogosphere is alive with talk about the FFEIC's guidance requiring stronger authentication for online banking. Inevitablty, someone says how useless better authentication is when PCs are so insecure.
I'm reminded of the frustrations we had in my last company, iTendant which marketed web-to-wireless service request management software to office landlords. As they say in real estate, the three most important things are "location, location, location".
In reality, location, building quality, rental rates and quality of support services are important and the landlords can't do anything about the first two after the building is up. They can lower their rental rates to attract more customers, but who wants to do that? The only thing they can do is to keep their tenants happy via top notch service which will increase occuppancy, reduce turnover and increase retention.
Banks can't really do anything about the consumer machine, except educate consumers and if they are going to do that, they might as well include information about two-factor and mutual authentication, the things they actually can do something about.
In addtion, banks control their servers and they should be extremely diligent about keeping an eye out for cross-site scripting vulnerabilities. For this, I recommend SPI Dynamics (FD: I'm an investor). Banks should scan their sites whenever there is a new vulnerability or when there is a change to the site.
BTW, we sold iTendant to Abrahams Industries. They have a solid hotel client base - that understands how important service is - and wanted better technology.
I'm reminded of the frustrations we had in my last company, iTendant which marketed web-to-wireless service request management software to office landlords. As they say in real estate, the three most important things are "location, location, location".
In reality, location, building quality, rental rates and quality of support services are important and the landlords can't do anything about the first two after the building is up. They can lower their rental rates to attract more customers, but who wants to do that? The only thing they can do is to keep their tenants happy via top notch service which will increase occuppancy, reduce turnover and increase retention.
Banks can't really do anything about the consumer machine, except educate consumers and if they are going to do that, they might as well include information about two-factor and mutual authentication, the things they actually can do something about.
In addtion, banks control their servers and they should be extremely diligent about keeping an eye out for cross-site scripting vulnerabilities. For this, I recommend SPI Dynamics (FD: I'm an investor). Banks should scan their sites whenever there is a new vulnerability or when there is a change to the site.
BTW, we sold iTendant to Abrahams Industries. They have a solid hotel client base - that understands how important service is - and wanted better technology.
- Category(s)
- Phishing and Fraud
- Mutual Authentication
2005/11/11
SEC on investor security
The SEC has released an education guide for investors on how to protect themselves from fraud.
Certainly this is laudable and to be expected from a government agency, but it also points out the differences in regulations between the SEC and the agencies that make up the FFEIC (FDIC, OCC, OTS, etc). A search of the SEC site turns up only this one article about phishing. While the FFEIC has shocked the banking industry awake with its demands for better authentication and security, the SEC is back in 2001 issuing recommendations like "use your own computer".
It could be my ignorance of what the SEC mission is, oh, wait, not really:
Internet stock trading and similar technologies changed the way markets worked, helping to bring transparency and efficiency into the market. Internet fraud could stifle those efficiencies and negatively impact the integrity of the market. I'm not typically for regulation - and I think the FFEIC guidelines are pretty relaxed as far as regulation goes - but if the brokerage industry falls behind the banking industry, the phishers will just target brokerages.
Certainly this is laudable and to be expected from a government agency, but it also points out the differences in regulations between the SEC and the agencies that make up the FFEIC (FDIC, OCC, OTS, etc). A search of the SEC site turns up only this one article about phishing. While the FFEIC has shocked the banking industry awake with its demands for better authentication and security, the SEC is back in 2001 issuing recommendations like "use your own computer".
It could be my ignorance of what the SEC mission is, oh, wait, not really:
The primary mission of the U.S. Securities and Exchange Commission (SEC) is to protect investors and maintain the integrity of the securities markets. As more and more first-time investors turn to the markets to help secure their futures, pay for homes, and send children to college, these goals are more compelling than ever.
Internet stock trading and similar technologies changed the way markets worked, helping to bring transparency and efficiency into the market. Internet fraud could stifle those efficiencies and negatively impact the integrity of the market. I'm not typically for regulation - and I think the FFEIC guidelines are pretty relaxed as far as regulation goes - but if the brokerage industry falls behind the banking industry, the phishers will just target brokerages.
- Category(s)
- Two Factor Authentication
- Mutual Authentication
- The URL to Trackback this entry is:
- http://www.wikid.com/WiKIDBlog/71/tbping
2005/11/30
Will the FFIEC Guidelines be a driver for the strong authentication market?
There is a great post on DigitalID World by Eric Nolan about the recent FFIEC guidelines regarding two-factor authentication being a driver for the strong authentication market, much as other compliance rules have boosted the identity management marketplace. It is a very inciteful article and worth the read. I have some comments though:
There is a problem with the federated model, however: it deals only with session authentication. Most strong authentication systems are susceptible to man-in-the-middle attacks. To thwart MITM attacks, you need cryptographically secure mutual authentication. To thwart session hijacking trojans, you will need transaction authentication or digital signing that is cryptographically distinct from the session authentication mechanism (lest the attacker generate a phony "connection lost, please re-authenticate" message).
I worry that the first bank to do an ad featuring their strong authentication solution as a differentiator will become a target and will have an "Oracle: Unbreakable" type of PR mess, even if it is a cross-site scripting attack. Security is hard to do and the attackers are not going to stop until the profit is driven out of the business. I would be careful here.
1. I'd imagine that strong auth will become a primary driver for federated identity technologies. As mulitple means of authenticating emerge, linking identities into small "circles of trust" will grow in importance -- and, for the first time, the end-user convenience factor will exist as a real motivation.
There is a problem with the federated model, however: it deals only with session authentication. Most strong authentication systems are susceptible to man-in-the-middle attacks. To thwart MITM attacks, you need cryptographically secure mutual authentication. To thwart session hijacking trojans, you will need transaction authentication or digital signing that is cryptographically distinct from the session authentication mechanism (lest the attacker generate a phony "connection lost, please re-authenticate" message).
2. I'd imagine that strong auth will become a primary driver in the acquistion cycle. The identity management "suite" won't stop at its current state. In the wake of the Oracle acquistions, RSA Security is already positioning its smart card and token platforms as a differentiator in the identity marketplace. Strong authentication will become a hot ticket for consolidation into the identity management stack.W00t!
3. I'd imagine that the flip side of "risk management" is "competitive differentiator" - with strong auth as the driver. How long is it until I begin to see commercials on CNBC praising the ease of use and secure nature of insert-online-bank's strong authentication tools? How long is it until some marketing type makes the risk management controls around identity theft a competitive differentiator for an online banking transaction? I'd bet not that long.
I worry that the first bank to do an ad featuring their strong authentication solution as a differentiator will become a target and will have an "Oracle: Unbreakable" type of PR mess, even if it is a cross-site scripting attack. Security is hard to do and the attackers are not going to stop until the profit is driven out of the business. I would be careful here.
- Category(s)
- Two Factor Authentication
- Mutual Authentication
2005/12/27
Winkin'; WiKID and OpenVPN
One reason I haven't been posting is that I have been adding some Flash demos to the website.
I have been using a product called Wink which is a free, closed source tool. I highly recommend it for simple Flash tutorials. The mutual authentication demo uses a time-based screen capture feature. The others use a static screen capture mode. Nothing fancy, it just works.
Speaking of which, we have tested WiKID and OpenVPN on Windows and Linux. And it just works too. There is how-to on the website. Support is provided via PAM and either TACACS+ (on the open source version of WiKID) or Radius (on the commercial).
I have been using a product called Wink which is a free, closed source tool. I highly recommend it for simple Flash tutorials. The mutual authentication demo uses a time-based screen capture feature. The others use a static screen capture mode. Nothing fancy, it just works.
Speaking of which, we have tested WiKID and OpenVPN on Windows and Linux. And it just works too. There is how-to on the website. Support is provided via PAM and either TACACS+ (on the open source version of WiKID) or Radius (on the commercial).
- Category(s)
- WiKID
- Mutual Authentication
- The URL to Trackback this entry is:
- http://www.wikid.com/WiKIDBlog/79/tbping
2005/12/30
Banks thinking strategically about security
Bank Lawyer's Blog has an interesting post about an American Banker editorial (apparently not available online) about the new FFIEC guidelines for stronger authentication for online banking.
We've already seen phishers target one-time passcode in Swedish. Clearly the bad guys will go where the money is.
The post quotes the editorial:
So, there are two recommendations here:
Banks that can provide value-added services and/or target high-value customers with the increased security will be the winners.
In other words, if banks, even small institutions, haven't been thinking "strategically" about enterprise security, they should take this opportunity to do so. As Ms. Sraeel points out, such strategic thinking is necessary "given the pace of technological change and how adept criminals are at keeping pace with innovation."
We've already seen phishers target one-time passcode in Swedish. Clearly the bad guys will go where the money is.
The post quotes the editorial:
It was bound to happen. With the Internet's meteoric rise for commercial use over the past seven years, it's surprising that multi-factor authentication was not mandated sooner. Think of it this way: The more that institutions do to safeguard customer and corporate information, the less likely they are to incur losses (obvious) and other damages such as the lack of proprietary information affecting mergers, stock performance and product launches (becoming more obvious).
Most important, though, the guidance could prompt financial institutions to look beyond what is expected; for larger institutions, this could mean giving customers and partners secure access to more online services. This can only be good for business, and well worth the investment in multi-factor authentication.
So, there are two recommendations here:
- Don't just meet the guidelines, get secure. Anticipate the attacks and meet them head on.
- Extend your services based on the increased security. What can you now do that you couldn't before?
Banks that can provide value-added services and/or target high-value customers with the increased security will be the winners.
- Category(s)
- Phishing and Fraud
- Mutual Authentication
- The URL to Trackback this entry is:
- http://www.wikid.com/WiKIDBlog/84/tbping
2006/01/05
More predictions for 2006
I already did some predications over on IDWorld. Of course, if I were afraid to fail I would have a real job. Here are more predictions for 2006:
I suspect the vast majority of these are wrong or that many have already happened and i just forgot.
- Phishers, having focused on Europe recently, will again focus on the US with more sophisticated tools.
- Attackers will increasingly target corporations for their HR databases for identity information.
- Strong Authentication will get a big boost from banks, but also from corporations that deploy SSL-based VPNs.
- Web 2.0 and Identity management will meet in 2006 resulting in lots of
discussions about privacy, enterprise vs individual identities etc. Slowly, people will realize that it's really employee vs customers as enterprises will always be providing the services. - People will start talking about permission-based identity services such as a service that will require a users' permission to check a credit report. these ideas will go nowhere because of incentive issues.
- Federated two-factor systems offered by the hardware token vendors will fail miserably. A combination of costs and privacy concerns will kill them, despite signing up one or two high-profile clients whose customers reject it a la Passport.
- 2006 will once again not be the year of biometrics or certificates.
- Someone will come up with an aggregator of user-centric universal identifiers. They will raise a bunch of VC money and fail.
- Confederated identity will take off. This is where a user maintains a handful of identity services and only uses services that support one of those systems. Registration pages are removed in favor of RSS-esque buttons that indicate support various identity services, such as Infocards, which get
- GYMA (Google, Yahoo, Microsoft, AOL) and ebay into the identity game.
- Patent issues with SAML will hamper it's adoption by the GYMA crew.
- Mutual authentication becomes a must have for all financial websites.
- Brokerage accounts will increasingly be targeted by phishers and fraudsters.
- Digital signing and/or transaction authentication will become a hot-topic again as banks and brokerage houses look to thwart session-hijacking trojans.
- Another payment processor will get the death penalty from Mastercard and Visa for a violation of their PCI standards.
- One of the credit reporting agencies will get in hot water for a breach, again.
I suspect the vast majority of these are wrong or that many have already happened and i just forgot.
- Category(s)
- Information Security
- Mutual Authentication
2006/01/10
More on Layered Authentication
Ok, I slagged the concept of 'layered' authentication as a marketing neologism in my response to Eric Nolan's identity predictions for 2006. I was overcome by prediction hysteria. I've got to calm down...
Here's the problem with most of the pitches I have seen for "layered authentication". Let's start with an actual pitch:
"Moving beyond the two-factor or multifactor authentication solutions available in the market today, the multi-layered approach provides a stronger form of authentication without compromising the online banking experience for end users. In addition to a user name and password, Intelligent Authentication leverages multiple patterns of online banking behavior and attributes of the online banking user to determine when it is necessary to block or challenge suspicious visitors."
I have a few problems with this:
1. "Moving beyond..." Let's judge the strength of the solution based on it's relative security. To break this security, all you need to do is a MITM replay attack, use a session hijacking trojan and/or know the user's challenge information. This really hasn't moved beyond.
2. What value is here? It's easy to log IP address, plant cookies, etc. I hope this is a free service. It's also easy to know which transactions are suspicious - the ones where money leaves an account.
3. A large number of users will absolutely hate this. They delete cookies, use WiFi in weird places and use multiple computers. They also have lots of money.
To me, layered authentication means session, host/mutual and transaction authentication. I think authentication needs to be consistent and involve the user. Using tools like cookies, which rely on DNS and are hidden from the user, aren't optimal solutions.
Here's the problem with most of the pitches I have seen for "layered authentication". Let's start with an actual pitch:
"Moving beyond the two-factor or multifactor authentication solutions available in the market today, the multi-layered approach provides a stronger form of authentication without compromising the online banking experience for end users. In addition to a user name and password, Intelligent Authentication leverages multiple patterns of online banking behavior and attributes of the online banking user to determine when it is necessary to block or challenge suspicious visitors."
I have a few problems with this:
1. "Moving beyond..." Let's judge the strength of the solution based on it's relative security. To break this security, all you need to do is a MITM replay attack, use a session hijacking trojan and/or know the user's challenge information. This really hasn't moved beyond.
2. What value is here? It's easy to log IP address, plant cookies, etc. I hope this is a free service. It's also easy to know which transactions are suspicious - the ones where money leaves an account.
3. A large number of users will absolutely hate this. They delete cookies, use WiFi in weird places and use multiple computers. They also have lots of money.
To me, layered authentication means session, host/mutual and transaction authentication. I think authentication needs to be consistent and involve the user. Using tools like cookies, which rely on DNS and are hidden from the user, aren't optimal solutions.
- Category(s)
- Two Factor Authentication
- Mutual Authentication
- The URL to Trackback this entry is:
- http://www.wikid.com/WiKIDBlog/88/tbping


Digg this!
Del.ico.us
Google
Yahoo bookmarks
Reddit
Spurl
Simpy

I saw this blurb about ID protection and VC interest and thought you might be interested in it.
They all seem really complicated.
Daniel