Posts

Enigma machine

Bcrypt is great, but is password cracking “infeasible”?

There are a lot of technical terms that mean something very specific to cryptographers but often mean something else to everyone else, including security professionals. Years ago I wrote about what it means to say that a cipher is “broken”. Today’s word is “infeasible”.

The news that sparked this lesson is the use of “computationally infeasible” in an announcement by Slack. Slack has announced that their hashed password database had been compromised, and their message was excellent: They clearly described what was available to attackers (usernames, email address, hashed passwords, and possibly phone numbers and contact information users may have added); they offered clear and useful instructions on what users should do (change passwords, enable two-step verification), and described what they have done and what they will be doing. And – most relevant for the technical discussion here – they have told us how the passwords were hashed.

In this case they said:

Slack’s hashing function is bcrypt with a randomly generated salt per-password which makes it computationally infeasible that your password could be recreated from the hashed form.

It is terrific that they chose to use bcyrpt for password hashing. bcrypt is among the three password hashing schemes that we recommend for sites and services that must store hashed passwords. The other two are PBKDF2 and scrypt. But Slack’s use of the term “computationally infeasible” here illustrates that one must be very careful when using cryptographic technical terms.

If you have a weak or reused password for Slack, change it immediately. Here is a guide to using 1Password for changing a password. And because the Slack app on iOS makes use of the 1Password App Extension, it is easy to use a strong and unique password for Slack.

Slack 1Password login Slack 1Password extension

If you would like to see how to use Slack’s two-step verification with 1Password take a look at our handy guide on doing just that.

 

But now back to what is feasible with password hashing.

One way hashing

When services that you log into store your password they should never store those as unencrypted “plaintext”. If they are stored as plaintext it means that anyone who can get their hands on that data file can learn everyone’s passwords. For example, Molly (one of my dogs) uses the same password on Poop Deck as she does on Barkbook. So if Patty (my other dog) learns Molly’s Poop Deck password, she can use it to break into Molly’s Barkbook account as well. This is why it is important not to reuse passwords.

Now suppose that Molly uses the password “rabbit” on Barkbook. (Have I mentioned that Molly is not the smartest dog in the pack?) Barkbook shouldn’t store just “rabbit”, but instead should store a one way hash of rabbit. A cryptographic hash function will transform something like “rabbit” into something like “bQ67vc4yR024FB0j0sAb2WKNbl8=” (base64 encoded).

One of the features of a cryptographic hash function is that it should be quick and easy to compute the hash from the original, but that it should be infeasible to perform the computation in the other direction. That is it should be pretty much impossible to go from “bQ67vc4yR024FB0j0sAb2WKNbl8=” back to “rabbit”. And it is.

Guessing versus reversing

With any halfway decent cryptographic hash function is it infeasible to compute the original from its hash if the original is chosen at random! But if you can make some reasonable guesses about the original then you can use the hash to check your guesses. Because passwords created by humans are not chosen at random, then it does become computationally feasible (and often quite practical) to discover the original based on the hash.

The actual formal definition of “one-way” for a cryptographic hash function, H(x), includes the requirement that x be the output of a uniformly distributed sampling of the domain of H. That is, considering all of the things that you can hash (under some set length), you need to pick something at random.  Otherwise a hash function might be invertible. Human created passwords do not meet that requirement and so the “computational infeasibility” of inverting a one way function isn’t applicable when its input is not chosen at random.

So now let’s correct Slack’s statement:

Slack’s hashing function is bcrypt with a randomly generated salt per-password which makes it computationally infeasible that a randomly created password could be recreated from the hashed form.

Modified Slack statement.

This, of course, is why you should use 1Password’s Strong Password Generator for creating your passwords. When your password is chosen randomly with a large set of possibilities, then it really is computationally infeasible to discover the password from the cryptographic hash.

Slowing down guessing

I mentioned that (for now) bcrypt, scrypt, and PBKDF2 are good choices for password hashing. Once the final results are in from the Password Hashing Competition and the dust has settled, we will probably have a good successor to those three. These are built upon cryptographic hash functions, but are designed for hashing specifically for when their input is not selected randomly.

Because cryptographic hashing is something that we have computers do a lot of, one of the things that we want is that it be fast. We want to be able to perform lots and lots of SHA-256 hashes per second without straining a computer’s memory. But if an attacker is going to be guessing passwords to see if they produce the right hash, we want to slow down the hashing. PBKDF2, scrypt, and bcrypt are all designed to require much more computation than a regular hash function to compute a hash. This can slow down an attacker from performing millions of computations per second to just thousands. The actual speed depends on many things, including the hardware that the attacker brings to bear on the system. scrypt, additionally, places specific demands on memory.

So the use of bcrypt means that attackers will need to do more work than they otherwise would to guess passwords stolen from Slack. That is a good thing, but it is not an “infeasible” amount of work.

What’s infeasible?

I started out by saying that I was going to talk about the word “infeasible”, but so far I have just been using it a lot. This is because its definition is abstract, subtle, and hard. I am not going to give a full definition, but I am going to try to get reasonably close. The discussion that follows is inherently technical, and nobody will blame you if instead of reading further you just wish to watch us pour ice water over ourselves. (Remember, that was a thing just last year.)

Welcome back to this article. It get’s progressively more arcane from this point onward.

The notion of infeasible depends on the relationship between the amount of work the defender has to do to secure the system compared to the amount of work that the attacker has to do to break it. A bank vault may take a minute to unlock if you know the combination, but it may take days to break through if you don’t. With cryptographic systems it can take just a fraction of a second to decrypt data if you have a key, but many times the age of the universe to do so if you don’t have the key.

Security parameters

What we want is the amount of work the attacker has to do to be vastly disproportionate to the work that the defender must do. It turns out that this can be stated mathematically, but first we need to introduce the notion of “security parameter” if we want our definition to stand the test of time instead of depending on the speed and power of current computers. So we will talk about how much work the defender and the attacker have to do in proportion to some security parameter.

Let’s pick, for purposes of exposition, an encryption system that operates at a security parameter of 56. The amount of computation that the the defender has to do to decrypt some data with the key is proportional to 56, but the amount of work that the attacker has to do to decrypt the data without the key is proportional to 2⁵⁶. Fifty-six is much much smaller than 2 raised to the 56th power, but today even 2⁵⁶ operations is within the reach of many attackers. Thirty years ago it was within the reach of just a few.

So now let’s suppose that we want to double this security parameter to 112. How much of a work increase might this cause the defender? You might be thinking that it doubles the cost to the defender, but the system I’m thinking of actually tripled the cost to the defender. Tripling the cost for double the security parameter may not seem like a good deal, but doubling the security parameter increased the work of the attacker by another 2⁵⁶, for a total of 2¹¹². This puts it well outside the reach of even the most resourceful attacker for a long time to come.

When we doubled the security parameter in that example, the work to the defender increased linearly while the work to the attacker increased exponentially. We want the work required of the attacker to increase exponentially with the security parameter while for the defender we increase it linearly or polynomially.

Doing time, time, time in an exponential rhyme

If the security parameter is n, we will tolerate it if the amount of work the defender must do is proportional to na for any a > 1. That’s what we mean when we say the work is “polynomial in n“. So if the work goes up with the square or cube of n we might grumble and seek more practical systems, but no matter how big the power that n is raised to gets, this is still a polynomial expression. An algorithm that works this way is called a “polynomial time algorithm”.

For the attacker we want the number of computations needed to be proptional to an expression in which n is in the exponent. So if the work to the attacker is proportional to b for any b > 1, so that the work is exponential in n. (Those of you who know this stuff, know that I’m leaving some things out and am taking some shortcuts.)

It might seem that a “big” polynomial get us bigger numbers than a “small” exponential, but no matter how much a polynomial function starts out ahead of an exponential, the exponential will always catch up. Let’s compare the exponential  y=1.1ˣ with the polynomial y=x⁶ + 2. For values of x below a few hundred, it looks like the polynomial is the runaway winner.Plot of polynomial taking early lead over exponentialBut we inevitably reach a point where the exponential function catches up. For the particularly examples I’ve given, the exponential catches up with the polynomial when x is about 372.73.

Plot with exponential catching up

Finally, if we go just a bit beyond the point where the exponential overtakes the polynomial, we see that the exponential completely flattens the polynomial.

Plot on scale where exponential flattens polynomial

Some computations will take a number of steps that are polynomial in n (“polynomial time algorithms”), and others will be exponential (“exponential time algorithms”). We say that a task is infeasible if there is no polynomial time algorithm to complete it with a non-negligible chance of success. I have not defined what a non-negligible chance of success is, but as the article appears to be growing in length exponentially, I will leave that discussion for our forums.

When we have this sort of asymmetry, where the work done by the attacker grows exponentially with the security parameter, but grows at most polynomially for the defender, there will always be some security factor beyond which the work to be done by the attacker is so enormously larger than what the defender must do as to just not be an option for any attacker.

Quibbling over terminology

Now that we have a workable definition of “infeasible” and a better understanding of what cryptographic hash functions do, we can take a closer look at Slack’s statement. First let me repeat that their overall statement was excellent, and I fully sympathize with the difficulty involved in writing something about security that is correct, clear, and usable. I’ve taken some shortcuts in my exposition on any number of occasions, and I’ve made my share of errors as well. My point here is not to criticize but instead to use this as an opportunity to explain.

Given what we believe about cryptographic hash functions it is infeasible to discover x if you are only given the hash of x but only if x is chosen at random. Furthermore this is true of any (decent) cryptographic hash function and is not limited to the slow functions that are recommended for password hashing. That is, we don’t need bcrypt or PBKDF2 for that property to hold.

The limits of slow hashes

Slow hashes – specifically designed for password hashing – are built because we know that passwords are not chosen at random and so are subject to guessing attacks. But slow hashes have their limits, and with the notions that have been introduced above, we can now talk about them more clearly. Using a slow hash like PBKDF2 slows things down for both the attacker and for the defender. And the amount of slow-down is roughly the same for both the attacker and for the defender.

If we increase the security parameter (number of iterations) for PBKDF2 the computational cost rises linearly for both the attacker and for the defender. This is unlike the security parameters we use elsewhere in cryptography, where we would like a small (linear or perhaps polynomial) increase in cost to the defender to create a large (exponential) increase for the attacker.

Let’s see how that works out with a concrete, if hypothetical, example. Suppose it is using 40,000 PBKDF2 iterations. Now suppose that you add a really randomly chosen digit to the end of your Master Password. Adding a single random digit will make an attacker do 10 times the amount of work that they would have to do to crack the original password. Adding two digits would make the attacker have to do 100 times the work of the original. Making a password just a little bit longer (with random stuff) makes the work required by the attacker increase exponentially. That is the kind of proportion of work that we like.

Now suppose 1Password uses 40,000 PBKDF2 iterations in deriving your Master Password. To get the same additional work as adding a single digit to your password, you would need to increase the number of PBKDF2 iterations to 400,000. And to get the equivalent of adding two digits, you would need to increase the number of iterations to 4,000,000. Once we have a goodly amount of PBKDF2 iterations, there isn’t that much gained by increasing it by an additional ten or twenty thousand. But there is much to be gained by even a small improvement in a Master Password.

PBKDF2 is terrific, and it is an important part of the defense that 1Password offers if an attacker gets a hold of your encrypted data. But you must still pick a good Master Password because the security parameter is linear for both the defender and the attacker. Unless there is a breakthrough in the slow hashing competition, a strong Master Password will always be required in order to ensure your security can withstand the test of time.

Shellshock is bad, unique passwords are good

Shellshock bash terminalA new security bug, commonly known as Shellshock (Officially CVE-2014-6271, is bad. It is fair to say that a large number of servers (particularly web servers) were vulnerable to serious attack for some time. It is likely that many still are, and we are unlikely to learn about most of them.

What are we do to? Answer: Use unique passwords for each site and service.

Squirrels, rabbits, and passwords

Squirrel mollyLet’s consider Molly, one of my dogs. She has a one track mind: Squirrels and rabbits. She also is not very good at counting, so she doesn’t understand the difference between one track and two tracks.

Molly tends to reuse the same password for lots of things. Her password for Barkbook is squirrel. It’s also the password for CatChasers and a number of other sites and services.

Suppose that Patty, my other dog, isn’t the sweet innocent little thing that she pretends to be. Suppose that she breaks into CatChasers and is able to steal user passwords from it. She learns that Molly’s password was “squirrel” on CatChasers, so she’ll check if Molly used the same password on Barkbook and other sites.

1P squirrel password

Password reuse is doubly bad

Indeed, when Molly uses the password “squirrel” on multiple sites, she is putting all those squirrels in one basket. If her password is stolen on any one of those sites, Patty can get into all of those.

The more places that Molly uses the password “squirrel,” the more likely it is that at least one of that sites will get breached, and the more damage is done when her password gets discovered at any one of those sites.

If Molly uses “squirrel” for twenty sites, there is a very strong chance that several of them are vulnerable to this new Shellshock flaw, Heartbleed, or any of the other known and unknown vulnerabilities being exploited. When Patty does break into one of those twenty sites, she will now have control of twenty of Molly’s accounts.

What you can do

In short, be careful. System administrators will be busy for a while. In addition to upgrading bash on systems that use it, they should be trying to track down which systems create environment variables with untrusted content and whether those systems ever invoke a shell.

But normal people (and I don’t think that many will dispute that system administrators are not “normal people”) are left with the knowledge that there are a lot of vulnerable systems out there. By far, the single best things we can do is to cut down on our password reuse. The easiest way to do that with 1Password is to give Security Audit a whirl.

There is so much more to say

Everyone with some sort of security point to make is using Shellshock to help illustrate and draw their favorite lesson from it. This is easy to do because Shellshock isn’t just a bug, it is a bug that can be exploited because of a series of design decisions that were pretty much asking for trouble. Each one of those decisions (or non-decisions) is something that everyone in the business really does know better about. But somehow, the software and systems engineering community has managed to ignore its own wisdom at each step of the way.

  1. We members of this community know not to pass untrusted data to various other processes, yet we’ve allowed systems that create shell environment variables (things designed to be passed all over the place) from the most untrusted sources of all. [E.g. CGI, DHCP Clients, etc].
  2. Our community knows that tricking systems into executing “data” is often how attacks happen, yet bash has a feature that deliberately allows what is normally data passed around to be executed.
  3. Whether computer science students like it or not they are taught that when data is in a particular class of languages it is impossible to validate it, yet with bash we’ve stuck a Type 0 languages inside of variables.
  4. Scripts and programs should (generally) avoid invoking a shell as even the Linux manual page for system(3) says

    Do not use system() from a program with set-user-ID or set-group-ID privileges, because strange values for some environment variables might be used to subvert system integrity.

    Yet calling system(3) is common practice because it is easier than invoking other programs the proper way.

When a system falls victim to Shellshock, it is because every one of those principles and guidelines have been ignored. The first one is in the design of various network services (such as web servers). Numbers two and three are in the design of bash, and number four crops up in innumerable scripts and programs. None of them are actually about the specific bug in bash. Instead, one through three are about specific design features of various systems.

There is a great deal I would like to say about each of these, but I will leave that ranting for another time. Today, I just wish to remind everyone about the importance of using unique passwords for each and every service.

Bash update for Mac OS X

Apple has made bash updates available to those who do not wish to wait
for regular software update:

OS X bash Update 1.0 may be obtained from the following webpages:
http://support.apple.com/kb/DL1767 – OS X Lion
http://support.apple.com/kb/DL1768 – OS X Mountain Lion
http://support.apple.com/kb/DL1769 – OS X MavericksTo check that bash has been updated:* Open Terminal
* Execute this command:
bash --version
* The version after applying this update will be:
OS X Mavericks:  GNU bash, version 3.2.53(1)-release (x86_64-apple-darwin13)
OS X Mountain Lion:  GNU bash, version 3.2.53(1)-release (x86_64-apple-darwin12)
OS X Lion:  GNU bash, version 3.2.53(1)-release (x86_64-apple-darwin11)

Password reuse lands Find My iPhone users in expensive hot water

1Password 4 for Mac icon

There are plenty of examples as to why friends shouldn’t let friends reuse passwords, but some users of Apple’s Find my iPhone have become the latest omen of why this practice is so dangerous.

On Tuesday, May 27, The Verge reported that Apple’s Find my iPhone feature was being used to lock devices for ransom. Some people found their Mac or iPhone locked—a legitimate feature of Find my iPhone—with a message of “Device hacked by Oleg Pliss” and a demand of $50 to unlock it.

At first it wasn’t clear how the malicious hacker(s) were able to compromise these devices, but today Apple stated that it wasn’t through an iCloud flaw. The most likely culprit, then, would be password reuse. Thanks to all the recent major breaches at some of the internet’s largest companies, including eBay, Adobe, and Yahoo, the hackers probably had plenty of material to rummage through.

Let this be yet another unfortunate and pricey lesson about reusing passwords. Don’t do it. Don’t let your friends and family do it. Send them these stories and get 1Password to effortlessly create strong, unique passwords for all your accounts.

Introducing the 1Password Watchtower service for Heartbleed and beyond

1Password Watchtower

When news of the internet’s Heartbleed bug broke last week, we published what we knew about it and the implications for 1Password and 1Password users.

To recap: 1Password is not affected by Heartbleed, but there are steps you need to take to protect your passwords from sites that may have been affected.

Today, we’re introducing a new service to help you check vulnerable sites and stay on top of your online security. We call it 1Password Watchtower.

A way to check if the bleeding has stopped

Your password data remains safe and secure within 1Password, but when your web browser sends a password to an insecure website, that particular password can be captured.

Most, but not all, websites have had some period of being insecure because of Heartbleed, and this is why so many passwords need to be changed.

Since those first few hours on April 7, we’ve gone from “what is this all about?” to “which sites do I need to change my password, and when?” Today, the 1Password Watchtower service will help you answer that question.

1Password Watchtower: Check this website

The categories of sites

With respect to Heartbleed, the 1Password Watchtower service will try to categorize websites into one of the following five categories.

1. Vulnerable

SiteChecker vulnerable example

Sites that are still exhibiting the Heartbleed bug should be avoided until they’ve fixed it. Once fixed, you should change your password.

If you reused a password for one of these sites, then all of those websites are also at risk. You should change your passwords on those other websites as soon as appropriate, and be sure to set up a different password for each of these sites.

2. Not currently vulnerable but needs new certificate

SiteChecker Needs new certificate

This is where things get complicated. While these sites have stopped the bleeding, their master keys may have been stolen while the site was vulnerable.

To protect against this, websites need to get new certificates signed by certification authorities, which simply takes time (especially when nearly every site needs to do it). It took two days to get our new certificate, and I would not be surprised if others will have to wait longer, especially if they submitted their requests after us.

For these sites we recommend that you change your password twice. Changing your password now will prevent an attacker from using any previously stolen passwords. Then you can change your passwords again once the site’s certificates have been reissued to guarantee that the new password is only known by you.

3. Not currently vulnerable and has a new certificate

SiteChecker new certificate example

These sites were vulnerable to Heartbleed at one time but have been completely fixed. You can go ahead and change your passwords on these sites.

You may find yourself with many sites for which you need to change passwords, but don’t let yourself get overwhelmed. Focus on changing passwords for your most important websites first.

1Password can help you through the process, and of course, this is a great opportunity to use 1Password’s Strong Password Generator to create a strong and unique password for each site.

4. Never vulnerable

SiteChecker Never Vulnerable example

Some sites and services were never vulnerable to Heartbleed, typically because they never used OpenSSL or had disabled various features.

One piece of good news is that, as far as we can tell, most banks fall into this category. However, to the annoyance of security researchers, banks are not telling us why they weren’t vulnerable; they are merely repeating that their customers are and have been safe.

For  sites that were never vulnerable, no special action is needed. You do not need to change those passwords if your passwords were unique to those sites.

But (and you will hear us repeating this often) if you used the same password on a “never vulnerable” site that you used on one which was vulnerable, then you should change your passwords to be strong and unique on both sites.

This illustrates why password reuse on multiple sites is so dangerous. Even services that have had excellent security on their own can be broken into with a password stolen from elsewhere. 1Password’s Security Audit will help you find duplicate passwords.

5. No SSL/TLS

SiteChecker: No SSL

Sites in this category are in no way affected by Heartbleed, but these are the services where it is most important that you don’t reuse passwords.

Some sites and services do not use SSL/TLS to secure connections between your web browser and their service. Because they have no transport security to break, their security can’t be “broken” by Heartbleed. Any password—or, really, any data—sent to such a site can be easily captured. If you have a password for one of these sites, make sure that you don’t use the same password for any other service.

Subdomains matter: It is important to remember that 1Password Watchtower checks the exact domain you tested. So even if go.com doesn’t use SSL, subdomains such as disney.go.com, may. It does not appear that one ever sends passwords to go.com itself, so its lack of SSL does not put passwords at risk.

How do we know which sites fall into which category?

Sorting hatAs 1Password Watchtower checks for Heartbleed, it performs a number of tests on a domain and its certificate, as well as looking at the results of earlier tests. But even with all of the tests that we run, there is some substantial “guess work” in the categorization.

We can reliably tell which sites are currently vulnerable and which sites aren’t. We can also check the start date for the validity of a certificate. We run other tests, but whether they produce results or not, they only offer hints at which category we should put a domain into.

If you are a site administrator and find that we are reporting incorrect results for your site or service, please make use of Heartbleed HTTP Headers to announce your condition or let us know.

Uncertainties

Never vulnerable or needs a new certificate?

The biggest uncertainty is that we have no reliable way to distinguish between sites waiting for new certificates and sites which were never vulnerable. Both such sites will not be currently vulnerable and will not have new certificates. We look at fragmentary results of previous scans as well as web server software to try to form a guess, but it remains a guess.

Is an old certificate really old?

Every certificate has a validity period. They have a “valid from” date and a “expiry” date. We are (mostly) using the date from which they are valid to see if they are old or new. However many recently reissued certificates have the same validity period as the one that they replaced. As a consequence, certificates that appear as if they are in need of replacement aren’t.

Are we talking to the right service?

Many high traffic web sites use load balancers, which don’t actually process your web request, but send off your request to a one of many back-end servers. The software on a load balancer is meant to be invisible, but it will often be different than what appears on the backend. The tests we perform involve a number of queries, some of which will be handled by the back-end servers and some by the load-balancer. For example, a load-balancer that was running an affected version of OpenSSL might be using IIS as a back end, and thus we might false report as “never vulnerable”.

Wrapped Heartbeed Heart: Strong, Unique, New Passwords

Use strong, unique passwords and carry on

Heartbleed is an astonishingly serious thing, but it isn’t cause to panic. Indeed, frightened people tend to make poor security decisions. The bulk of the work is being done by system administrators, and there are changes to come in the ways critical software is scrutinized. But for most people like you and me, the job is to improve our password practices.

Many—I’d like to think nearly all—1Password users are good about having strong, unique passwords for each site and service. That habit should already make the current task easier for you. Heartbleed and this initial version of 1Password Watchtower gives you another opportunity to improve even more. Doing so will make you safer now and long into the future.

Time to give 1Password 4 for Mac’s Security Audit a whirl

1Password Security AuditIt was bound to happen eventually. A massive Adobe data theft of 130 million customer names, emails, encrypted passwords, source code, and more will enable almost limitless password reuse attacks in the coming weeks.

Suppose you are one of the 130 million people who’s oddly encrypted passwords were among the Adobe password breach. Suppose that you used the same password there as you do for PayPal.

To make matters worse, suppose you actually listed that fact in Adobe’s password hint. Since the malicious attackers dumped the Adobe data online, a quick check of Adobe customer password hints shows that there are more than 700 that say things like “paypal” or “sameaspaypal”. There are more than 20,000 hints referring to “bank”. I will talk about password hints at some other time; my point here is all about password reuse.

Only a fraction of the people who are reusing passwords will make that clear in their password hints. We already know password reuse is common. We also know that criminals do indeed exploit password to steal from people.

I am very tempted to explain all about Adobe’s peculiar method of storing passwords. It’s really a cool story with lots of interesting lessons, and explaining it would involve poorly encrypted pictures of a penguin.

I am also tempted to dive into gory details of the statistical properties of the data, the analysis of which has kept my computer busy for days on end. Likewise, I could rant about Cupid Media’s failure to encrypt or hash passwords for 42 million customers. Or I could talk about privilege escalation and the MacRumors discussion forums breach of 860,000 hashed passwords a week earlier, leading to the capture of all 860,000 hashed passwords.

But it is far more important for me to repeat what we’ve said in many different ways and at many different times: Password reuse—using the same password for different sites and services—is probably the biggest security problem with password behavior.

We want to fix that.

Knowing the right thing to do is easier than doing the right thing

Like most people, you weren’t born using 1Password, it’s something that came to use later in life. Now that you use 1Password, you will (or should) be using the Strong Password Generator when you register for a new website so you get a strong, unique password.

But think back to those dark days when you needed to come up with passwords on your own. You probably picked from a small handful that you had memorized, so now you’re stuck with a bunch of sites and services for which you used the same password.

Security Audit selections

Getting all of those old passwords sorted out is going to be a chore, but it doesn’t have to be done all at once. Best of all, 1Password 4 for Mac can help, thanks to its new Security Audit feature.

Let’s use an analogy: say that Molly (one of my dogs, and not really the cleverest of beasts) has just started using 1Password. She has a few passwords, but not many. Even though she doesn’t know how to push open a door that is already ajar, she can make use of the new Security Audit tool in 1Password for Mac.

In the left sidebar of 1Password 4 for Mac, down toward the bottom, there is a section called “Security Audit”. When Molly clicks (or paws) “Show” next to “Security Audit” she sees a number of audits available. She can select “Weak Passwords”, which will show her all of her items with weak passwords. She can also look at password items that are old. But the selection we are interested in today is “Duplicate Passwords”.

Security Audit: Molly's duplicates

Security Audit in 1Password 4 for Mac, displaying Molly’s duplicate passwords

What Molly sees is that she has two sets of duplicates. One of them is used for two Logins, and the other one is used for four Logins. As we can see, her Adobe.com password of “squirrel” is used for her Barkbook, Treats R Us, Cat Chasers Logins as well.

Molly transfixed by "squirrel"Molly should, of course, go to each of those sites and change her passwords on them. But there are squirrels in the back yard to bark at, and changing all of those passwords may seem overwhelming. So Patty (the cleverer dog in the family) advises Molly to think about which of those Logins are most crucial. Molly can’t tolerate the thought of anyone else getting a treat; so she starts with Treats are Us.

This does mean going to the Treats are Us site and using its password change mechanism. 1Password is smart, but it isn’t quite smart enough to go browsing through the sites to find their password change pages. Molly may decide that her Barkbook Login is also very important, and so will change that one right away as well.

Ideally, Molly should fix all of her weak and duplicate passwords as soon as possible. And as Molly has only a handful of Logins, she could do that. But for those of us who may have a large number of old accounts, it is probably best to check Security Audit and update reused or weak passwords at the most important sites first. Then, updating other passwords a few at a time is an easy way to make all our accounts much more secure.

More than just one password: Lessons from an epic hack

Mat Honan, a 1Password user and writer for Wired, did everything right. He had strong, unique passwords everywhere. Yet he was the victim of an “epic hack”, and had to put a great deal of effort into getting his digital life back.

A very brief account of this Homer-worthy hack is that someone talking to Amazon customer service got into Mat’s Amazon account, from which they were able to learn enough about him to then call Apple’s customer service to get a new password set. Once they had Mat Honan’s Apple ID and password they used Remote Wipe to erase his iOS devices and his Macs.  This has been written about extensively elsewhere, but I would like to talk about this in the context of whether there are useful lessons for 1Password users.

Mat described part of his recover process thusly:

I’m a heavy 1Password user. I use it for everything. That means most of my passwords are long, alphanumeric strings of gibberish with random symbols. It’s on my iPhone, iPad and Macbook. It syncs up across all those devices because I store the keychain in the cloud on Dropbox. Update a password on my phone, and the file is saved on Dropbox, where my computer will pull it down later, and vice versa.

But I didn’t have it on any of our other systems. So now I couldn’t get to my keychain. And so I was stuck in a catch-22. My Dropbox password was itself a 1password-generated litany of nonsense. Without access to Dropbox, I couldn’t get my keychain. Without my keychain, I couldn’t get into Dropbox.

Lesson 1: Some might need more than one password

I love the idea that 1Password allows me to just remember one password, my 1Password Master Password. But some of us may actually want to remember a couple more. Here are the strong, unique passwords that I choose to remember:1Password in Dropbox

  1. My 1Password Master Password for the desktop
  2. My 1Password Master Password on my iOS devices
  3. My Dropbox password
  4. The passcode for my iOS devices
  5. My computer login password
  6. Password for my primary email account

Not everyone will have the same list. Plus, if you use the same Master Password on iOS as you do on the desktop, then your list is of course a little shorter.

What is relevant here is number 3 on that list. I need my Dropbox password in circumstances where I may not have access to 1Password. For example, when I start using a new computer, the first thing I install is Dropbox and the second thing is 1Password. This way, I have all of my 1Password data available to me as I go about setting up subsequent things.

Of course if I always had my phone with me, I could get my Dropbox password from 1Password on my phone, but I didn’t want to count on always having my phone. I’m guessing that this is what Mat did, and he certainly didn’t count on having his phone maliciously obliterated—along with all his other devices—via iCloud’s remote wipe feature.

Fortunately, Mat found a way back into his Dropbox account—turn out he had set up Dropbox on a machine that had not been wiped. So he was able to get to his 1Password data there, and begin to recover his digital life.

Constructing strong, memorable passwords

How do I make good strong passwords that I can also remember? I try to follow my advice in Toward Better Master Passwords. I have yet to follow my own advice with everything, but I am slowly migrating the few passwords that I do need to remember to that system. Indeed, it makes sense to change these gradually so that you are sure to have solidly memorized one new password before creating another that you need to remember.

A few more things I remember

In addition to the passwords that I feel I have to remember, here are a few things that are very convenient for me to remember instead of always looking up in 1Password. I can look them up if I really needed to, but often I need them where I can’t easily get them from 1Password:

  1. My bank card PIN
  2. My bicycle lock combination
  3. My Apple ID password
  4. My SSH private key password

I simply  haven’t figured out a way to copy and paste my bike lock combination from 1Password to the lock.

Lesson 2: Become a backup believer

There are two kinds of computer users: Those who have experienced a catastrophic disk failure and those who will.
— Ancient wisdom, source unknown.

First of all, making backups is essential. Today most people have two options for a backup system. We can go with off-site backups, or we can back up to a local disk. Backing up off-site is great protection if your house burns down or is burgled. You have put your eggs in different baskets. Backup to a local disk has the advantage that you aren’t depending on a remote service that you may not be able to access in an emergency. It is hard to make a case that one strategy is better than the other in general.

Here is something that Mat learned in the process.

I’m certainly a backup believer now. When you control your data locally, and have it stored redundantly, no one can take it from you. Not permanently, at least. I’ve now got a local and online backup solution, and I’m about to add a second off-site backup into that mix. That means I’ll have four copies of everything important to me. Overkill? Probably. But I’m once bitten.

But – and here is another reason to have a memorable Dropbox password – your online, off-site backup system will require a password to access. If you encrypt your at-home backups, those too will require a password to work from. Good backups are important, but you may need to get to your 1Password data before you can restore from a backup.

An old lesson: Don’t reuse passwords

Even if we take good care of our passwords, that doesn’t mean that all the sites and services that we use take the same care. Mat’s case illustrates this fact when it comes to password reset mechanisms, but it can also apply to how passwords are stored and encrypted on sites. Because not everyone handles things perfectly, we need to make sure to use unique passwords for each site and service.

Password reuse strikes again, and a bit closer to home at Dropbox

1Password in DropboxNot so long ago, I wrote about a case where attackers were taking passwords that were leaked from one site to go after users on another. In that case, the target was Best Buy. Today’s case hits a bit closer to home for 1Password users, as Dropbox accounts are being attacked using passwords stolen from non-Dropbox sites. Just as no passwords were stolen from Best Buy, no passwords have been stolen from Dropbox. The passwords were stolen from breaches at other sites and then just applied to Dropbox accounts.

To give you an idea of the dangers of password reuse and how this type of attack works: suppose Molly has an account on chasing-cute-cats.com and that site got breached. Also imagine that the site didn’t store passwords in sufficiently secure ways, so that after the breach it was possible for attackers to actually figure out what many users’s passwords, including Molly’s, are. The attackers now have Molly’s username and password on that site. You might figure that there is little harm done because there really isn’t a lot that people could do with Molly’s account on chasing-cute-cats.com.

But now suppose that Molly uses the same username and password on Dropbox (Molly doesn’t take advice all that well). The attackers can try to log into Molly’s Dropbox account with the username and password they discovered from the breach at chasing-cute-cats.com. This, according to the recent announcement by Dropbox, has been going on with a small number of Dropbox accounts.

Users of 1Password probably don’t need to be reminded why it is so important to have unique passwords for every separate site and service. But because this case of password reuse with Dropbox is such a good reminder, it can’t hurt to talk about it again in the hopes we can all help spread the word.

Of course, even if someone were to get a hold of your 1Password data through Dropbox or some other means, they would not be able to get your usernames, passwords, and other data stored within it without knowing your 1Password Master Password. But this is why we designed the 1Password data format with the knowledge that some people may have their data files stolen. Indeed, just yesterday I wrote (in gory detail) just how well 1Password and your Master Password work together to resist even the most sophisticated password cracking tools.

Irony, spam, and discovery

Mail things this message is spam

One of the accounts broken into that way belonged to a Dropbox employee.
It turned out that that the unnamed (but presumably very embarrassed employee) also had some files that included the usernames (which are email addresses) of some Dropbox customers. Naturally, the attackers did what attackers do when they get a hold of a bunch of email addresses: they passed (presumably sold) that list to spammers.

Again, it was only the email addresses that got taken; not passwords. But then, spam went out to a number of Dropbox users, some of whom had set up site specific email addresses. For example, Patty may have created an email address patty+dropbox@example.com that he used only for Dropbox. Nobody knew or ever saw that email address except for Patty and Dropbox.

But if Patty+dropbox@example.com was among the email addresses stolen and passed on to spammers, Patty would start getting spam to that address. Patty, being the clever one, would realize that somehow her Dropbox email address had been captured. She might even complain to Dropbox about this, along with a few others who have suddenly seen spam to their Dropbox-only email address.

And now we arrive at the beginning of the story. It was exactly complaints like this that led Dropbox to bring in an outside security investigator to look at the spam issue back on July 18.

What have we learned and what is there to do?

Molly is afraid of ThunderFirst of all, we have been reminded yet again that Molly is not as clever as she thinks she is, while Patty shows an abundance of caution (sometimes too much). Now, regular readers of my posts will know that Molly and Patty are my dogs. Molly, while incredibly sweet, wins few prizes for intelligence. Patty is much brighter, but is always on high alert and will fire off a warning bark if a molecule moves across the street. There is a lesson somewhere in here about learning to be cautious about the right things. Panicked people (and dogs) tend to make poor security decisions, but that discussion is for another time. All we need to say here is that Molly, as presented above, needs to have a unique password for each site.

Patty barks at everything

We are also reminded that one site’s security is dependent in some ways on other sites. The operators of chasing-cute-cats.com might think that they don’t need to be particularly careful with their users’ passwords, but they are wrong. As long as people (or dogs) reuse passwords, it is the responsibility of everyone who stores passwords to store them in uncrackable forms.

Furthermore, because so many websites and services are storing passwords poorly, we all need to act as if our website passwords are stored poorly at each site. As we’ve been reminded by an ongoing case involving Tesco (a large UK grocery chain and retailer in the UK and Europe), its generic statements like “passwords are stored in a secure way” are meaningless unless we are told how they are encrypted.

How many passwords do I need to remember?

I would love to be able to say that with 1Password you only need to remember your 1Password Master Password. It’s in the name. 1Password does the job of remembering all of the other non-memorable passwords. After all, Troy Hunt is largely right when he says that the only secure password is the one that you can’t remember. But the first thing I do when I set up a new computer is install Dropbox to sync my 1Password data, and then install 1Password. There are times when I need to know my Dropbox password in order to be able to use 1Password. So, despite the name, I actually need to remember two strong, unique, and, this time, memorable passwords.

Fortunately, you and I can use the mechanism described in Toward Better Master Passwords to be able to manage the very few passwords that we actually need to remember.

Friends don’t let friends reuse passwords

We’ve written about password reuse before, and we’ll be writing about it again. Password reuse—using the same password for multiple sites or services—is both rampant and dangerous.

There is real evidence that people are getting robbed because they are reusing their passwords. Thieves systematically exploit reused password to pay for retail items or hijack accounts for other intentions. And yet, we are reminded again this week by the recent leak of almost half a million Yahoo passwords that a majority of people just can’t stop reusing passwords.

I’ve seen password reuse and the damage done

Suppose you used the same password on Sony’s PlayStation Network as you Best Buyuse for your password when shopping with Best Buy. Now, suppose that your PSN username and password was among the 77 million leaked in April 2011. An attacker could, in principle, use that information to take a good guess at your password for, say, Best Buy.

Well this isn’t just something that can happen “in principle”. From an underappreciated report by John Fontana over at ZDNet:

After months of Best Buy customers reporting compromised accounts, the company has finally confirmed hackers are attacking its online retail site using credentials stolen from other sites.

It’s a worst-case scenario, where credentials stolen from one site are used to access other sites, most notably retail or banking sites where hackers can extract some value.

I have no doubt that things like this have been going on for a while, but it is always hard to confirm that this is what has happened when someone “hacks” a users account at a retail site. So let there be no doubt that password reuse puts people into real danger. It happens.

Some habits are hard to kick

Sites and services that store user passwords unencrypted or poorly hashed are a serious danger to their customers. But when they get breached and their password database made public, it is a boon to people who study password security. One of those people is Troy Hunt, who has taken this as an opportunity to look at password reuse between PSN and Yahoo.Chart of PSN-Yahoo password reuse

Of the 302 usernames in common between the two breaches, 59% of them had the same password on each site. Note also that the PSN breach was more than a year ago and was very widely reported. Put simply, we can estimate that about 60 percent of people ignore advice to change their passwords elsewhere.

Helping you to help yourself

I’ve argued many times before that when we see people systematically making poor security choices, we can’t just blame the user. We—the security business—have to look at how we can make it easier for people to behave securely. 1Password is our attempt at fulfilling that goal. We work to make it easy for people to have strong and unique passwords for each site.

First of all, 1Password provides you with a Strong Password Generator, in both the app itself and the 1Password browser extension. This generator makes it drop-dead-simple to create website passwords that are strong and unique. Plus, you don’t need to remember them because 1Password remembers them for you.

Although 1Password wasn’t born yesterday, many of us have Logins and passwords for sites that were created before we had the Strong Password Generator, which means we may still be using some passwords on multiple sites. Here are some tips on how to use 1Password to help you find duplicate password and clear those up.

Websites have responsibilities, too

Anybody who stores your passwords has responsibilities, too. We know that sites get compromised and their user databases stolen. What we don’t really know is how frequently this happens because only a fraction of those breaches get made public. Not only do websites and services need to take steps to prevent the theft of their user’s personal data, they need to store the passwords in a form that is useless to intruders.

It appears that the Yahoo passwords were stored with no encryption or hashing at all. I was astounded when this was discovered with Sony’s PSN last year, and I am astounded today that Yahoo would make the same mistake. I have been berating sites for not hashing their passwords well; I hadn’t expected to encounter more sites that didn’t hash at all. Because of their poor practice, everyone whose Yahoo password was leaked is vulnerable to having their accounts hijacked on every other site where they use the same password.

On password breaches and security processes

Today it was reported LinkedIn had a password breach. This is the most frustrating sort of security problem, because even if you’re using all the security available on the longest most complex password you can generate, that doesn’t help if someone else gets ahold of it. As more and more services are offered online, and then connected to other logins you already have, it’s not just a minor password change when something happens to, for example, your Facebook password. Now you have to worry that whoever got access to Facebook now has access to all those other things. Do you even remember what ALL those other things are?

As part of the “security is a process, not a product” philosophy we use here at AgileBits, there are a variety of things to consider when you want to secure your online activity. One such thing is what I mentioned above: those other apps and services you authorized to use your login on Facebook or Twitter, or in today’s current example, LinkedIn. It’s a good idea to review those permissions periodically, and one handy way to do that is with a site called MyPermissions.

You can think of MyPermissions as a dashboard for reviewing and controlling your preferences across many of these sites at once. It’s like cleaning out your closet and getting rid of all those things you have no more use for. Hopefully you won’t have too many “I authorized THAT!?” moments, but if you do, revoking access is usually pretty easy.

On the upside, one of the nice things about 1Password is the extra layer of security it provides with the Strong Password Generator. As long as we see that “Password1” is still one of the most popular passwords in use, you, dear 1Password and Strong Password Generator user, are already way ahead of most people when it comes to securing your data.

If you still have friends, family, or coworkers who just don’t get why strong passwords are more important than ever, here’s an analogy that might help: Using a really common easy password (password, Password1, 123456, etc) is the equivalent of leaving the windows down and the keys in the car. Using 1Password is locking the car, rolling up the windows, and having an excellent alarm system. Why would a thief bother with your car when there’s one right next to it just begging to be stolen? Particularly when we are talking about logins that store credit card data (Amazon 1-click, anyone?), a nefarious person will be happier with the hundreds of numbers they can snag in less time than it would take to crack your password.

I know it’s frustrating to have to keep track of all of this, but it’s really no different than real life. I always think of the Public Service Announcement on television where a guy walks up to people in a coffee shop and starts trying to convince them to let him use their bank account for a wire transfer. Everyone turns him down and the ad says “If you wouldn’t fall for it in real life, why fall for it online?” It seems like more work because most of us haven’t been doing this our whole lives, so it’s not second nature like “don’t wave around the money you just got from the ATM” and other life tips we now consider common sense.

Having said all that, here are some useful information and steps to find your weakest links and strengthen them.

You can start by opening 1Password for Mac and selecting View > Layout > Traditional. Once there, then go to View > Columns > Password Strength, and make sure it’s enabled. Now you can see, and sort by, the security of all your passwords. If you want to collect the weakest passwords, create a Smart Folder to show those. Go to File > New Smart Folder, and a search dialog will pop up in the top of your window. Make sure you set the search criteria in the bar at the top to search “Everywhere” and “Everything,” and below that select the following:

  • All of the following are true:
  • Password Strength
  • is less than or equal to
  • Select a number here. It doesn’t matter what number you use. Start with 40 and if that looks overwhelming, switch to 20. Once 20 is done, then go back to 40. This is your first pass at updating passwords.
  • Click Save, and retitle your New Saved Search something else (Mine is just called Weakest).
  • When you have time to devote to updating these weaker passwords, you can use the Password Generator within 1Password to update them. As you increase the strength, they will no longer show in your Smart Folder.
  • Now you’ve updated all of the ones that were the weakest. Hooray! Now right-click (or ctrl-click) on your empty Smart Folder and choose Edit Smart Folder… and bump up that number. Now if you have a few more showing, get those updated too.

Of course, I don’t expect you to drop everything and blow your weekend on the exhilarating task of updating your passwords. But when you have a little time to spare, knock off a few here and there. The next thing you know, your weak passwords are history.

Two thirds of web users re-use the same passwords

I may never get tired of talking about password reuse (using the same password on different sites), but you may get tired of hearing me go on about this. So I will keep this post short.

Troy Hunt has done an excellent analysis of the passwords of the most recent Sony breach. There are lots of scary data in there, but I wish to highlight that two thirds of users whose data were in both the Sony data set and the Gawker breach earlier this year used the same password for each system.

If you use 1Password on the Mac, take a look at Mike’s tips on how to use 1Password to help identify duplicate passwords and get you strong, unique passwords for every site.

1Password for Windows users can identify passwords that may be identical simply by sorting their passwords by password strength.

To change an existing password for a site, you can’t just change it entirely within 1Password, but you need to go through the website’s password change mechanism. Take a look at our guide for changing passwords for how 1Password can help you every step of the way.

[Edited 2011-06-09 to correct Troy Hunt’s name and affiliation]