OAuth is a protocol that lets applications request data or privileges you have on a remote service without you having to provide your credentials for that service. A classic use case for this “valet key” system is contact import – you can let a site load your address book from Gmail without giving that site your actual Gmail password. Twitter recently required that any third-party applications using their API must authenticate using OAuth.

Twitter’s implementation is based on OAuth 1.0, which was finalized in April but has been in development for several years and is already widely supported. But work on a new version is now under way, and Facebook has already implemented one variety of the draft specification for applications that connect to their service. OAuth 2.0 currently defines specific flows, or client profiles, for handling authentication: Web Server, User-Agent, Native Application, and Autonomous. The first two are most commonly used for web applications, and implementations of the third may end up being quite similar.

The process for most clients involves three broad parts. (Note that “client” in this context refers to the application seeking access, not the person using the application.) The first involves user authentication. For a web-based service, this will often mean ensuring the identified user is currently logged in and then asking for their permission to enable access if they have not previously granted it. Second, the client has to authenticate. In other words, the client making the request has to prove it is the same application that the user granted permissions to in the first step. If both of these steps complete without error, the client is given means to access the protected resources, typically with a temporary code known as an access token.

The specific details of how these steps happen depend on the client profile used. Facebook’s standard Graph API authentication is an example of the Web Server flow. When first requiring access to private user data, a third-party application will forward the user’s browser to Facebook’s authorization server. The request includes a public code identifying the application and a URI under the application’s control. Facebook prompts the user for the permissions and (if they are granted) redirects the browser to the provided URI, along with an authorization code. The client then makes a request directly to Facebook which includes this authorization code and a secret code identifying the client. Facebook then sends back an access token, which is used to authenticate specific access requests for the duration of the session.

The User-Agent profile differs in that it relies on a user-agent’s same-origin policy rather than a client secret for authenticating the client. This process provides OAuth capabilities for JavaScript-based applications that do not have a server-side component and thus cannot ensure identifying codes are kept secret.

Simplicity was a major factor in creating OAuth 2.0, and thus several parts of OAuth 1.0, such as signatures and nonces, no longer apply. However, OAuth 2.0 requires transport-layer security of TLS 1.2 at minimum (as of draft 7) for the interface used to request and receive access tokens. The spec also recommends that secure channels be used for other parts of the process. In Facebook’s implementation, all server interfaces are accessed via HTTPS addresses.

From a security perspective, OAuth is a good step in that it discourages the anti-pattern of one application requesting a user password for another application. It can also protect users in other ways; for instance, if someone intercepted the authorization code for a Facebook application, they would not be able to use it for data access without also obtaining the application’s client secret. However, OAuth only addresses particular issues with third-party access and should not be considered a silver bullet for security. As an example, access by Facebook applications vulnerable to cross-site scripting may still be hijacked once the application has been authorized.

While OAuth 2.0 is still in draft status, Facebook’s deployment makes it in wide use already, and we’ll likely see many more implementations in the months to come. The description above should help you understand the basics of how OAuth 2.0 works, but if you’re interested in further details, check out the full spec and Facebook’s specific authentication guide.

Recently, Imperva released a study (pdf) of the passwords extracted from the December 2009 RockYou security breach that resulted in the compromise of over 32 million user accounts. This study examined some statistics of the passwords retrieved, including the number and variation of characters use to construct them. The results were pretty bad. Here are the highlights:

-30% of users had passwords made up of 6 characters or less. Most brute force attempts are moderately successful against short passwords.

-Over 50% of passwords were all lowercase, or all numbers. This is bad because the keyspace is reduced. Even a password that is longer than 6 characters is weakened if it has a small character set distribution.

On the surface, these two statistics aren’t a good look at all, especially considering the ease with which an attacker could successfully guess simple passwords.

Also, in many cases, a password breach may not just make a user’s account vulnerable on the breached site, but can also lead to their account being compromised on other sites as well (plenty of people use the same password on multiple sites).

However, there is an alternative way to interpret this data. Although there is no way to verify this, it could be the case that users are starting to give value to the importance of some accounts AND the security of the website associated with it. And those accounts that are of low significance (like a site they just sign up on to play a game) get simple, easy-to-remember passwords, while accounts of greater personal significance (banks, primary email, etc.) get the more robust passwords. Similarly, it could be the case that users think sites like RockYou are sketchy anyway, and thus more likely to get hacked than other more-serious sites.

So, in a way, the user could be protecting themselves from a site breach. I know I wouldn’t care if I had a RockYou account and the site got breached since I wouldn’t really use that same password anywhere else important. It may be annoying, but it is much better than knowing that my super-secret 28-character password is sitting on some stranger’s computer simply because somebody left the door open.

So if you think of this report from the perspective of users managing risks reasonably instead of users being victimized, it almost makes sense that 29,000 people had ’123456′ as a password.

Today Threatpost sent me to a news article about the fact that Twitter is protecting against bad passwords by checking for them. And, the list of bad passwords is contained right in the source of the signup page. (Line 282 in the current source of that page.) This raises two questions in my mind:

1) Where did twitter get this list? Was it their own creation, or is it based on, say, the 370 most commonly used passwords on twitter? Is Twitter making any users which use one of these passwords change their password? If I were to say, hack the source of the signup page, could I still sign up with a ‘banned’ password?

2) What passwords *should* be on the list, but aren’t? One of my favorite test passwords “asdf;lkj” isn’t on there. What password do you think should be banned, but isn’t? Let us know in the comments.

All of us are terrible at remembering passwords, causing us to find convenient ways to make logging on to our Twitter, bank, and other online accounts a bit easier and much less secure. Users combat password fatigue by using the same password for all of their accounts, selecting short and weak passwords, or creating bad compliant passwords.

There is a simple way to make sure that your passwords you don’t use often or care about too much a bit more secure than “PoisonRocks1″ – like the hair bands of the 80s, just forget about them. Don’t remember those passwords; just reset them each time you need to log in to the account. Before you get alarmed at what I’m proposing, think about it. Most websites will send users a 6 character, randomly generated password upon reset – which is better than 99% of passwords that users pick.

You can even write down all of these reset passwords on a post-it note and carry it in your wallet and just reset the passwords each week or whenever you feel like it. You’ll have a decent password that is constantly changing and not connected to any of your other accounts. (Business managers, you’ll be insulated from outside passwords being stolen and used on your corporate network, although this tactic won’t work in most business environments unless you want your help desk to work on even more password resets.)

There are some websites that will only send you links to reset your own password or send you reset passwords in clear text in an email. In both situations it’s better to create randomly generated passwords using an online generator or using OpenSSL and testing its overall strength. Passwords sent in the clear really shouldn’t be trusted since emails are the digital equivalent of postcards and constantly setting your own password will just cause more password burnout.

For proper security you need real two-factor authentication so that you’re not relying solely on a password (something you know) but something you have as well (like a smart card). Of course, it won’t help you much if you keep losing your token. For your other accounts, try resetting the passwords and see how the online service handles them. Do they have you click a link in an email to follow and retrieve a new, random, and complex password?

Password resets generally rely on email accounts, so you’re only as secure as your email password. I don’t recommend forgetting your passwords and constantly resetting logins to any sensitive accounts, just the ones you don’t care too much about. Besides, if someone does end up stealing your password to some forum or other non-essential account, you’ll be resetting your password anyway.

picture: KaCey97007

Recently, I was buying a bottle of wine at the grocery store and was asked to show my ID.  My license picture was taken about 4 years ago, when I was 20-30 lbs lighter and before I started shaving my head, so it doesn’t look all that much like me anymore.  The clerk was skeptical, and he asked me to show another form of ID, which I provided by showing him a few credit cards.  Apparently, that was enough to convince him that I was who the license said I was.

What if I had just stolen someone’s wallet, though?  I would have easily been able to produce credit cards that accompanied the license in the wallet.  Showing that extra piece of ID really didn’t add any authentication to the transaction at all, but it allowed me to complete my age-restricted purchase.

Most IT people have heard of the concept of two-factor authentication;  pick two of the three classic categories (“something you have”, “something you know”, “something you are”) for a high level of authentication.  I’ve heard it argued, however, that multiple items from the same category (specifically, the “something you know” group), can be considered stronger than one.  I disagree with this sentiment.

If you can get “something you know” from someone, such as a network password or other shared secret, it’s generally trivial to get another “something you know” from them.  Two pieces of information are almost exactly as strong as one piece of information.  However, if an application designer, much like the store clerk that sold me the wine, is willing to accept two of the same authentication factor as a strong assurance of identity, then the application is more of a security risk than one that accepts only one form of identity because of the nature of the information that application is likely to provide.

It’s a common mantra of security theory that I’ve repeated ad nauseam:  security controls must be appropriate for what is being protected.  Two pieces of knowledge are not better than one, and if they are treated as such, then the application is not secure if it must protect information that requires something more than just a password.

If you haven’t heard of OpenID, I suggest you create a livejournal account, and start seeing where you can log into with your live journal credentials. You can also go read more about it at openid.net. The basic premise is a distributed authentication system that allows a user to select their authentication provider when they log into various web sites. The hitch is that you and the site you’re wanting to log into have to use a mutually agreeable authentication provider.

When OpenID was first announced, it touted that you could run your own OpenID server, and then you’d never have to give your password to the site you’re logging into, only the site (which you trust) that you’re authenticating to. That completely runs afoul of the whole “mutually agreeable” authentication provider. If the site you’re logging into doesn’t trust your OpenID provider, you’re never going to be able to use it to authenticate. Most of us have moved past this point, and expect that we’ll be using major OpenID providers rather than our own, but the protocol still allows it, and it can be used among friends.

One of the huge benefits of OpenID is that each OpenID provider can authenticate their users in whatever way they want – password, two-factor, etc. But the relying party still gets to choose what authentication level they’ll trust (and so far, the only models I’ve seen are password based).

So, why will OpenID succeed? Once people realize that they can log into sites that may look sketchy without having to give their passwords directly to that site, they may start visiting smaller sites that just don’t have the security that the larger sites do. This gives a huge boost to those smaller companies by bringing in more consumers.

Not long ago, I posted about snooping admins and suggested some ways to prevent them from abusing their positions. Today, we have an example of an administrator who used his powers to prevent other admins from logging into the network.

Terry Childs, who had become disgruntled over discipline for poor performance, reconfigured the network so that only he had access. He has refused to surrender the password for his account, and at the time the linked article was written, work was still being done to regain access to the network.

So, we can add this to the list of things to be wary of when handing out permissions to administrators. It looks like they knew about a month ago that this guy was up to something, but he was still able to cause all this trouble. It’s good to see that the security of the network is strong enough to keep you out if you don’t have the right password, but maybe there should be some sort of emergency break-in procedure for a situation like this.

Another lesson to take from this is that dealing with people and their egos is a delicate task. It pays to be careful how you handle employees. Security is bound to fail when your own people are working against it.

Jeff over at Coding Horror lashed out at the MENSA web site today, after discovering that their web site uses a presumably weak password storage mechanism that stores passwords in a recoverable format. The main point is that because the passwords can be retrieved by the application and sent back to the users, then they must be stored in a way that would allow an attacker to obtain a list of all (or some) of the passwords in the system.

One primary reason that this is seen as a bad thing is that many users use the same password for all of their various accounts, and therefore if the password is compromised in one place, it’s compromised everywhere. Apparently, according to this argument, every web site should have bulletproof security regardless of what it is that the web site does, in order to protect its users other accounts with other web sites. While this is a noble sentiment, and it would be great if this would happen, it’s a silly argument.

Security costs money, in terms of development, support, maintenance, training, etc. Therefore, security is built into an application as much as is reasonable for what the application does. If I’m designing a web site that lets you register your e-mail address, and all my web site does is associate your e-mail address with your home address so you can order a pizza online (let’s forgo the concept of credit cards for the moment and assume this is all handled with cash), why in the world should I need to have my site armed to the teeth with SSL, salted password hashes, password complexity requirements, and password expiration periods?

Since I’m not a member of MENSA, I don’t know what sort of services are available through their web site. If they aren’t performing anything that requires a high amount of non-repudiation and authentication, then why should anyone care if they’re storing passwords weakly? If you get your E*Trade account hacked because it had the same password as your MENSA account, that is not MENSA’s fault, because you shouldn’t be sharing passwords between any two systems, let alone two systems with vastly different security requirements. Don’t use the same password for your bank account as you do for your local pizza delivery place, and you’ll have a lot less to worry about.

Most corporate users are bombarded with guidelines and regulations on how to set good passwords. Users are forced to remember rules they don’t want to, leading to password fatigue. Administrators are given the sense that passwords are secure and users feel the same way if they’re following the rules.

People know that a password has to be 8 characters, but they really don’t know why – here are some surefire ways to be certain you (and your users) are picking weak passwords, despite length and complexity requirements.

• 1 Make It Up Yourself – Most users are going to come up with a ‘familiar base’, then add simple numbers and symbols (1 and !) to make their passwords compliant. Make good use and recommend some decent random password generators to your users.
• 2 Use Your Personal Account Passwords – Password change requirements are a good at keeping this problem under control (which is why your company should enforce them). Users using the same network password that is used for their personal email, social networking, or other less secure websites can place hidden vulnerabilities in your security architecture.

• 3 Change Your Password with Predictable Increments – Sure you have to change your password every 45 days, but do you just change all of the numbers from 111 to 222? Does Bob123! change to Bob234!?

Refer to #1, use randomly generated passwords.

It’s a good thing that machines can force password complexity and length requirements, but don’t let your users hack around them.

Password strength meters are all over the Net. These tools are designed to determine how long, random, and complex a given password is.

In general, I think they make good indications about passwords. It’s just that most people type in their dictionary word and tack on a number or two to get a ‘strong’ password.

See how PasswordMeter.com rates these 2 passwords (the second one randomly generated using 63 available ASCII characters):

• ‘Computer1’ – 56% = “Good” password rating.

• ‘buty1{’ – 34% = “Weak” password rating.

Try it, a couple of random passwords and I got 28-70% ratings using just 6 characters. I know this is all in the algorithms used at each stage – so what’s a user to do?

My advice is to download a copy of (the free) TrueCrypt. Create an encrypted drive (for the paranoid go with a hidden one) and store your passwords in a text file there.

The TrueCrypt password should be at least 8 characters with 1 number and symbol in it. The text file should have all 8 character randomly generated passwords (here’s a good random generator).

You only have to remember the single password to the encrypted folder. Make a copy and back it up to a USB drive and you’re ready to go mobile.

Remember, never submit your email, name, or any other information along with a password you’re testing out in an online generator. It’s a good way to get your password stolen.