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.

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.

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.

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.

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.

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:

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.

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

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 mysql@example.org 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!

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

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

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

    # wget https://www.cryokey.com/ca.pem
  3. 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.

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

  5. 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
    ...
  6. 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

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

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

  3. 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/CN=a@b.c’.

—- MYSQL USER ACCOUNT MANAGEMENT

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

  2. 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!

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:

  1. Identification: Who are you?
  2. Authentication: Prove that you are who you claim you are.
  3. Session Management: Establish a working relationship based on the credentials.
  4. 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!

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?