First was with my mechanic. I like my mechanic – they’ve saved me quite a bit in the past. But they’re notoriously bad about answering the phone. However, they are surprisingly up to date for such a shop. They have a website which allows you to schedule your appointments online, no need to call. That’s great!
Necessarily, this means you need to have an account on the website. Okay, this makes sense: they track your name, contact information, kind of car you have, and the car’s maintenance history including mileage. While nothing there is particularly incriminating or dangerous unto itself, it’s not the sort of information I’d like to have broadcast to the world, either. So it’s good that this information is kept in an individual account not available to others.
However, I admit that I couldn’t recall my password for that account. No problem, I put in the username and requested a password reset. The automated tool asked for my email, which I gave, and it sent me a new password.
Do you see the problem? It wasn’t asking me for my email address to confirm that I should be the recipient of that password. It was asking in order to know where to send the new password. There was no confirmation process; it just sent the password to the address I’d provided.
And that’s how I got into someone else’s account. My first clue was that I don’t own a Mitsubishi. No harm done – I didn’t even get the person’s contact information, I simply figured out my correct account name (I was off by one letter) and logged in properly. But that’s no security at all.

On the flip side, I wanted to get support for a piece of electronics I bought recently. I was looking for a driver for it, and couldn’t find anything, so I thought I’d go ahead and contact their support team. In theory this should be a straightforward enough thing. In practice, not so much. You have to open an account with the manufacturer. For which you need to own an actual product. Now, that’s a bit of an issue – what if I was looking at buying a product and wanted to know beforehand if the driver existed? But I already owned this item. So I went to open the account (and set up to handle all the forthcoming spam, I’m sure.) Part of the process involves saying just which device you own. Now, the item I had wasn’t listed. I made the best match, a similar item with a different model number. Shouldn’t make a difference, right?
Oh, but it does. The item I selected is listed, for some reason, as out of warranty. And on that I was frustrated – I cannot make inquiries about an item which is out of warranty.
I’m sure this system reduces needless support requests. In this case it also prevented a real request; I won’t be buying this company’s products in the future.

What can we learn here? Well, two companies, two lessons.

In the first case, make sure your system applies basic security. My mechanic has relatively trivial information on me, sure, but they have some information, and they’re not securing it well enough. The idea of a confirmation before resetting a password has been “best practice” for longer than I can remember. If you’re going to bother having individual user accounts, there’s no excuse to not treat them with at least some security.

In the second case, your security shouldn’t get in the way of your business. Sure it’d be nice to be able to make sure every single contact was authenticated and properly routed, but if you have any reason to deal with the public that’s just not going to happen.

The overall lesson is that even if you’re a small company, your security has to match your needs. An off-the-shelf solution without any thought behind its application won’t do you any good.

Passwords look like they’ll be sticking around for a little while longer as a key component in single-factor authentication. The more we promote the practice of choosing sturdy passwords, the faster we will be able to turn one of their biggest weaknesses into a strength.

More likely our readers already know that short passwords are practically useless and have adopted longer passwords of 12-20 characters or more.  Perhaps you’ve read the recent xkcd comic demonstrating that several case-insensitive common words strung together are collectively more secure than conventionally complex 10-12 character passwords.  In a general sense, yes, increasing length increases difficulty so much more quickly than making your password unwieldy.  Some of us at Gemini prefer to use whole sentences as passwords (as long as 30-50 characters) where possible.  Even if case-insensitive, a length of 30+ is so non-trivial that brute force attacks are eons beyond impractical.  However, not all account services permit you to use passwords that long, so to remain secure, you have to rely on high complexity (and maximum length).  If you have many of these types of accounts, it may be easier to use a password manager for those accounts such as LastPass, a tool that saves and encrypts passwords for your use, after prompting for a master password (this can be long and complex and also further bolstered by multi-factor authentication).

Sometimes it can also be difficult to manually devise a truly random complex password for these accounts, and for that there are many password generators, but I personally prefer using Wolfram Alpha because it gives a very thorough summary.  Just enter “password of n characters”, where ‘n‘ is the length you require, and it produces a lengthy report.  One interesting application is that it also spits out a phonetic form of your password in call signs, which can help you memorize the one they gave you or be used as a very long password itself.  Wolfram Alpha also displays the password entropy and total permutations of passwords that length for varying alphanumeric sets, which is rather interesting to see, and you can change password input rules, too.  For instance, if I want to write out an all-lower-case sentence of 30 characters for my password, WA tells me that there are about 10^42 permutations and 185 bits of complexity – far too difficult to brute force.  In case you’ve never seen or done these calculations before, this is a terrific way to gauge how secure your passwords ought to be.  It also gives nice examples of each for you to write down (the text isn’t selectable).  This tool is quite handy and was also recently featured on Lifehacker.

With all this in mind, protecting access to your e-mail has become an important priority. Using strong passwords is a great starting point, but that’s only one level of security. Many companies use another system, known as two-factor authentication, to protect sensitive data, but it hasn’t been widely deployed for consumer services.

Today, however, Google is making two-factor authentication available to users of Gmail – or any other service that involves a Google account. That means that instead of logging in by simply providing information you know (your password), you also have to prove you have something: your mobile phone. Whenever you login at a particular computer/browser for the first time, you’ll be prompted for a secondary code that’s either sent to you as a text message or generated with an app on your iPhone, Blackberry, or Android device. This gives you another layer of defense against phishers and hackers trying to access your inbox.

The new feature is not enabled by default, since it requires a phone and will likely be unfamiliar to most users. But you can enable it on your Google Accounts by visiting the Account Settings page and look for “Using 2-step verification” under Personal Settings. More information is available at the Google blog.

If you’re not inclined to crank out the numbers yourself, you might find the answers you’re looking for here.

Here are some basic stats:

• With access to super-computing-like power (trying over 1 billion per second), it only takes about 84 days to crack the common 8 character password (alphanumeric mixed case, including special characters).
• With access to a less powerful class of attack machines (10k per second), without including special symbols, an 8 character mixed-case alphanumeric password would need 692 years to brute force completely.
• Numeric-only passwords are low-hanging fruit.

The data only takes into account the maximum time it would take to brute force a password by exhausting the key space. It does not include tricks or techniques someone might use to optimize an attack. The most significant factor in the success of this approach is the use of the hardware. The price, availability, and power of hardware have a direct bearing on the protection offered by the typical single-factor password authentication scheme. In addition, as technology improves, the barrier to entry for brute forcing will drop, potentially allowing more would-be attackers to try their hand at it. Also, botnets dedicated to brute forcing passwords will get faster as the hosts (typically infected PCs) that comprise their processing power become faster. The golden standard “8 character alphanumeric+special” password is already within reach of a well-funded attacker (and has been for a while).

If you haven’t already, it may be time to start picking longer passwords for important accounts.

With passwords, though, another option is available: one-way hashes. A hash function takes an input of data, such as a password, and outputs a value that’s always the same length and format. The algorithm is designed so that it’s easy to calculate a hash, but essentially impossible to reverse the process. Also, slight adjustments to the input drastically change the output value, and the chances of two values leading to the same hash are extremely unlikely. To use another analogy, think of a person’s fingerprint. It’s easy to capture a fingerprint using an ink pad and paper. But if you start with a fingerprint and want to identify the person it came from, you’re at a loss without a database of records to check. And once again, finding two identical fingerprints from two different people would probably never happen.

If an application stores the hash of a password instead of the actual password or a value generated by reversible encryption, then theoretically, the password would remain safe if the database were ever breached. When a user tries to log in, the application simply generates a hash of the supplied password (remember, generating hashes is easy) and compares it against the stored hash. If they match, the user has given the right password. If not, the password is wrong.

Just as people have built databases of human fingerprints, however, databases of hashes exist for common values, so only using a hash would not protect users with simple passwords. Weaknesses have also been found in older hash algorithms, such as MD5. Better options include SHA-1 and the various versions of SHA-2, but they are still not sufficient on their own. Extra protection comes from adding “salt.”

In this context, salt refers to an extra string of random information that’s unique for each saved record. This salt is then concatenated with the password and a hash is generated for the entire new string. The salt needs to be saved along with the hash in the database so that login passwords can still be verified, but it should still be kept secret as much as possible. When a user logs in, their supplied password is concatenated with the salt, hashed, then checked against the stored hash.

With this system, an attacker who manages to break in to the database will only recover salted hashes instead of actual passwords. The nature of hash algorithms means that even if a user had a simple password, the salt helps ensure that their hash won’t match any found in common hash databases. To figure out each password, an attacker would have to compute all possible values with each individual salt, vastly multiplying the amount of computation required.

Of course, just as toothpaste manufacturers remind buyers that their products are only one component of good dental health, salted hashes are only one part of a secure application. In fact, with technologies such as OpenID, OAuth, and Facebook Connect, many sites really don’t even need to handle user passwords any more. But if your application does require its own authentication, a robust implementation of salted hashes ought to be a baseline for password security.

In a perfect world, websites would just use OpenID or other roaming credential, so that everyone would only have one secure password to manage, and we wouldn’t have to rely on bad home-grown authentication management from each web site.  However, this isn’t likely to happen anytime soon.  In the meantime, here are a few tips on password security that should help keep your accounts a little bit safer:

1) Do not use words, phrases, dates, or numbers that are of any significance to you, such as birthdays, your home address, or pets’ names.  (I think the law requires every password article to include this tip.)

2) Use mixtures of upper case, lower case, numbers, and special characters.  The longer, the better.  (This one, too)

3) If you can’t remember your passwords, don’t write them down – use a password management tool that you can store on a USB token to take with you on the go.  Make sure it’s a secure tool that uses high quality encryption.  (Readers and SM Bloggers, any products you’d recommend?)

4) Never re-use passwords for multiple locations.  If you absolutely, positively refuse to use completely unique passwords for each site, consider appending your password with something you can easily remember about the site.  For example, if you want to use Password123 for several low priority sites, instead use Password123papajohns.com, Password123gawker.com, etc.  This isn’t truly secure, as the pattern is easily figured out by a human looking at it, but it should at least stop automated scripts from successfully using a compromised password elsewhere.

5) Beware the password reset “security questions”!  Things like your mother’s maiden name, the street you grew up on, pet’s names, etc, are trivial to figure out, especially if you like filling out “which vegetable are you?”-type questionnaires on Facebook.  You don’t actually have to answer the security question with an answer that makes sense – for a question such as “What is your mother’s maiden name?”, the system will not care if you say “pamplemousse”…just make sure you can remember the answer as well!

Anyone have any other password tips to share?

You don’t know me.  I’m nobody.  My name is Steve.  I came across a database dump from Gawker.com earlier this evening.  It’s making its rounds around the internet.  Besides just the code dump from gawker.com among other sites, it also contains email addresses and passwords for over 1.3 million accounts.  I’m sending this email to the 200,000 or so people who’s passwords were included, in plain text, in this archive.  I have your password.  However, I have 0 interest in it.  Obviously i’m anonymous so how can you trust me – you can’t.  But trust me, if I had interest in your password, I wouldn’t be emailing you saying I have it. That’s just dumb.  The reason I’m telling you this is because people all over the world, who aren’t like me, who won’t notify you, have it.  They will use and abuse it.  Change your gawker.com credentials. Now.  MORE IMPORTANTLY, change passwords on other sites you visit that use the same one as your gawker.com/lifehacker.com/gizmodo.com login.

Well, it was believable enough… then, I read an article on Forbes and knew it wasn’t a scam. Argh. To their credit, Gawker has some informative posts on their breach and how to audit and update passwords.

As background: I use a password manager to manage my passwords, and it helps me use secure passwords wherever possible. However, I have a number of passwords which predate my use of a password manager, and for many sites I used the same password. Yes, it’s a bad security practice that we’ve talked about before, and even XKCD has weighed in.  The use of this same password didn’t bother me – it was my password for using on sites that I considered “low impact”. In other words, I didn’t feel like it was a big deal if that password was compromised.

Receiving that email, along with a notification from Google that my account had been locked out, was a wakeup call. Suddenly, it became a big deal to me.

So, I spent this evening going through my password manager’s records. I have 507 saved passwords.  I had nearly 150 with the same password.  I changed every one of them to a randomly generated password.  It took me over three hours to go through that process.  A tremendous hassle. Let me suggest from experience: change those passwords you use on many sites.  If you try to do them all at the same time, it will be a tiring and painful process.

How do you measure security strength?

That is, we know that an 8-character password with upper-case letters, lower-case letters, numbers, and special characters is definitely stronger than a 6-character password with only letters and numbers. But how much stronger is it?

Unfortunately, that’s incredibly hard to answer.

Of course, we know that there is no such thing as bulletproof security; if an attacker has sufficient time and resources, any security measure can be surmounted. Passwords can be broken, encryption can be cracked, etc. Given that the goal of security is to keep an attacker out, perhaps the most direct way to measure the effectiveness of security is, “How much effort will it take for the attacker to defeat it?”

This can be expressed in a fashion rather similar to programming complexity, using “Big O” or “asymptotic” notation. Which is useful because it communicates a key concept: multiple layers of poor security are not equal to one layer of good security. One might be inclined to think that, for example, requiring three weak password authentications is better than just one weak password authentication. But, while the difficulty in breaking one password is O(n), the difficulty in breaking three passwords is just O(3n) – which is, asymptotically, the same thing!

For real security improvements, the cost of defeating the security must be a higher order of complexity – it must be O(n log n), or O(n^2) or the like. That’s a real improvement over O(n). In the real world, this means adding levels of complexity to a password, requiring a hardware token, or adding in biometric identifiers.

But even expressing security in terms of complexity won’t really work: it doesn’t account for the myriad ways which attackers might use. Keeping passwords as an example, you may require strong passwords which truly are an order of magnitude harder to defeat than simple passwords… but if you’re not using good encryption for transmission, you’re no more secure. And even if you’re using good encryption, a wrench can still get the password (not that I advocate this method, of course, and especially not when my kneecaps might be involved!)

So, realizing that there are no easy fixes, and that attackers can be resourceful, how do you measure the level of security?

Well, so far the best idea I’ve seen has been to create a composite score based on your vulnerability to various attack vectors, giving weight depending on the expected likelihood of a given vector. Yes, that’s right: benchmarks.

And ultimately, you don’t want to get too hung up on the score. With benchmarks, you can usually manipulate to get whatever score you want. It’s just a number; the question is whether you’re secure. So use a metric, or pick a team that uses a metric, which you believe realistically reflects the threats you expect to see. And whatever the answer you get, the question is binary: “Am I secure enough?”

However, after learning how Facebook expects people to request the one-time passwords (via mobile SMS), a potentially negative side-effect becomes apparent. Passwords are often the first line of defense encountered by an attacker. But in this case, OTPs actually undermine the benefit of the original password by creating a temporary token that can be used instead. This creates a security tradeoff, whereby the benefit of a secret password is sacrificed for protection against an untrusted system (kiosk, library computer).

This tradeoff isn’t inherent to OTP systems, and only exists for Facebook because the person requesting the access token is not required to prove their ownership of the respective account each time. Access to the mobile phone linked to the account is all that is required to access the goodies. In the time it takes to send a text message, an attacker could essentially hijack an account.

Curiosity and a few minutes alone with someone’s phone might be all you need to turn Facebook’s shiny new “security feature” into another privacy misstep.