CryoKey

The easy and safe alternative to password authentication!

[cryokey]

Password Best Practices

Ars Technica just recently posted an article about modern password cracking capabilities. Many of the user commentators on that article have clearly seen the original xkcd comic about password complexity. The Ars Technica article really highlights the sorry state of password security today.

If passwords are so weak, then password "best practices" are just an exercise in futility, especially as cracking capability improves. At the very least, current password "best practices" need review. They were established when users had fewer accounts and cracking capability was in its infancy. Given the rather bleak prospects of passwords, I don't think the traditional password "best practices" really make much sense anymore. Instead, I propose a more practical set of "good practices" that should hold over password-users until sites start adopting newer forms of authentication. These "good practices" are much more realistic and easier for average users to adopt.

* GROUP TOGETHER LOW-RISK SITES THAT SHARE A PASSWORD

First, you need to evaluate your accounts to determine which ones are low-risk. A low-risk account is one that basically has limited consequences if an unauthorized user gains access. A compromised low-risk account would be annoying, but you would not have urgent need to recover access. Think of sites like video games, weblogs, clubs, or even various streaming sites. I'd even say social media sites are low-risk, but some might argue otherwise.

Your goal is to reduce the number of passwords that you need to manage. Reducing the password burden allows you to make use of stronger passwords. You might find that you actually visit a lot of low-risk sites, so you shouldn't waste time and effort memorizing unique strong passwords for each one. One decent password can easily cover numerous low-risk accounts.

However, you do want to compartmentalize any damage. If one site gets hacked, then all sites that share the password are suspect. Therefore, don't resign all of your low-risk sites to one password, because you're exposing that password to more frequent attacks, and if the password leaks out, you'd have to update your password on many more sites. But five or six sites to a password works quite well.

Also, try to determine how frequently you use each account. Sites that you rarely use should probably share a password with many others, or else you'll likely just forget the password. On the other hand, sites that you frequent can be part of a smaller group with a stronger password, since you'll have a lot of practice entering those passwords.

* GENERATE UNIQUE, SUPER-STRONG, PURELY RANDOM PASSWORDS FOR YOUR HIGH-RISK ACCOUNTS

High-risk accounts have more at stake, but some of these accounts (such as utility bills and such) may still be eligible for password sharing, as long as the groups are small. High-risk accounts (typically in finance, health, or safety) are worthy of the strongest passwords that you can handle. At the top of the chain of risk is your E-Mail account, which should never share a password with any other account. Your E-Mail address is your one true network identity, and handles reset/recovery for pretty much every other account.

My last post gave a naive overview of password complexity; in reality, passwords typically consist of a lot less entropy because people tend to choose passwords that are easy to remember. Less entropy means fewer combinations for a given length. To get the theoretical strengths of a password, it needs maximum entropy. And to get maximum entropy, a password must consist of completely random characters where every allowed symbol has an equal probability of showing up.

You can try to come up with your own random password, or maybe you want to get fancy and pull a random set of characters from three entropy sources, then shuffle them together. But for most cases, you can just use some software to generate a random string. We've even created a simple client-side password generator for your convenience. Just avoid any results that resemble dictionary words, even if they have character substitutions (such as a '3' for the letter 'e'). If you get a result that resembles a word, re-roll it! And remember: size is important. High-risk accounts should use the longest passwords, preferably at least 12 characters.

Conventional wisdom suggests that, if a password is easy for you to remember, it's easy to crack as well. Therefore, the best passwords are hard to remember. But are they really that hard to remember?

* WRITE DOWN PASSWORDS UNTIL YOU HAVE TRAINED YOURSELF TO USE THEM

The best way to learn any new password is to just use it! The more you use it, the more it sticks in your mind. (That's why you should group infrequently accessed accounts together with shared passwords. You get to use each password more frequently, which greatly improves retention.)

Unfortunately, learning a long and random password is very difficult under the current password "best practices" because they discourage users from keeping hard copies of their passwords. The user has to create and remember a complicated new sequence without any external assistance, which is very mentally taxing.

In reality, writing down a password isn't so bad, as long as nobody else ever sees the password. Therefore, if you create a super strong password, write it down until you've used it enough to recall it on demand. Every time you use the password, you reinforce the memory. To speed up the process, you can practice typing in the password for a few minutes until you've impressed the character sequence in mind and body. You can also speak/whisper the letters as you type them if voicing the password helps you remember (as long as nobody is listening).

If you're going to record the password, try to use pen and paper (like on a small post-it note) instead of storing it on a computer, and definitely don't store it online. Ideally, you should keep the physical hard copy close to you - maybe in your wallet or a locked drawer. Then, to be safe, you should destroy the hard copy as soon as you've learned the password, especially for high-risk accounts. Find a shredder, a fireplace, a vat of black dye, or some concentrated bleach - use your imagination - to destroy the written record, just like the good old days of information repression!

* DON'T CHANGE PASSWORDS UNLESS THE PASSWORD HAS ACTUALLY BEEN COMPROMISED

I come across many password "best practices" that suggest periodic changes to the password. To this day, I still don't understand how this questionable "best practice" became gospel, and I also don't understand why people continue to propagate it. The only reason why you would ever need to change your password is if an unauthorized user managed to learn the password. If the user already had a strong password, he would just be wasting a perfectly effective password and all the effort spent learning it. And the new password may not even be as strong as the old one! Furthermore, changing passwords doesn't necessarily increase security; if anything, frequent changes decrease security because users will end up selecting easier passwords to limit the overhead of learning truly strong passwords.

A few years back, a Microsoft researcher wrote about the futility of periodic password changes. Basically, the moment a hacker steals a password database, the clock starts ticking. He must use the data before the security team discovers and nullifies the attack. If he plans to sell account data on the information black market, he needs fresh data, because the data loses much of its value once the victim discovers and responds to the intrusion.

Periodic password changes strain a user's mental capacity and add tremendous overhead in account management time and effort. But if you change a password and nobody is there to witness the previous one, has it really changed? In this case, no. Regardless of how often you change your password, a successful attack will expose your current password. The hacker is not going to save your password for use in the future because the site will soon discover the attack and force you to change your password. Therefore, unless you change your password every few minutes, unprompted password changes will not disrupt any attacks.

However, when an unauthorized user gets access to your password, you will eventually find out, so save yourself the pain and futility of constant password rotations. The better solution is to train yourself to recall a few very strong passwords, and only change a password if it somehow leaks out to the wild. Since you won't change passwords very often, you can train yourself to use much stronger passwords.

* MOST IMPORTANTLY, PREPARE FOR THE INEVITABLE PASSWORD THEFT

As I've said in the past, good passwords may be hard to crack, but they are still vulnerable to other attacks: phishing, key-logging, or simply attacking a site with weak security. And unfortunately, as the Ars Technica article pointed out, cracking capability grows over time, so even good passwords have a limited lifespan.

It doesn't matter how strong your password is or how good your personal password practices are. In the end, assume that malicious users will always be able to find a way to gain access to your password. Therefore, don't sit on your ass and think that anyone is invincible on the net. Take some responsibility for your own identity. Assess your security needs, compartmentalize the potential damage, and have a plan to respond to loss of identity.

That's right, you need to come up with a worst-case scenario plan! If you know your accounts, their relative risks, and the way you group them by password, then you can easily come up with countermeasures when something goes wrong. Then you'll have a quick and decisive reaction to any breach. Having a plan for the worst case scenario is the final step to true security.

[cryokey]

Password Strength

I recently had to choose a new username at Chase bank, which made me shake my head. Chase had imposed requirements for complex usernames - requiring uppercase, lowercase, digits, and special characters without repeating. It's basically a meaningless second password.

Most people seem to assume that complex passwords are "better." Yahoo! recently posted another article about good password practices, which advised complex passwords. But as seen in that old xkcd comic about password strength, a complex password is not necessarily an effective password.

The strength of a password really boils down to the number of possible password combinations in a character set. A 4 digit PIN code, for example, only has 10^4 (10,000) possible combinations. On the other hand, a 4 letter code has 26^4 (456,976) possible combinations. A modern computer can blow through those combinations pretty quickly, but at least the 4 letter code would put up a little more of a fight. A truly strong password needs an astronomical number of combinations that would be computationally intractable for brute force searches.

Now, adding password requirements to increase the complexity of a password is one way to strengthen a password. Unfortunately, as passwords become more complex, they become less usable. What we really need are practical passwords that can rival the processing power of today's password cracking farms.

Simple Passwords vs. Complex Passwords

To compare the relative strengths of two different password requirements, I've whipped up this simplified equation:

a / b = log(B) / log(A)

Where:

A is the size of the first character set

B is the size of the second character set

a is the length of a password from set A

b is the length of a password from set B

Let's say we're comparing a simple password of all-lowercase characters (A=26) against a complex password that consists of uppercase, lowercase, digits, and maybe a period and underscore (B=64). Then:

a / b = log(64) / log(26) = 1.27647632132

Put into plain English, a simple password would need to be 27.65% longer than a complex password to match its strength. In other words, the strength of a 12 character complex password would be equivalent to somewhere between a 15 or 16 character simple password. A quick calculation of possible character combinations highlights the comparison:

43,608,742,899,428,874,059,776 = 26 ^ 16 (simple) 4,722,366,482,869,645,213,696 = 64 ^ 12 (complex)

From a casual observation, in terms of mathematical brute force strength, a 16-character simple password (such as "iamalittleteapot", "asdfqwerzxcvaoeu", or even "qqqqqqqpqqqqqqqp") would theoretically be stronger than a 12-character complex alternative (such as "iM_l1tlT.p0T"). Of course, adding one more character to the complex password would tip the scales the other way. But which password is easier to remember and use: "iamalittleteapot", or "iMa_l1tlT.p0T"? Factor in the best practice of using a different password for each of your hundred accounts, and you'll see just how cumbersome the complex password requirements can be.

Besides, strong passwords may resist password guessing, but they won't help against more direct assaults such as keyloggers, phishing schemes, or attacks on sites with weak information security practices. Simple passwords that are strong yet easy to create and remember would greatly streamline recovery after a security breach.

Keep in mind, this calculation is just a very naive way of comparing password strengths, but it should get the point across to people who aren't in information theory and security (which is to say, most people in the world). Ideally, we should be measuring entropy of the content, as seen in the xkcd comic. But the bottom line is that a password is one thing where you can safely say, "Size totally matters."

Of course, password strength would be irrelevant if sites just employed newer forms of authentication. Sadly, the password inertia is still very strong. It's so strong, in fact, that minimum complexity requirements are now bleeding into usernames. As a result, I suppose I'm just going to have to start getting used to the "Forgot Username" flow at Chase.

[cryokey]

Acceptance of Password Alternatives

Just this past week, SecureKey won a contract to provide "cloud-based authentication" for the USPS, paving the way for other US agencies to eventually adopt their authentication model.

First, congratulations to SecureKey on this milestone. Their announcement is a small yet important step forward on the road to password liberation. The news is even more impressive when you consider the difficulties that alternative authentication systems have faced trying to gain acceptance. But with the growing number of alternative authentication technologies available today, why do most sites still stick with usernames and passwords?

Security experts cite various possible explanations, but I think there's another subtle reason for the lack of acceptance. I'm starting to believe that the security industry itself may be unintentionally exacerbating the problem. Early on in the development of CryoKey, I realized something: the security industry focuses so much on the heavy-duty identity consumers that they end up neglecting an important audience - the low-profile site.

The Forgotten Audience of Security Technology

What's a low-profile site? The answer is subjective, but I'm sure anyone can think of a few if they take a moment. These are everyday sites normally run by one guy, a few volunteers, or any group that targets a more niche audience, whether big or small. Think of sites like Penny Arcade, WebOS Nation, Smart Insider, Greater Boston Soaring Club, or even BronyState. The common theme is that none of them participate in the current security dialogue that's trying to determine the future of identification and authentication. They are, quite simply, low-profile in the security conversation.

Authentication and identification are fundamental problems that ultimately require users and site operators to change their behavior. Unfortunately, the world of security is very off-putting and generally inaccessible to most people. As a result, a lot of site operators don't participate in the dialogue because they aren't interested in the technical details, or maybe some of them don't know how to get involved. Whatever the reason for keeping silent, their needs are still just as relevant as the Microsofts and Amazons of the world. The truth is, thousands of these sites dot the Internet, and they all manage their own users. Therefore, any truly widespread alternative to passwords will need their seal of approval as well.

Make no mistake: we need robust solutions because critical services have a lot more at stake. Providers such as SecureKey offer the richer capabilities that heavy duty identity consumers require. But focusing too much on the big players ratchets up the security demands and increases complexity, leaving the casual site in the dust. Most of these low-profile sites simply don't have the resources to integrate and follow the continuing developments within the realm of security.

Active Outreach Instead of Voluntary Input

Every site - big or small - suffers from the password burden, but few sites actually adopt a password alternative. I can understand why the big sites would hesitate to adopt new technologies, but smaller sites have less at stake, so they are in a better position to experiment. Unfortunately, when you're just one person trying to run a community site with maybe a few volunteers to help, you simply don't have the resources to dive into the deep rabbit hole of network security.

If the off-putting language, complexity, and rapid rate of change within the world of security causes these service providers to tune out the dialogue and direct their attention to other issues, then we need to make the first move and approach them. We can't just sit by and wait for interested parties to join in the conversation or else we limit the contributors to only a small and very biased audience. Instead, we have to actively engage all affected parties to discover what they need. Otherwise, some of the less security-centric parties may not know what to say or how to get involved in a dialogue that may ultimately affect their services in some way. Without their acceptance, any decisions that come out of the dialogue will have a much harder time gaining widespread acceptance.

Do you know someone who runs an authenticated site? Ask them what they think about passwords and the alternatives, and see what it would take for them to try an alternative. Send them to the Petition against Passwords to share their pain and learn more about password alternatives!

In particular, we at CryoKey would love to hear about their thoughts and concerns about integrating external authentication in their site. We'd love to help them find alternatives, whether it's CryoKey or some other solution that better fits their requirements. We just want people to loosen their death grip on passwords and get started with something! I'm confident that, if users as well as service providers give this new crop of password alternatives a chance, they will quickly see for themselves just how much better an online experience can be without passwords.

[cryokey]

The 5th IDESG Plenary Meeting

Due to the news coverage of other major security-related conferences like DEFCON and BlackHat at the end of July, many people may not have noticed that the Identity Ecosystem Steering Group (IDESG) held its fifth plenary meeting at the MIT Media Laboratory on July 24-26. Since the decisions of the IDESG would likely impact CryoKey's development in some way, I decided to attend and hopefully catch a glimpse of their vision of an "identity ecosystem."

Now, if you've never heard of the IDESG before, don't worry; it's a relatively new organization that likely doesn't affect you directly. The IDESG was born out of the National Strategy for Trusted Identities in Cyberspace (NSTIC), signed by the president in 2011 to help pave the way for a new generation of online identification technologies. The NSTIC is the plan, while the IDESG is one of the bodies executing on the plan.

From what I can tell, the IDESG is basically an advisory body made up of public and private organizations that are involved in standards and technologies related to online identification. The group does not seek to directly draft specifications, protocols, procedures, or other formal standards. Instead, it advises on relevant standards to make sure they can work together to create a consistent user experience (which is what I consider the "identity ecosystem"). While it's mainly an advisory body, the IDESG will ultimately establish an accreditation process that sort of gives a "works within the identity ecosystem" stamp of approval to compatible technologies.

At the moment, the IDESG is in a very formative state, so ironically, they are still grappling with their own identity. This was the fifth plenary meeting after all, and the first meeting was only the August of 2012! Therefore, most of the plenary activity revolved around administrative and organizational topics. Yet you could see the potential of the IDESG by looking at the minds and ideas assembled at the meet. I was certainly surprised to encounter so many concerned individuals from such unexpected fields as real estate. Secure identification truly affects everyone!

Unique in a Crowd

One of the highlights of the plenary meeting was the "Unique in a Crowd" talk by Alex 'Sandy' Pentland, who gave a talk on the value of information as an asset, and how the information can be used for all sorts of beneficial purposes. Just by using anonymous, aggregate data, you can make detailed projections of things like poverty, crime risk, and even pandemics. In fact, personal information collected from everyday activity can uniquely identify an individual and even predict things like health and disease better than genes.

Apparently, a fingerprint typically needs 12 sample points to uniquely identify an individual, but only four points of human mobility data could assure the same level of identification. To drive home the point of mobility-based identification, Dr. Pentland's research team issued Android devices installed with tracking software to volunteers at the start of the plenary meeting. The volunteers didn't know anything about the research or the information being collected, but carried the devices for the 24 hours before his talk as they went about their business. When Dr. Pentland finally revealed the purpose of the devices during his talk, all but three of the devices were able to uniquely distinguish the volunteers - based solely on periodic scans of nearby Wi-Fi stations! (And of the remaining 3 that couldn't uniquely distinguish a user, 2 of them failed due to technical problems.)

While the results were impressive, identification based on personal tracking data still faces many significant issues. For example, users will still need a way to identify themselves when they break out of their baseline behavior patterns. Also, user-controlled data is at least subject to manipulation, as demonstrated by some mischief during the happy hour event. While musing over the point of the Android devices and the kind of information they were gathering, Andre Boysen of SecureKey and I traded our tracking devices just to see what would happen. At worst, I figure that we would invalidate our results and irritate a few researchers. But in a real world scenario, such data manipulation would surely carry greater consequences!

In addition, the implications of personal data are pretty profound, and certainly raise a lot of concerns about abuse and privacy. People are even more sensitive to privacy these days due to the recent backlash over government monitoring. So part of the research involves the proper sharing of such data under the openPDS project. But even with user-authorized sharing, information is still vulnerable to theft or misuse, and the consequences are not clear yet. Therefore, the proper use of personal data is still an open debate, one that will hopefully be resolved if this technology is to ever see widespread adoption.

Bottom Line

During his talk, Bob Blakley, the plenary chairman, mentioned that he hoped the dialogue would be productive and "fun" - to the extent possible in the world of security, I suppose. After all, I don't think most people consider the grim world of security as their idea of a fun time. But hey, I can say that I had a good time observing the wheels in motion as I met many fascinating people and listened to thoughtful conversations. The happy hour was certainly fun, and I was able to meet the good folks at TraitWare, a unique identification/authentication technology based on dynamic Qr codes.

In any case, the IDESG is definitely an interesting group, one that has a very worthy goal (to foster an identity ecosystem). Security and identification is a complicated beast, and heaven knows that the current state of online identification could use some direction! The IDESG is still trying to hammer out a common definition of the identity ecosystem and their own place within this ecosystem. But I'd love to see how the IDESG looks after they've had another year to organize themselves and start making more functional (rather than organizational) decisions.

[cryokey]

Trust, Security, and E-Commerce

Let's take a short trip back to 2005!

2005 was kind a pivotal year for e-commerce. Back in 2005, most people were still uncomfortable with e-commerce, preferring to do their shopping and personal business in brick and mortar establishments. However, e-commerce was gaining momentum. By 2006, the majority (51%) of internet users finally started getting comfortable with online transactions, as seen by the Center for the Digital Future's long-running study.

To reach the tipping point of acceptance, e-commerce had to overcome some major hurdles, especially concerning trust. A November, 2004 paper by Efthymios Constantinides shows the importance of trust in the consumer perception of e-commerce. In the paper, trust has many components, but includes the concepts of Transaction Security, Customer Data Abuse, and Customer Data Safety. The paper is still interesting because similar concerns exist today, though many users have gotten over their anxieties on trust. (Presumably, most consumers have not had any adverse experiences despite the risks, and the benefits to online commerce are just so compelling!)

During the trailing dot-com years leading up to 2005, businesses pushed very hard to gain user trust in e-commerce, but it still took about 5 years of gentle prodding before the majority of users were comfortable. Once most users got comfortable with online purchasing, however, the greater world of e-commerce kind of "settled in" and basically relaxed their push to gain trust. Still, the e-commerce dependent businesses don't want to lose ground on all their hard-earned trust. So most online outlets generally downplay the severity of today's increasingly frequent security breaches.

Clearly, the downplay of the security threats is working, as Americans continue to ride the wild e-commerce beast through security minefields with great confidence. One of the findings of the recent Digital and the New Consumer study shows that Americans are less worried about privacy/security when shopping online despite the frequent high profile security breaches. From the WNCT9 article summarizing the whitepaper:

Americans are less worried about privacy/security when shopping online: Despite high-profile security breaches regularly making headlines in the US, Americans are less concerned than their global counterparts about sharing sensitive information online or being the victim of fraud. Globally, 78 percent of consumers worry at least occasionally about their security when shopping online. More than half (54 percent) of respondents in Brazil worry every time they make a purchase online, as do 49 percent in Chile, 43 percent in Colombia and Mexico, and 32 percent in Argentina. Similarly, 37 percent in France and 33 percent in Italy are every-time worriers. In contrast, only 1 in 10 Americans worry every time they place an order online, and 1 in 4 report that they are never or only rarely concerned about the security of their information while making purchases online.

On one hand, this feeling of invincibility is important because so much of America's economy depends on online commerce. Losing faith would not help the already struggling economy. On the other hand, this complacency is a real obstacle to the next leap in security: shifting away from passwords.

Most everyone agrees that we need password alternatives, but changing consumer behavior is very hard. Businesses had a lot to gain during the drive for e-commerce adoption, so they were almost united in their drive to encourage users to move their personal activities online. And when consumers finally accepted e-commerce in mass, users were also able to reap the benefits of the incredible efficiency and convenience of doing so many things online 24 hours a day. It was a win-win situation!

Unfortunately, this time, we're dealing with a more abstract concept. Most businesses lack the motivation to help push the change because the economic incentives aren't obvious. After all, security is about preventing loss, not making gains. Neither businesses nor users will see many tangible benefits from better security, especially if the security measures are working.

Several years ago, one of my colleagues in banking told me that banks don't see security as a big problem ("at the moment") because the loss of business from inconveniencing users with additional security would be greater than the losses from fraud. (The Efthymios Constantinides paper mentions usability as one of the main e-commerce concerns at the time.) Also, implementing new security measures incurs development and maintenance costs. So if a bank expects to lose, say, a hundred million dollars to account fraud, then they prefer to just eat that loss because the amounts pale in contrast to the money flowing through.

But times are always changing, and the losses from fraudulent activity are also increasing. In the end, economics will drive the major businesses to change. Until then, we in the world of security technology must continue to forge alliances that call for change, trying to reach out to the pro-active people who want to stay ahead of the security arms race.

[cryokey]

Where did all the fancy authentication schemes go?

Just recently, Motorola announced a new scheme to improve the state of authentication and identification: the Password Pill!

An identification pill is certainly an out-of-the-box authentication model, and a real attention-grabbing press release! Unfortunately, like many people these days, I have a hard time getting really excited about the technology. Throughout the years, I have seen announcements about all sorts of amazing authentication schemes. We can see some examples just by looking at recent history:

Faces and Patterns

Walk Gait Authentication

Skin (Dattoos)

Barcode Login

Chip Implant Identity

Butt-Print Identification

Grip Authentication (also proposed for guns)

Tattoo Pattern Identification

Heartbeat Identification

Bioimpedance Authentication

Behavioral Authentication

Each of these breakthroughs promised to revolutionize security (and specifically identification/authentication). So while Motorola's press release is cool and very inspiring, I'm still skeptical about its actual applicability. With all the alarm and hype in the recent security news, I don't think I'm the only one who has become a little jaded at the lack of actual real-world progress. I mean, what's next? Olfactory Authentication?

Now, I certainly want new and better authentication schemes. But why are we still stuck in the world of passwords despite all the development? Why aren't any of these revolutionary schemes gaining any traction? Are they all doomed to fade into history as mere gimmicks?

One problem may be that a lot of these experimental schemes are biometric. As I've said in the past, biometrics are convenient, but very limiting, especially if someone else matches a marker or you physically change. Biometrics also do not provide 100% assurance. Imagine if we fed that controversial glove into a computer to determine the OJ Simpson verdict. If the computer relied on fit alone, you bet it would acquit! Consequently, unless used for low-risk identification, biometrics simply can't work alone, and so they aren't a general enough solution.

Then these schemes run into the problem of practicality. A lot of these fancy schemes are useful in very specific situations that don't match everyday use cases. Is a Nissan Leaf Forum user going to want to log in with his gait? Is a Consumer Checkbook subscriber going to implant a RF chip into his arm just to enter a review? Do people want to RSVP to a wedding by identifying themselves through butt prints? I'm guessing... no.

There's an old saying among video game software engineers: "If you do something great, nobody cares. If you do something wrong, nobody forgets." I'm sure the rest of the security industry feels the same pain. You can't see the results of successful security, but you can certainly see the consequences of security failures. Most people aren't interested in news about bad things that haven't happened. That's why people are more excited to talk about fancy authentication schemes than the realities of security news.

Unfortunately, when dealing with personal security, the bottom line is that Practical trumps Cool. Novel authentication schemes may add to the security dialogue and raise a lot of public awareness to the growing security threats, but they aren't going to solve the current identification and authentication problems. The Internet was built around passwords, so usability practically depends on them. Any wildly off-the-wall solution will not stick.

Even an evolutionary solution like OpenID (which was also built around passwords) endured a long, hard battle for acceptance. OpenID has been around since 2005, and despite backing from major players such as Microsoft, Google, Yahoo, and so on, you can hardly say that OpenID has been "widely accepted." After eight years, an appreciable number of major sites do use it to some extent, but most of my colleagues don't use it. In fact, many people I encounter still don't even know what OpenID is!

But alternative forms of authentication are inevitable, which is why we at CryoKey continue the thankless task of developing out our solution. We want to help site operators stay ahead of the game to avert their own worst case scenario. Right now, every week is filled with various security breaches, and passwords are involved (either as a cause or a casualty) of many of these incidents. Without continued development on realistic options, the current trajectory of online security will eventually grind overall Internet usability to a halt (or at least into an eternal game of Whack-A-Mole).

If Internet hopes to stay ahead of this arms race against online criminals, then the security industry needs all the help it can get. So let's keep those exotic identification/authentication ideas flowing, because if nothing else, they are inspiring. And the industry could certainly use the happy press, given its more grim subject matter. For all of those silent Internet guardians that feel underappreciated, each of these announcements is a shining reminders that there are thousands (if not millions) of brilliant minds working tirelessly in the background trying to protect the netizens of the world.

[cryokey]

Practical Uses of CryoKey with MySQL

In my previous post, you learned how to set up a MySQL server to recognize CryoKey credentials. You also learned how to set up the MySQL command line tools to automatically present the CryoKey credentials when establishing database connections.

In practice, most people don't use command line tools to access databases. Therefore, I wanted to demonstrate how you would use CryoKey credentials to access MySQL in more typical database usage scenarios:

MySQL Workbench, a popular MySQL database management tool

Perl DBI with MySQL DBD

PHP with the MySQL Improved ('mysqli') API

PHP with ADODB

--- MySQL Workbench

MySQL Workbench is a powerful visual interface for the MySQL database system. You can use it to set up the MySQL SSL configuration to support CryoKey. However, as of right now (Workbench v5.2.37), you can't actually set up certificate-based database user accounts from the user interface. Therefore, you'll still need to use the 'GRANT' command with the 'REQUIRE SUBJECT' directive to manage access.

Either create or open a server instance. You will see the server dashboard:

To manage SSL configuration, go to the Security tab under Configuration->Options File:

To check the configuration (or availability) of SSL, look for the 'have_ssl' value of a server's System Variables tab under Management->Status and System Variables:

After you set up the server, you need to set up certificate-based accounts. Look at my previous post for details on how to get a user's CryoKey subject string and associate it with the account. To recap, first acquire CryoKey credentials. Then get the user's CryoKey subject string:

# openssl pkcs12 -in cryokey.pfx -clcerts -nokeys -out my.crt # chmod 0444 my.crt # openssl pkcs12 -in cryokey.pfx -nocerts -nodes | openssl rsa -out my.key # chmod 0400 my.key # openssl x509 -in my.crt -noout -subject | sed 's/^subject=\s*//'

Then, connect to the database as an administrator and link the user's CryoKey subject string in a 'GRANT':

mysql> GRANT ALL PRIVILIGES ON [database].* TO '[name]'@'[host]' REQUIRE SUBJECT '[CryoKey subject string]';

When creating or editing connections to databases in MySQL Workbench, you can specify the user's CryoKey credentials from the Advanced tab in the connection settings:

Note that shell variable expansion is not available. Therefore, use absolute paths for the certificate and key files, because the working directory may vary (under a typical Kubuntu 12.10 installation, the working directory would be 'Documents' in your home directory). If you connect using 'TCP/IP over SSH', the certificate and key files are relative to the user's account on the SSH server.

Click 'Test Connection' to see if you set up the connection properly. If the test succeeds, click 'OK' to apply the changes.

--- Perl DBI

Using CryoKey credentials to access MySQL databases is fairly simple under Perl DBI. Perl's MySQL DBD allows you to specify your CryoKey certificate and key files in the data source name. Just remember that the paths are relative to the current working directory.

This sample script opens a connection to a database called 'testdb' on a local MySQL server. The user, 'dbuser', will try to connect using the certificate from 'my.crt' and the key from 'my.key' located in the current working directory.

#!/usr/bin/perl use DBI; use strict; use warnings; my $dbname = "testdb"; my $hostname = "localhost"; my $username = "dbuser"; my $key = "my.key"; my $certificate = "my.crt"; my $dsn = "DBI:mysql:database=${dbname};host=${hostname};mysql_ssl=1;mysql_ssl_client_key=${key};mysql_ssl_client_cert=${certificate}"; my $db = DBI->connect($dsn, $username) or die "Can't connect: $DBI::errstr\n"; my $results = $db->selectall_arrayref("SHOW STATUS LIKE 'ssl_cipher'"); foreach my $i (@$results) { foreach my $j (@$i) { print "[$j] "; } print "\n"; } $db->disconnect();

Running it should output something like:

[Ssl_cipher] [DHE-RSA-AES256-SHA]

If the value is '[]' (empty), then something went wrong; make sure the certificate and key files are valid, and make sure the MySQL server has been set up for SSL.

--- PHP MySQL Improved (mysqli_*)

Direct certificate support is available to the 'mysqli' API, but not the older 'mysql' API. To specify a certificate, you use mysqli_init() to create a connection object, ssl_set() to specify the certificate and key, then real_connect() to open the connection. Afterwards, use the connection normally.

<html> <head> <title>CryoKey MySQL</title> </head> <body> <?php $dbname = 'testdb'; $hostname = 'localhost'; $username = 'dbuser'; $db = mysqli_init(); $db->ssl_set('my.key', 'my.crt', NULL, NULL, NULL); $db->real_connect($hostname, $username, NULL, $dbname); $result = $db->query("SHOW STATUS LIKE 'ssl_cipher'"); echo "<table border='1'>"; while ($row = $result->fetch_row()) { echo "<tr>"; foreach ($row as $cell) { echo "<td>{$cell}</td>"; } echo "</tr>"; } echo "</table>"; $db->close(); ?> </body> </html>

Running the script should output something like:

If the 'Ssl_cipher' field is empty, then something went wrong; make sure the certificate and key files are valid, and make sure the MySQL server has been set up for SSL.

--- PHP ADODB

The current version of ADODB doesn't let users specify SSL connection parameters. However, you can work around this limitation by specifying a certificate and key in the system options file (normally '/etc/mysql/my.cnf' as of MySQL v5.1.15). Simply add the SSL connection parameters to the '[client]' section:

... [client] ... ssl-cert=/etc/ssl/certs/mysql.pem ssl-key=/etc/ssl/private/mysql.key ...

Remember that, if you don't provide absolute paths, the files will be relative to the script's working directory. Make sure to set the certificate and key file permissions properly, or else everyone will have access to the credentials! In our example (and typical Linux distributions), system keys go in '/etc/ssl/private' with mode 0440 and group 'ssl-cert'. We also put system certificates in '/etc/ssl/certs' with mode 0444. Any users that need access to the system keys should be in the 'ssl-cert' group.

Then, use ADODB to connect using the 'mysqli' driver. You will need to set the 'MYSQL_CLIENT_SSL' client flag:

<html> <head> <title>CryoKey MySQL</title> </head> <body> <?php include_once("adodb5/adodb.inc.php"); $dbname = 'testdb'; $hostname = 'localhost'; $username = 'dbuser'; $db =& ADONewConnection("mysqli"); $db->clientFlags = MYSQL_CLIENT_SSL; $db->Connect($hostname, $username, NULL, $dbname); $db->SetFetchMode(ADODB_FETCH_ASSOC); $results = $db->Execute("SHOW STATUS LIKE 'ssl_cipher'"); if ($db->ErrorNo() == 0) { while (!$results->EOF) { $row = $results->FetchRow(); print_r($row); $results->MoveNext(); } $results->Close(); } ?> </body> </html>

If successful, you'll see a line that looks like:

Array ( [Variable_name] => Ssl_cipher [Value] => DHE-RSA-AES256-SHA )

If the value is empty, then something went wrong; make sure the certificate and key files are valid, and make sure the MySQL server has been set up for SSL.

This workaround has its limits. The files are usually relative to the current working directory. Therefore, the certificate and key must be in the same directory as the running PHP script, which leaves the key vulnerable. You can always use absolute paths to put the files somewhere less accessible. Or wait for ADODB to add more thorough MySQL SSL connection support.

MySQL's certificate support is very basic right now. While it certainly has room for improvement, most users generally don't use SSL connections, preferring to stick with username/password/host access controls. Right now, SSL connections are mainly used for the secure communications, especially during replication. Therefore, development on such support isn't a high priority, but the support should improve if more people start using MySQL's SSL capabilities.

Still, CryoKey credentials can work with MySQL despite the current state of support. They're especially useful for scripted database access. You may be asking, "Why bother?" Well, some people may want the added assurance of certificate based authentication, especially when combined with normal passwords. Besides, you may want to connect using an encrypted connection, and authenticating with CryoKey credentials isn't such a big leap if you're already connecting over SSL anyway.

If you do use CryoKey for database authentication, consider using a system identity (as opposed to a personal identity). For instance, you could generate credentials for [email protected] if you can get mail for that account (maybe through a forwarding mechanism).

The same credentials used in MySQL can also be used in other ways for typical Linux tools. In future posts, I'll describe some other back-end uses for CryoKey credentials, including the possibility of automating a verification flow for system accounts!

[cryokey]

CryoKey with MySQL

If your favorite sites don't recognize CryoKey just yet, don't fret! CryoKey still has other useful applications.

CryoKey's manual-install credentials are well suited for any software that makes secure connections over SSL. The popular MySQL database system is one great example. Starting from version 4.0, MySQL has been capable of authenticating and encrypting SSL connections, but the support is very primitive and rarely used. So today, I'd like to talk about using CryoKey for MySQL user identification.

Normally, to use client certificate authentication in MySQL, an administrator needs to set up a private certificate authority and manage certificates, keys, and configurations. CryoKey eliminates the hassle by handling all of the certificate authority duties for you. You can simply treat the CryoKey authority as a certificate dispenser.

This example was based on a Linux (Kubuntu 12.10) installation, but should be equivalent for any other distribution.

--- SETTING UP THE MYSQL SERVER

If you haven't done so yet, install MySQL v4.0 or later compiled with SSL support.

# sudo apt-get install mysql-server

The typical MySQL packages found in most distributions will have SSL support. To see if SSL is available in your MySQL server installation, just try to start the server with an SSL option such as 'mysqld --ssl --help'. If you get an error like '[ERROR] mysqld: unknown option '--ssl'', then your MySQL was not compiled with SSL.

Download the CryoKey Certificate Authority (CA) Certificate. You can always get the latest CA certificate bundle using:

# wget https://www.cryokey.com/ca.pem

Get a certificate and key for the server. MySQL requires the server to have a certificate and key, even though they're not that useful to MySQL. If you have a SSL certificate/key for your web server on the same machine, you can theoretically use the same certificate/key. You can also ask CryoKey to generate self-signed test credentials at https://www.cryokey.com/public/selfsign.php. Then, extract the certificate and key:

# wget https://www.cryokey.com/public/selfsign.php -O cryokey.pfx # openssl pkcs12 -in cryokey.pfx -passin pass: -clcerts -nokeys -out certificate.pem # openssl pkcs12 -in cryokey.pfx -passin pass: -nocerts -nodes | openssl rsa -out key.pem

Once you extract the certificate and key, you can delete the 'cryokey.pfx' file.

You should now have three files: 'ca.pem', 'certificate.pem', and 'key.pem'. Recent Linux distributions confine the MySQL server with AppArmor. The default MySQL server AppArmor profile normally allows the server to read files with a '.pem' suffix from the MySQL configuration directory. Therefore, you should put these files with the rest of the MySQL configuration files in '/etc/mysql' (or just /etc prior to MySQL v5.1.15).

# sudo install -m 0644 ca.pem /etc/mysql # sudo install -m 0444 certificate.pem /etc/mysql # sudo install -m 0400 key.pem /etc/mysql

Note that the key file should only be readable by the owner (root).

mysqld can take command line parameters to enable SSL, but we'll be making modifications to the options file instead. The MySQL server normally starts at system startup, so changing the options file is more practical than modifying startup scripts or upstart configurations.

Add the following lines to the '/etc/mysql/my.cnf' file under the '[mysqld]' section:

... [mysqld] ... ssl-ca=/etc/mysql/ca.pem ssl-cert=/etc/mysql/certificate.pem ssl-key=/etc/mysql/key.pem ...

Now just restart the server:

# sudo service mysql restart

To see if everything is working, run this MySQL query:

> SHOW VARIABLES LIKE 'have_ssl';

If the 'have_ssl' variable has a value 'YES', then your server is ready for SSL!

--- SETTING UP THE USER

Each user will need his own certificate and key. The user should complete the CryoKey verification process and download the manual install file (usually 'cryokey.pfx'). After downloading the credentials, extract the certificate and key (using the given PIN code):

# openssl pkcs12 -in cryokey.pfx -clcerts -nokeys -out user.crt # chmod 0444 user.crt # openssl pkcs12 -in cryokey.pfx -nocerts -nodes | openssl rsa -out user.key # chmod 0400 user.key

Once you extract the certificate and key, you can delete the 'cryokey.pfx' file. Note that the key is not password protected, so it's vulnerable to theft. You will have to protect it more carefully. Also, be aware that certificates do expire; currently, the manual install certificates are only valid for 30 days. (We're likely going to increase the duration as time goes on.)

The 'mysql' command line client can take arguments to specify your credentials. However, to simplify command lines (and make the credentials available to other applications), you should instead update your user-specific '$HOME/.my.cnf' under the '[client]' section:

... [client] ... ssl-cert=user.crt ssl-key=user.key ...

With the options file properly set up, you will automatically attempt to authenticate with your CryoKey credentials when you connect to any MySQL server (without needing additional command line arguments). Note that the files are relative to the current working directory. You can use absolute paths if you like, but shell expansion is not available in the options file (so you can't use '~/user.crt' or '$HOME/user.key' in the options file).

You're not done yet! You will need to know the certificate subject string to associate a database user account with your credentials. To get the subject string:

# openssl x509 -in user.crt -noout -subject | sed 's/^subject=\s*//'

You'll see something that resembles '/C=us/O=*/OU=1/[email protected]'.

--- MYSQL USER ACCOUNT MANAGEMENT

Now you need to bind user accounts to CryoKey credentials using the MySQL 'GRANT' request. Specify 'REQUIRE SUBJECT' with the user's certificate subject as an argument. You can also (optionally) specify 'REQUIRE ISSUER' with CryoKey's CA certificate subject, which should always be '/C=us/O=CryoKey/OU=Authority/CN=www.cryokey.com'. If you specify both the subject and issuer, you can just use 'AND' to link the directives:

> GRANT ALL PRIVILEGES ON [database].* TO '[name]'%'[host]' REQUIRE SUBJECT '[user certificate subject]' AND ISSUER '/C=us/O=CryoKey/OU=Authority/CN=www.cryokey.com';

Only one subject string can be associated with a database user. You can always change the associated credentials by running the 'GRANT' request again for a user/host with a new subject string.

If the user has set up the options file correctly, he can now authenticate with MySQL using the CryoKey credentials over SSL:

# mysql -u [name] [database]

If the account requires SSL, then opening a non-SSL connection will fail (with a 'SSL connection error' or some variant). When you successfully connect with the appropriate credentials, you can use the MySQL '\s' command to examine the connection. The 'SSL' line should show the cipher in use. (If it says 'Not in use', then you didn't authenticate with SSL; in fact, you are not even on an SSL link!)

--- NEXT STEPS

Following these steps will allow you to authenticate and encrypt your connections with SSL. Note that all communication will be encrypted in this connection. You do pay a price in performance, especially when establishing a connection. Therefore, we highly encourage persistent connections if you use SSL with MySQL.

In my next post, I will show you how to integrate CryoKey authenticated MySQL connections with database consumers such as PHP and Perl. Stay tuned!

[cryokey]

Challenges to Integrating External Authorities

Every day, people have to "log in" to various sites and services in order to access their personal content. But have you ever wondered about what actually goes on when you "log in"?

If you can understand what happens during a "log in" flow, then you may start to see why integrating external authorities into existing systems has historically been so difficult. In the past, the security industry spent a lot of time trying to improve security while sacrificing usability. Today, the industry puts more emphasis on usability, but the improvements are usually user facing. Integration with existing systems can still be very difficult, and remains a major hurdle in acceptance of new authentication schemes.

The concept of "logging in" is actually rather ambiguous, but generally refers to a process that eventually grants a user privileges to protected resources. We can divide the act of "logging in" into four parts:

Identification: Who are you?

Authentication: Prove that you are who you claim you are.

Session Management: Establish a working relationship based on the credentials.

Access Control: Under the current session, what can you do?

The main purpose of identification is to distinguish yourself from the other users. Your identity can be any kind of distinguishing feature. It can be your real name, an alias, or even conceivably just a picture. An identity can contain additional information such as a photograph or other personal details (like the information found on a driver's license). Online, your identity is basically your username.

Once you declare your identity, you must now prove that the identity does, in fact, belong to you. The authentication process usually involves a challenge of some sort. The most common challenge is a password, and other factors (such as biometrics and physical tokens) can come into play as well.

If you pass the challenge, you can establish a relationship with the service. Now, HTTP is connectionless and stateless, so web services will often symbolize the relationship in a reusable session token, sort of like a ticket stub that grants re-entry. (Otherwise, you'd have to go through a challenge for every request.) The context of a session - who generates and manages them, where it's valid, when it expires - will vary. When you "log out", you are explicitly breaking the relationship so that the service will no longer recognize you.

Now, a session doesn't actually imply any privileges. Services grant privileges based on access control rules which apply to the session user. Access control behavior is extremely service-dependent, and generally involves more granular permissions. But the rules do play a role in what a user perceives as "logged in". For example, the rules may refuse access at certain times of day, or require periodic re-authentication, even with a valid session.

Some examples of different "log in" flows:

SSH: Identify yourself with a username, then authenticate with a cryptographic challenge. SSH works on top of a stateful, persistent TCP connection, which effectively manages the session. Access control comes from standard operating system user permissions.

This flow is just one example of a basic connected service. SSH is very flexible, and other authentication schemes are possible, such as passwords or even digital certificates. However, most SSH authentication uses anonymous RSA or DSA keys. Therefore, even though you may not need a password to authenticate, you still need a way to specify an identity.

Standalone Services (such as MediaWiki and WordPress): Identify yourself with a user name, then authenticate with a password. HTTP connections are stateless/connectionless, so to avoid logging in for every request, they store session IDs in local storage (cookies), and store session context in a database. Access control is based on user privileges stored in a particular instance's database.

The "log in" flows of these popular wiki and blog implementations are typical of most online web services. They do allow external authentication, though they tightly couple the four components. As a result, incorporating an external authentication scheme is like hammering a square peg into a round hole; it's possible, but it's not easy, and the result is far from pretty.

Services using OpenID: Identify yourself with a username and authenticate with a password against an OpenID provider. The service usually has to link your OpenID username with a locally recognized identity. Generally, the service you're trying to access manages its own session and access controls.

In effect, you identify and authenticate against an OpenID provider, and the service manages its own session and access controls. The chosen OpenID provider, however, has its own session and access controls, which may affect the "log in" experience in unexpected ways.

Services using Facebook Login: Identify yourself with your Facebook username (E-Mail address), authenticate with your Facebook password. The service will establish its own session with the user, and apply its own access controls.

Facebook Login is complicated, but for typical web site authentication, you generally "link" an account on the service to your Facebook account (following more or less the OAUTH specification). You first "log in" to Facebook to receive a token. You pass this token to the service, which then uses it to establish a session with Facebook and retrieve the user identity.

As you can see, services typically want to manage their own sessions and access controls. They are, however, more easily able to delegate the identification and authentication tasks. Unfortunately, once you involve external authorities in the "log in" flow, the behaviors of the external authorities start to creep into the "log in" experience. For example, OpenID and Facebook Login have their own sessions and access controls that play a role in the overall "log in" flow. Overlapping functionality adds confusion over who is responsible for what.

In addition, some authorities like Facebook Login have their own agenda. Facebook Login caters to the interests of the main Facebook service, and the specification evolves to meet their own needs. As some StackOverflow users observe, Facebook Login has changed a lot in the not-too-distant past, and as it changes, Facebook just drags the developer community with them whether they like it or not.

Ideally, an external authority is a dedicated third party that doesn't carry the baggage of additional capabilities or requirements. External authorities should focus only on identification and/or authentication, which are the two parts that are easiest to delegate. All external authorities must be able to satisfy some basic integration concerns:

How do I get the identity of the user?

Who should verify the identity?

How much do I trust the authorities that verify the identity? (Is their authentication scheme appropriate?)

What happens if the authority is compromised or not otherwise accessible?

If the external authority includes session and access control capabilities, some additional questions may apply:

Who initiates and terminates a session? (Can it be done by the external authority?)

Who is responsible for the privileges? (What privileges should I associate with the session?)

What happens when a session/privilege on the authority changes?

Organizations that have balked at the monumental engineering task of integrating an external authority in the past should take another look at today's new authorities. The recent crop of dedicated authorities all have a much smaller integration footprint. In fact, some authorities such as YubiKey and CryoKey don't involve any sort of session or access control at all. Even if you are a one-man shop with little time, you should be able to make use of one of the modern external authorities, given the options available.

Do you have any experience in integrating external authorities? Please share with us if you do!

[cryokey]

Multiple Authority Authentication

Multi-factor authentication has been pretty effective to date for protecting accounts. Probably the most recognizable second factor (to the general population) has been one-time passwords (OTPs) or those short term PINs found in RSA tokens. Various groups such as E-Trade and even Blizzard have deployed a form of these tokens, where authentication relies on your actual username/password combined with the current code on the token's display. Other organizations such as Google have come up with their own second-factor OTP solution based on SMS.

With multiple authentication factors, if an attacker should defeat one scheme, then the other scheme(s) would still be able to protect the user. For example, when hackers stole RSA's master secrets back in 2011, they didn't automatically gain access to the accounts of every RSA token user. Security may have weakened, but access still depended on other factors (typically the original passwords of individual users).

The RSA breach also demonstrates that compromising an authority is basically equivalent to compromising the authentication factors that it represents. The factors in use wouldn't matter, since hackers could theoretically have the power to steal passwords, generate new tokens, or reassign biometric signatures, among other mischief.

Sadly, no authority is invincible, and anyone who says otherwise is just trying to sell you something. Authentication services are obviously juicy targets because of the potential scale of the payoff (for the hacker). They are also arguably easier to break than any well-studied authentication scheme. A typical authentication service presents a larger "attack surface" because it involves more people and complicated internal machinery. Therefore, every authority must have a procedure to respond to their own worst-case scenario. (If they don't, then you should be alarmed, if not wary!)

Multiple authorities can save the day when credentials become unsafe, whether due to a compromised authority or due to direct theft from a user. Instead of one organization taking on the awesome responsibility of securing every user's identity, multiple strong identity authorities would share the burden. That way, hackers would need to attack on multiple simultaneous fronts, and authorities would be able to catch each other when one should stumble. In a true multi-authority scenario, nobody is the weakest link, because we are all in this together, as part of one powerful, pro-active, self-repairing link.

Independent sites/services are better off sharing the authentication burden for more practical reasons as well. An end-user service shouldn't need to invest the engineering and support to manage their own authentication schemes. They may depend on secure identification, but unless they specialize in security, they have their own products/services to deal with! Furthermore, if each organization had its own token, your pockets would eventually be overflowing with blinking, battery-powered dongles next to a fistful of traditional keys.

We're not just talking about giving users a choice of authorities. We're talking about requiring verification from multiple sources to log in (at the very least, one other source). Obviously, passwords will be a nuisance for multiple-authority verification. Fortunately, this current generation of authentication schemes (like LastPass, YubiKey, Persona, OneID, and CryoKey) make authentication so simple, checking against multiple authorities should have minimal impact on the user authentication experience.

In short, multi-factor authentication by itself isn't a magic bullet. Truly strong identification will make use of multi-authority authentication. Metaphorically speaking, each factor may represent a strong weapon, and an authority may represent a warrior. But if your village needs protection, one samurai may not be enough, no matter how many weapons he possesses; however, seven might make all the difference.

How many hurdles are users willing to go through to access their sites? What could a single site do to improve its own security if it is unable to incorporate multiple-authority authentication?

[cryokey]

Authentication Roundup

As a follow-up, I wanted to summarize the key points between the authentication schemes described in my last post. Comparisons are difficult because each scheme is so unique, and small details have major implications. But we can identify some of the more recognizable differences in this brief comparison matrix:

table { border: 1px solid black; } table tr td { border: 1px solid black; text-align: center; vertical-align: middle; } table tr td.heading { width: 15%; } table tr td.label { text-align: left; }

LastPass YubiKey Mozilla Persona OneID CryoKey Technology Password Hardware Certificate Certificate Certificate (Optional Hardware) Identity Any Any E-Mail E-Mail? E-Mail Authority Local Local/Central Central Central Central Feasible as Second Factor No Yes Yes Yes Yes External (Non-Browser) Functionality No Capable No No Capable Personal Data Form Fill None None Form Fill None Setup and Management Local Token Identity Provider Account OneID Account Existing E-Mail Account Internet Access Optional Important Required Required Optional Cost Structure Optional Subscription Per-Token Free Free (Optional Paid Services) Free (Optional Paid Services) Client Integration Dedicated Software Hardware Driver Browser Capability Browser Capability OS and Browser Capabilities Service Integration Pre-Existing Web API Web API Web API SSL Client Certificate (Web API Available)

Notes:

CryoKey works with the operating system certificate repository and the SSL protocol. Operating system certificate repositories such as MS Cert Store or Apple Keychain are very secure, and available to other local applications. SSL authentication flows are also very secure, having been thoroughly vetted over the years. Servers use SSL authentication extensively (seen by the padlock icon in the address bar for HTTPS sites). On the other hand, client certificates, to date, have been used only in government, military, and academia because of their relative complexity.

In contrast, LastPass, YubiKey, Persona, and OneID all work on a higher level. They manage their own credentials and verify security after the lower level protocols complete the connection. Therefore, CryoKey can actually augment these schemes, because CryoKey can authenticate the very communication protocols that the other schemes build upon.

Some people may say, "why is Persona listed as a centralized authority when it's actually distributed/federated?" We consider it centralized because you can't really distribute authentication. For example, you can't use Google servers to verify your Yahoo identity. Like OpenID, Persona acts more as a conduit for users to access the centralized authority of their choice. To the end user, the act of logging in using Persona certainly feels centralized.

LastPass and YubiKey (and also CryoKey) have the ability to work offline. Local authentication is useful in environments with limited network connectivity (due to security or other constraints). For ideal authentication, YubiKey needs access to the YubiCo servers. But YubiKey can work independently as a strong random password generator as well as other yet-to-be-developed functionality. LastPass only needs network access to update or retrieve from the centralized repository (to synchronize the passwords for multiple devices). Theoretically, it should work on local web applications even without a network.

Again, keep in mind that all authentication schemes are relevant. Multiple schemes are best because using multiple schemes allows one method to make up for any limitations of another. But if you have to pick only one, you should base it on your own values (or the preferences of your typical users).

What do you consider important from an authentication service? Do you value privacy and basic information, or do you prefer to establish more thorough credentials? Do you prefer a solution that still makes passwords available? What do you think about carrying around hardware tokens?

[cryokey]

Password Alternative Options

Over the past year, the password burden has been attracting increasing industry attention. When we started developing CryoKey a while back, the only alternative authentication scheme was OpenID, which is primarily a password-based framework with a fair level of acceptance. In the end, our frustration with passwords and authentication drove us to come up with our own solution. But now, many great minds are rising to the challenge of finding a successor (or at least a companion) to password authentication. I'm very excited by the thought that I will soon be free of password creation, maintenance, recovery, and all of these malicious users trying to steal passwords and account databases.

We're now starting to see a lot of development on the necessary authentication technologies that may someday liberate users from the burden of excessive password use. Several promising services are now available at various stages of polish, each with their own vision of user identification and authentication. In addition, the FIDO alliance aims to bring different authentication schemes together by providing a set of standards that simplify their adoption and use in web authentication. But with all these options comes confusion, since each technology works in a different way, and each solution has its own specializations.

Here is a brief rundown of a few of the more promising models that stand out (in my opinion):

Centralized Password Database: LastPass

LastPass is one of the most popular password database applications around. They allow you to easily store account information and fill in account forms, and provide a simple way to quickly generate a strong random password as well.

Highlights: Since it simply adds another layer on top of passwords, LastPass can work with existing sites. Instead of individual site passwords, users only need to know one master password, and the data can synchronize to different devices.

Limitations: LastPass works only on web forms. It merely masks the password burden without actually solving the major problems with passwords. For instance, your individual sites still maintain user credentials, and the databases are still vulnerable to theft. You need LastPass software to access your credentials (especially if you let LastPass generate the passwords), or else password recall will be difficult on shared/public machines.

Physical ID Token: YubiKey

YubiKey is one of the better-known consumer hardware tokens around. It acts as a OTP (one-time password) generator that also automatically enters the password for you. YubiKey has partnered with other organizations (such as Google and even LastPass) for greater acceptance.

Highlights: Authentication relies on the presence of a physical object, so it's very secure. It's also very simple, and works well as a second authentication factor.

Limitations: A separate device is more secure, but also requires users to carry around another device, which some people may not like. You can lose/forget/break the key. It may not be compatible with all machines/devices. It also costs money.

Federated Cryptographic Single Sign-On: Mozilla Persona

The open-source community will obviously come up with their own solution as well. Mozilla Persona is basically a process/protocol that identifies users using an E-Mail address and authenticates them using public key cryptography. You log in to Persona to automatically generate a temporary key pair (valid for no more than a day), which the browser caches. Then, during a browser session, you can use the temporary credentials at participating sites to gain access. As a result, you only need one password to log into the Persona Identity Provider and generate short-term credentials, which are used to answer cryptographic challenges to prove your identity.

Highlights: As a Mozilla project, Persona is quite proud to be free and not-for-profit. Persona uses short term credentials with public key cryptography to enhance security. One Persona account (E-Mail address and password combination) will give access to all participating sites. Persona only needs to know your E-Mail address, so it's more private than other solutions.

Limitations: Not all sites recognize Persona, and not all domains will work as your identity (domains require an Identity Provider server). To generate credentials, you will need access to a Mozilla Persona provider. Authentication also relies on a third-party identity provider's availability and security practices. Identities can only be E-Mail addresses. Authentication requires a browser with local storage (HTML5) and cookies enabled.

Cloud-Based Device Certificate Authentication: OneID

OneID uses public key cryptography with digital certificates to identify users. Actually, OneID identifies devices (or rather, device-browser combinations), but these days, users generally don't share devices. After creating a OneID account, users can "activate" other devices, granting them the ability to authenticate as a user. When logging in, the OneID servers work with the locally stored certificate to prove your identity to a destination site.

Highlights: OneID is secure because identification relies on a private key that is generated locally and never leaves the device. Authentication is as simple as logging in with a button click. You can also store personal information with OneID for easy form-filling.

Limitations: OneID generates and stores keys in local storage, so it requires a capable web browser (HTML5) to function properly. OneID seem to lack the ability to identify multiple accounts, since it ties a single account to a single device/browser combination. Browser "private sessions" may disrupt usage (since local data may go away at the end of the session or when cleaning browser data).

Client-Side User Certificate Authentication: CryoKey

Last but not least is CryoKey, currently in a technology demonstration/shakeout state. Generate credentials with a simple E-Mail verification, and use credentials by merely selecting your identity with a click when accessing a participating site. Like OneID, CryoKey uses certificates and a cryptographic challenge to identify users. Like Persona, your E-Mail address identifies you, and we don't keep any other information. However, CryoKey works at a lower level by tightly integrating with existing browser/operating system services, technologies, and protocols to the fullest.

Highlights: CryoKey is simple, secure and free. CryoKey can provide limited identification even without network access. A single device/browser can host multiple identities. Users only need access to an E-Mail account when generating credentials, and don't create a separate account with CryoKey. Credentials are available through operating system services, allowing external (non-browser) applications to use the identity for general purpose cryptographic functionality. Credentials can also integrate with hardware tokens (in fact, we briefly had a demo token during development). As a result, credentials are available for a wide range of external uses from mail signing to data encryption or even scripted authentication (such as automatically authenticating a server application to a MySQL database in a Perl script).

Limitations: Not all sites recognize CryoKey. Actual user experience depends on browser and operating system interfaces and security models. Since basic credential generation depends on access to the E-Mail account, CryoKey is not suitable for authentication of E-Mail accounts.

This analysis is based on a cursory review of a few existing services. Actual technical details require a lot of digging because most of the more advanced solutions simplify their descriptions to avoid drowning users in the frustratingly complicated world of computer security. (If you want to see what I'm talking about, take a look at Persona's technical details, which contain terminology and concepts that require a strong understanding of security considerations.) I tried to simplify the analysis by keeping it at a high level, so if I made some serious misrepresentations or omissions, let me know.

Before people start a holy war about "which solution is best", I want to stress that, despite any limitations, each service provides a worthy solution to today's password burden. Besides, as development continues, I expect most of these limitations to disappear. In any case, different schemes can and should co-exist because each person/organization has its own use cases and values. Furthermore, identity services should be working together to stand up against the growing capabilities of malicious users. No solution is perfect, but one scheme may cover for the limitations of another scheme, and different solutions working together would establish even greater identity assurance. I can imagine a future where a secure site like a bank would require at least three independent identification sources to log in; that would be truly distributed authentication!

What are your experiences with alternative forms of authentication? Are there any other technologies that you think deserve mention?

[cryokey]

Apparently, computer security is an incredibly boring subject. Just the mere mention of security topics causes eyes to glaze over. Therefore, a friend challenged me to describe CryoKey without using any trade terminology.

Describing CryoKey without terms such as "certificate" or "key" is like writing a love song without using the word "love", or playing Scrabble without the letter "R", or even describing the Last Airbender movie without expletives. I tried to draw a diagram, but threw it away because it started to look like the Tokyo subway map. At that point, I gave up and headed to a bar (where all great ideas are born). At some point during that evening, I was talking about Yuko Oshima when inspiration struck.

Imagine that a friend of mine is pining for his favorite super idol, Yoko Kojima. He may know her, but she doesn't know him. However, both of them know and trust me. So, being the noble wing-man that I am, I offer to help my lovesick friend arrange a romantic rendezvous. Then:

Over a tear-splashed beer, my friend tells me that his life is simply not worth living unless I can set him up with Yoko Kojima, and gives me his phone number.

I record his phone number, then choose a time and place for the two to meet.

At the specified time and place, he meets Yoko and hands her his phone.

Yoko calls me using my friend's phone, and I check the Caller ID to see if it matches what I am expecting.

If the phone number, time, and place all line up, I confirm his identity to Yoko.

He then proceeds to have a hot date with Yoko Kojima. Sparks fly, and everyone is happy (except maybe Yoko Kojima's other #1 fans). Who knows where this budding romance will go? And it's all thanks to CryoKey!

This hypothetical blind date roughly illustrates CryoKey's Lightweight Authentication model, which is used by our WordPress plugin and MediaWiki extension. So if you want to experience what it's like to be set up on a blind date with your favorite idol, then visit a WordPress or MediaWiki site that uses CryoKey. Just keep your expectations in check; in practice, it's not that exciting, and everything happens so quickly, it'll be over before you know it. Oh, and, Yoko Kojima is not actually involved. Sorry to disappoint.

I'm sure people will have questions about these steps. Most notably, pop idol Yoko Kojima doesn't actually exist as far as I know, so don't ask me to set you up. (In fact, I don't know any idol singer superstars at all, but I can dream!) Keep in mind that I'm greatly simplifying the explanation with metaphors so that I wouldn't have to use terms such as "certificate" or "key". In reality, CryoKey is considerably more involved and thorough.

[cryokey]

Federated Identities

Today's online identities are moving towards a "federated" model. A federated identity consists of information tied to a single account that multiple services may recognize. All identities (even federated ones) depend on two components: the authority that generates the identity and the authority that checks the identity. As an example, suppose that your identity consists of a Yahoo! username and password. When you create a Yahoo! account, Yahoo! is the generating authority. Thereafter, only Yahoo! can verify the authenticity of the identity. (You can argue that biometrics don't require identity generation, but at some point, an authority has to link the biometric signature with an identity. Otherwise, the biometric signature is just meaningless data.) When people think about federated identities, they usually think of OpenID, one of the oldest systems around. But some people may have the wrong idea about OpenID. It's not some sort of "decentralized" or "distributed" identification authority, as I've heard some people describe. So let me clarify one point: OpenID is not an authority; it's really just a standard way for sites to use federated identities from various centralized authorities (providers). Each OpenID provider generates and verifies its own identities. In other words, OpenID authentication ultimately requires a single, central authority. Consider the consequences if, say, Yahoo shuts down tomorrow. Well, all Yahoo! OpenID identities will disappear as well. You can't very well use a Google OpenID provider to authenticate your Yahoo! OpenID account. (Well, maybe if Google buys Yahoo!, they can choose to share user databases, but by then, they've become a single authority.) Now, the greater technology community loathes centralized power, which may be why many people want to believe that OpenID is decentralized. After all, critics often question the tremendous power of centralized organizations (such as Spamhaus and its control over the fate of mail). I also agree that centralized authority is usually a deal breaker. Unfortunately, while you can decentralize the use of your identity (by using it with multiple services), authentication must be centralized. At some point, some authority has to be able to declare that a particular identity belongs to you, and the only one who can really verify an identity is the one who created it, no matter how that authority delegates the final verification. Some people claim that other federated identities such as Google, PayPal, Facebook, and even CryoKey are somehow more centralized than OpenID. In reality, these authentication system are no more centralized than any particular OpenID authority/provider. They all provide federated identities and a single sign-on authentication flow, though outside of OpenID, the other authorities are fragmented and cumbersome. Furthermore, external authentication is normally just an option (unless a site actually chooses otherwise). In fact, blending multiple optional authentication systems is a great way to participate in a truly distributed authentication system. A truly "decentralized" or "distributed" authentication system can't rely on any one authority/provider, which rules out OpenID. In a "decentralized" authentication system, multiple authorities would be able to verify a single identity. But allowing multiple authorities to verify an identity just exposes the identity to more vulnerabilities. On the other hand, a "distributed" authentication system would require identification from multiple authorities. Think of the kinds of identification you must present when you get a job; you normally need at least two forms of ID, but you get to choose from a list of allowed identifying materials. The Internet equivalent would be requiring at least two accounts for identification from a list of maybe a dozen possible authorities. Anyway, most sites don't really care if authentication is "decentralized" or "distributed". Most sites only care about single sign-on, which is just one part in the larger world of federated identities. And users do welcome federated identities because they're tired of creating and managing their hopelessly overflowing closet of accounts, most of which they rarely use. Theoretically, federated identities would help reduce the sign-up barriers for new users and encourage repeat visits. I personally avoid creating new accounts because I don't want to add another account to my manifest, and if I can't remember a rarely-used account, I'd rather just avoid the site altogether than go through a forgotten password flow. Sadly, to date, most of the smaller and more casual sites haven't adopted the various single sign-on implementations because of the back-end complexity combined with the fragmented authorities. Higher security sites also avoid federated identities due to trust/security concerns. The gains are simply not worth the efforts, especially for smaller operations. We built CryoKey to address the limitations of existing single sign-on solutions, especially in cases such as limited network connectivity and multi-factor capabilities. CryoKey is very good at augmenting existing authentication, and fits in very well in truly distributed authentication systems. Services that need strong security can incorporate CryoKey without adding to the usability burden. And we're constantly making improvements to simplify integration with existing sites. As a bonus, CryoKey is also easier to embed into client applications (although these days, most applications have moved to the web, so client integration isn't as important now). CryoKey also has one fairly useful feature: it can generate identities for any domain without requiring any special "provider" implementation. As a result, any domain can now offer a federated identity. In contrast, other systems work only with specific domains. In the case of Google's federated login system, you could log in using any Google account, including accounts in domains managed under Google Apps. In OpenID's case, a site would need a complex "provider" implementation to recognize identities for their own domain. But what if you wanted to use external identities such as your hellokitty.com account? Yeah, CryoKey can do that - without any additional effort! Single sign-on solutions are currently very fragmented and difficult to integrate. Every provider has its own solution to meet its own agenda, which just pushes more complexity to the integration process. OpenID, though relatively popular, is no magic bullet either due to its own complexities and points of failure. But CryoKey is different because we are solely an identification service, so we don't have to confine our authentication model to meet other internal requirements. As a result, we can take the necessary steps to dramatically lower the barriers to using single sign-on authentication. CryoKey is an option that we hope everyone will consider if they're looking for a simple identification solution.

[cryokey]

For most people, this is old news, but... Back in January 2013, Apple quietly closed a significant long-standing vulnerability where iTunes communication were flowing through regular HTTP without encryption. In other words, malicious third parties could easily eavesdrop on usernames and passwords traveling in the clear. Hackers even had enough power to tamper with communications, changing requests or installing unsolicited software. This flaw may very well be the root cause of the infamous Towson hack, which had been going on for years (since at least 2010) without any answers. This recent iTunes lapse is just another example of the increasingly frequent leaks of user information online. Even if malicious third parties don't immediately use their ill-gotten data, all of that user information is quite valuable, and you should assume that they will end up on the information black market. Still, most people will not notice any effects from any particular breach, as the number of hackers and attacks are still relatively low compared to the size of the data sets that they acquire. Working through such vast data takes a lot of effort, even for hackers. But don't let the scale of the problem lull you into a false sense of security. The same advances that makes technology more accessible to everyone also serves to make hacking accessible to a larger audience as well. And as time goes on, technology gives hackers more capabilities, allowing them to attack more frequently and do more damage with each success. If you're one of the pro-active information systems professionals who actually cares about securing the future of your online service, then what can you do if everyone's personal information is already floating around in the wild? Account recovery is normally based on personal information, after all. The answer is to incorporate identification and authentication techniques that AREN'T simply based on personally identifying information or shared secrets committed to memory. Even better, security-critical environments should blend in multiple authentication factors. Unfortunately, as I've been describing in past posts, every mode of authentication has advantages and disadvantages, and multiple factors also multiplies the level of inconvenience. While users do value security (because a security breach is a tremendous hassle), to most of them, identification and authentication is just necessary overhead that most of them would rather skip. Users don't go to sites because they're excited about authentication. They only jump through authentication hoops because they have to - if they want access to the juicy goodness behind those armored gates. Security is a shared responsibility. While most people will just shrug in resignation at these breaches and keep doing what they're doing, services have a little more responsibility because they are the ones that ultimately decide on how to protect their content. Therefore, they have more power to effect positive changes. In contrast, end-users can't do much more than encourage sites to protect their personal information better.

[cryokey]

Token-Based Authentication: How CryoKey Fits In

Do you hate passwords? Well, join the club. And even if you don't necessarily hate passwords, you must recognize their limitations by now. But what other options are really feasible today? Out of all the current authentication factors, token-based authentication may have the most upside as a password alternative. Tokens are pretty intuitive; if you have the proper token, you get access. People have been using various access tokens for thousands of years - keys, signet rings, tickets/vouchers, and so on. Modern day tokens are quick and easy to use, and can be replaced if lost/damaged. They are more accurate than biometrics and less error prone than passwords (since they don't rely on memory). On the other hand, they do cost money and take up space. They can also be lost, stolen, or damaged. They're also not very general; a key, for instance, may open a specific door, and a signet ring only identifies you to people who recognize the insignia. To date, digital tokens have had very limited visibility to the average user. Government and academic institutions use them in very high security applications. Some businesses have started to adopt hardware tokens as well, usually with some kind of one-time-password generating token. But the current approach to digital tokens will eventually lead to a nightmare scenario where you have one token for your E-Trade account, one for your Blizzard Battle.net account, one for your work VPN, one for your Apple ID, and so on. These tokens just don't inter-operate, and they end up scaling just as poorly as passwords. They are also very hard to actually deploy on the server side. Each organization need a token distribution infrastructure as well as significant configuration and synchronization on the back end. The cost and complexity of tokens basically rule out acceptance by smaller services. CryoKey aims to make cryptographic token-based authentication available to a much larger audience by balancing strong security with simplicity and convenience. We created CryoKey to bridge the gap between the expectations of secure token-based authentication and the realities of everyday computing. CryoKey addresses the major problems of current token-based authentication solutions: cost, inter-operability, and accessibility. First and foremost, CryoKey is free for both users and services. Users won't have to buy a token that's subject to loss, theft, or damage. Service providers don't have to invest in a complicated back-end to recognize custom tokens. In addition, users don't have to purchase software such as password managers or hardware such as cumbersome fingerprint readers. CryoKey works with the preexisting capabilities found in all modern operating systems (including tablets and smartphones). As a single sign-on authority, CryoKey is not subject to the same inter-operability issues as private token schemes. As a result, users won't have to accumulate hulking key rings filled with access tokens. From our perspective, you already have a token: the device you're using! These days, you have to identify yourself to your device first before you can use it. A separate token is just needless overhead. So our solution makes your device your key instead! And unlike services that deploy their own independent solutions, CryoKey is a pure third party authority that focuses on general purpose identification and authentication. Any service is free to recognize CryoKey, and users are able to use the same existing credentials on all participating servers. Current development on certificate-based authentication focuses on developing ideal authentication systems with absolute assurances at the cost of convenience and usability. Most sites won't consider these solutions because complex identification schemes would only repel users on the majority of sites that people visit every day. Therefore, rather than force sites to make huge sacrifices for security, CryoKey simply aims to raise the bar on password-based security by providing a much simpler and easier to integrate certificate-based authentication model. While a simpler authentication model is useful for many sites, CryoKey is also flexible enough to work as an additional factor in situations that demand additional security. In the end, we can extol the virtues of CryoKey until we're blue in the face, but it's up to users and especially site operators to try it out and see for themselves how CryoKey improves account access. Whether you're a user or a webmaster, we hope that CryoKey will be useful to you. We'd be happy to help if you are trying to integrate CryoKey into your site, and we'd love to hear your comments one way or the other!

[cryokey]

Passwords and the Weakest Link

Passwords have certainly had a bad rap lately. Security experts have been raising alarms about the "password problem" for years now, and some high-profile security breaches over the past few years really punctuate their message. When they complain about the "problem with passwords", they point out a laundry list of concerns such as password strengths, social engineering, and lax information protection practices, to name a few. But let's not understate the value of the password! It's certainly an admirable technology that served the Internet well during its formative years. Passwords are very compelling because they're intuitive and cheap. Users are responsible for protecting their passwords, so creating and remembering passwords does incur some overhead. Still, when you look at a password system in isolation, you can see that the security it provides is surely worth the minor inconveniences. To understand the problem with passwords, just take a peek at the password "best practices" advice. Today's best practices ask users to create a separate password for each account. The passwords should be at least 8 characters with a random mixture of case, numbers, and symbols (the allowed symbols vary from service to service). The password should not be memorable/predictable, such as a birthday, name, or dictionary term. Furthermore, you should change your password periodically, and never recycle, re-use, or share passwords with others. You also have to be careful when you use passwords as well. Don't enter them into unknown forms. Customer service should never ask for your password, so don't send them even on request. Be wary of sending passwords over public networks. Keep your machine secure to avoid key loggers. Don't let others see you type your password. Avoid entering passwords on public or shared computers. Also, never write down passwords; a secure password should only ever reside in your memory. These "best practices" are just off the top of my head, but they represent the most common advice. Taken in isolation, they seem reasonable, and definitely ensure secure password usage. Unfortunately, today's Internet is unbelievably diverse, and users now have to manage numerous passwords, revealing the password's ultimate weakness: scalability. Nobody follows the "best practices" because they're simply impractical in today's computing environment. No matter what you tell them, people are going to just do what's convenient: use a few simple passwords among a multitude of different accounts. Most of the accounts aren't of very high value to them anyway. And some of the "best practices" such as password complexity and periodic changes do more harm than good. Besides, most people don't take security seriously, and think that identity fraud won't happen to them. Those of you who HAVE been hacked know what I'm talking about: these are the people who constantly poke fun at you with comments like, "You're being paranoid! You're overreacting! Why are you going through all that fuss? I'm not concerned, there are better targets for fraud than me." And so on. But part of the cavalier attitude comes from the industry itself, which wants to assure people that the net is safe, or else Internet commerce would die. So when a major account database like Epsilon or Blizzard gets hacked, they try to assure you by downplaying the fallout. But guess what: you can recover a password with the stolen personal information, which, if you think about it, is arguably MORE important than any single account password! Internet services recognize the password security dilemma, yet instead of trying to simplify their systems, they stack more complexity on an already complex problem. They demand stronger passwords, and now multiple passwords and "secret questions" and secret images and phrases. Some sites now even impose username restrictions. These initiatives only make life harder for the user, and pretty much guarantees a lost-password flow (or lost-username flow for those stringent username requirements) every time an occasional user tries to log in. A whole new software category of password keepers has popped up to address the challenges, but these solutions only sweep the problem under the rug. The underlying problem (the password burden), still remains. Each service still has to maintain and protect them. And in the end, the passwords can still be ex-filtrated through sharing or socially engineering. Unless, of course, you still follow the impossible password best practices! As many security experts in the past have explained, adding complexity only makes legitimate use harder, but doesn't necessarily guarantee any gains in security. In other words, you will definitely have a harder time securing yourself, but an attacker may not have any more difficulty compromising your account. After all, a system is only as secure as its weakest link, and it doesn't matter if you have a solid oak office door with an electromagnetic lock if someone can just go over the drop ceiling (or cut the power). Furthermore, security favors simplicity. A system that relies on many complicated modules is weaker because it exposes a larger "surface" vulnerable to attack (to put it one way), giving an attacker more options. Today's online services are also very long interdependent chains, so their fates are often tied together. Each one is a vital link to a user's overall security as much as the user's own password discipline. Unfortunately, each organization has its own security practices. Poor security practices combined with weak password discipline results in easy pickings for a determined hacker. Gizmodo's Matt Honan discovered this unfortunate reality himself in the summer of 2012 when a hacker exploited weak information disclosure practices in Apple and Amazon to gain access and subsequently take over all of his other accounts from the initially compromised account. I know my post may be TL;DR for many, so bottom line: the "problem with passwords" isn't that passwords are a bad technology. The problem is actually password overuse combined with the industry's unrealistic assumptions and expectations about password best practices. Why must users suffer under the yoke of these so-called "best practices" for so many passwords? Why are individual services constantly re-inventing the wheel with their own password implementations, account databases, password/account reset/retrieval systems, and support staff to handle passwords? Even more confounding, why are casual sites like message boards, games, or your neighbor's gardening blog adding to the burden with their own password account systems? We wonder the same thing, which is one reason why we came up with CryoKey in the first place: as an attempt to create a simple, common identification model that seeks to reduce the password burden, not replace passwords altogether. We believe that keeping a few high-strength passwords for critical accounts and deriving password-free identities from these accounts creates a solution the strengths of both passwords and digital certificates.