Posts

Filling with your approval: On 1Password’s App Extension and iOS 8 security

App ExtensioniOS 8 has an incredible feature coming called App Extensions, and we’re thrilled to say we have a 1Password extension ready for developers to use right in their apps! In apps that gain support for our extension, you will no longer have to copy and paste passwords from 1Password. Yes, it really is a game changer, and you can see it in action for yourself.

Naturally, this new-fangled way for apps to interact in iOS 8 is leading people to ask how we do this in a secure manner:

  • Are we really letting third-party apps poke around inside of your 1Password data?
    • Answer: No, that is not how extensions work.
  • Can these third party apps ask 1Password for your PayPal password?
    • Answer: Well, they can ask, but you decide if they should get what they ask for.
  • Can they trick you into entering your 1Password Master Password into something that isn’t 1Password?
    • Answer: The very same mechanisms that prevent that today apply to application extensions.

TL;DR

I will elaborate on all of this below. But to summarize, all of my points and these safeguards in both iOS extensions and 1Password are built on an important design principle: Nothing happens without your explicit action.

Read more

Heartbleed: Imagine no SSL encryption, it’s scary if you try

heartbleedOnly two months ago, in the wake of the “goto fail” bug, we had to point out that 1Password’s security does not depend on SSL/TLS. Today, with the far more damaging Heartbleed bug in OpenSSL, we need to tell you the same. 1Password’s technology is not built upon SSL/TLS in general, and not upon OpenSSL in particular. 1Password’s encryption remains safe.

This bug matters for everyone

Just because 1Password’s technology isn’t affected by this doesn’t mean that you aren’t. Pretty much everyone is affected by this. Many of the secure connections that you use with various services, including HTTPS connections to secure sites for shopping and many other activities, may be fully readable to attackers. Of course, this includes the usernames and passwords that you use to log in to various services. It’s not just HTTPS connections, but IMAPS—how your email program, such as Mail.app or Outlook, talks to a mail server—may be vulnerable.

“So I need to change all my login passwords, right?”

Your 1Password data remains safe, as does your 1Password Master Password. But whether or not you use 1Password to log into an affected site or service, your username and password, along with everything else that happens over that supposedly encrypted connection, may be exposed to attackers.

You will, at some point, need to change a lot of passwords. And 1Password makes this much easier than it other would be. But don’t rush to do that just yet. Not every server is affected, and those that are need to fix things at their end before you change your password. If you change your password before the servers fix things, then your new password will also be vulnerable to capture.

All that most of us can do is wait at this point. Presumably, various service providers will announce over the next few days when and whether users should change passwords or be aware that other confidential information may have been exposed.

Change password example

When changing your passwords, be sure to pick “Update existing Login” from 1Password’s prompt!

At this point, I can only guess at how long it will take for various service providers to make announcements. They are in a difficult position right now. First, they need to determine whether they are vulnerable. That means finding out if their particular SSL/TLS service was using OpenSSL (the most popular SSL library in use today) version 1.0.1 (Released March 2012) through 1.0.1f (1.0.1g, containing the fix, was released April 7, 2014).

Once a service upgrades to a fixed version of OpenSSL (or to some other cryptographic library), they will need to revoke the certificate that they had been using with with the vulnerable version of OpenSSL and obtain a new certificate. Exactly how long that takes will depend on how quickly they can get things sorted out with their certification authority. Certification authorities are going to be very busy over the next few weeks.

Only after a new, certified certificate is in place on a server that is not using a broken SSL/TLS library will it make sense for you to update your password for that service (or even trust your communication with it). Most of us simply have to wait until notified by various websites and services when and whether we should change passwords.

Certificates and keys

If you are curious about what is actually exposed by the heartbleed bug, read on. It requires some understanding of how certificates work, but I’ll try to give an overview of just the parts we need for this discussion. I will take a lot of shortcuts in the presentation and pretend that things are simpler than they actually are.

How certificates and keys work

In order for your browser and a web site to encrypt the communication between them, they need to use an encryption key. That key is typically a 128-bit number. Now, it may be that your browser and the particular website have never spoken to each other before, so they need to work out an encryption key for this session in such a way that someone listening in will not know what the key is. It’s as if they have to work out a password to share between them while communicating where anyone can listen.

The encryption key that they work out is just for that particular session. The next time your browser establishes a connection to that server, a new key is worked out. This is called a “session key”.

Establishing a session key

Your browser and the server work out a session key using something called “public key encryption”. Public key encryption is the nearest thing to magic you will find in mathematics and cryptography. When I describe what I do to school kids on career day, I say that I get to think like a criminal and do magic with math.

Anyway, the server will have a public key and a private key that are mathematically related. The public key is not a secret at all. The mathematically related private key is. It is possible to use the public key to encrypt stuff that can only be decrypted with knowledge of the private key.

So (and this is taking a big shortcut), your browser can pick a random session key and encrypt it using the server’s public key. Because only the server knows the corresponding private key, only the server can decrypt the encrypted session key. Once your browser has sent a randomly chosen session key to the server, both the server and browser can use that session key for their communication throughout that session.

The private key is a big, long number. Often thousands of bits long. And it can’t be just anything; it has to have the appropriate mathematical relationship to the public key. Clearly no human is going to be dealing with those keys directly. Typically, those keys are stored in a something that can be used by the server software and is protected by a password.

This scheme of using a password to protect a key and then have the key be used for the encryption is typical of high security software. You find this in SSH, PGP, and in 1Password. A strong key is picked by the software and that key is then encrypted with a password that a human uses. With 1Password, your data is encrypted with a random 256-bit key that is chosen when your data vault is created. Your Master Password is used (indirectly) to encrypt that key (again, I’m skimming over some details).

How heartbleed bleeds your privacy

Anyway, the heartbleed bug pretty much allows an attacker to probe a server that will end up revealing the private key. Once an attacker knows the private key, they can decrypt session keys that have been sent to the server, and thus decrypt all of the encrypted traffic that goes back and forth between the browser and the server.

Another bit of magic with public key encryption is the notion of “digital signature.” Your browser can create a mathematical challenge using the public key that only someone with knowledge of the private key can solve. This is part of how a website proves to a browser that it is what it says it is. If an attacker learns the private key of some website, then it can masquerade as that site.

All in all, the capture of a server’s private key is a bad thing, and that is what this bug enables.

Update for system administrators

Most of us ordinary folk need to wait for sites that need fixing to actually get fixed, then wait for instructions on whether we need to change passwords. But some of us need to get working. The definitive source for information about Heartbleed is heartbleed.com.  Since this article was originally written, Filippo Valsorda has published a tool for checking which sites are vulnerable (this has also finally pushed me to play with the Go programming language I’ve been hearing so much about).

Heartbleed pass

The IMAPS server passes the Heartbleed test

Valsorda has also created a web page based on his testing tool, which makes it easy for people who don’t wish to install and run the command line program to see which websites (or other services) are currently vulnerable to Heartbleed. I wanted to test the IMAP (mail access) server used by Fastmail.fm (which I use for my personal mail).  The name of the IMAP server is “mail.messagingengine.com” (which I happened to look up in my Email accounts category in 1Password). Because I wasn’t testing normal HTTPS, which used port 443, I also had to enter the port number for IMAPS, 993.  So what I put in the form was “mail.messagingengine.com:993″. This nicely passed the test at the time I tested.

Heartbleed fail example

The Heartbleed test fails for Dreamhost at the time of testing

To test a website, you do not need to put in the port number. The test will default to port 443 (HTTPS). So I was able to test Dreamhost.com by just using “dreamhost.com” in the form. At the time I tested, dreamhost had not updated to the fixed version of OpenSSL, and so the test reported it as vulnerable.

Patching OpenSSL isn’t enough

It is important to remember that during the period that your site was vulnerable attackers could have captured the key for the SSL certificate. Once they have your key, they can (under most circumstances) continue to read and manipulate traffic to and from your site. So the next step is to generate a new certificate and get that signed by a Certificate Authority. This is also a good opportunity to ensure that your RSA or DSA key is at least 2048 bits long. 1024 bit RSA and DH keys are no longer considered safe.

Once you have your new certificate signed and in place, you should inform users that their sessions may have been compromised prior to the installation of the new certificate. They should then change their passwords and take whatever other action is appropriate given that confidential data may have been exposed.

Updates

The bulk of this article was drafted late Monday (April 6) night and in the wee hours of Tuesday morning. We will have a series of other articles and announcements coming soon, so please continue to watch the Agile Blog for news here and 1Password on Twitter,  on Facebook, and on App.net. We will also be providing only minor updates to this post, as we prepare new ones.

April 12

  • A new certificate for agilebits.com was put in place on April 10 and Dropbox.com put a new certificate in place on April 11.
  • Now that Dropbox is using a new certificate, we’ve removed the earlier advisory for users of the 1PasswordAnywhere feature.
  • We’ve added some links to password changing instructions for 1Password 4 for Mac.

Crackers report great news for 1Password 4

To understand why this is really good news for us and for 1Password users, it is important to know what “crack” means in this context. I’ll come back round to that and why we encourage the developers of hashcat, John the Ripper, and cryptohaze to take a crack at 1Password. But first, let’s talk about this news and what it says about your password security.

Cracking fast and slow

If someone gets your 1Password data, they will not be able to decrypt it without your Master Password. A determined attacker might then try to guess your Master Password. Your job is to pick a good Master Password so that it will take trillions of guesses before the attacker finds the right one. Our job is to make sure that they can’t make millions of guesses per second on common hardware, thus significantly slowing down the guessing process, ideally to the point of futility. We do our job by using a “slow hash” for deriving encryption keys from your Master Password. In 1Password 4, that slow hash is PBKDF2-HMAC-SHA512. For the Agile Keychain Format it is PBKDF2-HMAC-SHA1.

keep calm

Jens Stuebe, the developer of a password hashing system called hashcat, has been testing just how many guesses per second he can get out of hashcat for the 1Password 4 data format. The hashcat demonstration showed fewer than 500 guesses per second, but with somewhat beefier hardware and a more realistic data file, a better estimate based on the hashcat data would be between 5,000 and 20,000 guesses per second. For all of the calculations below, I will use the more pessimistic (for us, the defender) estimate of 20,000 guesses per second. It’s not because I think the pessimistic estimate is the most realistic, but simply that it is better to err on the side of caution.

If you use a four word password from the scheme described in Toward Better Master Passwords, then at 20,000 guesses per second it would take more than 5,600 years for a high-end PC with with multiple graphics processing units (GPUs) to work through all of the 3.65 trillion equally possible passwords. Of course, the attacker won’t have to try all of those. On average, she will find the right one after going through about half of the possibilities. So the average time to crack will be about 2,800 years. If you use a five word password, then the average time to crack will be more than 20 million years.

20-and-5K-guesses-per-sec

We like crackers

With enough time (perhaps far more time than the life of the universe) it will always be logically possible to guess a Master Password. This is simply the nature of the beast. We need to know how many guesses an attacker can make in a second, a day, a year with the resources available to them so that we can devise the most effective defenses against these sorts of attacks.

We make our own estimates, but the best estimates come from looking at real data. We will, on occasion, run our own tests but the people who specialize in password cracking are the people who perform the most stringent tests and will look for things that we might not notice. We want to know how hard they have to work at guessing passwords. We are extremely supportive of projects like John the Ripper, hashcat, and Cryptohaze. Indeed, conversation with people involved in these projects has very much helped us develop better resistance to password cracking.

This is one of several reasons why we are open about our data format. We get better analysis from the security community by doing so. Hashcat, and John the Ripper, worked against some sample data we make available to the public.

Cracking isn’t breaking

When crackers develop tools to guess at 1Password Master Passwords, they are not “breaking” anything. They aren’t exploiting vulnerabilities. They are just automating password guessing. Because they are working directly on the data files themselves, not with the 1Password software, things like lock-outs after multiple failed guesses aren’t an option (and don’t provide any meaningful security against encryption tools like this).

The technical stuff

The 1Password 4 data format uses PBKDF2-HMAC-SHA512 with an absolute minimum of 10,000 iterations when transforming a Master Password to a decryption key. I’m not going to explain what all of that means, but I will say that PBKDF2 is a Password Based Key Derivation Function that is designed to require that there be lots of computation in getting from an entered password to a key. It is specifically designed to slow down cracking attempts.

The attacker is able to build special machines for their cracking efforts, and software carefully optimized for that hardware. Defenders like us have to be able to process a single password in an acceptable amount of time for them on the hardware in their pockets. As a consequence, the attacker can process a candidate password much more quickly than the legitimate user. @bitwiesil, the developer of Cryptohaze, describes this as an Attacker/Defender Ratio (ADR).

For example: if it takes 1/4 of a second for a user’s Master Password to be processed on their mobile device, but the attacker using specialize hardware can make 10,000 guesses per second, the ADR would be 2,500. In a perfect world, the ADR should be 1:1, but that is never going to happen. Plus, ADR in the tens of thousands, instead of in the millions or billions, is a hard but more realistic goal.

The limits of PBKDF2

PBKDF2 isn’t perfect. Most importantly, it can only go so far. We can reach a point where even tiny improvements to a password (say, just adding a digit) can offer far more additional protection than adding extra strength to PBKDF2. For example, adding a single random digit to the end of a password will offer as much as going from 30,000 PBKDF2 iterations to 300,000. And the latter can do real harm in making legitimate decryption too slow. Increasing the number of PBKDF2 iterations does not change the Attacker/Defender ratio at all.

There are a couple of other things that PBKDF2 doesn’t do. When it uses SHA1 internally (a very common configuration), it can be optimized to run extremely quickly in GPUs, giving the attacker a high ADR. Computers built with several (or many) GPUs operating in parallel can still perform many billions of SHA1 computation per second. GPUs cannot be so easily tuned when PBKDF2 uses SHA512 instead of SHA1. Our use of SHA512 within PBKDF2 in 1Password 4 is overwhelmingly the biggest reason that we are seeing such a small Attacker Defender Ratio in the hashcat report.

There is another, more subtle issue with PBKDF2 which can allow the attacker to double the ADR in some peculiar cases. Those cases can be avoided (once people know to avoid them), and a doubling of the ADR is not a big deal. But this does show that PBKDF2 is not the slow hash we would design today.

PBKDF2 is not “memory hard”. It is designed to raise the cost in computation for both attacker and defender, but it doesn’t force a substantial demand on computer memory. If, as the case has been, that the price of computations falls faster than the price of computer memory, the attacker can affordably purchase or rent a fleet of fast processors. But, if we build a slow hash function that also requires substantial memory use, we have more flexibility in trying to reduce the ADR.

So why do we stick with PBKDF2?

For all of its warts, PBKDF2 is the best choice for 1Password today, although it may not be tomorrow.  We can mitigate some of the limitations of PBKDF2 in our design, which we currently do. After all, the great results that we have from this weekend’s hashcat report show that we continue to be successful with it.

The best alternative to PBKDF2 that is reasonably well available and scrutinized is scrypt. If scrypt or similar had been further along as a standard, we probably would have used that. But because you need to unlock your 1Password data on a variety of different platforms, we need to use cryptographic functions that are included in well-tested libraries for all of those platforms.

This is why the Password Hashing Competition is so important. This is an effort to develop and agree upon a design for a successor to PBKDF2 that takes into account everything we’ve learned since it was first developed. The aim is that the successor will have enough support to become available to developers in many cryptographic tool kits. But that is a hope for the future. Right now we continue to use PBKDF2 in a way that takes its various quirks into account.

Your part of the job

Even the slowest hash with a perfect Attacker/Defender Ratio can’t protect a weak Master Password. Our job is to make sure that, when an attacker needs to guess trillions of passwords, they have to really work to do so. Your job is to pick a good Master Password so that it is trillions of passwords they need to guess instead of thousands. In our sample data that hashcat used, the password was “fred” (this was also made public). So even performing less than 500 guesses per second, hashcat was able to find the password “fred” in less than a minute.

Updated to correct spelling and add in a few links.

Your Master Password is your defense from Dropbox breaches, real and imagined

1Password in DropboxRumors of a Dropbox data breach spread this weekend, a breach that ultimately turned out to be false. But even in instances of false alarms, it is useful to remind 1Password users that their 1Password data cannot be decrypted without the Master Password. So let me take this opportunity to remind everyone that your 1Password data cannot be decrypted without your Master Password. If someone steals your 1Password data – whether from the theft of your own computer or through the breach of a sync service – they cannot decrypt it.

Fact checking

It is worth noting that when a perpetrator of a rumor like this self-identifies as “Operation Troll Security”, it might be worthwhile to double check their claims before jumping to conclusions or even reporting the claims further. This is particularly true if a perpetrator has a history of claiming responsibility for every notable site outage, then laughing at people who believed them. Operation Troll Security doesn’t often tell the truth, but it may be wise to heed one particular tweet:

https://twitter.com/1775Sec/status/421861679631044608

Despite the fact that the claims of a Dropbox breach were a complete hoax, it still is worthwhile to point out some things about the security of your 1Password data if it ever does fall into the wrong hands.

End-to-end encryption

1Password uses what is called “end-to-end” encryption. 1Password on your computer or mobile device encrypts your data with keys that are derived from your Master Password. Those keys are never stored anywhere or transmitted. Nobody, not even us at AgileBits, ever sees those keys or your Master Password. This is why it absolutely essential that you don’t forget your Master Password. We cannot reset it or reconstruct it. Your data can only be decrypted by you.

We designed 1Password this way from the outset because we knew that computers get stolen and services get compromised. By placing all encryption and decryption under your control, we become far less reliant on the security of any sync service.

Protecting Master Passwords

If an attacker does get hold of your 1Password data, the only feasible way for them to attempt Password Based Key Derivation Function diagramto decrypt it would be to try to guess your Master Password. Of course, they wouldn’t sit there typing in guesses. Instead they would run automated password guessing systems against the data.

We have a long history of building mechanisms into 1Password’s data format that make it harder for attackers to guess your Master Password. When we released 1Password 2.5 in 2007 with the then new Agile Keychain data format, we added PBKDF2 so that anyone trying to run automated password guessing systems against captured 1Password data would have to perform lots of slow computation for each guess. You can read more about PBKDF2 and this aspect of our design in an older article of mine, Defending against crackers: Peanut Butter Keeps Dogs Friendly, Too. Many of the details have changed over the intervening years, but the essential concept remains the same.

Toward better Master Passwords

DicePBKDF2 makes it harder for those automating password guessing, but it does have limits. You need to do your part by choosing a good Master Password. Even a small improvement to a Master Password goes a long way. Adding a single truly randomly chosen digit to the end of your Master Password makes the attacker work ten times longer to guess it. Adding a truly randomly chosen word make the attacker work thousands of times longer. Adding two truly randomly chosen words makes the attacker work tens of millions of times longer.

You will note that I emphasized the phrase “truly randomly” a few times there. That part is crucial. People turn out to be very unrandom even (especially?) when they are trying to be random. If you follow our advice in Toward Better Master Passwords, you will see how you can securely pick words at random to add to a Master Password. Hint: It involves rolling dice. It’s fun!

A hoax is a hoax, of course of course

Even though the report of a Dropbox breach was a hoax, you still may ask what role Dropbox security plays in the security of  your 1Password data. I hope that this article helps explain that and how using 1Password can keep your secrets safe. I look forward to further discussion in our forums.

1Password and The Crypto Wars

Of all of the revelations about the NSA that began in June and continue to this day, the one that has shocked me the most is the fact that the United States National Security Agency has been deliberately inserting weaknesses into security products and even into NIST standards. In light of this, it is fit and proper for anyone who relies on 1Password for their security and privacy to ask whether 1Password has been, or could be, tampered with to deliberately weaken it.

The easy questions

Has 1Password been deliberately weakened?

No.

Have we, AgileBits, ever been asked/compelled/pressured/contacted by any entity asking us to weaken 1Password?

No.

Could we be compelled to weaken 1Password or allow for the weakening of 1Password?

Not without substantial risk that such attempt would become public.

Those questions are the easy ones to answer. The harder question is why you should believe those answers.

Why should you believe us

It is impossible to absolutely prove that our answers to the easy questions above are truthful. But what I can do is provide a number of more verifiable claims, each of which makes it harder for us to lie about any of this. In combination, these should be enough to persuade you that there is no backdoor (deliberate weakness) in 1Password and that it would be very unlikely for one to be introduced.

They can’t gag all of us

We have developers in four separate countries: Canada (AgileBits is a Canadian company), the United States, the United Kingdom, and the Netherlands. The gag orders that accompany National Security Letters in the US would not bind non-US citizens outside of the US. Likewise the Canadian, British, or Dutch analogues to National Security Letters wouldn’t bind US citizens. To compel all of us to betray our customers and principles, they would need to coordinate that legal compulsion in four jurisdictions.

This doesn’t entirely rule out the possibility of such a set of gag orders, but it does make such compelled silence much harder to achieve. This also doesn’t rule out other avenues of attack. In particular, could just one or two people within AgileBits sneak in a backdoor? We’ll talk about that below, but note that the inability to gag so many of us means that a backdoor would have to remain unknown to most of us.

Our lack of data collection is verifiable

Your 1Password data is under your control. Out of the box, 1Password creates a local data file (your “vault”) and sync is disabled. We never have the opportunity to see your Master Password or even your encrypted 1Password data. 1Password not only gives you “end-to-end” encryption, but our overall design means that we are never in a position to turn over or intercept your data. We simply never see it in any form whatsoever.

Furthermore, we never see how you use 1Password. We don’t know what sites you log into, we don’t know how many 1Password items you have. Indeed, we don’t even know whether you use 1Password or not. We offer a soon-to-be-incremented number of data synchronization methods, none of which involve us ever having the opportunity to intercept your data. When 1Password 4 for Mac arrives soon, Wi-Fi sync (currently in testing) will allow you to sync locally, meaning your data never has to leave your local network.

You can monitor 1Password network activity for yourself to confirm that your data, even encrypted, is never sent to us. All of this dramatically reduces where a backdoor could be inserted.  Indeed, it eliminates the otherwise easiest to insert and most difficult to detect backdoors. So an entire range of attacks is already off the table.

As always, this doesn’t rule out all kinds of mischief, but it substantially limits the scope and opportunity for an attack.

Our data format is verifiable

We have been very open about providing the details of the encryption and data format that 1Password uses. Anyone can verify that 1Password does produce the files we say it does. They can also examine whether that over all design is strong.

This doesn’t rule out every kind of sabotage that could be done, but it does rule out a broad range of some of the easiest lines of attack. Because this limits where a weakness could be introduced, it’s harder for a deliberate weakness to be introduced that isn’t noticed by others who can access the source code.

As a consequence of this, everyone with access to the source code knows where to look for possible tampering. This makes it harder for a backdoor to be introduced without it being noticed by many of us. As pointed out above, they can’t gag us all.

Lavabit has set a precedent

One company, Lavabit, has shut itself down rather than comply with betraying their customers. This increases the risk of discovery to those trying to compel developers to introduce weaknesses.

It is impossible to predict how we would react in absence of having the full details of such compulsion in front of us; there are just too many unknowns and too many forms of compulsion. But the very real possibility that we would shut ourselves down (which would be public) rather than sabotage what we do and love should act as some deterrent to those who might wish to compel us to introduce a backdoor.

Only communications tools appear to be targeted

From the most recent revelations, the targets appear to be communication tools and protocols. 1Password is not such a tool. This doesn’t mean that the NSA couldn’t change their focus, but from what we know so far, 1Password is not the kind of thing they are after.

Going around crypto instead of through it

Even if you don’t find any of the individual reasons listed above to be persuasive, they interact powerfully. In combination, they make it much harder to get a weakness into 1Password without taking on large risks of getting caught and failing. Any attacker, including the NSA, will avoid high risk, high cost attacks if there are safer and easier alternatives. I’m therefore confident that the NSA would rather go around 1Password than through it.

Crypto Wars II

In the 1990s, there was a series of debates, pressure, civil disobedience, and cryptographic developments that have come to be known as “The Crypto Wars”. At the heart of this was the US and other governments’ efforts to prevent people from having access to cryptographic tools which those governments couldn’t break. In the end, governments (seemingly) surrendered, in large part because the tools they wished to use to enforce those restrictions (export restrictions, the Clipper Chip) just weren’t going to work.

What the 5 September, 2013 revelations show is that the US government has taken a different tack. The Crypto Wars may never have ended. Instead of explicitly and openly trying to limit the power of the cryptographic tools allowed to the public, they are now surreptitiously sabotaging the tools that we all use. As before, this will be fought on the political front—people telling their representatives that they don’t want hobbled security tools—and on the technological front—building better, stronger, more robust and verifiable systems.

Our role in this as a company is to be transparent about our approach to security while keeping your 1Password data protected.

Just in Time Decryption

1Password for iOS icon supersized1Password only decrypts what you need at the time you need it. If Molly (one of my dogs) is using 1Password to log in to SquirrelsAreEvil.net, only her SquirrelsAreEvil Login details are decrypted. Her RabbitRecipies Login, along with all her other hundreds of items, remain encrypted.

I’d like to explain why this is such an important security feature, as well as why it’s vital for Molly’s security tool to lock her 1Password data when she steps away from her computer. Limiting what is decrypted, and for how long, provides some concrete benefits, though it also raises some interesting questions. Read on to see what I mean.

Keeping secrets small

It is easier to keep sixteen bytes of data secret than it is to keep sixteen megabytes of data secret. Quite simply, it is much harder to handle and manage sixteen megabytes of data in a secure way than it is to keep just sixteen bytes secret. This is true for both people and for computer systems. You can manage your 1Password Master Password securely (in your head), but you could not do the same with all of your passwords and logins. After all, that’s why you use 1Password in the first place.

1Password enables you to turn a large secret—all of your various login information for services, secure notes, WiFi passwords, bank account details, credit cards, etc.—into a small one that you can manage—your 1Password Master Password. This is what I mean when I say that encryption allows you to turn big secrets into small ones.

Just as it is hard for a human brain to handle large secrets securely, it can also be difficult for computers. When computers are running short of working memory, they might have to make temporary notes of what is “in their heads” (writing to swap files). If a program crashes, it might write to disk some of what is in its memory (core dumps), and there are various other ways that a computer or computer program can accidentally mishandle secrets.

big-and-small-secrets

There are tools that systems and programmers can use to make it harder to accidentally reveal secrets, but these methods work best for little secrets. So it would be much better for a computer to only have to manage one little secret. Like you, the computer can be good at managing such secrets. Of course, a little secret (one that fits in sixteen or thirty-two bytes of data, for example) can be very very important. Note that, when I talk about “big” or “little” secrets here, I only mean the size of the data.

The way to turn big secrets into little secrets on a computer is to encrypt the big secrets with an encryption key. After that, the encryption key (or the password from which the key is derived) becomes the secret. The encrypted data, because it is encrypted, does not need to be kept secret. With the encrypted data and the key, there is no need to keep the unencrypted secret data around.

Throwing away the key

When you lock 1Password or it locks through auto-locking, 1Password throws away the key (the details are a bit more complicated as there are multiple keys and these are handled slightly differently in different versions and platforms. But let’s stick with this for now). Without the key, the encrypted data cannot be decrypted, nor is there any way to steal the key since it’s been destroyed.

The only way to decrypt data once the key has been destroyed is to make a new key, and making a new key requires your Master Password. Making keys from your Master Password is called “key derivation”. It is a subtle, but crucial, part of the design of any cryptographic system. For those interested, you may read the gory details of key derivation in 1Password 4.

When to throw away the key

When I’m working, I often get up and pace around the room. Too often I pace all the way to the refrigerator and grab a snack. This is not great for my health, but it also means that someone might walk over to my computer and take a look at the passwords I have stored in 1Password. If my computer account is accessible and if 1Password has the key, then an attacker can get at my data.

autolock-1P3-8

If I worked in a crowded office with people coming and going, that would be something I should be concerned about. In such a case, I would go to 1Password > Preferences > Security and set Auto-Lock to lock after only a few minutes of computer inactivity. I would also set these preferences to lock when the screensaver is activated or when the computer goes to sleep. This would mean that I might have to type my Master Password a few more times a day, but it will help immensely with keeping my secrets, well, secrets. Plus, typing my Master Password a few more times each day will help ensure that I never forget it.

Is Auto-Lock helpful?

An argument can be made that even the most aggressive auto-lock settings provide no meaningful security. I think that Auto-Lock is important, but let me first outline the argument against it.

Suppose Molly (one of my dogs) is working at her computer and runs off to chase a rabbit. She has set up auto-lock so that 1Password will be lock quickly. Molly knows that Patty (the other dog) is trying to find out where the bones are buried, a secret Molly keeps in a Secure Note in 1Password. When Molly is off chasing a rabbit, Patty goes up to Molly’s computer and sees that 1Password is locked. Patty cannot find out where the bones are buried.

But Patty came prepared. Patty doesn’t care that 1Password is locked because Patty replaces the copy of 1Password on Molly’s computer with a bogus copy of 1Password. After all, Patty has as much access to Molly’s computer as Molly would have, and that typically involves being able to install software. When Molly returns (without a rabbit) she sees what appears to be 1Password, nice and securely locked. She types in her Master Password, but the imposter version of 1Password sends that Master Password to Patty.

So the question remains, what good does locking 1Password do?

Auto-Lock *is* helpful

Even though it is possible for Patty to defeat Auto-Lock’s security, it is, in practice, much harder for her to do so than to simply read the data she wants when 1Password is unlocked. Even if Patty had a good imposter of 1Password at hand, and even if she could install it quickly and easily, she runs a much higher risk of getting caught because she has made large changes to Molly’s system.

There may also be barriers to installing an imposter 1Password on Molly’s machine (or otherwise changing the security system of the machine). An administrator password may be required for a normal software install. Something like Gatekeeper may detect that new software is running and ask for an administrator password. It is true that all of these can be worked around if Patty has enough time at Molly’s computer, but these all make it ever more difficult in practice for Patty to tamper with Molly’s computer in a way that will work, can be done quickly, and won’t be detected.

Raising the attack bar

We can never (well, … hardly ever) protect a computer against someone who has unsupervised physical access to it. It can be tampered with down to the boot loader. Suppose Molly is using full disk encryption (FDE) with Filevault 2 on the Mac, and she shuts down her computer completely. Patty might disguise herself as a maid (she is evil that way) and when cleaning Molly’s dog house physically replace the boot ROM on Molly’s computer. Patty can then ensure that the next time the machine boots up, it captures a copy of the disk encryption password and also installs whatever changes to the operating system and software that Patty wants.

In principle, there is little we can do practically to defend against such attacks. But it is far harder to execute an evil maid attack than to simply look at someone’s unlocked passwords. By locking 1Password, Molly makes Patty have to work that much harder (and increase her risk of getting caught) than if Molly didn’t lock 1Password.

Requiring a login password from the screensaver further increases the difficulty (and thus reduces the plausibility) of a successful attack. Using Full Disk Encryption raises the attack bar even higher.

These are cases where the good guys actually have the advantage. There are simple and relatively costless things we can do that very substantially raise the cost to the attacker.

Defending against practical attacks

We have to look not only at theoretical attacks, but the practical arsenal of attackers. We build defenses to increase the amount of work an attacker has to do. If the amount of work the an attacker has to do is beyond what that particular attacker can (or is willing to do), then we have successfully defended against that attack.

Auto-Lock features, like 1Password’s, can successfully defend against what might otherwise be common attacks. It may not defend you against a specially trained spy who has lots of time with your computer, but it will defend you against the nosy officemate who takes the opportunity to grab what she or he may when you briefly leave the room. The world has many more nosey officemates than trained spies.

Summary

We keep as little of your 1Password data decrypted as possible, and only for the shortest amount of time, because it is far easier to manage small secrets securely than large secrets. Features like Auto-Lock can’t always defend against everyone who gets access to your computer, but they do make the job of the attacker substantially more difficult. Indeed, it makes the difficulty of an attack prohibitive for the kinds of attackers we most often find for this category of threat.

Understanding Sharing

1Password 4.2 for iOS has been released with a really nifty sharing feature. This allows you to conveniently share items with other people and keep them updated. Before getting into the details, it is important to know that the data is well encrypted within 1Password, but it is not encrypted when it is not in 1Password. In other words: share over secure channels and be sure you can trust your recipients. More on that later.

The overview

share-transparentIn 1Password 4.2 for iOS you can share an item (a Login, a Credit Card, or anything else in 1Password) by tapping on the share icon. You can then share the item by Mail or by Message. The recipient will just have to tap on the link in the message or email to easily import or update the item into their own 1Password keychain. It’s remarkably easy and convenient. It’s great for families, whose members need to share certain Logins and other 1Password items.

Just be sure to share with care. When you send one of these messages, anyone with copy of 1Password can import the item into their own library. So you will need to find a “secure channel” that is sufficiently secure for your needs. More on this, and so many other things, in the somewhat roundabout article below.

Even dogs can learn to share

Login for NewBarkTimes

Patty (one of my dogs) and Molly (the other) have a subscription to the New Bark Times.Patty set up the account and put the Login Password into 1Password. She uses it when she wants to read up on the latest techniques of how to steal the human food without getting caught. Molly – as a member of the same household – is also entitled to read the online edition. She likes to sniff the comics, which are mostly just depictions of dead squirrels. They are funny because the squirrels are dead.

Ways of sharing

So how do Molly and Patty share the Login information for the New Bark Times? I’m going to run through some sharing options, starting with the most cumbersome and finishing with the most convenient.  You can jump ahead to the section on using the new feature in 1Password 4.2 for iOS, but it is easier to understand what is going on and find what works for you if you follow along.

(Pass)word of mouth

Patty can simply tell Molly the password, and Molly can use that information to create an entry into 1Password. Note that Patty telling Molly the password and account details while they are both hiding under the bed constitutes “sharing over a secure channel”. They do so where Mr Talk (my neighbor’s cat) can’t listen in.

The advantage of this method is that it is the most secure. It is easier to arrange a secure channel for whispering something into someone’s ear than for transferring a data file with sensitive information. At least it’s easier for members of the same pack or household.

Any time Patty updates the information, she’ll have to tell Molly, who in turn, will have to edit her data. Likewise if Molly makes changes, Patty will have to manually (“pawually”?) edit her own 1Password data.   Wouldn’t it be nice to avoid all of those manual edits?

1PIF, two PIF

Before they got their paws on 1Password 4.2, Molly and Patty had worked out another way to share the New Bark Times Login. They didn’t like all of the manual editing, so they managed to share the Login by exporting and importing a 1PIF (“1Password Interchange File”) file with that Login. 1PIF files can be imported and exported to and from 1Password on Mac and Windows.

Patty would select the item and  use  File > Export Selected …  >  1Password Interchange File from the menubar. All Molly needs to do is import that 1PIF into her 1Password data, and not worry about manual editing.

1PIF files are not encrypted, so Patty and Molly need to use a secure channel to exchange them if they don’t want Mr Talk getting that data. They might use some file sharing over their local network, and they should remember to securely erase the 1PIF after it is done.

Sharing updates: Unique in all the world

There is another nice features about using 1PIFs this way. Every item created by 1Password has a Universally Unique Identifier (UUID). If Patty and Molly each create their own separate Logins for the New Bark Times, they will have different UUIDs even if their content is identical. But if Patty creates the item and exports it as a 1PIF for Molly to import, they will end up having the same UUID.

Here is where the magic comes in. If you import an item with a UUID of something that already exists in your data, 1Password updates the existing item instead of just creating a new one in your keychain (I’ll save the explanation for how we make sure that the UUIDs really are unique as a birthday present). If Molly modifies the New Bark Times Login, she can export it it for Patty to import, which will update the item in Patty’s keychain.

1Password 4 makes sharing even more convenient

Exporting and importing 1PIFs is fine as far as it goes for 1Password 3 for Mac and 1Password for Windows, but until now, 1Password for iOS didn’t have an import or export mechanism.

1Password 4.2 for iOS gained just such a sharing system, and it is extremely convenient.

Sharing a Login by MessageWhen Patty looks at the Login item in 1Password for iOS, she can tap the Share icon, then select “Message” or “Mail”. After that she should select “Message Login” or “Mail Login”.  These options share the 1Password item in a form that isn’t fit for humans (or dogs) to read. Instead, it uses an obfuscated format that your recipient can easily import into 1Password.

But note again, even though it isn’t designed for humans to read, its contents are still exposed to anyone, including the nefarious Mr Talk, who has access to 1Password. This is another reminder that Patty and Molly need to find a secure channel for sharing 1Password items.

The alternative Mail and Message format, “Mail/Message Clear Text”, puts the Login’s details in a human readable format. And it’s not just Logins that can be mailed or messaged. You can Mail Software Licenses, Message Credit Cards. Almost everything in 1Password can be shared this way; attachments are the only thing that don’t make the trip.

NewBarkTimes-import2When Molly receives the email or the message, all she needs to do is tap on the included link. At right, you can see what this looks like if the Login was sent by Mail.

The import will add a new item if the received item has a UUID that isn’t already in the recipient’s keychain. All Molly needs to do is approve the import of the new Login.NewBarkTimes-import1

Sometime later, Patty may update the item. She might add in a Note to the Login with the answer to a security question (Q: “Favorite pet”, A: “Me”).  Though of course, Patty should know not to give predictable answers to security questions, either.

NewBarkTimes-import3

After Patty has made some changes, she can just send the item to Molly again.

This time, 1Password will see that an item with the same UUID already exists in Molly’s data, so it will prompt Molly to see if she wants to update the item. Molly, of course, can also make changes and send the updated item to Patty.

This makes it really easy for Patty and Molly to share these items between their iOS devices via iMessage, which can provide a sufficiently secure channel for most purposes.

Finding a secure channel

As with 1Password’s other sharing methods (including word of mouth), Patty and Molly need to make sure that they have a secure channel. That is, they need to know that the message is going to the right person (don’t accidentally send it to Mr Talk); they need to know that it is coming from the right person; they need to know that nobody can listen in on the channel; and they need to know that nobody can tamper with the channel.

iMessage probably provides a secure enough channel for most people for most cases, though it may not be sufficient if you are trying to keep secrets from Apple or from law enforcement agencies. Even if you don’t anticipate attacks from those sources, there are a few cautions:

  1. It’s not always clear when a message will be sent by iMessage or via the much less secure SMS. Unfortunately, we haven’t (yet) found a way to make it clear from within 1Password when a message is going out over iMessage or not.
  2. It is often a bit too easy to accidentally send a message to the wrong recipient. So please take care that you really are sending it to the correct address.
  3. After a message or email has been sent and received, you should look at ways to delete the messages. For email, this is particularly difficult to do thoroughly, as most email servers create backups.

Molly and Patty might be willing to use one channel for sending their New Bark Times Login that they wouldn’t be willing to use for sending their First Bank of Canis Major Login. These are choices that only Patty and Molly can make for themselves.

Doing the two-step until the end of time

Enigma machineIn my discussion of Dropbox’s new two-step authentication, I skimped on the cryptography. Because we had to move quickly, I wanted to focus at the time just on our recommendations, so I told a few fibs about how the way the six digit codes “get” to your phone. Now I want to explain how it really works.

Not only that, but I will sneak in a little introduction to Message Authentication Codes (MAC), which plays a major role in our newest version of the 1Password data format. This topic is also worth revisiting because our new release, 1Password4 for iOS, works well with Dropbox’s two-step verification.

Speaking of, let’s start with Dropbox’s two-step authentication system. I did try to warn readers that I was being less than forthcoming about the full truth when I suggested that a six digit code is sent from Dropbox (or Google) to your phone:

There are also some really cool things about how the protocols for two-factor authentication work, but I will bite my tongue and leave that discussion for another day. What this means, however, is that a great deal of what I say in describing the system below is a pack of lies.

Even my word “protocol” could be confusing, as it might imply some network activity. The magic of the system is that anything using this type of Time-based One Time Password (TOPT) tool will compute the same six digit code at a particular time with the initial set-up secret. Dropbox’s login system will calculate the six digit code on its own; and a tool that you use, such as Google Authenticator, will also calculate the six digit code on its own. No network connection is needed after the first time setup.  In my example below, I’ll use Google Authenticator, but it isn’t the only TOPT tool out there.

Initial set up

When you first set up something like the Google Authenticator you scan in a QR code. It might look something like this:Sample QR code for setting up authenticator

The code contains a label that will typically be “Dropbox:your-email@example.com”, and it contains a secret that is randomly generated and unique for each account. The secret might look like “MQZDKZRZGBRWMMZXMI4TCMZUMYYDKYTC”. Putting this inside of a QR code just saves you a lot of typing. If you don’t have a camera that can be used to scan the code, there is even a link for getting the information that you should type in. Scanning this in is the only time that information will be transmitted (in this case, transmitted via your phone’s camera) from Dropbox to Google Authenticator.

Google Authenticator on your phone will keep a copy of the secret, and so will the Dropbox servers. That shared secret allows both Google Authenticator and Dropbox to calculate the same six digit codes when needed.

Counting on time

When you log into Dropbox with your username and password you will then be prompted for the six digit code if you have enabled two-step verification. You will then open Google Authenticator on your phone and you will see six digits. Those six digits are computed from a combination of the the shared secret and the current time. The current time is the number of seconds since the first instant of 1970. It is rounded down to the nearest half minute. This is why the number changes every thirty seconds.

Dropbox website prompting for security codeWhen you enter the six digit code during Dropbox’s login process, Dropbox will perform the same calculation. It has a copy of the secret that was first shared, and it too knows the current time. If what you enter matches what it has calculated, you’re in.

Your phone will not need any network connection as long as its clock is reasonably accurate. Fun fact: your phone actually makes minor adjustments to its clock pretty much every time it connects to any kind of network that allows it to check a time server on the internet. Today, most networked computers and devices know the current time to within less than one 10th of a second.

Because the code depends on both the time and on the shared secret, we end up with a different code during each 30 second period. This makes it a one time password.

Beyond the end of the world (January 19, 2038)

Ancient eunuchs foretold global catastrophe on January 19, 2038, as their long count calendar comes to an end and starts a new cycle from zero

—Anonymous

Aztec sun stone (replica)

Replica of the Aztec sun stone. This has nothing to to with Unix or Mayan time keeping.

The number of seconds since the very beginning of 1970, known as Unix time, is often maintained in a single variable in the computer’s operating system. When Unix was first designed, this number was stored in 32 bit variable. That means that the number could range from 0 to 232. Zero corresponds to the midnight January 1, 1970 (UTC). So what time does 232 correspond to? That will be 3:14:07 (UTC) on January 19, 2038. Bad things will happen then to computers that still are still using 32 bit integers to store Unix time.

So will Google Authenticator stop working in 2038? No, it should be fine. Even though iOS devices – based on 32-bit ARM chips – do just use 32 bit “long” integers, Google Authentication doesn’t rely on that. It uses NSDate to get Unix time on iOS.

Indeed, the actual standard defining the TOPT states:

The implementation of this algorithm MUST support a time value T larger than a 32-bit integer when it is beyond the year 2038.

Another wrinkle in time

Unix Time really is the number of seconds since the very beginning of 1970, but that number ignores leap seconds. Twisted clockLeap seconds are added (or subtracted) on occasion to account for the fact that the speed of the Earth’s rotation can change slightly due to earthquakes, other seismic activity, and even tidal activity (not only do I get to talk about a calendar system reaching its end and resetting, I get to talk about earthquakes and tidal waves in the same post!). A leap second was added at the end of June 2012, so noon (leap second adjusted) on July 1 was actually only 86399 seconds later (by Unix time) than June 30 instead of 86400 seconds later as you would normally get between two days.

The TOPT standard requires the use of Unix time, which is defined to ignore leap seconds. This way, everyone who follows the standard will be using the same clock and calendar. Also, keep in mind that Unix time isn’t just for Unix-based operating system like OS X, iOS, and Android. Windows has a similarly defined FILETIME, which differs in its start time and that it counts in nanoseconds instead of seconds, but it can be converted to Unix time easily enough for use in the TOPT protocol.

Time to meet MAC

Earlier, I said that the code, or one time password, is computed from the secret key and the time, but not just any old computation will do. For the system to work securely, we need the computation to meet some requirements which include:

  1. It must be easy to calculate the code from the key and the time, but it must be completely unfeasible to calculate the key from the code and the time.
  2. It must be unfeasible to predict without knowledge of the key what the code will be at some particular time even if you have observed what the code is at many other times.
  3. The calculation will always give the same result if given the same key and time (it is a function).

These look similar to some of the requirements we wanted for a good cryptographic hash function. And a cryptographic hash function will play a central role in how this is all done.

This also looks as if we are using a shared secret key to create a digital signature on the time. Digital signatures also involve hash functions. But “digital signature” isn’t really the right term here because those are based off of public/private key systems. With TOTP, we have a shared secret.

In place of a digital signature, we have a Message Authentication Code (MAC). This is not to be confused with “MAC” of “MAC address” that you see as hardware addresses for networking equipment, and certainly not to be confused with “Mac” (Apple’s family of computers) or “mac” (the mackintosh raincoat). Maybe this will help keep things clear:

A lowercase mac, for when you need wet wear
And an all-caps MAC is made by software
You’d be just as cool as the great Ry Cooder
If  you never confound these with a Mac computer

One of the ways to use a cryptographic hash to create a MAC is the HMAC. You will hear more about HMAC in the not-so-distant future.

Keeping time, time, time

One consequence of this sort of system is that it makes the computers’ knowledge of the time part of the security system. This isn’t anything new; this requirement has been part of the Kerberos system for decades. Indeed, one of my first roles in system administration was keeping clocks in sync with each other, specifically for Kerberos.

TARDIS

Unfortunately, this means that if someone can tamper with the time signals a computer receives from outside, then they can do damage to other aspects of security. We need systems to verify that the messages they get about the time are authentic, but the less-than-ideal state of secure time synchronization could be the subject for a new series of rant posts. Fortunately, I’ll spare you.

It is also not clear at this point what forms of time travel this or other security protocols can resist. I believe that there is a research paper in this question somewhere for an adventurous student and a flexible professor.

Six digits from 160 bits

Let’s now put all of these pieces together. Dropbox and Google Authenticator each have the shared secret from when you set up your two-step verification. And each know the correct time at the moment. So when each calculate the HMAC of the current time, using the shared secret as a key, they will calculate the same number. If they use SHA-1 for the hash function (as they do in the current system) the number that they calculate will 160 bits long, or roughly 48 digits. The final step is to compute a 6 digit number from that 160 bit number. But let’s save time and skip those final details.

Time for closing remarks

Dropbox’s two-step authentication is a great thing, and 1Password for iOS now works more smoothly with it. But it does the most good for people who are using weak or re-used passwords to log into Dropbox. Thankfully, 1Password users don’t really need to worry about that problem.

Hashing fast and slow: GPUs and 1Password

The net is atwitter with discussion of Jeremi Gosney’s specially crafted machine with 25 GPUs that can test hundreds of billions of passwords per second using hashcat, a password cracking system. Password crackers, like hashcat, look at the cryptographic hashes of user passwords and repeatedly make guesses to try to find a password that works. 1Password has been designed to resist automated password cracking attempts exactly because we anticipated developments like this.

Don’t get freaked out by the numbers

Windows XPFirst and foremost the reports of 348 billion passwords per second is specifically about passwords stored in the LM format used on Windows XP, exploiting the notorious design flaws and limitations LM hashes. (If you are still running Windows XP; and particularly if you are running NT, 2000 or 2003 domain controllers, please, please upgrade.) The hundreds of billions of  passwords per second reached against those hashes does not mean that passwords stored in other formats can be cracked that quickly.

By the way, this isn’t the only important news about password security to come out this year’s excellent Passwords12 conference. I couldn’t quite make it there this year, but I will talk about other developments from it in coming weeks. Today, all eyes are on GPUs guessing billions of passwords per second.

Slow and Fast Hashing

Typically when a password is “stored” on a system that you log into it is not the password itself, but instead it is a cryptographic hash of the password. I’ve written about some of the ways that password  can be hashed before. HashcatThese can roughly be divided into two categories: slow hashes and fast hashes. Slow hashes are specifically designed to slow down the kinds of attacks we are discussing.

Your 1Password Master Password is processed using the slow hashing system known as PBKDF2. 1Password’s use of PBKDF2 and your use of a good Master Password keep your data resistant from password crackers such as John the Ripper and hashcat if you chose a good Master Password.

Defending against future threats

There are several lessons from this. Gosney’s work does reflect real innovation and a breakthrough, but it isn’t an unexpected breakthrough. People who keep an eye on these things – and we do keep an eye on these things – expected something like this within the next couple of years.

We need to design systems that work against plausible future threats, not just against current threats. This is what we have always tried to do with 1Password.

Lessons and actions

  1. Your 1Password Master Password and your 1Password data remain safe, we designed the Agile Keychain format from the beginning to resist crackers like this. But it is also important for people to select strong, memorable, Master Passwords.
  2. It is more important than ever to have unique passwords for each site and service. As password cracking gets easier, the risks of using the same password on multiple sites increases. This is because if password hashes are stolen from one site, attackers have a better chance of discovering the password from the hash. Once they have that, they can try the same password on other sites.
  3. When using 1Password’s Strong Password Generator, try to create passwords that are at least 20 characters long.

Back to the Future

Gosney slow hash chartI’ve talked (well even boasted, I suppose) about how our earlier design decisions are protecting 1Password users today. But we have to look at what design decisions we make today will do for 1Password users half a decade from now.

Gosney’s machine can also be used against slow hashes, including PBKDF2 passwords. You can read more (and see cool pictures) of the design of Grosney’s hashcatting machine in the conference presentation slides (PDF).

Furthermore PBKDF2 was not designed to specifically impair parallel processing. But because GPUs have unusual and restricted ways of addressing memory, it is possible to design systems that make parallel processing using GPUs slower. This leaves a number of questions that we continue to look at.

  1. Do we need to change anything at all in anticipation of even more powerful machines tuned toward PBKDF2? (We don’t yet Password Based Key Derivation Function diagramhave estimates on how many passwords per second this system could try against a 1Password data file.)
  2. If we do need to change things, when do we need those changes need to be in place?
  3. Should we look at more parallel and GPU resistant alternatives to PBKDF2, such as scrypt?
  4. Should we look at tinkering with options within PBKDF2 to make it more resistant to GPUs working in parallel?

These are not new questions. We are always asking ourselves these and other questions in order to keep your 1Password data secure and protected, both now and in the future.

[Updated 2012-12-06 15:50 UTC. Updated to correctly explain that Gosney's system is not limited to LM hashes. Thanks to Jeremi Grosney, Solar Designer, and others who pointed out my error. I have also taken the opportunity to add more clarifications and links to background throughout.]

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.