WiKID
Up one level2005/03/01
WiKID Reviewed by SC Magazine
I'm pleased that WiKID was included in a review by SC Magazine. You can see the review online now.
The review process went pretty well, but I was frustrated by a couple of things. For example, they lost the CD of documentation. I really don't want to kill trees to print things that people mostly don't read, but we probably will from now on, just for reviewers ;). In all though, it was a very interesting process and I respect their goal of being more picky and less communicative than a typical customer would be.
I also recognize that WiKID's funky caps will always result in various mis-capitalizations until we have the heft and recognition to make it otherwise. You don't see many people writing about "Ibm" or "Rsa". :)
BTW: If you are interested in reviewing the WiKID Strong Authentication System, let me know - you can post comment or contact me at nowen -at - wikidsystems.com
The review process went pretty well, but I was frustrated by a couple of things. For example, they lost the CD of documentation. I really don't want to kill trees to print things that people mostly don't read, but we probably will from now on, just for reviewers ;). In all though, it was a very interesting process and I respect their goal of being more picky and less communicative than a typical customer would be.
I also recognize that WiKID's funky caps will always result in various mis-capitalizations until we have the heft and recognition to make it otherwise. You don't see many people writing about "Ibm" or "Rsa". :)
BTW: If you are interested in reviewing the WiKID Strong Authentication System, let me know - you can post comment or contact me at nowen -at - wikidsystems.com
- Category(s)
- WiKID
- Information Security
- The URL to Trackback this entry is:
- http://www.wikidsystems.net/WiKIDBlog/12/tbping
Re: WiKID Reviewed by SC Magazine
Posted by
Iang
at
Nov 04, 2005 07:41 AM
The link shows 404?
Re: WiKID Reviewed by SC Magazine
Posted by
nowen
at
Nov 16, 2005 01:29 PM
Thanks! Fixed it.
2005/09/01
Understanding the flexibility of WiKID
There is a lot of flexibility in WiKID. It can be daunting.
Each WiKID token client supports multiple domains across multiple servers. This means that one token can replace all a users passwords if those services support WiKID. WiKID becomes like a key chain of hardware tokens.
Each user can have multiple tokens. So you can have a corporate PC client, a wireless client on your Blackberry and a home PC client. These tokens may have the same WiKID domains on them or not. The only way a user can establish a second token on the same domain, though, is with a valid passcode from the first token. (This requirement prevents a rogue admin from setting up tokens without the user’s knowledge.)
Tokens can be wired or wireless. We support both a PC-based token client (Windows, Mac and Linux) and wireless (Blackberry, Palm, J2ME, PocketPC), or both as mentioned above.
Users can be set up automatically or manually. WiKID is unique among two-factor authentication systems in that users can be completely set up without an administrator’s assistance. Users can also be validated manually and re-validated immediately by an administrator.
Each domain can have its own security requirements. Minimum PIN length, passcode lifetime, max bad PIN attempts before lock-out and max bad passcode attempts can all be configured by the administrator.
WiKID is open source and commercial. As a free, open source solution WiKID makes sense for services that typically only require a password for security because WiKID is easier for end-users (who only have to remember a PIN) and far more secure. Yet, authentication is a very key element of network security, so support services and commercial add-ons are important too.
Each WiKID token client supports multiple domains across multiple servers. This means that one token can replace all a users passwords if those services support WiKID. WiKID becomes like a key chain of hardware tokens.
Each user can have multiple tokens. So you can have a corporate PC client, a wireless client on your Blackberry and a home PC client. These tokens may have the same WiKID domains on them or not. The only way a user can establish a second token on the same domain, though, is with a valid passcode from the first token. (This requirement prevents a rogue admin from setting up tokens without the user’s knowledge.)
Tokens can be wired or wireless. We support both a PC-based token client (Windows, Mac and Linux) and wireless (Blackberry, Palm, J2ME, PocketPC), or both as mentioned above.
Users can be set up automatically or manually. WiKID is unique among two-factor authentication systems in that users can be completely set up without an administrator’s assistance. Users can also be validated manually and re-validated immediately by an administrator.
Each domain can have its own security requirements. Minimum PIN length, passcode lifetime, max bad PIN attempts before lock-out and max bad passcode attempts can all be configured by the administrator.
WiKID is open source and commercial. As a free, open source solution WiKID makes sense for services that typically only require a password for security because WiKID is easier for end-users (who only have to remember a PIN) and far more secure. Yet, authentication is a very key element of network security, so support services and commercial add-ons are important too.
- Category(s)
- WiKID
- Two Factor Authentication
- The URL to Trackback this entry is:
- http://www.wikidsystems.net/WiKIDBlog/58/tbping
2005/09/06
WiKID Strong Authentication and Laws of Identity
Last week, I blogged about the flexibility of WiKID. Today, I want to apply that thinking to Kim Cameron’s Laws of Identity. How does WiKID’s flexibility support the Laws? Obviously, WiKID would only be a part of the identity system – the authentication piece. The question is how does WiKID enable this metatsystem to comply with the laws.
1. User Control and Consent
Technical identity systems must only reveal information identifying a user with the user's consent.
No one is as pivotal to the success of the identity metasystem as the individual who uses it. The system must first of all appeal by means of convenience and simplicity. But to endure, it must earn the user's trust above all.
WiKID can’t help too much with the policies that create trust, but it is very simple to use and a convenient way to manage multiple credentials.
2. Minimal Disclosure for a Constrained Use
The solution that discloses the least amount of identifying information and best limits its use is the most stable long-term solution.
There is not much here that applies to WiKID, except that WiKID can support multiple authentication relationships in a single domain. Hardware tokens cannot do that, so they will promote federated identity services which users will have to trust not to violate this law. It’s better not to have the temptation.
3. Justifiable Parties
Digital identity systems must be designed so the disclosure of identifying information is limited to parties
having a necessary and justifiable place in a given identity relationship.
The identity system must make its user aware of the party or parties with whom she is interacting while sharing information.
The justification requirements apply both to the subject who is disclosing information and the relying party who depends on it. Our experience with Microsoft Passport is instructive in this regard. Internet users saw Passport as a convenient way to gain access to MSN sites, and those sites were happily using Passport—to the tune of over a billion interactions per day. However, it did not make sense to most non-MSN sites for Microsoft to be involved in their customer relationships. Nor were users clamoring for a single Microsoft identity service to be aware of all their Internet activities. As a result, Passport failed in its mission of being an identity system for the Internet.
WiKID brings something to the table here – because a single WiKID token client can support with multiple independent servers across multiple parties, there is no need for a single identity provider like Passport. Of course, WiKID can support and greatly increase the security of a federated identity system.
4. Directed Identity
A universal identity system must support both "omni-directional" identifiers for use by public entities and "unidirectional" identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles.
Bluetooth and other wireless technologies have not so far conformed to the Law of Directed Identity. They use public beacons for private entities. This explains the consumer backlash innovators in these areas are currently wrestling with.
Public key certificates have the same problem when used to identify individuals in contexts where privacy is an issue. It may be more than coincidental that certificates have so far been widely used when in conformance with this law (i.e., in identifying public Web sites) and generally ignored when it comes to identifying private individuals.
This law is very insightful, in my opinion, and WiKID’s model works well within it. WiKID stores no personal information in the client or the server, except a username. The server may rely on personal contextual information to establish the relationship, but it is not stored in WiKID’s client or server. For example, WiKID provides an intranet application for the automatic validation of users based on trusted LAN credentials. Essentially, the trust assertion of the LAN credentials is transferred to WiKID in this process (I hope I’m using my “Laws of Identity” verbiage correct here). A vendor to that company could choose to trust those credentials via an assertion from that employer (either using WiKID’s protocol or using SAML, for example). The same user can set up a domain with their online bank using some other trusted method. There is no personal information stored in that domain either and it is directed solely at the bank. There is no cross-over between the employer and the bank.
5. Pluralism of Operators and Technologies
A universal identity system must channel and enable the inter-working of multiple identity technologies run by multiple identity providers.
The universal identity metasystem must not be another monolith. It must be polycentric (federation implies this) and also polymorphic (existing in different forms). This will allow the identity ecology to emerge, evolve, and self-organize.
Our focus right now at WiKID is adding more network clients to support a plethora of services, platforms and languages. Additionally, there are plenty of ways to extend WiKID across enterprises and services, such as via federation or via cross-credentialing (i.e., you can use a WiKID one-time passcode from service X to establish a relationship with service Y). Finally, we offer WiKID in both open source/free and commercial versions making it economically viable for logging into both your blog, your corporate VPN and your online bank.
6. Human Integration
The universal identity metasystem must define the human user to be a component of the distributed system integrated through unambiguous human-machine communication mechanisms offering protection against identity attacks.
The question is how to achieve very high levels of reliability in the communication between the system and its human users. In large part, this can be measured objectively through user testing.
We have focused a great deal on ease-of-use for the end user (as well as for the administrator). We also need to draw a strong comparison between the WiKID token client and PIN and a bank ATM card and PIN. We want users to understand the need for securing their token and PIN.
7. Consistent Experience Across Contexts
The unifying identity metasystem must guarantee its users a simple, consistent experience while enabling separation of contexts through multiple operators and technologies.
To make this possible, we must "thingify" digital identities—make them into "things" the user can see on the desktop, add and delete, select and share. (We have chosen to "localize" the more venerable word "reify".) How usable would today's computers be had we not invented icons and lists that consistently represent folders and documents? We must do the same with digital identities.
I’m not sure I agree that this is necessary, but in a way, WiKID does this. I have a domain in the WiKID client called “WiKID Corporate” which I use to get access to our corporate resources. I don’t know why I would ever “share” this. That would seem to be a potential violation of Law 4.
- Category(s)
- WiKID
- Two Factor Authentication
- The URL to Trackback this entry is:
- http://www.wikidsystems.net/WiKIDBlog/59/tbping
2005/09/12
"Strong Authentication for the masses"
WiKID got a nice review over at the Coffee Corner. I hope they do test the WiKID server on your home network. That is exactly the scenario we envisioned when we released the open source version. No reason why home users shouldn't be able to have strong authentication. I do want tot try to clarify some of the issues, if I understand them correctly:
1. "It would be possible to capture and spoof the encrypted PIN transmission to the WiKID server." The PIN is sent to the WiKID server encrypted by the server's public key and a one-time use AES key. Capturing and spoofing the PIN in hopes of getting the OTP doesn't do you any good unless you also steal the one-time AES key and the user's private key.
2. "In a traditional scenario, not only is my PIN secret but my token is unique - somebody has to have my token in order to impersonate me. With WiKID, I can authenticate using anybody’s device client that has my server’s key." Not so. Each user has a unique public/private key pair with their WiKID token. The security of the system is not solely dependent on keeping the PIN safe.
I look forward to hearing about the install. I think we've done a pretty good job there keeping things simple, but it always helps to get feedback.
1. "It would be possible to capture and spoof the encrypted PIN transmission to the WiKID server." The PIN is sent to the WiKID server encrypted by the server's public key and a one-time use AES key. Capturing and spoofing the PIN in hopes of getting the OTP doesn't do you any good unless you also steal the one-time AES key and the user's private key.
2. "In a traditional scenario, not only is my PIN secret but my token is unique - somebody has to have my token in order to impersonate me. With WiKID, I can authenticate using anybody’s device client that has my server’s key." Not so. Each user has a unique public/private key pair with their WiKID token. The security of the system is not solely dependent on keeping the PIN safe.
I look forward to hearing about the install. I think we've done a pretty good job there keeping things simple, but it always helps to get feedback.
- Category(s)
- WiKID
Re: "Strong Authentication for the masses"
Posted by
Michael Peters
at
Sep 12, 2005 07:00 PM
I don’t think WikiD is very secure at all. It is subject to a simple replay attack.
Their description of the token is that it ” … is is encrypted with the WiKID Server’s public key - assuring that only that server can decrypt it with its private key.” This is subject to several attacks. On its face, it means anyone can copy this encoded message and replay it in an attack.
In a more sophisticated version of this attack, the super secure encoded message is intercepted in a MIDM. The authenticated message is forwarded to the server, which sends the bad guys the OTP.
Re: "Strong Authentication for the masses"
Thanks for the nod. I'll talk about your points in a later comment (between teleconferences for work at the moment). Am working on the install at the moment - aside from a lack of documentation, nothing has broken at the moment. Note that I'm using Gentoo, which is not an RPM-based system, so I'm figuring things out as I go.
Drop me an email, as I do have some questions that I'd like to hash out outside of comment boxes.
Drop me an email, as I do have some questions that I'd like to hash out outside of comment boxes.
Re: "Strong Authentication for the masses"
Okay, focused now.
However, you describe there that the PIN is also encrypted with a single-use AES key. If that encryption happens before encrypting with the server public key, then fabulous - each encrypted PIN message is unique and can't be replayed. If the PIN is encrypted first with the server public key, then the single-use AES encryption is really acting like an SSL session and can be attacked by a MITM attack - recover the public key-encrypted PIN from the AES-encrypted traffic, open a new session to the WiKID server with new AES keys and replay. (I think, anyway. It depends on whether or not I can recover the AES key exchange from sitting in the middle or not. That may not be possible.)
"When a user wants to login,say to a VPN service, they enter a PIN into the WiKID Two-factor Client, it is encrypted by the public key of the WiKID server and sent to the server. If the encryption is valid, the PIN is correct and the account is active, the server returns the one-time passcode encrypted by the Client's public key."
This would imply that the OTP is returned encrypted by the device client public key, not a user's public key. Great example - my wife and I share the same laptop. I'll have the device client installed there. Do I need to have it installed a second time for her to use, or (as I expect) would she use the same device client, feed her username and PIN code, and get back a OTP for her? Then the device client isn't unique to the user, I can roam freely between device clients (that have been configured for my Domain), and the uniqueness is limited to the PIN.
However, you describe there that the PIN is also encrypted with a single-use AES key. If that encryption happens before encrypting with the server public key, then fabulous - each encrypted PIN message is unique and can't be replayed. If the PIN is encrypted first with the server public key, then the single-use AES encryption is really acting like an SSL session and can be attacked by a MITM attack - recover the public key-encrypted PIN from the AES-encrypted traffic, open a new session to the WiKID server with new AES keys and replay. (I think, anyway. It depends on whether or not I can recover the AES key exchange from sitting in the middle or not. That may not be possible.)
"When a user wants to login,say to a VPN service, they enter a PIN into the WiKID Two-factor Client, it is encrypted by the public key of the WiKID server and sent to the server. If the encryption is valid, the PIN is correct and the account is active, the server returns the one-time passcode encrypted by the Client's public key."
This would imply that the OTP is returned encrypted by the device client public key, not a user's public key. Great example - my wife and I share the same laptop. I'll have the device client installed there. Do I need to have it installed a second time for her to use, or (as I expect) would she use the same device client, feed her username and PIN code, and get back a OTP for her? Then the device client isn't unique to the user, I can roam freely between device clients (that have been configured for my Domain), and the uniqueness is limited to the PIN.
Re: "Strong Authentication for the masses"
First, this is AWESOME! This is far more analysis than we got at some F500 financial services companies - but that is for another blog post.
First, think of WiKID as a public key transaction with symmetric encryption at the transport layer. It is possible to get the OTP request and replay it to the server. The server responds with the OTP encrypted by the token client's public key and the attacker can do nothing with it unless they have the client's private key. The AES key is a chain block cipher. It is a variable length so it looks different each time, even if it happens to have the same data.
Second, the MITM attack described by Michael is valid for all forms of authentication. However, WiKID can be extended to thwart this attack. More on that later too.
i.The user selects the domain for which he or she needs a passcode.
ii.The user provides the PIN for the domain, created in the registration process.
iv.The payload (password request) is sent encrypted to the server.
v.The server receives the request and decrypts the request with its private server key.
vi.The server looks up the appropriate requesting client device (via the deviceID for the security domain) and verifies the PIN.
vii.If the PIN is correct for the security domain and client device, the server creates the passcode payload by creating a passcode (length is administratively configurable) for the client device and encrypting this payload with the client public key. The payload is then transport encrypted with the random AES key provided by the client.
viii.The passcode is then time-stamped and allowed to live based on the parameters of the security domain (from seconds to days, depending on sensitivity of asset).
ix.The WAS then returns the client request with the payload.
i.The response must be decrypted with the random AES key sent in the request.
ii.The payload must be decrypted with the client private key.
iii.If the payload is verified, the passcode is displayed on the device and the user can use the passcode for access to the network service.
iv.If the payload is not verified, an error is created and the process should be repeated.
v.Lastly, the WAS only allows passcodes to be valid for a specific time period and they may only be used one time.
First, think of WiKID as a public key transaction with symmetric encryption at the transport layer. It is possible to get the OTP request and replay it to the server. The server responds with the OTP encrypted by the token client's public key and the attacker can do nothing with it unless they have the client's private key. The AES key is a chain block cipher. It is a variable length so it looks different each time, even if it happens to have the same data.
Second, the MITM attack described by Michael is valid for all forms of authentication. However, WiKID can be extended to thwart this attack. More on that later too.
i.The user selects the domain for which he or she needs a passcode.
ii.The user provides the PIN for the domain, created in the registration process.
iv.The payload (password request) is sent encrypted to the server.
v.The server receives the request and decrypts the request with its private server key.
vi.The server looks up the appropriate requesting client device (via the deviceID for the security domain) and verifies the PIN.
vii.If the PIN is correct for the security domain and client device, the server creates the passcode payload by creating a passcode (length is administratively configurable) for the client device and encrypting this payload with the client public key. The payload is then transport encrypted with the random AES key provided by the client.
viii.The passcode is then time-stamped and allowed to live based on the parameters of the security domain (from seconds to days, depending on sensitivity of asset).
ix.The WAS then returns the client request with the payload.
i.The response must be decrypted with the random AES key sent in the request.
ii.The payload must be decrypted with the client private key.
iii.If the payload is verified, the passcode is displayed on the device and the user can use the passcode for access to the network service.
iv.If the payload is not verified, an error is created and the process should be repeated.
v.Lastly, the WAS only allows passcodes to be valid for a specific time period and they may only be used one time.
Re: "Strong Authentication for the masses"
The server responds with the OTP encrypted by the token client's public key and the attacker can do nothing with it unless they have the client's private key.
*smacks forehead* Ah, I get it now. You're not encrypting the response with the server's private key (to prove it came from the correct server), you're encrypting it with the client's public key (so only the correct client can understand it). You're doing two-way asymmetric encryption. That makes sense now.
As for the multiple clients, I get that now too - you're using the device client ID to represent the user identity, and the PIN for verification. That makes sense, and having multiple device clients on one computer allows for multiple users - one device, many users. I also have plurality in the other direction - many devices, one user - as I plan to have a client configured for me on my home computer, my work computer, et cetera. (If the J2ME client gets opensourced, then I may just put it on my cell phone and be done with it.) I assume there are ways to tie multiple devices to a single user account on the target system; I haven't gotten that deep into the configuration yet.
*smacks forehead* Ah, I get it now. You're not encrypting the response with the server's private key (to prove it came from the correct server), you're encrypting it with the client's public key (so only the correct client can understand it). You're doing two-way asymmetric encryption. That makes sense now.
As for the multiple clients, I get that now too - you're using the device client ID to represent the user identity, and the PIN for verification. That makes sense, and having multiple device clients on one computer allows for multiple users - one device, many users. I also have plurality in the other direction - many devices, one user - as I plan to have a client configured for me on my home computer, my work computer, et cetera. (If the J2ME client gets opensourced, then I may just put it on my cell phone and be done with it.) I assume there are ways to tie multiple devices to a single user account on the target system; I haven't gotten that deep into the configuration yet.
Re: "Strong Authentication for the masses"
Well, we certainly can be better about explaining things and sometimes I can type faster than I think ("the PIN is encrypted with the one-time AES key" instead of "together with the one-time AES key").
Open sourcing the J2ME client will be tough. We tested RSA and ECC packages to see how long key generation took on a J2ME cell phone. The numbers looked to be about 14 days for RSA and 14 hours for ECC. With the Ntru packages, it isn't even noticeable.
Open sourcing the J2ME client will be tough. We tested RSA and ECC packages to see how long key generation took on a J2ME cell phone. The numbers looked to be about 14 days for RSA and 14 hours for ECC. With the Ntru packages, it isn't even noticeable.
Re: "Strong Authentication for the masses"
Hm. Good point about the computational, er, limitations of J2ME devices. One approach might be to offload that task to a standard computer. Use a PC program as a builder/packager to generate the keys, wrap them up with the J2ME client, and make that a package to install on the device. It's an off-the-cuff suggestion, but the key generation only happens once, so there may be a way to offload that processing time (given a trusted network).
Re: "Strong Authentication for the masses"
Posted by
Michael Peters
at
Sep 14, 2005 09:34 PM
If someone copies the WiKID and the PIN from a system, isn’t the entire logon compromised?
You couldn’t really use this for banking could you?
Re: "Strong Authentication for the masses"
If someone has the PIN and the private key, then they have both factors, the equivalent of having the ATM card and the ATM PIN.
Re: "Strong Authentication for the masses"
Posted by
Michael Peters
at
Sep 15, 2005 08:19 PM
What would I suggest? Well, for starters I would suggest we use a technology that can’t be readily exploited.
It is really not like getting my ATM card at all – far from it. Spyware regularly gets into the PCs of most users. If it isn’t some form of adware it’s a key logger. It isn’t a huge leap to steal the WiKID certificates as well. This ability to have your Wiki stolen and not know about it is indeed troubling.
There are a number of assertions you have made on your web site and in the above reply that are flat out not true. Lot’s of applications that use hardware tokens implemented over the Internet that are absolutely immune to MITM and sniffers. Companies like Cisco, Microsoft, Citibank, and many more do so.
The other assertion is the cost, which you have categorized as high - a highly imprecise term. Simple math could prove that it is lower than software tokens. Assuming that a hardware token is between US$20 - US$60, and that a corresponding software WiKID token is only US$1 (using numbers that maximize WiKID cost per unit) a deployment of 10,000 units would cost as much as US$600,000.
Since the potential for a stolen hardware token being used to exploit an account is very small, and the reverse being true for a software token, we must factor the potential exploit risk. Of 10,000 accounts, with an average of $1,000 (or $10M), times some none zero risk, meets a breakeven point at 6%.
That is to say, if 6% of WiKID accounts are exploited, you are at exactly breakeven mathematically, using best possible numbers. Using numbers less favorable to WiKID, breakeven could be at 2%. That is very risky.
WiKID may have application somewhere but I couldn’t recommend it to a Microsoft or anyone of my companies.
Finally, just so that no one feels that I have deflected any of your comments, separate accounts for sessions and transactions don’t help since for spyware, two accounts are as easy to steal as one.
It is really not like getting my ATM card at all – far from it. Spyware regularly gets into the PCs of most users. If it isn’t some form of adware it’s a key logger. It isn’t a huge leap to steal the WiKID certificates as well. This ability to have your Wiki stolen and not know about it is indeed troubling.
There are a number of assertions you have made on your web site and in the above reply that are flat out not true. Lot’s of applications that use hardware tokens implemented over the Internet that are absolutely immune to MITM and sniffers. Companies like Cisco, Microsoft, Citibank, and many more do so.
The other assertion is the cost, which you have categorized as high - a highly imprecise term. Simple math could prove that it is lower than software tokens. Assuming that a hardware token is between US$20 - US$60, and that a corresponding software WiKID token is only US$1 (using numbers that maximize WiKID cost per unit) a deployment of 10,000 units would cost as much as US$600,000.
Since the potential for a stolen hardware token being used to exploit an account is very small, and the reverse being true for a software token, we must factor the potential exploit risk. Of 10,000 accounts, with an average of $1,000 (or $10M), times some none zero risk, meets a breakeven point at 6%.
That is to say, if 6% of WiKID accounts are exploited, you are at exactly breakeven mathematically, using best possible numbers. Using numbers less favorable to WiKID, breakeven could be at 2%. That is very risky.
WiKID may have application somewhere but I couldn’t recommend it to a Microsoft or anyone of my companies.
Finally, just so that no one feels that I have deflected any of your comments, separate accounts for sessions and transactions don’t help since for spyware, two accounts are as easy to steal as one.
Re: "Strong Authentication for the masses"
If you are concerned about a compromised PC, just use the wireless client.
I agree that certain applications are not susceptible to MITM attacks - even without hardware tokens, but ones that rely on a user validating the SSL certificate are indeed susceptible to those attacks. I think you are missing the attack here. A real-time MITM phish where using a OTP does not help. The only way to stop it is by mutual authentication, which a hardware token cannot do.
As for our assertions regarding the cost of hardware token, I stand by them. The numbers we have used for items such as the cost of token distribution are from sources such as Gartner. We can always be less expensive than any type of hardware token.
We are not trying to sell snake oil here. I know that WiKID can be attacked, but we stack up very well against hardware tokens, particularly for consumer-oriented https-type applications.
I agree that certain applications are not susceptible to MITM attacks - even without hardware tokens, but ones that rely on a user validating the SSL certificate are indeed susceptible to those attacks. I think you are missing the attack here. A real-time MITM phish where using a OTP does not help. The only way to stop it is by mutual authentication, which a hardware token cannot do.
As for our assertions regarding the cost of hardware token, I stand by them. The numbers we have used for items such as the cost of token distribution are from sources such as Gartner. We can always be less expensive than any type of hardware token.
We are not trying to sell snake oil here. I know that WiKID can be attacked, but we stack up very well against hardware tokens, particularly for consumer-oriented https-type applications.
Re: "Strong Authentication for the masses"
Posted by
Michael Peters
at
Sep 16, 2005 10:01 PM
Your answers were a bit too dismissive.
For starters, I can use my PC with a hardware token, thank you very much. It just doesn't much help your sale by sending me off with the comments "if you are concerned about a compromised PC, just use the wireless client."
My sole goal is to understand the value-added of WiKID. I am not sure it is worth continuing this discussion on this blog, so I will not try again, except to note this one last final set of comments. I am only voicing the opinions that I am sure others have when they read your web site.
I was using Gartner's numbers on the cost of a hardware token. This is a business I know a lot about and it would be extremely helpful if we quoted data and not terms like high, low, secure, and what not. Specificity is what I want.
We should at least be able to agree that the cost of deployment of hardware or software tokens include the cost of FTE's (full time Engineers), planning, server hardware, deployment costs (emails, announcements, distribution), support costs, replacement costs, and of course, for hardware, the cost of the tokens themselves.
There isn't a substantial case to be made that costs are lower for deployment except for the cost of the fobs themselves. Everything else is about the same cost. We'll also ignore completely the cost of installing the software token on a PC. This cost is not zero, but we'll just ignore it for now.
That leaves only the cost of the token as the differentiator. Gartner claims that the tokens themselves are between $25 and $45 each. Add all of the other deployment costs and the cost of a toke, hardware or software is more like $125 each.
We can do some math here, but at 10,000 tokens, the hardware totals at $450k, support and IT costs consume the remaining $800k.
With software tokens, 10,000 licenses may be $1 each, with support and IT costs adding up to $800k (if we agree that these costs are the same).
The difference is $450k, or $45 per token. In my earlier posting I quoted a figure even more favorable to WiKID at $60 per hardware token.
Using the same logic as the previous post, break even is at 4.5% (or at 6% if you use my previous numbers).
If you have a different set of numbers, I certainly would like to read about it.
For starters, I can use my PC with a hardware token, thank you very much. It just doesn't much help your sale by sending me off with the comments "if you are concerned about a compromised PC, just use the wireless client."
My sole goal is to understand the value-added of WiKID. I am not sure it is worth continuing this discussion on this blog, so I will not try again, except to note this one last final set of comments. I am only voicing the opinions that I am sure others have when they read your web site.
I was using Gartner's numbers on the cost of a hardware token. This is a business I know a lot about and it would be extremely helpful if we quoted data and not terms like high, low, secure, and what not. Specificity is what I want.
We should at least be able to agree that the cost of deployment of hardware or software tokens include the cost of FTE's (full time Engineers), planning, server hardware, deployment costs (emails, announcements, distribution), support costs, replacement costs, and of course, for hardware, the cost of the tokens themselves.
There isn't a substantial case to be made that costs are lower for deployment except for the cost of the fobs themselves. Everything else is about the same cost. We'll also ignore completely the cost of installing the software token on a PC. This cost is not zero, but we'll just ignore it for now.
That leaves only the cost of the token as the differentiator. Gartner claims that the tokens themselves are between $25 and $45 each. Add all of the other deployment costs and the cost of a toke, hardware or software is more like $125 each.
We can do some math here, but at 10,000 tokens, the hardware totals at $450k, support and IT costs consume the remaining $800k.
With software tokens, 10,000 licenses may be $1 each, with support and IT costs adding up to $800k (if we agree that these costs are the same).
The difference is $450k, or $45 per token. In my earlier posting I quoted a figure even more favorable to WiKID at $60 per hardware token.
Using the same logic as the previous post, break even is at 4.5% (or at 6% if you use my previous numbers).
If you have a different set of numbers, I certainly would like to read about it.
Re: "Strong Authentication for the masses"
Please don't take my excitement for our product as a dismissive attitude. Far from it, I appreciate your feedback and your continued debate. If you would like to take it offline, I'm more than happy to continue.
I think we disagree on two points. First, I think that the cost of shipping 10,000 hardware tokens is higher than the cost of distributing software. Gartner assigns a $15 cost of token distribution for hardware tokens in scale, as I mentioned. I agree that there will be a cost for distributing software, but it will not be anywhere close to $15 per user. So we do not agree that the support and IT costs are the same.
I'll give you my take on WiKID's numbers. If you take 10,000 users again, the price of WiKID is $16 per year. We offer a prepayment discount though of 10% per year, so if you pay for three years, the upfront cost is $33.60 or $336,000. Since we can automate the entire process of rolling out the WiKID tokens, I would estimate about $50,000 for IT and support costs. Let's call it $400,000 or $40 per person versus the $125 per person you quote.
Further, our costs will drop with scale. The cost of mailing a token will not, so we can be much cheaper as volumes increase - which will be the case for online banking.
More on WiKID
The WiKID thread continues at Thinking WiKID Thoughts, the blog of the CEO of WiKID systems. Awesome stuff....
2005/09/15
Tell us what you want - poll or comments
A key strength of WiKID is it's ability to handle multiple domains across multiple servers. We can guess at some of the key apps that people will want to have two-factor authentication, but it's better to just ask.
We have set up a short, one-question poll on the open-source website with generic applications listed such as webmail, vnc and ssh. Take a second to let us know what you think the top three are.
If you really want to get specific, you can make a request or suggestion in the comments. Even better, if you want to help WiKID-enable an application, let me know via sourceforge We're very pleased with the developer additions we've had so far, but the more the merrier.
We have set up a short, one-question poll on the open-source website with generic applications listed such as webmail, vnc and ssh. Take a second to let us know what you think the top three are.
If you really want to get specific, you can make a request or suggestion in the comments. Even better, if you want to help WiKID-enable an application, let me know via sourceforge We're very pleased with the developer additions we've had so far, but the more the merrier.
- Category(s)
- WiKID
- Two Factor Authentication
2005/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.wikidsystems.net/WiKIDBlog/69/tbping
2005/11/18
Oracle buys Thor
Oracle bought Thor, which I thought was very interesting. As Pete Lindstrom pointed out, it was a busy week for security-related acquisitions. This post at Digital ID World (hat tip to Venture Chronicles sums up my thoughts. I wonder if Oracle will go after RSA? I have my doubts. Oracle is just really going after Sun, IBM, etc.
it's clear to me that strong authentication and identity management solutions need not be purchased from the same vendor. The fact that RSA competes against Tivoli, CA, HP, Sun, etc just gives me more potential friends. I would think that those vendors chafe when one of their customer uses SecurID with their product, since they know that the profits from SecurID go into ClearTrust.
it's clear to me that strong authentication and identity management solutions need not be purchased from the same vendor. The fact that RSA competes against Tivoli, CA, HP, Sun, etc just gives me more potential friends. I would think that those vendors chafe when one of their customer uses SecurID with their product, since they know that the profits from SecurID go into ClearTrust.
- Category(s)
- WiKID
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.wikidsystems.net/WiKIDBlog/79/tbping
Digg this!
Del.ico.us
Google
Yahoo bookmarks
Reddit
Spurl
Simpy
