Introducing Watchtower 2.0: The turret becomes a castle

Introducing the all new Watchtower – it is absolutely gorgeous, and appears to be rather timely!

Twitter asked their 330 million users to change their password yesterday due to a security snafu, putting privacy and security at the forefront of everyone’s mind once again.

1Password includes Watchtower, with its suite of security tools, making it the easiest and most comprehensive way for you to check the security of all your passwords.

Watchtower report

With a click of a button, Watchtower audits your passwords against a wide range of security vulnerabilities giving you an easy to read report with simple steps on how to fix any issues it finds.

Let’s take a look at some of the defences.

On the lookout for breaches

Watchtower will automatically notify you if there’s been a security breach for a website you use. A bright red bar that’s pretty darn hard to miss will display across the top of the item, prompting you to change the password for that site.

Login showing a breach

Please excuse me while I hop away for a sec and go change that Twitter password. 😀

A vanguard for pwned passwords

Watchtower can check your passwords to see if any have been exposed in a breach. Integrating with Troy Hunt’s haveibeenpwned.com service, your passwords are checked against over 500 million exposed passwords, highlighting any that are found.

Watchtower showing vulnerable passwords

To keep your passwords private, Troy found a brilliant way to check if passwords have been leaked without ever sending your password to his service.

Strong, unique passwords are your greatest defence

Using strong, unique passwords for every website is your surest way to keep safe. When a website is breached and your password compromised, that password can be used to sign in to other websites that use the same one. If you’ve reused that password elsewhere, you’re putting all those sites at risk.

Watchtower not only shows you which of your passwords should be stronger, it also alerts you when you’re using the same passwords for more than one website.

Graph of password strengths

Now would be a great time to use Watchtower to see if you reused your Twitter password for your bank account 😱

A second line of defence

Enabling two-factor authentication (2FA) on websites is a great way to keep your accounts there safe. Watchtower will now let you know about websites you have saved in 1Password that support 2FA, but don’t have it enabled.

Alert showing missing 2FA

This gives you the chance to enable 2FA for those sites. When you enable 2FA, make sure to keep the one-time password in 1Password.

Don’t get caught off guard

Watchtower not only looks out for your passwords, but for you as well. It will now warn you if one of your credit cards, driver’s licenses, or passports are expiring soon, making sure you aren’t scrambling to make last-minute arrangements.

Alert showing expiring passport

Here in Canada you can’t travel internationally if your passport expires within 6 months, so this can be a real life saver if you have that long-planned vacation coming up soon.

Try today with your 1Password membership

Watchtower is available today, so it’s time to give it a try now!

Sign in to your 1Password.com account, select a vault, and click Watchtower in the sidebar to create your report. If you don’t have a 1Password membership, start a free 30-day trial to get started.

Oh, and don’t forget to change your Twitter password :)

How strong should your Master Password be? For World Password Day we’d like to know

Just how strong should a 1Password Master Password be? We recommend that Master Passwords be generated using our wordlist generator using passwords that are four words long. This gets you something like “napery turnip speed adept”.

Among other things, this gives you the chance to learn new words. My dictionary has now informed me that “napery” means household linens such as table cloths and napkins. But let me move on from obscure vocabulary to asking about Master Password strength: What we know about Master Password strength, what we would like to know about it, and how can we get expert password crackers to help us learn?

That’s why we are announcing a password cracking challenge to be managed by Bugcrowd with cash money rewards. First prize earns $8192, second prize is half of that, and third prize is half again. The race will beginhas begun at noon Eastern Time on World Password Day, May 3, 2018. For those who want to jump right to the contest details, without reading the rest of this, you can head right over to our Bugcrowd brief or to our description. The challenge hashes/keys are now available.

1st prize: $4096. 2nd: $2048. 3rd: $1024.

What is your Master Password for?

Your Master Password is your defense against someone who manages to steal your encrypted 1Password data from your own machines. Your data on our machines is also protected by your Secret Key, making Master Password guessing futile. Unlike a human usable password, your Secret Key is completely unguessable, and that is what makes what is stored on 1Password.com uncrackable.

Sample Secret Key

But your Secret Key does not protect you if data is stolen from your own devices because your Secret Key is stored on your own devices. Likewise, our Multi-Factor Authentication only defends against attempts to connect to our systems. MFA doesn’t protect you from data acquired from your own machines. So when it comes to keeping 1Password data stored on your own machine from prying eyes, your Master Password is your defense. It needs to be as strong as you can reasonably use and it must be unique.

Consider Molly (a not all that bright dog), who has a Master Password of “RabbitHunter#1”. She also has some very important Login items, such as her PawPal account within 1Password. Now suppose that Mr Talk (the neighbor’s cat) has contrived to steal data off of Molly’s laptop, including her encrypted 1Password data.

Mr Talk will set up automated password guessing software to make many thousands of guesses per second. We can slow that down with PBKDF2, but Mr Talk is doing everything on his own machines and is not connecting to any of our systems. That is why MFA doesn’t do Molly any good in these circumstances. Now if Mr Talk has some expertise in password cracking and is willing to dedicate some computer power to this, he might be able to crack that Master Password within a few hours or maybe it would take a week. However long that is is how much time Molly has to change her PawPal password and other passwords that she keeps in 1Password.

Let’s suppose that Mr Talk got Patty’s data as well. But Patty (a clever dog) used our Strong Password Generator and ended up with a Master Password of “saddle harass mod gunk”. Even if Mr Talk dedicated enormous amounts of computer resources to this, it would take decades or centuries to crack that. So Patty remains safe because she used a strong, randomly generated Master Password.

Again, for Mr Talk to have a whisker of a chance of cracking any of these passwords, he’d need to get data directly from Patty and Molly’s system, which will also provide Mr Talk with their Secret Keys. Mr Talk would not be able to launch such an attack from data acquired from our systems.

Reducing the guesswork by measuring the guessing work

How did I come up with saying “hours to a week” for Molly’s and “decades to centuries” for Patty’s? I did so with a lot of guesswork. But we’d like to improve on that guess work, and the way to do that is to invite (incentivize) expert crackers to try to crack passwords and find out just how much work they have to put into it.

Now if my guess about decades is anywhere on target for the four word password, that is simply too large of a challenge. So we are presenting a number of keys derived from three word passwords from our password generator. We are also posting all the details about how they were generated and the wordlist used.)

We are also simplifying some of the odd details of our key derivation function to focus solely on the 100,000 rounds of PBKDF2-HMAC-SHA256. This will make it easier for participants to get set up without really affecting the result of what we are trying to measure with this exercise.

We want winners

We want people to win the prizes, and we want people going into this to know that we want people to win. Otherwise we wouldn’t get participants to put in the effort that we are trying to measure.

So let me remind everyone again, the challenges that we have created here do not have the protection of the Secret Key and they are using Master Passwords that are at the weaker end of what we recommend. This contest simulates attacking only one single component of 1Password security.

Knowing your system is a good thing

It’s been nearly seven years since we helped revive the notion of wordlist-based passwords with our article Toward Better Master Passwords. And one of the many virtues of generated passwords is that they remain strong even if the attacker knows how they were generated. So with that in mind, we are also publishing the source used to generate the challenges.

How long until we have answers?

If we knew how much effort it takes to crack a three word password, we wouldn’t be giving away money to find out, would we? We also don’t know what kinds of resources people will throw at the problem. If people or teams dedicate fleets of hashing rigs at the problem they will find things more quickly than someone who just uses a couple of more ordinary computers.

Mining rig

Money is time

It may be more useful to ask about the cost of cracking a password versus how much time it takes. In any particular cracking attempt there will be some combination of fixed costs and variable costs ranging from developing the expertise and equipment depreciation to the cost of the electricity used to run and cool the machines. We want to develop an estimate that considers the total cost. So we hope that the challenge takes long enough that the results will show a useful mixture of fixed and variable costs.

We’ve also structured the contest as a race. The first to find a password will earn $8192$12288, while the second place prize is $2048 and the$8192. The third place prize is $1024$6144, And the fourth place prize is $4096.

My own wild guess is that it could take anywhere between $250 and $2000 worth of effort to crack one of these three word passwords from our list, and so we’re offering a first prize that is double the higher end guess. This way it should be worth their time to switch some of their coin mining rigs over to password cracking.

Update: Nearly three months into the contest it is clear that I underestimated the cost. We have increased the prizes twice by now (July 26, 2018), and are still not certain that it is enough. Join us and participants in the forums for discussion of updates in cost estimates and how we may ensure that this challenge is worthwhile to participations.

What now?

If you would like to participate, head over to Bugcrowd for the official rules and to get set up with them if you are not already a Bugcrowd researcher, as all submissions will go through them. Details can also be found in our crackme challenge Github repository.

If you’d like to just follow along at home before and after the starting gun on World Password Day, keep following us on Twitter, Facebook, or your favorite place to do such things. And if you would like to discuss things further, just join us in our discussion forums. We’ve set up a specific discussion in our Lounge for this discussion.

Multi-Factor Authentication in 1Password

The more the merrier, my mother likes to say. And why shouldn’t that apply to authentication factors? You have your Master Password and Secret Key, and they’re combined to be one amazingly strong factor via Secure Remote Password. We’ve added two more to the guest list, and you get to invite whichever you’d like.

Two-Factor Authentication

Two-factor authentication in 1Password is implemented with Time-based One-Time Passwords. Time-based One-Time Passwords is a mouthful, so forgive me for abbreviating it to TOTP from here on out. TOTP is a widely adopted standard and it’s a great way of adding a familiar additional factor to your authentication process.

When setting up two-factor authentication, you’ll be provided with a TOTP secret that you can store in an authenticator app of your choosing. 1Password has been a TOTP authenticator for years now and storing it there is very convenient, but we recommend also storing it in an authenticator app like Authy. Ideally you’d store it in both so you have access to it when needed. When it comes to backups, the more the merrier, just like Mom said! 🙂

Any time you sign in to your account from a new device you’ll be prompted for a one-time password. Use the authenticator app to get the current one time password, punch it in and you’re off to the races.

Turning on two-factor authentication is a breeze. All you need to do is go to My Profile, choose ‘More Actions’ on the action bar on the left, then ‘Turn On Two-Factor Authentication’. From there instructions will have you set up in no time. Just make sure that you keep your TOTP secret safe as it’s going to be required any time you sign in from a new device.

Duo Security

Duo Security is a slightly different approach to protecting accounts and has been available as a beta feature in 1Password for a number of months. The feedback we’ve gotten from it has been unanimously positive, and Duo is now available for anyone using 1Password Teams or 1Password Business. The best part of Duo is that once configured by an administrator it will automatically apply to all members of the team.

When you sign in to 1Password, you’ll be prompted to send a push notification to your mobile device where you can either allow or deny the request to sign in.

Duo + 1Password for Mac

Duo is a great option if you’re looking to enforce the use of an additional factor across a whole team.

Another Layer of Protection

The awesome part about these additional factors during authentication is that they get to stand on the shoulders of Secure Remote Password. The SRP handshake needs to occur and all additional factor requests get the benefits of that secure channel. Without SRP the same attacks that could disclose your password to an attacker eavesdropping on a connection could also disclose your additional authentication factor. SRP protects both your password and the additional factor. This also means that enabling two-factor authentication or Duo does not mean that you can have a weaker Master Password. They protect against very different things, and your Master Password is ultimately what’s protecting your data.

Supported Across All 1Password Apps

We’ve rolled out support for both Duo and TOTP in all of our apps. Windows, Mac, iOS, Android, Web, and Chrome. We’ve even added both to our 1Password CLI tool, and it’s pretty amazing to have a terminal emulator trigger a push notification to my iPhone. Just make sure that you’re using the latest versions of our apps and you’ll be set.

 

Finding Pwned Passwords with 1Password

Yesterday, Troy Hunt launched Pwned Passwords, a new service that allows you to check if your passwords have been leaked on the Internet. His database now has more than 500 million passwords collected from various breaches. Checking your own passwords against this list is immensely valuable.

We loved Troy’s new service so much that we couldn’t help but create a proof of concept that integrates it with 1Password. Here’s how it looks:

What’s even more fun than watching this video is giving it a try yourself. 🙂

Checking your passwords

This proof of concept was so awesome that we wanted to share it with you right away. It’s available today to everyone with a 1Password membership. To check your passwords:

  1. Sign in to your account on 1Password.com.
  2. Click Open Vault to view the items in a vault, then click an item to see its details.
  3. Enter the magic keyboard sequence Shift-Control-Option-C (or Shift+Ctrl+Alt+C on Windows) to unlock the proof of concept.
  4. Click the Check Password button that appears next to your password.

Check if your password has been pwned

Clicking the Check Password button will call out to Troy’s service and let you know if your password exists in his database. If your password is found, it doesn’t necessarily mean that your account was breached. Someone else could have been using the same password. Either way, we recommend you change your password.

In future releases we’ll be adding this to Watchtower within the 1Password apps, so you can see your pwned passwords right in the 1Password app you use every day.

As cool as this new feature is, we would never add it to 1Password unless it was private and secure.

Keep your passwords private and secure

Personally, I’ve always been afraid of using a service that requires me to send my password to be checked. Once my password has been sent, it’s known, and I can’t use it anymore. It’s the same reason why “correct horse battery staple” was a strong password until this comic came out. 🙂

Thankfully, Troy Hunt and his friends from Cloudflare found a brilliant way to check if my password is leaked without ever needing to send my password to their service. Their server never receives enough information to reconstruct my password.

I’m really happy they managed to find a way to make this possible because it allowed us to integrate this feature with 1Password.

Hopefully you’re as intrigued about how this works as much as I am. It’s what got me the most excited when I saw Troy’s announcement!

How it works

Before I dive into the explanation, I want to reiterate that Troy’s new service allows us to check your passwords while keeping them safe and secure. They’re never sent to us or his service.

First, 1Password hashes your password using SHA-1. But sending that full SHA-1 hash to the server would provide too much information and could allow someone to reconstruct your original password. Instead, Troy’s new service only requires the first five characters of the 40-character hash.

To complete the process, the server sends back a list of leaked password hashes that start with those same five characters. 1Password then compares this list locally to see if it contains the full hash of your password. If there is a match then we know this password is known and should be changed.

Troy has a detailed writeup of how this works under the hood in his Pwned Password v2 announcement post. Check out the “Cloudflare, Privacy and k-Anonymity” section if you find this as fascinating as I do.

Take some time to play with our proof of concept. Generate some new passwords to replace your pwned ones, and let me know what you think in the comments. 😎

A thank you to Troy Hunt

Troy Hunt is a respected member of the security community. He’s most well known for his Have I been pwned? service.

Troy invests a lot of his personal time collecting data from every website breach he can find, adding every leaked password to his database. The Internet is a safer place thanks to Troy Hunt.

Edited: I’m thrilled to see Troy likes what we’ve done with this. 🙂

Developers: How we use SRP, and you can too

Donkey: Oh, you both have layers. Oh. You know, not everybody likes onions. Cake! Everybody loves cake! Cakes have layers!
Shrek: I don’t care what everyone likes! Ogres are not like cakes.
Donkey: You know what else everybody likes? Parfaits! Have you ever met a person, you say, “Let’s get some parfait,” they say, “Hell no, I don’t like no parfait”? Parfaits are delicious!

1Password uses a multi-layered approach to protect your data in your account, and Secure Remote Password (SRP) is one of those very important layers. Today we’re announcing that our Go implementation of SRP is available as an open source project. But first, I’d like to show you the benefits SRP brings as an ingredient in the 1Password security parfait.

Parfaits: delicious and secure

The first layer of security in 1Password, your Master Password, protects your data end to end – at rest and in transit – but we wanted to go further. The second layer is something we call Two-Secret Key Derivation. It combines your Secret Key with your Master Password to greatly improve the strength of the encryption. Thanks to your Secret Key, even if someone got your data from our servers, it would be infeasible to guess your Master Password.

That still wasn’t enough for us, though. When we first started planning how we were going to securely authenticate between 1Password clients and server, we had a wish list. We wanted to ensure that:

  • your Master Password is never transmitted or stored on the server.
  • eavesdroppers can’t learn anything useful.
  • the identity of user and server are mutually authenticated.
  • the authentication is encryption-based.

There was actually one other requirement that wasn’t exactly part of the list but applied to every item in the list: we didn’t want to roll our own solution. We know better than to roll our own crypto, and we wanted to find a proven solution that’s been around and has stood the test of time.

We wanted this layer to be just right.

SRP: a hell of a layer

It took us a while to find what we needed for this layer. (Apparently the marketing department of augmented password-authenticated key agreement protocols is underfunded.) But we eventually found SRP, which ticked all our boxes. SRP is a handshake protocol that makes multiple requests and responses between the client and the server. Now, that may not sound very interesting – and I’m not one to show excitement easily – but SRP is a hell of a layer. With SRP we can:

  • authenticate without ever sending a password over the network.
  • authenticate without the risk of anyone learning any of your secrets – even if they intercept your communication.
  • authenticate both the identity of the client and the server to guarantee that a client isn’t communicating with an impostor server.
  • authenticate with more than just a binary “yes” or “no”. You actually end up with an encryption key.

All this makes SRP a great fit for 1Password, and it keeps your data safe in transit. As an added bonus, because SRP is encryption-based, we end up with a session encryption key we can use for transport security (the fourth layer) instead of relying on just Transport Layer Security (TLS).

So that’s four layers of protection for your 1Password account: Master Password, Secret Key, SRP, and TLS. Now I’d love to show you how SRP works step by step in 1Password.

How 1Password uses SRP

Before any authentication can be done, the account needs to be enrolled. 1Password does this when you create an account. To use SRP, you’ll need a couple different things:

  • a key derivation function (KDF) that will transform a password (and, in our case, also your Secret Key) into a very large number. We’ve chosen PBKDF2.
  • an SRP group consisting of two numbers: one very large prime and one generator. There are seven different groups; we’ve chosen the 4096-bit group.

Enrollment

To enroll, the client sends some important information to the server, and the server saves it:

  1. The client generates a random salt and Secret Key.
  2. The client asks the user for a Master Password.
  3. The client passes those three values to the KDF to derive x.
  4. The client uses x and the SRP group to calculate what’s called a verifier.
  5. The client sends the verifier, salt, and SRP group to the server.
  6. The server saves the verifier and never transmits it back to the client.

Now the account is ready for all future authentication sessions.

Authentication

To authenticate, the client and server exchange non-secret information. Then the client combines that with a secret that only it knows and the server combines it with a secret only it knows:

  1. The client requests the salt and the SRP group from the server.
  2. The client asks the user for the Master Password and Secret Key.
  3. The client passes those three values (minus the SRP group) to the KDF to derive x.
  4. The client:
    1. Generates a random secret number a.
    2. Uses the SRP group to calculate a non-secret counterpart A.
    3. Sends A to the server.
  5. The server:
    1. Generates a random secret b.
    2. Uses the SRP group to calculate a non-secret counterpart B.
    3. Sends B to the client.

So A and B are exchanged, but a and b remain secrets. Through the power of math, the client (with x, a, B) and the server (with the verifier, A, b) can both arrive at the same very large number using different calculations. This is the number that 1Password uses as a session encryption key.

Verification

The last step is verification. After all, no amount of fancy math will help if the numbers don’t match up between client and server.

To verify, the client and server exchange encrypted messages:

  1. The client encrypts a message with the session encryption key and sends it to the server.
  2. The server decrypts the message and verifies it.
  3. The server encrypts its own message with the same session encryption key and sends it to the client.
  4. The client decrypts the message and verifies it.

If the client and server both used the correct inputs then they’ll both have the same session encryption key, which allows them to decrypt and verify the message. If they don’t use the correct inputs, everything fails.

The verification process proves to the server that the client has x, which can only be derived using the correct Master Password and Secret Key. It also proves to the client that the server has the verifier, which ensures that the client is communicating with the 1Password server, not an impostor.

Now that it has been verified, the session encryption key can be used to encrypt every message between the client and server going forward.

As you can see, it’s critical to remember your Master Password and keep your Secret Key safe if you ever want to authenticate your 1Password account. They’re also very important layers, after all. 🙂 And, like any good parfait, everything comes together to create something better than the individual layers alone.

Implement SRP in your own app

We love SRP so much that we want to see it used in more of the apps we use. That’s why we want to help you get started with SRP in your own project. Our Go implementation of SRP is available as an open source project:

This package provides functions for both clients and servers, and you only need to BYOKDF (Bring Your Own Key Derivation Function, like any good party). It’s the same code we’re using on our server and in the 1Password command-line tool, so we welcome security researchers to take a look and report any issues through the 1Password Bugcrowd bug bounty program.

SRP is one of the less appreciated parts of 1Password, and I hope I’ve explained it well enough for you to implement it in your own project. You can read more about how we use SRP in the 1Password Security Design White Paper. Leave a comment if you have any questions, or file an issue if you see something that can be improved.

Until next time, enjoy that parfait!

Same as it ever was: There’s no reason to melt down

The Intel CPU flaw, that is being referred to as “meltdown”, is a big deal. It allows for a whole (new) category of malware to do things that it otherwise shouldn’t be able to do. This is not a good thing, and it remains a threat until operating systems are updated to no longer rely on some specific security features of the CPUs.

But just because it is an extraordinary bug doesn’t mean that it requires an extraordinary response from most people. (Operating system designers are not “most people.”) The same practices that you should already be doing are enough.

What you can do is what you may already be doing

Stay updated, be careful where you get your software

Malware that exploits meltdown may be particularly powerful, but it is still just malware. And so the practices that we’ve always recommended are the practices that will protect you now.

  1. Keep your system and software up to date
  2. Be careful about where you get your software.

Regarding point 1, it appears that the latest version of High Sierra already has defenses to guard against meltdown. If you are using macOS be sure that you are up to date. It also appears that Microsoft is in the process of releasing a security update for Windows.

For the second point, I recommend downloading software from app stores, such as the Mac App Store and the Microsoft Store. They can’t guarantee that no malware slips through, but they provide the easiest and most effective filter available.

Whatever you do, don’t respond to “scareware”. Scareware is typically sold through something that pops up fake alerts about your system being infected or compromised. These scary (and fraudulent) alerts then try to entice you into installing and running tools that will “clean” or “repair” your system. Unfortunately those tools do the exact opposite of what they claim to do.

Panicked people make poor security choices. And so this is why I am worried that fear about this issue might lead people to become more susceptible to scareware. Take a deep breath, don’t panic, and be calmly suspicious of scary alerts.

What we can do is what we have already been doing

1Password is designed so that even if an attacker can read every bit of data on our systems they cannot learn your secrets. We simply don’t have the capacity to decrypt your data, and that holds of anyone who compromises our systems. This has been essential to 1Password’s design from the very beginning, and it is why we don’t have to panic either.

Furthermore, it appears that AWS (our hosting provider) has already begun patching the servers. Keeping up with updates is one of the things we hire them to do.
1Password Encryption

Same as it ever was

I don’t want to downplay the extraordinariness of this bug. It is fascinating in many ways, and it does have broad impacts. But unless your job is to design and maintain operating systems, you should just follow normal practices of keeping your system up to date and not installing dodgy software.

There is a great deal of speculation and news coming thick and fast and it may well be that some of the details of what I have said here will need correction. But the core message should remain the same. Keep your systems and software up to date, and don’t install software from untrusted sources.

1Password keeps you safe by keeping you in the loop

This is a story with many beginnings and many threads coming together. The very short read of it is that 1Password’s browser extension has always been designed from the outset to keep you safe from some recently discovered browser based attacks on some password managers.

Researchers at Princeton University’s Web Transparency and Accountability Project were investigating tracking scripts on web pages, and discovered that several of them attack browser-based password managers and extract the email addresses, usernames and sites stored in the browser’s password manager. As I said, 1Password is designed in such a way as to not be vulnerable to the kinds of attacks those scripts used. The scripts that attempt this are from Adthink (audience insights) and OnAudience (behavioralengine).

Whether or not they make malicious use of the passwords they extract, they are certainly learning which sites you have records for in those password managers. I would like to add that we’ve designed 1Password so that we cannot know which sites and services you have logins for.

There is a huge amount to say about the contemptible behavior of these trackers, and I’m hopeful that others will say so clearly. Here, I want to talk more about what all of this illustrates about 1Password’s design and our approach to security.

Saying “no” to automatic autofill

A commonly requested feature is an option that that would have 1Password automatically fill in web forms as soon as you navigate to those pages in your browser. 1Password, instead, always requires that you take some action. Perhaps it is just hitting ⌘-\ or Ctrl-\ or using our Go and Fill mechanism or even setting up a 1Click Bookmark. But whatever of several mechanisms 1Password makes available, you have to tell it that you want it to fill material on the page.

Plenty of you have written in over the years, saying that they would like 1Password to fill in web forms as soon as they get to a page, with no human intervention. We’ve even been told that it is a very popular feature of some other password managers.

It’s not a lot of fun saying “no” to feature requests. But that is what we have done for as long as I can remember. And for the rest of this article, I’m going to draw from something I wrote in our forums back in 2014.

Because of security concerns we are disinclined at this time to offer, even as an option, the feature you (and so many others) are asking for. […] but I do want to give you an overview of our reasoning for what might seem like an odd choice.

Automatically filling a web form with no user intervention other than visiting the page can, if combined with something that works around the anti-phishing mechanism [of 1Password], lead to an attack where lots your usernames and passwords are submitted to a malicious site in a way that is silent and invisible to you.

The longer answer

I will use the terminology adopted by David Silver and co-authors in Password Managers: Attacks and Defenses at the USENIX security conference (2014). In the terminology of that paper, this requested feature is “automatic auto-fill” instead of what 1Password does with “manual auto-fill”. That is, 1Password requires some user intervention before it will fill a form (such as you typing Ctrl-\), instead of simply filling when you visit a page.

Although I am citing material from 2014, this kind of attack had been discussed since at least 2006, noting that

It’s really not phishing, as it doesn’t actually require the user to believe anything, as the social engineering portion of the attack is not there. As such you can steal user information through any page, as long as the automatic form submission requires no user input to fill the form.

This isn’t new.

Why am I now going to talk about phishing?

One of the great security benefits of 1Password is that it helps you avoid phishing attacks. When you ask 1Password to fill information into a page, it will not fill into pages that don’t match the URL of the item.

1Password has a number of mechanisms to prevent filling into the wrong page. That is, if you go to a form at paypal.evil.com 1Password will not fill in a password saved for paypal.com because the domains don’t match correctly. Tricking a person into filling out something like their PayPal password to something that only masquerades as PayPal is called “phishing”. The idea is that it should be harder to trick a password manager than a person. And it usually is. This is one of the many ways in which 1Password keeps you safe.

For the kinds of attacks we’ve been talking about, the malicious web page content needs to trick or by-pass the password manager’s anti-phishing mechanism. If a malicious script on MyKittyPictures.example.com is going to try to grab PayPal credentials, then it is going to have to fool the password manager into thinking that it is filling in a place that matches paypal.com.

We work very hard to make 1Password do the right thing in such cases. 1Password’s anti-phishing mechanisms work very well at preventing it from filling into the “wrong” web forms. But because of the nature of the HTML, iFrames, protocols, javascript, iFrames, conventions, page designs, and iFrames, the defenses that we (and everyone) have to use are messy and involve a series of rules and exceptions and exceptions to those exceptions. (Did I mention that iFrames are a trouble spot?) It is exactly the kind of thing that we know can go wrong.

So the question we’ve had to ask ourselves is if the anti-phishing mechanisms are strong enough to mean that we never ever have to worry about 1Password in data to the wrong place. We needed to decide whether the tools available for that defense are strong enough to allow us to build a mechanism that meets our standards. Unfortunately they don’t, and so we insist on another line of defense.

Invisible forms

The fields in which usernames, passwords, credit card numbers, and so on get filled won’t always be visible to you. Any page could have a form on it that you don’t see. If the designer of the form is attempting to trick a form filling mechanism, there is no way that 1Password could actually check to see if the fields really are visible.

So if the anti-phishing mechanism can be tricked, then when you visit a malicious web page (including those that have malicious tracking scripts on them) you could have your private information silently and invisibly stolen if automatic auto-fill were in place.

Sweep attacks

The malicious form could be designed to reload itself spoofing a different password each time. So that is, a single malicious injection point could trick your automatically auto-filling password manager into giving up your passwords for many different sites. David Silver referred to these as “sweep attacks”, and that is what it appears that these advert trackers are doing.

At this point, I have not fully studied their scripts to know the precise mechanisms they used, but it certainly is some form of sweep attack.

Doing good and doing no harm

Here is where I go off on a bit of a philosophical abstraction. As I’ve said, I don’t believe that a password manager can offer 100% absolute protection against phishing. But suppose there is one attack out of a million in which it fails to protect against phishing. If you use 1Password, you are much safer against the other 999,999 attempts and you are no worse off than you would be without it. Even in that one in a million case, using 1Password doesn’t add to your risk.

But now contrast that with a situation with a password manager that does allow automatic autofill. A password manager that can be subject to a sweep attack enables a kind of attack that wouldn’t be possible without the use of a password manager.


If you are using a password manager that allows for automatic autofill, turn that feature off. If you are using a password manager that doesn’t allow you to turn that feature off, switch password managers. And when you consider making such a switch, please remember that we’ve never allowed automatic autofill at any time in our more than 10 year history. We believe that you have to be in the loop when it comes to giving your secrets to anyone else. That design philosophy helps keep you safe and in control.

It ain’t over till it’s over

I’m sure that there will be more news to come over the next few days or weeks about the extent of these malicious trackers and precisely which password managers were affected. So please follow in comments for more information.

Why is this information sensitive? The deeper Equifax problem

As the world now knows Equifax, the credit rating company and master of our fates, suffered a data breach in May and June 2017, which revealed to criminals details of 143 million people. (I would have liked to say, “143 million customers“, but that is very far from the case. We have no control at all over Equifax and other credit rating companies collecting information about us. We are neither their customers nor users.)

The revealed data includes:

  • Social Security numbers
  • Dates of birth
  • Addresses
  • Driver’s license numbers (unspecified number of these)
  • Credit card numbers (209,000 of these)

There are many important things to ask about this incident, but what I am focusing on today is why has non-secret information become sensitive? None of those numbers were designed to be used as secrets (including social security numbers and credit card numbers), yet we live in a world in which we have to keep these secret. What is going on here?

Identity crisis

Names only provide a first pass at identifying individuals in some list or database. There are a lot of Jeffrey Goldbergs out there. (For example, I am not the journalist and now editor-in-chief at the Atlantic. But there are lots of others that I also am not.) Also people change their names. Some people change their name when they get married. (My wife, Lívia Markóczy, decided to keep her name because we figure it is easier to spell than “Goldberg”.) Others change their names for other reasons.

We have three “Jeffreys” at AgileBits, but fortunately we have distinct family names. Though sometimes I think that everyone who joins the company should just go by “Jeffrey” to avoid confusion.

Anyway, names alone are not enough to figure out who we are talking about once we get beyond a small group of people. So we use other things. Social security numbers worked well in the US for some time. They didn’t change over your lifetime (except in rare circumstances) and nearly everyone had one. Dates of birth also don’t change. So a combination of a name, a date of birth, and a social security number was a good way to create an identifier for nearly every individual in the US, with the understanding that a name might change.

Sometimes it is not a person that we need to uniquely and reliably identify. Sometimes it is something like a bank account or charge account. Cheques (remember writing those?) have the account number printed on them. They uniquely identify the particular account within a bank, and a routing number (in the US) identifies the bank. The routing number is also printed on each cheque.

Things like social security numbers and driver’s license numbers are designed as “identifiers” of people. They are ways to know which Jeffrey Goldberg is which. Occasionally getting email meant for the journalist is no big problem, but if he gets himself on the no-fly list, I want to be sure that I don’t get caught up in that net. Likewise, I don’t want my doctor or pharmacist mixing me up with some other Jeffrey Goldberg who isn’t allergic to the same stuff that I am. Nor does some other Jeffrey Goldberg want the record of speeding tickets I seem to acquire.

Things like bank or charge account numbers are used to uniquely and reliably identify the particular account. While I wouldn’t mind if my credit card charges were charged against someone else’s account, they would certainly mind, and so would the the relevant bank. (I’m going to just start using the word “bank” broadly to include credit card issuers, automobile loan issuers, and the like.)

A username on some system is also an identifier. It identifies to the service which particular user or account is being talked about. I am jpgoldberg on our discussion forums. That username is how the system knows what permissions I have and how to verify my password.

Identifiers are bad secrets

Something that is designed and used as an identifier is hard to keep secret. A service can hash a password, but it needs to know which account is being talked about before it can look up any information. In many database systems, identifiers are used as record locators. These need to be efficiently searchable for lookup.

Identifiers also need to be communicated before secret stuff can happen. Bank account numbers are printed on cheques for a reason. Now really clever cryptographic protocols – like the one behind Zero Cash – can allow for transactions which don’t reveal the account identifier of the parties, but for almost everything else, account identifiers are not secret.

Identifiers are hard to change. If you depend on the secrecy of some identifier for your security, then you are stuck with a problem when those secrets do get compromised. It is a pain to get a new credit card number, and it is far worse trying to get a new social security number. Getting a new date of birth might also be a teeny tiny problem.
The point here is that, given what identifiers are designed to do, they aren’t designed to be kept secret.

Authenticators

Authentication is the process of proving some identity. And this almost always involves proving that you have access to a secret that only you should have access to. When I use 1Password to fill in my username (jpgoldberg) and password to our discussion forums, I am proving to the system that I have access to the secret (the password) associated with that particular account.

The password is designed to be kept secret. The server running the discussion forum doesn’t need to search to find the password (unlike searching to do a lookup from my username), so it can get away with storing a salted hash of the password. Also, I can change the password without losing all of the stuff that lives under my account. (Changing my username would require more work.) Plus, my username is used to identify me to other people using the system, and so is made very public. My password, on the other hand, is not.

What banks did wrong

The mess we are in today is because financial institutions have been using knowledge of identifiers as authentication secrets. The fact that someone can defraud a credit card issuer by knowing my credit card number (an account number) and my name and address (matters of public record) is all because at one point, credit card issuers decided that knowledge of the credit card number (a non-secret account number) was good way to authenticate.

I have not researched the history in detail, but I believe that this started with credit card numbers when telephone shopping first became a thing (early 1970s, I believe). Prior to then, credit cards were always used when the account holder was physically present and could show the merchant an ID with a signature. The credit card number was used solely as designed up until that point: as a record locator.

The same thing is true of social security numbers. Social security numbers were not secret until banks started to use knowledge of them as authentication proofs when they introduced telephone banking. Before then, there was nothing secret about them.

And on it goes

Because high-value systems use knowledge of identifiers as authentication proofs we are in deep doo-doo. And it will take a long time to dig ourselves out. But we continue to dig ourselves deeper.

It is fine to be asked for non-secret identifying information to help someone or something figure out who they are talking about. I like it when my doctor asks for my date of birth to make sure that they are looking at and updating the right records. But when they won’t reveal certain information to me unless I give them my date of birth, then we have a problem. That is when they start using knowledge of an identifier as an authentication secret.

Over the past decade or so, various institutions have been told that they can’t hold on to social security numbers, and so can’t use them for identifiers. That is a pity, because those are the best identifiers we have in the US. But what is worse is that knowledge of the new identifiers is being used for authentication.

Right now, Baskin-Robbins knows my date of birth (so they can offer me some free ice-cream on my birthday). In ten years, will I have to keep my birth date a closely guarded secret so that I don’t become a victim of some financial or medical records crime? If we keep on making this mistake – using identifiers as authentication secrets – that is where we are headed.

Incentives matter more than technology

I do not want to dismiss the technological hurdles in fixing this problem, but I believe that there is a bigger (and harder) problem that will need to be fixed first: the incentives are in the wrong place.

When Fraudster Freddy gets a loan from Bank Bertha using the identity of Victim Victor, Bertha is (correctly) responsible for the direct financial loss. The problem is that there are costs beyond the immediate fraudulent loan that are borne by Victor. But Victor has no capacity or opportunity to prevent himself from being a victim. In economics jargon, Victor suffers a negative externality.

Bertha factors in the risk of the direct cost to her of issuing a loan to a fraudster. She looks at that risk when deciding how thoroughly to check that Freddy is who he says he is. Bertha could insist that new customers submit notarized documents, but if she insists on that and her competitors don’t, then she would lose business to those competitors.

But Bertha does not factor in the indirect costs to Victor. She has no dealings with Victor. Victor isn’t a potential customer. So if Victor has costly damage to his credit and reputation that requires a lot of effort to sort out, that is not Bertha’s problem (and it certainly isn’t Freddy’s problem.)

Only when Freddy and Bertha (the parties to the original deal) have to pay the cost of the damage done to Victor (Economics jargon: “internalizing the externalities”) will Bertha have the incentives to improve authentication. I don’t have an answer to how we get there from here, but that is the direction we need to head. In the meantime, if you find yourself a victim (whether you’re a Victor, a Jeffrey, or something else entirely), Kate published a post earlier this week with tips to protect yourself until we (hopefully) do get all of this figured out one day.

Net neutrality: Keeping the Internet safe and accessible for all

Lo, everyone! Back on October 29, 1969, that two-letter greeting was the first message sent over ARPANET, the predecessor to the World Wide Web. Today, on July 12, 2017, people from around the globe are coming together for a day of action to fight for net neutrality. The principle of net neutrality states that all Internet traffic should be treated equally, but those who control the transmission of that data have been fighting for the right to place their preferred data in the fast lane and leave data they don’t like in a traffic jam. We here at AgileBits care quite a lot about data, and while we’re glad your sensitive data is safely locked away, we think the data we want to share on the Internet should remain accessible to everyone. Read more

Be your own key master with 1Password

Encryption is great. By magic (well, by math) it converts data from a useful form to complete gibberish that can only be turned back into useful data with secret number called a key.

I happen to think that the term “key” that we use for encryption and decryption keys is a poor metaphor, as it suggests unlocking a door or a box. Cryptographic keys are more like special magic wands that are essential to the process of transforming data from its useful (decrypted) form to gibberish and back again. Read more