ABSTRACT: My wife is always telling me how she hates
usernames and password. I concur. I have over 400 usernames and passwords.
Usernames and passwords are horrible for users: hard to remember, hard to
use, and insecure. I think I must spend at least 30 minutes a day on
identity issues like these. The current identity solutions aren't good for service providers either:
risk of mass breach, support costs, loss of traffic from users who can't get
past the login screen, and loss of sales due to friction from cart
abandonment and/or forgotten passwords.

That's why I created OneID: to provide a
better alternative to today's antiquated identity paradigms. OneID is
identity re-invented; the future of identity. It is the world's first
trustable third-party Identity as a Service (IaaS). A brand-new identity architecture that is easy to use,
private, and secure. A single user-centric permanent identity that you manage, it works
for consumer and enterprise applications, on-line, in-person, and
over-the-phone, it's
always in your control, on your devices, and it is way better than anything else on the market
today. You can get one in 15 seconds. It doesn't even require a download.

The problem

“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?”

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.”

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).

We determined was that the most important feature
was to create an identity provider that consumers and websites could trust.
Trust had to baked into the architecture and protocols. It couldn't be an
operational policy decision (e.g., we'll secure the code on this system so
nobody can modify it). All the code dealing with a user's identity had
to be out in the open and not behind a firewall like it is at everywhere
else.

OneID had to be the world's first trustable
consumer-provisioned federated identity, i.e., an identity that you can make
yourself and use on any website. Done right, that identity would be much
stronger (and easier to use) than an identity that was created by the
site itself. Think of it as a trustable Facebook Connect that adds security,
privacy, and ensures the identity is in control of the user and that ensures
that Facebook knows nothing about where the identity is being used or what
is in it and that no matter what code changes are made at Facebook, they
can't pose as me at a website. If we could achieve that, then we'd end
username / password proliferation because fundamentally the reason we have
so many usernames and passwords is because there is not a single trustable
consumer identity provider on the Internet today. OneID would change that.

I also wanted to
make sure it was compliant with the
NSTIC principles. I read the
NSTIC vision
document before starting OneID and it was similar to the vision document that I had written
for OneID.

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.

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.

“The most trustworthy system is one where its design is such
that you don’t need to trust it.”

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.

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:

my username (none)

my password (none)

complete root access to my laptop

complete root access to my cell phone including the
OneID app

complete access to my email

read access to every file at OneID including source
code and all data files

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!

Validation

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.

“OneID is the best approach to digital identity that I've seen.”

-- Jon Callas, cryptographer

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.

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.”

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."

Raising $7M

“I believe OneID will be one of the most significant platforms
to be built in the next 10 years”

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.

Applications

OneID can be used anywhere identity is being used today.
Here are some examples of what can be done with the technology behind OneID:

One-click login (instead of username/password) for
websites; allow you to use either.

For SSO portals and VPN, OneID can be an alternative to
username/password/token login (similar to how Facebook and Google buttons
are alternative ways to login to a website).

Digital claims (you can prove you own the email
address without having to send the user an email to confirm his email)

Two-factor login with or without an out-of-band device
(meet FFIEC requirements)

Mobile app login: no more usernames or passwords to
remember. Mobile app can also ask OneID to bill the user's credit card. This
means users don't have to re-enter credit card information into each
application and the credit card information is much safer.

In-person check-in into a hotel or rent a car: you tap
your OneID card on the merchant's reader, your phone prompts you to release
information requested, you click OK, and everything is done.

Over-the-phone authentication: you tell the person your
phone number (if they can't use callerid) and your OneID Remote app asks you
to approve release of the information (or charges) requested.

Couponing: OneID can pick up a coupon from Site A and
present it at Site B, e.g., a Hertz CDP code or an affiliate code.

Fraud information: we can tell you if the person has
been identity proofed and the likelihood they are a robot rather than a
human

Direct email offers: just click the offer in an email,
click OneID checkout, and buy the item without typing, even on a mobile
phone

Loyalty & purchase with one swipe: Swipe the OneID card
at checkout and be able to access loyalty information and billing
information about the user. The user can set a $ threshold on his phone if
he wants to pre-approve large purchases or purchases from new vendors.
Otherwise, the purchase goes through and the user is notified.

3D Secure: OneID integrated at an issuing bank can use
OneID to complete the bank verification instead of a username/password login
at the bank. This enables a bank to out-of-band 2-factor a 3D Secure
operation and is much safer than a standard username/password 3D Secure
authentication and also much easier for a user. OneID secure checkout can
also use 3D Secure transparently so that the user isn't even aware it is
happening. The merchant gets the 3D Secure benefits, the customer never knew
it happened. There is also a clever way to make the PAN of the credit card
unusable by anyone in the middle, effectively creating end-to-end security
without sharing any secrets.

POS card present transactions: Issuing bank can ask
OneID for approval on every single transaction or on transactions exceeding
a certain $ amount or cumulative $ amount (or for new vendors).

As part of a HIPPA compliant solution. OneID is great
because there is nothing that is more private and secure without sacrificing
user convenience. All user data is encrypted and OneID lacks the keys to
decrypt. Furthermore, OneID can't track what sites you've visited.

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:

Acquiring new users and new user registration is
simple, fast, and easy. If a OneID user comes to your site and hits the
login button, you can acquire all information required to create his account
with a single click including his name, email, and preferred credit card. Or
you can ask for his credit card later if you like. Again, a single click. If
the user doesn't have a OneID already, then he can create a new OneID
account without having to define a username or password. That is a huge
benefit that your users will love. Everyone hates filling out the forms and
everyone hates adding "yet another" username and password they must manage.
Your users will love you.

We reduce friction; we make it easy for the user to come back. Your
customer doesn't have to create a username or password. They can come back
and log in without having to remember or type anything. And they can come
back on any device they own. It's a lot easier to login with OneID than a
username and password.

We make it IMPOSSIBLE for any hacker to compromise
or expose your password file. If attackers break into your site, they
will never again be able to compromise your password file which results in
very bad PR and potential liability. The password file for OneID is just
public keys...useless to an attacker. Any site which uses shared secrets for
authentication is a ticking time-bomb... sooner or later your password file
will be breached.

We increase security without affecting usability. OneID is already two-factor security on a any device
(if the user chooses to define a password). If you require two-factor,
OneID provides that without requiring a second device. So OneID on a single
device is as secure as username + password + RSA SecurID...but without
having to carry a second device. If you require two-factor with two devices,
we can provide that too (the OneID Remote app on your phone). It is immune
to Eurograbber, and doesn't use SMS. OneID logins and transactions are more secure.
Security is a benefit for both the site and the users. The beauty of OneID
is that the security doesn't come at a usability cost. Using just a single
device, OneID is already two-factor authentication, and that's without the
user doing anything. No phishing, no keylogging, no chance of a mass
break-in. And the user or the site can increase that security (5 levels of
security to choose from). So the user and sites can enforce any minimum
security level they want. So if it is a large transaction, the site can
request an out-of-band PIN verification, for example.

We increase customer loyalty. Imagine two
stores... identical goods.. at a shopping mall. At Store #1, when you walk
in the door, they know who you are. At Store #2, they ask you for photo ID
and whether you remember the purchase amount of your last purchase in the
store (which is a secret you share with the store... the equivalent of a
password). If you can't remember, they tell you that they will send you a
postcard to your home address with the information (the "I forgot my
password reset link") and to go home and check your mail ("look at your
email") and then come back with the correct answer. Which place you are
going to shop at?

Identity proofing optional. Suppose you run a
site like Craigslist, eBay, etc. These sites are based on trust. But you
don't really know who the seller or the buyer really is. With OneID, because
it is your ONLY identity, people are more willing to make an investment to
identity proof themselves so that they will because it means more sales.
Sellers only want to complete transactions to buyers who are legit. Buyers
only want to buy goods from sellers who are real and legit. OneID can help
by identity proofing people 5 different ways....once per person!

Detect abuse. Is this a guy we've kicked off before
coming back yet again? Sites like Yahoo, Craigslist, etc kick people off
who abuse the system. But if you require people to use a OneID we can tell
you whether they are likely to be an abuser or legitimate user.

Increase conversion, especially on mobile. We make transactions a lot faster and easier,
especially if you are using a mobile phone. If
you make it easier to buy stuff or renew a subscription or membership (by making it easy to login and checkout),
people buy more stuff. If you make checkout really fast where nothing can go
wrong, you complete more sales. Consumers love it, and sites love it. Amazon
got close to a 2X improvement in conversion when they added one-click
checkout. Our technology is comparable to Amazon one-click but it works on
any site. And it works for new customer registration, login, and checkout.
You can even checkout without being logged in (and it will associate the
purchase with your account). There isn't a faster and easier way to checkout
on the web.

Lower fraud for CNP transactions. When fraud
happens, the merchant eats the cost. Because a user registers his credit
cards once with OneID, we can afford to do a lot more checking than any
individual merchant can do (both in time investment and money). We also have
much more data about the user and the user's device than any merchant will
ever have. There more than 20 techniques OneID is able to use to identify CNP fraud.
In addition, the smartest attackers will avoid OneID because it is much more
difficult to crack.

We eliminate the PCI liability if you want. If
you want the user's credit card data, we'll give it to you. If you want to
avoid the PCI liability issues, we can still submit the transaction with
your merchant account or ours in such a way that card information is never
disclosed to your company. So you can have it your way.

It's easy to provision a OneID account after a login
or transaction. If the user doesn't have a OneID, a new OneID can be
created
after the checkout in two clicks, no typing. That OneID is fully filled out
with the user's information and credit card information. So it's easy to provision new
and existing users with a OneID that is linked to their account on your
site. You can provision both a legacy account and a OneID account. The user
is much more likely to come back to your site with their OneID account
because there is no username or password for the user to remember.

Lower friction. If the user already has a
OneID, we clearly reduce friction. If they don't, they can create a OneID in
a single click.

OneID is an option. Sites that adopt us add
OneID as an option for login, form fill, and checkout. For users who don't
want to change, they are not forced to change.

We provide pre-verified email addresses for all
users. No need to have users verify their email.

More revenue because people won't share OneIDs.
Users often share usernames and passwords. Those are easy to share with
minimal risk. OneIDs aren't easy to share because it is your entire
identity... the ability to log into any site. It would be like giving your
friend all your usernames and passwords! We make it much easier to enforce one login per
person access. If your website charges a subscription fee for
access like netflix, nytimes, angie's list, wall street journal, etc., then
you don't want people sharing their usernames and passwords with their
friends. This is easy to do with usernames and passwords. With OneID, it's
impossible to do...you either give your friend your entire identity or you
don't. You can't give someone an access key that only works on one website.
Since most people aren't going to give their entire identity to someone
else, it means that people are much more likely not to share their
single-user account. OneID can also be used to manage multi-user access to
sites.

Rewards. Certain sites that sign up new users
have an opportunity to earn compensation for each new account.

It rocks on mobile. If people access your site
from a mobile device, it's night and day difference with OneID. Login and
checkout without typing anything, even if they've never been to your site
before.

We give sites all the information they want (with the
user's consent of course). We bring the user's identity, all of their
addresses, and all their credit cards to a new site. All of that can be
shared with the site easily.

The user never leaves the site in order to use OneID.
We do not take people off your site. OneID is easily integrated on your
page, or shown in a dialog box. The user never leaves your site

Integration is easy. 20 lines of HTML and about
20 lines of server code. We've had sites that had us integrated in 30
minutes. Some sites took 4 hours. If you just do QuickFill, you can add that
in less than 15 minutes.

Even if you don't sell anything on your
site, if just a login is required to access your site, we can still make a dramatic
difference in usability because logging in with OneID is much easier
than even facebook connect...there is nothing to remember because OneID is
device based. I do not remember my Facebook or Amazon login for example. But
I do remember my OneID login because there is nothing to remember!

Directly do a transaction from an email with zero
friction. Whether it is my AT&T bill or my bank statement, it's just too
much pain to click through and view the statement. The username and password
get in the way. The same is true for email promos...buy this product or sign
up for this event or renew this membership. Too much friction so people don't bother. An ask for a $5
donation...sure I can afford it, but I get 400 emails a day and my time is
limited. I'd like to make the donation, but I've got 399 other emails and a
meeting and I just can't afford the time. OneID
changes all this. You can do a single-click purchase or donation or even
just RSVP for an event right from
an email ask. No typing. No login. Nothing to remember. From any device with
your OneID. The implications are huge.

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.

The OneID vision:
A single, secure, permanent identity you can use for anythingWouldn't it be
great if you could have a single secure, permanent, private, easy to use identity that you
could use anywhere for anything? That is the vision of OneID. To be able to use for desktop, web, mobile, in-person,
over-the-phone, on-line, enterprise, and consumer applications. Try it now
at www.oneid.com.

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
is: