Why I started OneID
By Steve Kirsch
In early 2011 my sister, Leigh Harris, called me in a panic. “Someone broke into my Yahoo account and is sending out spam. What should I do?” she asked. “Relax,” I said. “They probably just got your password from another website you log into. Just change your password and you’ll be fine.” She replied, “But I don’t use that password on any other site!” I said, “OK, then run a malware checker.” She said, “OK, if I run a malware checker and change my password, how do I know if it is safe to log into my bank or PayPal?” I thought about that for a few seconds and I said, “Well, you don’t.”
When I said that I realized that that was a terrible admission to have to make to my sister in 2011. Usernames and passwords have been around for 50 years but we still don’t have a good way to provide basic authentication services to consumers in a way that is convenient and secure! And users are up to their eyeballs in usernames and passwords. I have over 400 of them myself. That’s crazy. Everyone I know hates usernames and passwords. A recent study pointed out that 38% of us would rather clean a toilet than think of a new password. There is a great five minute comedy routine on YouTube showing how ridiculous the current username and password system is.
Passwords are no longer safe in today's world either, e.g., see this recent article which explains "Why passwords have never been weaker—and crackers have never been stronger." Or this article, "New 25 GPU Monster Devours Passwords In Seconds," which points out, "Gosney’s system elevates password cracking to the next level, and effectively renders even the strongest passwords protected with weaker encryption algorithms, like Microsoft’s LM and NTLM, obsolete."
The bottom line is this: the current identity system is broken. It has been broken for a very long time.
The search for a solution
There were no solutions around. And there was nothing on the horizon coming that would solve the problem either. Instead I found that people were still trying to apply band-aids to a fundamentally flawed system... like 2-factor tokens or Phone Factor type solutions. Those things just make it even more inconvenient for users. They add friction. Everyone I know hates those RSA tokens.
We have the technology. Asymmetric cryptography was invented 36 years ago. But as recently as 2011 (before OneID), there was not a single consumer website where you could login without using a shared secret. Not one! Now that is very impressive. In 36 years, nobody had figured out how to make public key crypto user-friendly enough for consumers to use.
Without a solution to the identity problem, we will keep having break-ins where millions of accounts are compromised, never ending malware, keylogging, and phishing attacks, and we will be doomed to have more and more usernames and passwords every year. It's an endless cycle and it keeps getting worse every year. And that's where we are today.
We need a way out!
But none of the existing solution categories provide a way out. If any of them worked, the number of breaches would be going down, I wouldn't be adding more and more usernames and passwords every day, and CIO's wouldn't be listing identity management as their biggest headache.
Password managers aren’t the answer. They just make it easier for the whole system to keep working. And they don’t work very well on iPads, iPhone, and with mobile apps. If there is malware on your computer, all your passwords are compromised instantly. That means going to 400 different websites to change your password. Horrible. I use RoboForm and it often will not pop up on a site, not work (like on Virgin America), or simply fill in the wrong information. And your account information on their servers is secured with a very low entropy secret (your "password") rather than something with lots of entropy (like what OneID uses). So if their servers are broken into, the reality is your identity is toast. If our servers get broken into, you have nothing to fear. The fundamental difference is that we have created and maintain several high entropy secrets (256 random bits) on your computer and only on your computer. What they have is a data that is encrypted with some variant of your low entropy password which is, for most people, equivalent to around 20 bits or so. The computational security of 20 bits vs. 256 bits is enormous (it is not linear). And then even if they decrypted your stuff in our repository (by cracking a 128 bit symmetric key), they still would lack the ability to do a high value transaction (which requires cracking two independent 256 bit ECC private keys). And even if they compromised everything in your OneID, you can easily shut them off...and you don't even have to change your password or PIN...just disable their device. And with OneID there is no risk that a site gets broken into exposing your password. So comparing OneID with a password manager is like....well it isn't even close.
Social logins like Facebook Connect aren’t the answer. They aren’t secure. They aren’t private. By Facebook's own admission, 600,000 facebook identities are compromised every day. Anyone at facebook who has the right access to the right systems can modify their code to pose as me. It's all security by operational policy. It only works if everyone is honest and nobody ever makes a mistake (remember the breach at Dropbox where you could download anyone's files?). With social logins, a breach at another site can reveal the password you use on facebook (a good portion of their breaches are due to this). And using a social identity get you into big trouble because the sites (the relying parties) typically require more than just your identity when they ask use to use a social identity to log in. For example, I logged into Quora with my facebook account and I found that my account was set up to follow every single one of my facebook friends. I never agreed to that.
Google isn't the answer. Google just another identity provider just like everyone else using the same old technologies. They can get broken into just like everyone else. A friend of mine had his password breached when Stratfor was broken into; they then used his password to compromise his Google account. My password at Google is a shared secret. Google knows it and I know it. The right people who work at Google can assume my identity. Google's idea of two-factor is just a software version of RSA SecurID, vulnerable to MITM and MITB attacks. Their second factor uses a shared secret too. Break into Google and you can pose as me. Google knows everything about me. So Google is not easy, not secure, not private, and I'm not in control. What's to like about that? Nothing! In general, any centralized IdP (which is pretty much everyone) can be compromised and then assert anyone's identity. Or their password database (or someone else's database) is breached and all hell breaks loose.
Federation (SAML, OpenID) isn't the answer. This is just protocols to re-use your already insecure identity. And it magnifies the risk. You start with an easy to breach identity and now you make it more attractive to attackers because it can now be used in more places. And SAML 2 is really hard to use and configure and there are vast areas which are completely undefined and left as an exercise for the reader.
BrowserID/Persona isn't the answer. Again, they use a shared secret to log into their system; you type in your password and it is sent right up to their servers in the SSL packet and appears at the other end exactly as you typed it. Get that and you are me. So you can do everything right and your identity can be compromised by systems outside of your control. Not good. Sure, they log into relying parties using asymmetric crypto; that's good. But the underlying authentication method is a shared secret.
Biometrics? Nope. Those are worse than shared secrets. Biometrics are shared un-secrets... anything you give one entity, once compromised, can be used at all other entities for the rest of your life. There is no way to change your biometrics! So biometrics are like a lousy password that you are forced to use everywhere and can never change. Secure authentication is all about secrets...NIST has said very clearly (in 800-63-1 for example) that "biometrics do not constitute acceptable secrets for e-authentication." Biometrics are OK to unlock tokens (in this case they are used locally), but remote biometrics (i.e., when the relying party doesn't directly and absolutely control the biometric reader) shouldn't be used for authentication because biometrics are commonly known and easy to "insert" into a remote biometric reader.
2 factor tokens (eg., RSA SecurID or soft tokens)? Nope. They do absolutely nothing to eliminate usernames and passwords which is the primary problem. The FFIEC says they aren't safe because they are almost always in-band (i.e., on the same device as the transaction). That's important. And in-band token is easily compromised by malware. For example, you type your username, your password, your token value into a Google login screen. But it wasn't really Google...it was an evildoer's website meant to look like Google. Or it was Google, but there was malware in the browser which intercepted the three pieces you just typed. Or there is malware that is keylogging everything. In any of these cases, the attacker only had to compromise ONE of your devices. And now that attacker has EVERYTHING he needs to log in as you: your username, your password, and your token. You are now hosed.
Secondly, hardware tokens are all shared secret based. You know that because anytime you type in a short code like that, it's guaranteed to be based upon a shared secret. There are two tip offs here that shared secrets are being used: 1) the code is shorter than 64 characters, and 2) the code was generated without knowledge of the transaction details. By contrast, OneID's asymmetric signatures are 512 bits long and they must always have an "input" that is also very high entropy that is being signed. OneID computes, on each device that signs, a SHA-256 hash of the original request and nonce, and then signs that hash. With a token, if you breach that shared secret repository (i.e., the server that does the verification of the short code), you can impersonate any user. RSA demonstrated how flawed every hardware (and software) token system is when their SecurID system was breached in April 2011. We knew it was going to happen sooner or later. Anytime you have a system that uses shared secrets for security, it is a ticking time bomb. Of course, RSA would never tell you that. But it's true.
Sure, you can argue that hardware tokens are better than nothing because they add another layer, but they decrease usability for a marginal increase in security and people hate them. The CISO of a large bank told me a story of one of his customers who came up to him after a talk and reached into his pocket and pulled out his SecurID and told the CISO, "You gotta get rid of this thing." OneID is the better way: it is much easier to use and adds a lot more security.
Two-factor add-ons like PhoneFactor or Authentify that are either voice based, SMS based, or app based isn't the solution either. There are three ways to compromise those solutions: phone number porting (which can defeat both voice and SMS authentication techniques), SMS intercept (such as Eurograbber), and app spoofing/cloning of the security app itself. They are provisioned with a shared secret. And they are managed by the financial institution, not the user. So if the user loses a device, the user himself now lacks the credentials to prove it is really him to disable the device.
X.509 and/or PKI? No. This has been out for over 20 years. There are no consumer websites where you can login with an X.509 certificate. And PKI isn't end-to-end secure. DigiNotar was a recent example of that.
The point is this. Shared secrets are unsafe. You shouldn't use them. Period. But people still use them because the security companies push it because nobody can figure out how to make public key cryptography user-friendly.
I was so frustrated! Why can't we just have one secure identity that we can use anywhere? Why can't someone solve this problem the right way... put those old fashioned shared secret paradigms aside which have proven not to work and come up with a new, better way that fixes all the problems with identity today that is based on public key cryptography a.k.a. asymmetric cryptography?
If you want something done right, sometimes you just have to invent it yourself!
I looked around and nobody was doing anything that looked like it would solve these problems. Everyone was doing the same things over and over again expecting a different result. That is why we constantly read of break-ins. Because we are fundamentally not doing anything to solve the core problems, the biggest one being the use of shared secrets.
I’m a pretty clever guy and I’m always up for a challenge. I've started 6 companies worth over 2 billion dollars in aggregate and I've invented technology that is used by over 300 million people. And like everyone else, I hate usernames and passwords.
So in early 2011, I started thinking about how to solve the problem of digital identity. I enlisted the help of experts such as Adam Back, Karsten Nohl, Stefan Brands, Jim Fenton, and Jon Callas to teach me cryptography and conventional approaches to the problem. I vowed not to duplicate any conventional solution since those were proven not to work. It had to be new, it had to be really clever, and it had to have an architecture that would absolutely guarantee that security and privacy couldn't be breached. It had to put the secrets to my identity in my exclusive control so that if someone messed up or there was a break-in, my identity would remain intact. And we had to make it so secure that Karsten couldn't break into my account no matter how hard he tried (Karsten is really good at breaking into things that nobody else can break like how he broke the security on Mifare cards).
And it would have to be really simple. As Adam Back taught me, complexity is the enemy of security. The more complex a system is, the harder it is to implement and the harder it is to prove it is secure. Simplicity and elegance were the way to go.
After about 23 different designs, I finally came up with a core design that was simple and elegant that I thought would work. Then Adam took over and fleshed out the specific crypto techniques we use. It is described in this 8 minute video, "OneID Technical Overview" and it is fully documented in a 20 page document that was co-authored by Jim Fenton and Adam Back. The protocols don't need to be secret. The security of the system is based on the security of the NSA Suite B cryptography (ECDSA, AES, and the P-256 curve specified by the NSA), not the secrecy of the algorithms. The only reason we don't publish it now is simply for competitive reasons.
Requirements of a proper solution
It was pretty clear that public key cryptography and device centricity had to be at the core of any credible solution. You had to make it as user friendly as signing up for a Facebook account. And you had to make it more secure than anything out there. Account recovery had to be completely hack proof, yet still very easy to use for the legitimate owner. And you had to do all of that, and more, without a download so you could run on all browsers including mobile phone browsers.
It was clear to me that there were about 22 core requirements of a trustable third-party cloud identity provider and we had to meet all of them.
Those were the basic ideas... here are the details:
Shared secrets (shared secrets are secrets that you share with a third party such as a password) are really bad. They are at the root of most security breaches. The design I came up with involved eliminating all use of shared secrets and replaced them all with zero-knowledge proofs using advanced elliptic curve cryptography digital signatures (using ECDSA) for all digital proofs, and splitting people’s identity into three different pieces kept in three distinct places. To prove you were allowed to log into a website, you would have to sign a crypto challenge (known as a "nonce") generated by the website using at least two independent asymmetric secrets in two different places, one of which had to be completely out of your control (the OneID cloud repository). For high value transactions, you'd need three independent secrets stored in three different places. That meant that there had to be two distinct classes of user devices: one class that would share one signature key and a second class that would share a second signature key. The repository would have the third signature key and it would always be required that the OneID repository sign the transaction. The repository signature would also only be able to be done if the user's devices provided a decryption keys for the repository's signature key, and if the repository has verified that all the requirements of the user and the relying party (RP) were satisfied including verifying the ECDSA signature from private keys unique to each device (so the repo will not sign if a device is stolen).
The system had to be end-to-end secure for every operation. End-to-end security means the transaction is digitally signed by the first computer the user touches and then directly verified by the service provider (aka "the relying party" (RP)). This means a 256 hash of the transaction must be independently computed by each signing device based on the original transaction parameters that are displayed to the user on that signing device (e.g., "Wire $500 from my account #3342 to Mom's account # 12356 at Wells Fargo ABA 234-454-233"). The 512 bit ECDSA signatures from each authorizing device are verified by the relying party (RP) against the public keys on file for that user, and the RP must also verify that the hash is correct as well, before it executes the transaction. What makes it end to end secure is that the security relationship is direct between the RP and respectively the OneID repo, user's Remote, and the user's device. There is no "certificate authority (CA)." Use of a CA (such as an X.509 cert) would violate end-to-end security.
Each authentication or authorization would require multiple, independent signatures. this is because any single device can be compromised. Highly secure transactions would require more signatures (just like a million dollar check requires the CEO and CFO to sign).
The minimum level of assurance for any device login, website login, or transaction could be settable by either the user or the RP. Therefore, the entity with the stronger security requirements would always win. There would be at least five basic levels to choose from. RPs would be able to set both the PIN and password timeouts to any value on a per transaction basis to minimize user burden. Therefore, a $10,000 transaction might require a PIN code to be entered within the last 15 seconds, but a $100 transaction might only require that the PIN code was entered within the last 30 minutes.
The identity would have to last a lifetime without changes to the public keys on file at an RP site, no matter what happens. I have 400 websites alone with my account. Once I've put my public keys on that site, they should be usable for life no matter what happens to my devices. So OneID had to be an identity system that is secure enough and flexible enough to last a lifetime. There are three reasons for this. First, there isn't a secure way to tell the site my public keys have changed. I can't use my OneID to do that because it would be assumed that the OneID would have been compromised. Secondly, the protocols to replace a public key add complexity to the protocols. Complexity is the enemy of security. And thirdly, there is simply no way I'm going to go to 400 different websites and try to manually convince them that it is truly me and that they should replace the public keys on file. So OneID had to be an identity that would be hard to compromise, and also still be very easy for only the legitimate owner to "get back" his identity even in the very worst possible scenario (where the attacker learns all the secrets from all the user's devices and also his PIN and password and then changes the user's PIN and password to lock the user out). OneID has a clever patent-pending technique for this "worst case" scenario.
Passwords would be optional and if you did define a password, you should be able to pick anything you wanted (no password standards!) and never be forced to change it, even if your account was compromised. For example, I chose not to define a password and I have no username. So I just told you my password (empty) and even though you know that, you can't break into my account! Passwords are useful if you have a device that typically others have physical access to, e.g., a PC at work, a shared home computer, and you want to restrict those people from logging in as you and you don't want to use the OneID Remote in PIN or PIN less modes.
If I chose a password like "x" it wouldn't help you either. Go ahead. Try to login at OneID now that you know that I have no username and my password is "x." Good luck!
And that's the point. It's completely fruitless for an attacker, even if he knows all your "secrets." So attackers will simply go for places that are insecure and where there is money...like your bank.
Cracking someone's OneID is really hard. Smart attackers will go after sites with high value assets that use usernames and passwords because they are easier to crack. It will be a long time, if ever, before attackers target OneID. The smart ones won't try.
There should never be any knowledge-based authentication questions. Everyone hates these. They are always so lame. They are either too easy for people to research, or too obscure to remember how you answered the question at that time.
We would not use SMS for a few reasons. First, even the telco’s themselves admit SMS is not secure for financial transactions. That's not just a theory. See New Trojan Exploits Mobile Channel as well as How a botnet has stolen 36 million Euro from European bank customers which details attacks that have stolen $50M so far from 30,000 bank accounts which were protected by SMS 2-factor authentication.
SMS is basically vulnerable to two things: number portability and SMS_READ permission. Telcos don't require a high level of authentication to port a phone number because the telcos aren't in the security business. They want to satisfy their customers (the consumer). So they won't put in extra steps because it will inconvenience legitimate requests. The second vulnerability is there is a legitimate need for some apps to access SMS messages. So there is an SMS_READ permission that must exist. Malware, in the guise of a security update, can ask the user to get this permission, either because the user doesn't notice or the user just assumes it needs it.
As Martin Kuppinger points out, "There is no simple solution to prevent such type of attack." We agree. That's why OneID doesn't rely on SMS.
In fact, OneID is immune to all five known 2-factor compromise techniques: phone number porting (which can defeat both voice and SMS authentication techniques), SMS intercept (such as Eurograbber), MITM/MITB, and app spoofing/cloning of the security app itself.
Secondly, SMS is really a horrible user experience. Having to transcribe auth codes is just like RSA SecurID... a really annoying user experience.
And finally, SMS is and never ever will be, end-to-end secure. For end-to-end security, you need an asymmetric digital signature from the user's device and to hash the transaction the same way at the RP as at the signing device. Otherwise, you have no digital proof that the user approved the transaction.
We would not rely on PKI because it is not secure because it relies on a third party (as DigiNotar proved once again) which gets in the way of end-to-end security. Adam Back, who is one of our security consultants, hates anything that is not end-to-end secure. He worked with us to make sure that there was no single point of compromise and that everything was end-to-end secure.
We would support 2-factor both within the same device (which is vulnerable to malware) and across different device (out of band two factor which is not vulnerable to MITM, MITB). OneID supports 1) out-of-band two factor, and 2) display and signing of the transaction on the second device. Both of these combine to give our users the strongest security available. Out-of-band is good, because it means that the attacker can't just compromise a single device. He has to either 1) fool you into confirming the transaction on a second device or 2) compromise your other device too. The second thing we do is an independent display of the full transaction and then a full digital signature of the transaction (where the SHA-256 hash that is signed is independently computed from the description of the transaction rather than just blindly signing the hash that was handed to it). So to fool OneID, an attacker MUST fully compromise your second device as well if he hopes to get his transaction approved. This is much stronger security than any token system. And OneID is easier to use because there is no typing of 6 digit codes. At worse, you type a 4 digit PIN that you already know.
It would be an identity system where even if malware were to clone your identity secrets from a device, that it wouldn't be usable from another device. We can safely assume that PC and Macs can be easily broken into with malware that specifically targets OneID and breaks into the HTML Local 5 storage where we keep some of the secrets. So there had to be at least 3 independent ways to detect when that happened (such as sync variables and independent device fingerprinting methods) and shut off a cloned device without user involvement.
If all the cypto secrets of any cloned device became known, it had to be completely unusable for an attacker. We accomplished that by requiring at least two signatures, where one of the signatures had to be from the OneID repository.
The system has to be immune to attacks such as the cloned app attack. In that case, thieves put malware on your browser, ask for you cell phone number, and then send you a link to install a rogue OneID app that is virtually identical to the real OneID app in that any external tests cannot tell the difference. We have a patent-pending solution to this attack (which you'll have to ask me about directly...it doesn't rely on any secrecy of the technique... but we aren't ready to tell the world yet). So the OneID mobile app is way more secure than any two-factor solution's mobile app such as Authentify or PhoneFactor.
If you lose a device, you should be able to disable it from any of your other devices.
Account recovery (which for OneID is only needed in the case you lose all of your mobile devices) would be easy and secure and immune to gaming the call center operator because nobody at OneID can ever send you a link to reset your password. If you lose all of your devices, you need to get the high entropy secret we sent you and you'll also need to know a PIN code too (and you only get 5 guesses a day for that; no offline attacks will work). So a Mat Honan attack can never happen with OneID. It's not because we set a call center policy to avoid it. It's because the fundamental architecture of the system guarantees it. As Adam is fond of saying, "The most trustworthy system is one where its design is such that you don’t need to trust it.”
Account recovery is often the Achilles Heel of identity systems. So we had to get this right. One trick you should be aware of is this: you absolutely know you are dealing with an insecure system if the identity provider can send you a password reset link via email...think about it...if they can send it to you, they can send it to themselves! And every site who relays that email reset message (about 20 different sites on average) can read your reset link. But I'll bet you can't name a single website/identity provider that can pass that simple test of not allowing you to reset your password! Not Google, not PayPal, not Apple, not Facebook. They will all happily send you an email to reset your password (or allow you to reset from the web). The only ones I know who are anywhere close to secure as OneID when it comes to account recovery are the whole disk encryption products where they tell you to print this number and put it in a secure place. But OneID is more secure than even those products because not only do you need that high entropy secret, you also need to supply something you know. So we are two-factor for account recovery. Vendors like RoboForm, LastPass, and Dashlane are in a very distant second place because the secrets to unlock your information is really low-entropy: your password. OneID never uses your password for any kind of encryption, and when your password is used for authentication, it is combined with a local salt (found only on your devices and not known to our servers) and then used as a signing key using ECDSA.
If you choose to define a password (or the relying party requires one), your account is instantly two-factor even if you don't own (or use) a smart phone! OneID inherently always uses devices secrets (something you have), so if you define a password, you are adding a second factor (something you know). So with a single device that you already have, OneID is already two-factor. If you add on our mobile app, our two factor is even better because: 1) it's an independent device, and 2) the transaction is shown on the second device so it's immune to a MITM, MITB attack on a single device.
PINs and passwords are always combined with local salts and used as a signing key on the nonce so there is never any chance that OneID will be able to learn or compute your PIN or password, no matter how short it is! So even if an attacker knew your PIN or password is just one character, someone who breaks into OneID would never be able to learn it or brute force compute it.
There would be no single point of compromise so even if a hacker broke into OneID he wouldn’t be able to assume your identity. It would be virtually impossible (you'd need billions of computers running decryption for decades) for anyone working at OneID to find out your name or where you were logging into (unless you allowed us to do that).
It would allow users to digitally sign digital invoices so that it would be possible to do end-to-end secure transactions where one endpoint is the consumer's ECDSA signature on the consumer’s own device which signed the purchase invoice, and at the other end is the financial institution that issued the card which verified the digital signature.
You would be able to pass the digital signing keys between your devices in a secure manner (we call this pairing) using a low entropy secret (a numeric pairing code a few digits long) using the cloud, but in a way that anyone monitoring the transmission wouldn't be able to decrypt it. We were pretty surprised to find out that nobody knew how to do this in a secure way. So we invented a really clever technique to do this and we filed a patent on it. It's one of our crown jewels to have a way to get this key piece right, because if you don't get it right, your whole security story is complete blown. We almost never talk about it (and only a few people know to ask), but it's one of the coolest protocols we invented. In most cases, users will use the QR code scanning method which shares a 128 bit AES symmetric key between the two devices using an out-of-band method (the QR code scan of one device by the other). That is obviously secure against eavesdropping by the OneID cloud.
Each device would also have a unique device key so if a device was stolen, the repository could refuse to sign any transactions from that device. So if someone stole a device, you simply disable it. Similarly, if someone learns your PIN or password, you simply disable the device they have. In both cases, you don't have to change your PIN or password.
It would be designed to recognize that people aren’t perfect and preserve your security even if you are fooled by a phish. For example, I don't have a username or password on my OneID account so it's just really hard for someone to phish my identity, even if I was completely fooled into revealing my information. There is simply nothing to phish!
It would be an identity system where you could “have it your way” so that it would satisfy the security and convenience needs of everyone from security geeks like my friend Jim Fenton and soccer moms and everyone in-between.
It would have to comply with the four NSTIC Guiding Principles: easy to use, secure, private, and interoperable.
Privacy had to be ensured in all directions where the parties only know what the user expressly wants them to know. Neither RPs nor OneID should be able to track you and your data had to be secure so only you can decrypt it. Non-trackability for RPs required us to use unique sets of public keys for each RP. This satisfies the need for unidirectional identity. OneID identifier are also opaque; they reveal nothing whatsoever about the user. OneID shouldn't be able to track you either. We ensured that all the data you sent to OneID was only decryptable at user endpoints. Because the user's device talks to directly to the RP, and OneID never talks to the RP, OneID would have no way to know what site(s) you've logged into. Futhermore, since all attributes are encrypted and decrypted exclusively on the user's local device(s), the OneID repository has no idea what is inside nor can OneID ever decrypt it. Whenever information is passed from the user's browser to their OneID Remote, it is encrypted with a crypto key that is shared between the user devices so even though the information passes through the OneID repository, OneID can't learn what is being done. The crypto keys are all generated on the user's devices and the transfer from device to device, although done via OneID, is done in such a way that OneID can't decrypt the communication (because the old and new device share a high entropy secret that OneID never sees).
OneID would have to have two classes of devices. This is because it's so easy to compromise desktop computers. So if there was only one class of device, an attacker than compromised your PC would have everything. So there has to be a second, independent set of secrets. In OneID, the OneID Remote mobile app uses a different signature key than is used with browsers on your dektop and laptop.
OneID would be designed so that if your identity is compromised, there would never be a need to change the public keys stored at any relying party. That is just too much of a hassle. OneID avoids this completely because even if all your devices are stolen, you can disable those devices so even thought the devices can be forced to sign, your repository will refuse to sign, so the attacker won't be able to log in anywhere.
OneID would have to be virtually attack proof. After all, what's the point of introducing a new identity system that is no more secure than the old one? We eliminated the need to have username or a password (passwords are optional). Phishing and keylogging attacks can't happen with OneID...there is simply nothing to phish or keylog. Malware attacks could compromise a device and act just like the user. So all really high value transactions should employ an out-of-band authorization involving two physical devices to be on the safe side.
Here's an example of how secure OneID is. I can give you all of these things:
and that will be insufficient for you to login to my bank or authorize a transaction greater than $15. I didn't give you my PIN code. It's only 4 digits, but we only allow 10 guesses a day (the guess requires the OneID repo to tell you whether you got it right so you can't do an off-line brute force attack), so it will take you on average about 5,000 guesses to get my password or about a year and a half. And every 10 consecutive bad guesses, i'm going to get an email about the bad guesses on that mobile phone you just stole from me. I will then disable that mobile phone and stolen laptop so you cannot guess any more on those devices. My other devices will be unaffected. So I didn't even have to change my password or PIN when my devices were stolen. I just disabled those devices. They are no useless for doing anything with my identity, even if you later learned my PIN code!
And finally, because I hate downloads (especially the ones like Java and RoboForm that ask you to download updates every week), I designed it so you wouldn’t have to download anything so it would work on any modern day browser. That also means you can use OneID on your mobile phone browser like Safari on your iPhone or iPad...finally!
I showed a prototype around to over 200 different companies. Everyone thought it was a brilliant solution to the problem. They said it was in a class by itself. Simple and elegant. Consumers I showed it to loved it. They couldn’t believe all the features it had and how easy it was to use; nothing to do but hit a button and remember a 4 digit PIN code which you can safely set to be the same as your ATM code since even if someone learned your ATM code, they can't log in as you.
Two of the largest credit card issuers in the world evaluated it and couldn't find any problems with the security. We asked one of them who they thought our competition was. They said, "You guys are in a class by yourselves." That's what I thought, but it was nice to have the third party validation.
The Global Cyber Security Center in Rome, Italy evaluated it and found it to be the most secure and innovative system that they have ever tested.
John Halamka, a highly respected healthcare CIO named OneID, "Cool Technology of the Week."
Avishi Ziv, a security and identity expert, said “OneID appears to have it. It appears to be built right ground-up to serve the cloud era, with the right underlying deep understanding of how these kinds of technologies should be implemented and deployed. This underlying understanding is pure innovation and is quite rare.”
The CSO of an early adopter bank told us, “Nothing interesting has happened in authentication in a decade; this is the first really intriguing approach that we’ve seen.” His bank is evaluating our system now.
Bob Pinheiro, Chair of the Consumer Identity Workgroup of Kantara, said “OneID seems to have a high potential to help solve the consumer authentication and identity theft problem in a usable way.”
TechCrunch called OneID "an all-out, world-changing infrastructure play." (TechCrunch, March 13, 2012).
Network World listed OneID as #1 of 7 "hot security companies to watch." (Network World, March 13, 2012).
My favorite quote was after a 3 hour presentation to a group of US government security experts. After the meeting, one of the experts pulled me aside and said, "You know we see a lot of presentations and hear a lot of BS, but if what you are saying is really true, this is exactly what the government needs."
OneID is a really big project that really changes the status quo. That's not so easy to do, but when you do it, the returns are huge. So I realized pretty quickly that I had to target VCs who like to take big swings. I wanted to get a couple of really smart, visionary investors who invest in game changing ideas. I pitched Vinod Khosla and he liked it. He likes really ground-breaking stuff like this. OneID is a perfect match to his investing style. Jonathan Heiliger, former VP Operations for Facebook loved it too. He had just joined Northbridge Ventures which prides itself as investing in "game changers." Perfect. So we split a $7M financing in April 2012 between the two VCs and we were off to the races.
OneID can be used anywhere identity is being used today. Here are some examples of what can be done with the technology behind OneID:
Rolling it out to sites
OneID went live to the world on November 1, 2012. Here's a 5 minute YouTube demo of OneID. Try it out. Let me know what you think.
As of December 2, 2012, there are over 100 web sites where you can use your OneID.
One of the largest financial institutions (a known technology leader, early adopter of new technology) selected OneID over all other competitors and will be rolling it out to all their customers.
Shopper's Choice, a top 350 site, deployed OneID within a few weeks of our launch and more in the Internet Top 200 will be launching soon.
It takes only 15 seconds to set up a OneID. If you later choose to define a password, or set up your mobile app, you can then do a two-factor login to any OneID enabled site (such as http://support.oneid.com which is OneID integrated into Zendesk).
Getting a new OneID account created (and provisioned on your computer) is faster and easier than signing up for a Facebook account! And there is no username or password to remember either.
If you want even more features, you can set up your mobile device and fill in your profile and define a PIN code on your OneID Remote app.
If you like passwords, you can define that too. No password standards... your password can be one character and your account is still unbreakable, even if someone learns your password (because they don't have your device).
Here are some reasons sites adopt us:
When we surveyed our user base, one of our biggest surprises was that the # 1 requested site that should implement OneID is Amazon. For example, I recently showed OneID to a randomly selected group of 10 Amazon users, none of whom had ever met me or heard of OneID before. Half the people said they didn't remember their Amazon login. After a 5 minute demo, 100% of them said they would love to use this on Amazon because it is so easy to use and there is no username or password to have to remember.
The significance of that is that I think a lot of sites think that users have no trouble logging into their site. The fact that username/passwords are a barrier even at a site as popular as Amazon suggests to me that every site with a username/password login can benefit tremendously from OneID and it should be very high on their priority list.
See OneID technology overview for information on the simple and elegant new architecture that OneID uses to keep your identity safe, secure, under your control, and private as well as a list of over 60 problems with the current identity system that OneID can solve and an 8 minute video that explains the OneID core authentication/authorization protocol.
Here's the 1 page simplified version of how OneID works.
The OneID vision:
A single, secure, permanent identity you can use for anything
Please help spread the word and together we can make that vision a reality.
If you'd like to add comments to
this page, or have questions, praise or suggestions, please contact me. My email
For more information, see the OneID documentation guide