No more passwords!

The meme goes on and on, and honestly, some of OneID’s own messaging contributes to it.  But what do we really mean when we say that passwords are an obsolete technology, ripe for replacement?

Three classes of evidence for authentication, called authentication factors, are generally recognized.  From…]]> Passwords must die!

No more passwords!

The meme goes on and on, and honestly, some of OneID’s own messaging contributes to it.  But what do we really mean when we say that passwords are an obsolete technology, ripe for replacement?

Three classes of evidence for authentication, called authentication factors, are generally recognized.  From NIST Special Publication 800-63-1:

• Something you know (for example a password)
• Something you have (for example, an ID badge or cryptographic key)
• Something you are (for example, a fingerprint or other biometric data)

Given the issues associated with the use of biometrics for remote authentication, the something you know factor can’t be ignored.  You can call them passphrases, PINs, or whatever, but they’re really passwords.  And as a team of respected researchers has pointed out, using passwords for authentication isn’t all bad.  So what, exactly, are we trying to get rid of?

Passwords, as they’re usually implemented, present two major problems:

• Users need to keep track of many complex passwords for websites and other internet services they use.
• Password databases at popular websites are being breached with increasing frequency.

The first problem is getting worse as more people, not just geeks, use more and more things on the internet. Of course, it’s important not to reuse passwords on multiple websites, lest the compromise of a single site have a broader impact for you. Passwords need to be complex so that they cannot be guessed, even by an automated “dictionary attack”. Password managers, provided that they are sufficiently secure and available to you on all the devices you use, do address these problems.

But password managers do not address the second, server-side, problem. Even for users who have complex passwords, the increasing performance of computers and the availability of cloud services and botnets with vast computational capability make it possible for attackers to try huge numbers of possible passwords against hashed values stored in the database. The use of “salting” techniques helps this problem to a degree, but recent research on compromised password databases has shown that as many as 86% of the passwords can be recovered in 30 minutes using modest computing resources. This problem is only getting worse as computational capabilities improve further.

OneID approaches something you know secrets (OneID passwords used on browsers and PINs used on the OneID Remote app) differently.  Because all OneID-enabled devices have secret keying information, the keys can be used when verifying passwords and PINs in a way that is not vulnerable to password guessing attacks. It isn’t possible to verify the password without the key as well. So even if a user’s OneID repository is compromised, a dictionary attack is not feasible because it would require both the password and a 128-bit random value the repository doesn’t have.  If a user’s device with that key is obtained by an attacker, the repository limits the rate at which guesses will be processed, and the user is warned via email of a possible attack.

The problem isn’t with passwords (or whatever you might call them). The problem is with how passwords are used and verified.  Authentication based on something you know is an excellent defense against a stolen device. We don’t propose to make that go away, but to make it work in a more intelligent and usable manner.

Photo credit: Image “Passwords” by Flickr user paul.orear used under Creative Commons license.

Virtually every hot topic in payments assumes the future presence of some…]]> I recently attended the PYMNTS conference at Harvard University, along with some of the payments industry’s most successful companies.  The industry is abuzz with the opportunities about to be unleashed as the mobile device evolves into its new potential role as a digital wallet.

Virtually every hot topic in payments assumes the future presence of some form of digital wallet including:

1. Merchant POS technology and what it enables for store experiences
2. Mobile devices and location-based data
3. Mobile platform extensions – white-label mobile applications – as extensions to “internet-enabling platforms”
4. Omni-channel retailing – the role of the mobile phone to link online/offline customer behavior
5. Loyalty & promotions programs that the flood of potential new customer data unleashes.

As I listened to the many intelligent presentations and participated in the discussions, two things struck me:

1. Aren’t most of these digital wallet offerings all from the companies whose cards are in my wallet, not the wallets themselves?  It seems that in the switch from the traditional leather wallet to the digital wallet, industry players perceive an opportunity to change who they are as companies and brands.
2. I took out my own real wallet a few times and noticed that at the top of my wallet today is my ID card (in my case, a CA drivers license).  I had the honor of being a captain at the conference event called a Think-a-Thon, and I asked my team of industry participants representing banks, payment gateways, merchant and government participants, “what is at the top of your wallet?”  One hundred percent also had their ID card as the top of the wallet.

An omni-channel wallet experience (to combine some industry jargon into my own new derived term) would mean my offline and online wallets would be linked somehow.  Seems like the logical common denominator and the logical top of my wallet is still my identity.

While the online world allowed us to become many people and develop digital schizophrenia (adoll, alexdoll, adoll34, doll_ap, etc.) the offline world mostly still has us anchored as a single human being with one identity.  I am still just Alex Doll to most people that trust (but verify) my CA DMV card or my US passport.

Many of the great triumphs coming from mobile revolution involve the re-linking of our digital identities to our real identities.  Indeed the entire omni-channel experience so sought after by retailers is predicated on some common identifier between offline identity and online identity.  After decades of investment in data tracking systems (CRM systems) to identify and understand customer behavior, there is much knowledge already gathered.

Most big retailers, card issuers and banks are already trying to re-link our schizophrenic online identities to our real identities today via what they already have– cookies, credit card numbers, loyalty card numbers.   But PCI data has minimized the ability to use CC numbers as the search index and loyalty cards only work for the % of our customers.  As the distinction blurs in the omni-channel world, I can no longer hide in the anonymity of adoll@hotmail, but rather will quickly become linked by all the enabling technologies to the real Alex Doll, who owns and at a minimum can verify, adoll@hotmail account messages.

We use our wallets in the physical world for identity, authorization, payments of all types, loyalty promotions, holding cash, holding receipts and parking tickets.  The online world is mimicking the offline world once again, except it’s leaving out the hardest part of the equation.  The bottom parts of the leather wallet are all being linked quickly in the digital world – payments, loyalty cards, promotions.  And yet, the likely winner of the digital wallet of the future will recognize the inseparable link of identity with the rest of the wallet.  The true “Top of the Wallet” has and always will be my ID card.  The company that wins the wallet race will be the one that gets the final and hardest piece of the puzzle right.

What is the top of your wallet?

Photo “Carbon fibre wallet” by Flickr user rh1n0 used under Creative Commons license.

True or false:  Is adherence to compliance requirements a “good enough” security posture? If you’re in a CISO or similar role, adherence to relevant compliance requirements…]]> This article is the fourth in a 5-part series on two-factor authentication. For more information about the series, please refer to the introductory article.

True or false:  Is adherence to compliance requirements a “good enough” security posture? If you’re in a CISO or similar role, adherence to relevant compliance requirements might be good enough to keep you from getting fired, but it’s not good enough protection.

One reason is that compliance requirements lag current threats. Compliance documents are updated periodically, but the threat landscape changes much more quickly. In addition, compliance requirements frequently focus on preventing a recurrence of past breaches, rather than looking forward to threats that might be expected based on technology trends. A good example of this is the storage of hashed/salted passwords, which are becoming less secure every day as computing speeds advance.

This is also true of two-factor authentication. While the use of SMS for two-factor authentication is considered acceptable according to all compliance requirements I have seen, there are early indications, both from threats like Eurograbber and recent advice from a group of Australian telecoms that SMS is not as secure as people think.

It’s also important to distinguish between two-factor authentication and use of a second independent “out-of-band” device. Some requirements, such as the FFIEC “Supplement to Authentication in an Internet Banking Environment”, put somewhat more weight in the use of separate devices because of the potential for man-in-the middle and man-in-the-browser attacks.

The size, sophistication, and other characteristics of your user base should influence the form of authentication you use. Implementation of separate hardware tokens is often quite expensive for a large user base. Methods like SMS that require mobile phone connectivity can be a problem if some users are in rural locations, in addition to the security concerns mentioned above.

The best approach is an authentication system that supports different ways of providing two-factor authentication, out-of-band approval, and combinations of the above. Approaches that introduce too much friction for routine use might be welcomed when applied only to high-value or high-risk transactions. Having the ability to “tune” the authentication system by changing the threshold at which stronger authentication is required gives you the ability to minimize losses from fraud consistent with providing the best possible online experience for your users.

In tomorrow’s concluding article of this series on two-factor authentication, we’ll describe an authentication and identity management system that has these capabilities.

We’ve been hearing a lot about two-factor authentication lately.

For example, after the password files at Twitter and Evernote were stolen, both companies announced that they would be…]]> This article is the third in a 5-part series on two-factor authentication. For more information about the series, please refer to the introductory article.

We’ve been hearing a lot about two-factor authentication lately.

For example, after the password files at Twitter and Evernote were stolen, both companies announced that they would be rolling out two-factor authentication (2FA) for their user base.

It certainly sounds like a responsible thing to do.   Here’s how it typically works:

When you access a website for the first time from a new computer, the site will send you a code via SMS to your cell phone. You enter the code into your browser and then the site puts a cookie in your browser with a random number unique to that browser (we’ll call it the “2FA secret”).  It stores a copy of that random number in the site’s 2FA secrets file. From that point on, the site will only let you in if your browser presents the 2FA secret when you sign in with a username and password. That way, even if the password file is stolen on that site (or another site where you used the same password), and the intruders crack your password, they can’t get into your account because they don’t have your cell phone.  Without your cell phone, they can’t get a magic code number for their browser. Problem solved!

Unfortunately, for the individual and the site, the problem isn’t solved at all.

Here’s the rub:

After a site implements 2FA, the hackers will simply steal both the password file and the 2FA secrets file.

So the user has just done a lot of work to authorize each browser, but in the end, they are not much safer than they were before. All the 2FA did was force the attackers to steal two files instead of one file.

In fact, you are now arguably more at risk since the attackers will likely have more information about you than they had before (because they will probably also steal the file of cell phone numbers).

To recap: a password file breach attack caused the site to add 2FA for stronger protection.  But the manner in which 2FA is deployed only serves to create the same, or more, centralized information about the site’s user base that is susceptible to attack.

The other big secret of 2FA that makes it a weak solution is that the adoption rate of most 2FA implementations is under 1%. So rolling out a feature meant to protect users that fewer than 1% will actually use is no solution at all. It is good for PR, but it is useless from any practical perspective.

And sites will never require people to use 2FA because users will complain.  Justifiably so, because if every site did the same thing, you’d be spending a lot of time authorizing every browser for every website. So if you thought password management was bad, this is even worse.

While 2FA is not a legitimate response to prevent password file breaches, there are legitimate benefits of 2FA. For example:

1. 2FA protects your account from phishing and keylogging attacks
2. 2FA protects against cross-site password file breaches. If your account is breached on another site, they cannot use your email and password from Site B to log in as you on Site A if you used the same email and password on both sites. That is certainly helpful since about half of us use the same password on all sites.

Is there a better approach that ensures that password files can’t be breached, that nearly 100% of users adopt 2FA, and that eliminates the management issues of authorizing every device with every website (and de-authorization if you lose a device)? Absolutely! I’ll talk about two techniques that can accomplish all of these goals in Friday’s post.

Photo “(245/365) Mwah shhh ponder” by Flickr user Sarah G… used under Creative Commons license.

If you’re considering two-factor authentication, it’s instructive to consider some common attacks.  Of course, there are many more than five attacks in the world, but these…]]> This article is the second in a 5-part series on two-factor authentication. For more information about the series, please refer to the introductory article.

If you’re considering two-factor authentication, it’s instructive to consider some common attacks.  Of course, there are many more than five attacks in the world, but these should give a starting point for evaluating others.

Key Logging and Redirection

One of the most common classes of malware attacks is the keystroke logger, where the attacker is able to monitor your typing to retrieve typed login credentials (typically username/password). Two-factor authentication is typically effective against these passive attacks, since they include a one-time password component obtained from the device (e.g., hardware token or phone). However, malware could also redirect some of those keystrokes to an attacker, whom you have just enabled to log in as you.

However, if the two-factor authentication is securely bound to a specific transaction or login from a particular location, this attack is greatly mitigated. For example, the authentication can be issued with a challenge that only permits the login or authorizes a specific transaction from a specific location. The description of the transaction can also be communicated independently to the user, so that they know that what they’re authorizing is what they intend.

Man-in-the-middle attacks

Network-based man-in-the middle (MITM) attacks are typically dealt with by cryptographic network protocols (SSL/TLS).  However, forgery of fraudulent cryptographic certificates, while relatively rare, has shown flaws in this dependency. This can be accomplished by injecting fake root certificates in the browser’s trusted certificate database, or by compromise of any of the many root certificate authorities already listed there. If an attacker is able to become an undetected intermediary, they can perform all of the capabilities of the Key Logging and Redirection threat above, but with less presence (and detectability) on the user’s computer.

Man-in-the-browser attacks

Sophisticated malware known as a “man-in the-browser” such as Zeus allows an attacker to falsify a user’s browser display, making them think that the website is doing what they intend while actually it is doing something completely different, directed by an attacker.  The best countermeasure for this is the use of a two-factor technology that independently and securely displays to the user the nature of a transaction being approved.  Ideally, this independent display would be on a different device using an independent communications channel.

Account recovery

You also need to consider what happens if you lose one of your authentication factors (or if an attacker pretends to). If the response is to temporarily disable two-factor authentication, then an attacker might be able to social engineer the account recovery process to get access to the account. Worse yet, if you’re using knowledge-based authentication (“What was the name of your first pet?”) for account recovery, these answers are often very easy for an attacker to guess and provide much worse security. Remember that the attacker will pick whatever is the weakest point in your authentication system to attack. It was account recovery more than the lack of two-factor authentication that exposed Mat Honan to a widely-reported and devastating attack last year.

Third parties

Some two-factor authentication systems rely on third parties in connection with the issuance, verification, or communication with verification of physical tokens. The vulnerabilities inherited from third parties are best illustrated by the breach of RSA’s SecurID authentication system in 2011. Although the extent of the RSA breach isn’t fully known, it is thought that the attackers could have gotten access to information to create counterfeit tokens.

Authentication using SMS text messaging and other telephony-related means is dependent on the mobile carrier’s practices regarding reassignment of phone numbers. If an attacker is able to convince the carrier that they are the user and they lost their phone and need a new one, they would be in a position to intercept text messages and phone calls, providing the second authentication factor. This has led to a request from some Australian telecoms that banks not use SMS for two-factor authentication.

These attack examples illustrate the importance of thinking broadly about how two-factor authentication can be defeated. You can be assured that the attackers are doing so.

Photo credit: U.S. Air Force

Recent security breaches have thrust two-factor authentication (2FA) into the spotlight.  As is often the case, certain assumptions are being made or benefits implied that can…]]> This article is the first in a 5-part series on two-factor authentication. For more information about the series, please refer to the introductory article.

Recent security breaches have thrust two-factor authentication (2FA) into the spotlight.  As is often the case, certain assumptions are being made or benefits implied that can mislead the decision-maker looking to incorporate 2FA.  Here are five common myths:

Myth 1:  If you have suffered a breach, turning on two-factor authentication for your users is a good quick fix.

Reality: Most sites can’t simply “turn on” two-factor authentication. Deployment of 2FA requires the issuance of tokens or cryptographic keys that are embedded in other devices, which requires user participation. If you suddenly start requiring 2FA for access to your site, many of your existing users won’t have the necessary means to log in, and will either clog your support queue or give up and go elsewhere.  But if you don’t require 2FA, most users won’t bother to enroll in it regardless of the security benefits.

Myth 2: Two-factor authentication is not susceptible to common threats.

Reality:  While two-factor authentication does improve security, it’s not perfect, and it attracts attackers because of its use for high-value applications. Most two-factor authentication technologies don’t securely notify the user what they are approving, so an inattentive user might approve an attacker’s transaction without knowing it. Third-party authentication tokens can have dependencies on the security of the issuer or manufacturer that may not be obvious until a breach, such as the March 2011 breach of RSA SecurID tokens.

Telecom-based technologies, such as text messaging (SMS), have specific dependencies on the security of the mobile provider, which is chosen by the user. A service using SMS can be vulnerable to any of a number of telecom providers’ practices regarding reassignment of phone numbers or security of messages. Malware on users’ phones that intercepts SMS messages and sends them to an attacker is also becoming more common.

Myth 3: Two-factor authentication is synonymous with ‘incorporation of a second device’ and cannot be accomplished effectively on a single device.

Reality: As users move to smart, personal devices, it has become more practical to load keying information into those devices in a manner that is tamper resistant enough to provide a high degree of security. For example, if properly designed, a smartphone application can manage keying information and prompt the user for something they know. It would then (as is done by OneID) use cryptographic techniques to prove that the user was in possession of the cryptographic key and knew the memorized factor without the need for those secrets to ever leave the user’s device.

Myth 4: Most 2-factor solutions are similar with only minor differences in approach.

Reality: While early two-factor solutions largely relied on hardware “tokens” that produced one-time passwords, the past few years have brought considerable innovation to 2FA. Many solutions involving SMS messages or other telephonic means are available. Others, notably OneID, provide 2FA using either a mobile application containing a cryptographic secret, or through keying information stored in the user’s browser. The degree of reliance on third-party services (either authentication service providers or telecom companies) is also a factor to consider, since breaches in these services have in the past resulted in authentication failure.

Myth 5: Two-factor authentication is an annoying compliance requirement with little material benefit to the business.

Reality: Some businesses do treat two-factor authentication as only a compliance requirement, rather than an opportunity to reduce fraud. Some even use technologies that barely qualify as two-factor solutions, such as browser fingerprinting, in an effort to meet compliance requirements while minimizing user impact. A far superior approach is to use a flexible authentication mechanism that requires 2FA for higher risk transactions, while giving users the convenience of single-factor authentication for common, lower risk operations. This balances the convenience of users with the benefits of fraud reduction.

The movement toward two-factor authentication is a good one, but like any trending technology approach, it’s important to read through the hype and understand the true benefits and costs. Adopting two-factor without really considering the problem to be solved and the differences in solutions in the market, can burden users while providing little security benefit. Through the remainder of the week, we’ll cover more key elements of an effective two-factor authentication deployment.

Up tomorrow: Five Common Attacks and How You Can Protect Against Them.

As a precaution, we changed the password on OneID’s Twitter account recently. To my surprise, the mobile apps…]]> Perhaps one of your accounts has been hacked, or you think it may have been, so you change the password.  Is that enough to make sure your account is secure?  If the account uses OAuth, perhaps not.

As a precaution, we changed the password on OneID’s Twitter account recently. To my surprise, the mobile apps that I use to access Twitter didn’t require me to log in again after the password change. This is because Twitter uses OAuth tokens to authorize apps that need to access your Twitter stream. OAuth tokens (the digital “permission slips” giving access to your account) behave in many ways like persistent (stay logged in) browser cookies in granting access to your account.  But tokens are not automatically revoked when you change your password.  This is in sharp contrast to browser cookies:  If you have several computers where you have logged in to Twitter and you change your password, you need to log into each browser again following a password change.

When you change your password, Twitter does display a message like this:

Unfortunately this message doesn’t tell you why you ought to review your applications.  If someone compromises your account, they can authorize their applications to access your Twitter account on your behalf.  To effectively lock down your account, you need to make sure that the attacker can’t continue to use those applications.

But it’s worse than that.  OAuth tokens are typically issued once per application, not once for each instance of the application. So even though I use Echofon on my iPhone, iPad, and Mac, only one OAuth token is issued for Echofon and is shared by those devices. As a result, the Twitter Applications page (https://twitter.com/settings/applications) can only show the list of apps that you have authorized, but not where (or in how many places) this has occurred. So if an attacker had gotten access to my account and authorized his or her own copy of the Echofon, I would have no way to see that this has occurred. It really isn’t possible to determine whether all of the authorizations are under your own control; there isn’t enough information.

I don’t mean to single out Twitter here; I have observed that Google+ also doesn’t invalidate tokens on password change, and doesn’t remind you (as Twitter does) about authorized apps when you change your password. As far as I know, there is no guideline recommending that issuers of OAuth tokens revoke the tokens when a password change takes place. This, to me, is an oversight: OAuth tokens should, by default, have exactly the same behavior as persistent browser cookies.

With the use of OAuth by services like Facebook, Twitter, and Google to provide identity management services, users need to be better educated in how to lock down their accounts, manage authorizations they (or attackers) have made, and need to be given visibility to what all of the authorized endpoints are. In the absence of that, tokens should be revoked by default when users change their password.

Image “plastic token” by Flickr user Token Company used under Creative Commons license.

Stuart McClure, CEO/President of Cylance, summed it up the best during our recent panel discussion, ‘What Should Twitter Do?,’ when he said, “Passwords are utterly…]]> Last week at the RSA Conference, we invited some industry folks plus key journalists for a panel discussion asking the question, “What Should Twitter do?” and here’s what we heard.

Stuart McClure, CEO/President of Cylance, summed it up the best during our recent panel discussion, ‘What Should Twitter Do?,’ when he said, “Passwords are utterly useless. ”

The former McAfee executive and noted author on hacking delivered some pointed comments during the panel discussion. “We’ve known about this security flaw, but until it comes out [in a breach] no one believes you.”

Just weeks before the RSA conference, Twitter was (again) hit with a security breach. Personal data from 250 user accounts were compromised. Shortly after, reporters came across a job posting that suggested Twitter may be implementing two-factor authentication, prompting media speculation about what Twitter should do.

The answer was ultimately not much. Added our own founder and CTO Steve Kirsch, also a panelist, “No matter what [Twitter] does from an engineering point of view, it cannot prevent a mass breach.”

The Wall Street Journal, MIT Technology Review, ZDNet, Dark Reading CRN and Frost & Sullivan attended to watch McClure and the rest of the security experts spar over security technologies and whether the password is DOA.

Rachel King of ZDNet did a terrific take on the panel and captured some of the greatest sound bites. It was a broad, far-reaching discussion concluding there isn’t much Twitter, or any other company relying on usernames and passwords, can do to fully secure their infrastructure from a password hack. The technology is too old, hackers are too good, and people are just too easy to fool. “It’s hard to engineer around human fallibility,” said John Bradley, senior technical architect for the office of the CTO at Ping Identity. “We’ve been trying for thousands of years.”

Moderator Jonathan Heiliger, former Facebook exec and current North Bridge Venture Partners investor, opened the discussion pointing out that the primary goal of user security these days is to make it financially unfeasible to be a password hacker. This was a common sentiment. As Jon Callas, former CTO of Entrust and co-founder/CTO of Silent Circle, put it, “If you can force the bad guy to go from wholesale hacking to retail hacking, we’ve won a lot.”

The industry and government is wrestling with new ways to approach security, according to Bradley. “The US government is encouraging standardization with the idea that once you start accepting federated identity providers in a non-exclusive, open standard way, you don’t have to have big relying parties. It could be OneID.