1Password for Slackers

As I sit here, I can see at a glance that a Pull Request was just merged to master, our unit tests ran successfully, Tim shut down the staging bastion, and Will’s daughter turned 2 today with a rather delicious looking cake.

What ties all these seemingly random topics together? Why Slack of course (you know, the company with the cool socks).

Channeling your inner Slack

At AgileBits we use Slack for almost all communication. We have dedicated channels for each team, company channels for announcements and even a water-cooler channel for the hot topic of the day.

In addition to team communication we also use Slack as an alert mechanism. We receive alerts when code is merged, builds are deployed, unit tests fail, thresholds are exceeded or errors occur. I find that having a single place to see or be notified by these alerts is indispensable. There is simply no way I’d survive having to switch to each and every tool to see what needs my attention.

There was, however one critical service that was obvious by its omission, and that was 1Password. Happily that is no longer the case :)

Introducing Slack for 1Password

When I set about adding Slack integration to 1Password (yep I still get to code) the challenge was deciding what to send to Slack. As always, our customers helped with great advice and I decided that there were two types of activities to send – alerts and notifications.

An alert is sent to Slack for an activity that requires your action. Confirming a new team member or account recovery are two examples. Simply click the link in the alert and you’ll be brought right to where you need to be to complete that activity.

A notification is an important 1Password event that you may want to review. For example a team member adding a new device to their account, enabling or disabling Travel Mode, or even signing in to their account. This allows you to review this activity and keep an eye out for unexpected behaviour.

You can choose which alerts or notifications to send to Slack and which channels those are sent to.

Keep on Slacking


Slack integrations are available for all Teams on the Pro plan. If you are not already on 1Password Teams there has never been a better time, so sign up today for a free trial :)

I am very excited by the new 1Password Slack integrations and hope you are too. I’d love to hear what other alerts or notifications you’d like to see sent to Slack. Let me know below in the comments!

Introducing 1Password 6.6 for Windows

We’ve been hard at work on a major update for 1Password 6 for Windows and I’m so excited to finally share it with all of you.  1Password 6.6 for Windows is here and it is HUGE.  I can’t possibly discuss every new feature here – there are 24 brand new features and 89 total changes made – but I’ll highlight a few that I’m most excited about. 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

Google I/O 2017: Fun, Sun, Autofill!

Unlike Jupiter’s Io, which completes its orbit every 2 days, Google I/O only comes around once a year. Thousands of people register, and a select number are chosen at random. This year, Michael, Saad, and I were lucky enough to get tickets (hmm…maybe I should play the lottery)!

While Michael has attended I/O in the past, this was a first for Saad and me. We went in not quite knowing what to expect, which only added to the excitement for us.

At AgileBits, we primarily work remotely, so we don’t often get the chance to see each other face to face and just talk. Sure, we can chat on Slack, but it’s also nice to be able to talk in person and riff off of each other.

So meeting up with Saad and Michael for Google I/O led to some of the most informative and productive conversation I’ve had lately. I handle customer support, while they mainly handle development, so we can often have different perspectives on issues and priorities. We hash things out over phone calls and chat regularly, but it’s nothing like putting our heads together and talking til the wee hours, face to face.

Of course the best part about Google I/O, the reason thousands make the trek to Silicon Valley every year, is seeing all the talks and all the new things! I’d watched some I/O keynote and session videos in the past, but nothing quite captures the energy of seeing it live.

Suffice it to say we were super excited for the Google Keynote and the Developer Keynote. There were some fun announcements that got us chatting about the opportunities opened up by all of this great technology. And speaking of opportunities, Google had a chance to tell us which sweet Android O will be named after (Oreo?), but instead they teased us with “Oh no, we’re out of time!” I guess we’ll find out soon enough. 😉

We saw lots of talks on Android architecture, and an interesting one on Kotlin. They were super informative. I was really excited to see all the VR/AR advancements, and we got to play around with them a bit during demos.

The best talk for us was the talk on Autofill in Android O. We’ve got a bit of a special interest in that topic, and we were thrilled to be featured in their presentation. I think the three of us were a little too giddy about seeing our name up there.

On Thursday night, after the presentations and other activities had wrapped up for the day, LCD Soundsystem put on a show in the Shoreline Amphitheatre. This being my first I/O, I had no idea there was going to be a show. It was quite a nice surprise! They handed out glitter makeup pens on the way in, so the three of us got dolled up and headed in to see the band.

At one point, James Murphy, the band’s frontman, said, “This one’s for the lovers,” which was greeted with absolute silence. I cracked up at the thought of all of us in the audience–tech industry geeks who were mostly there with coworkers. He followed that with, “This one’s for all the lonely people?” That one got the applause he was looking for.

 

All in all, it was a great week. I’m so glad I got to experience Google I/O for the first time. It’s always a blast when we get the band back together, and it was absolutely worthwhile to fantasize about the future of the platform and what it means for 1Password.

Introducing Travel Mode: Protect your data when crossing borders

We often get inspired to create new features based on feedback from our customers. Earlier this month, our friends at Basecamp made their Employee Handbook public. We were impressed to see they had a whole section about using 1Password, which included instructions for keeping work information off their devices when travelling internationally.

We knew right away that we wanted to make it easier for everyone to follow this great advice. So we hunkered down and built Travel Mode.

Travel Mode is a new feature we’re making available to everyone with a 1Password membership. It protects your 1Password data from unwarranted searches when you travel. When you turn on Travel Mode, every vault will be removed from your devices except for the ones marked “safe for travel.” All it takes is a single click to travel with confidence.

It’s important for me that my personal data be as secure and private as possible. I have data on my devices that’s ultimately a lot more sensitive than my personal data though. As one of the developers here at AgileBits I’m trusted with access to certain keys and services that we simply can’t take any risks with.

How it works

Let’s say I had an upcoming trip for a technology conference in San Jose. I hear the apples are especially delicious over there this time of year. :) Before Travel Mode, I would have had to sign out of all my 1Password accounts on all my devices. If I needed certain passwords with me, I had to create a temporary travel account. It was a lot of work and not worth it for most people.

Now all I have to do is make sure any of the items I need for travel are in a single vault. I then sign in to my account on 1Password.com, mark that vault as “safe for travel,” and turn on Travel Mode in my profile. I unlock 1Password on my devices so the vaults are removed, and I’m now ready for my trip. Off I go from sunny Winnipeg to hopefully-sunnier San Jose, ready to cross the border knowing that my iPhone and my Mac no longer contain the vast majority of my sensitive information.

After I arrive at my destination, I can sign in again and turn off Travel Mode. The vaults immediately show up on my devices, and I’m back in business.

Not just a magic trick

Your vaults aren’t just hidden; they’re completely removed from your devices as long as Travel Mode is on. That includes every item and all your encryption keys. There are no traces left for anyone to find. So even if you’re asked to unlock 1Password by someone at the border, there’s no way for them to tell that Travel Mode is even enabled.

In 1Password Teams, Travel Mode is even cooler. If you’re a team administrator, you have total control over which secrets your employees can travel with. You can turn Travel Mode on and off for your team members, so you can ensure that company information stays safe at all times.

Travel Mode is going to change how you use 1Password. It’s already changed the way we use it. When we gave a sneak peak to our friends at Basecamp, here’s what their founder, David Heinemeier Hansson, had to say:

International travel while maintaining your privacy (and dignity!) has become increasingly tough. We need better tools to help protect ourselves against unwarranted searches and the leakage of business and personal secrets. 1Password is taking a great step in that direction with their new Travel Mode. Bravo.

Travel Mode is available today, included in every 1Password membership. Give it a shot, and let us know how you travel with 1Password.

Learn how to use Travel Mode on our support site.

Time to make the switch

In light of the recent announcement that Meldium is closing, it’s the perfect time for your team to find a new password manager – and 1Password is here to apply for the position! If you were affected by this closure, are worried about your password manager going away (or being bought out for a third time), then it’s time to make the switch to 1Password.

After all, a password manager is too important to choose one that won’t be here for the long haul.

Why choose us?

We could tell you that we’re the best, that we’ve won all kinds of awards, and that we’ve got the best security and customer support. Or we could give you a free trial, where you could see just how easy it is to fall in love with 1Password. We’ll do both, but first let’s tell you a bit about our company ;)

1Password began 10 years ago when Dave and Roustem had the dream of building an easy, secure way to remember and fill passwords. Since then we’ve grown to over 80 passionate people across 4 continents.

In the many years that 1Password has been around we’ve seen many password managers come and go. Some have been flash-in-the-pan, fly-by-night companies, others have been VC funded exercises in getting bought or acquired. Through it all, 1Password has consistently led the way making password management as beautiful, usable and secure as it can be.

We’ve had a blast building 1Password over the last 10 years and are honoured to have millions of customers call 1Password home. We’d love to have you join us as we look forward to the next 10 years.

After all – password management is what we do. It’s all we do. It’s what we love to do.

Switch now and Save

We know it can be tough to ask for additional budget when you are already paying for a password manager. Don’t worry, we have you covered there too. Switch your team to 1Password by June 30th and send us the remaining invoice for your current password manager and we’ll add DOUBLE the credit to your new 1Password account.

Switch to 1Password Teams for double credit

It’s easy to get started. Once you have signed up for your free trial send your receipt to maketheswitch@1password.com. Our team of amazing people will reach out and help you make the switch. It’s just that easy – almost as easy as using 1Password.

So take this opportunity to switch your team to 1Password. You’ll never have to worry about switching again :)

1Password is #LayerUp-ed with modern authentication

We should remember on this World Password Day that passwords have been around for thousands of years. They can’t be all bad if we’ve kept them around so long, but some things need to change.

This year we are partnering with Intel to talk about layers of security, and in this article I’m going talk about how 1Password adds invisible layers of security to what might look like an old-fashioned sign-in page with a username and password.

Passwords are not a bad way of proving who you are. But the way that they’re used in practice exposes people to a number of unnecessary risks. It is long past time to move beyond traditional password authentication, and with 1Password accounts, we’re doing so.

Breaking tradition

When we designed the sign-in process for your 1Password account, we wanted something that looks reasonably familiar to people but secures against the risks that a traditional password login does not. Indeed, when you sign in to a 1Password account, although you enter your Master Password, you do not send us any secrets at all.

The buzzword explanation is that our end-to-end encryption uses Secure Remote Password (SRP) as a Password-based Authenticated Key Exchange (PAKE) along with Two-Secret Key Derivation (2SKD) to get all of the security properties we want without having to place too much additional burden on the users.

If you’re interested in knowing what exactly all that means, read on. Otherwise stop here and enjoy a technical discussion of how migratory swallows can transport coconuts:

Halt! Who goes there?

Authenticating (proving who you are) with passwords hasn’t really changed much over the centuries. And I’m going to start my discussion of the security properties it does and doesn’t offer with a very traditional example.

King Arthur Queen Penelope approaches a castle gate where a guard (we’ll call him Vincent) is on duty.

Many web services use this traditional method, and many are plagued with the same security problems (which I will get to shortly). As a society we need to be doing much better than this, and we are proud to say that 1Password is doing much better than this!

1Password’s major line of security is its end-to-end encryption: your data is encrypted with keys that never leave your devices. So even if someone does get past the castle gate there is not much they can do with what they find inside. But today we are talking about the security of signing in to the 1Password service.

The problems found in the castle gates method

A method of authentication that has been in place for thousands of years may have a lot going for it. It simply shouldn’t be dropped like coconuts dropped by migrating swallows. But it does bear looking into. And when we do look into it, we see lots of problems.

  • Reuse: If Penelope uses the same password for multiple castles, then the discovery of one of those passwords in one place can lead to a breach of all of the castles that she uses that password for.
  • Guessable: The sorts of passwords that Penelope is going to use in these sorts of circumstances are probably guessable with a reasonable amount of effort. This guessing can be made easier if an attacker gets hold of the data that Vincent stores to verify passwords (even if it isn’t the passwords themselves).
  • Replay: If someone overhears Penelope saying her password to Vincent, then they can use what they overheard to pretend to be Penelope at some later time.
  • Revealing password to those in the castle: Even if Penelope and Vincent could avoid being overheard, Penelope is giving away a secret to someone who may or may not be the real Vincent. Even if it is the right Vincent, she has to trust him to not do anything he shouldn’t with her password (like pretending to be her at some other castle).
  • Not mutual: Penelope proves to Vincent that she is who she says she is, but Vincent does not prove to Penelope that she is at the castle that she thinks she is at. Sure, it might be tricky for one castle to pretend to be a different one, but internet services are another matter.
  • Further communication is still unsafe: If Penelope is brought within the castle walls after authentication, all is good. But if (keeping the analogy closer to an Internet service) she remains outside the castle but carries on conversations with people within the castle, their conversation will still be overheard and perhaps tampered with by someone else outside the castle walls.

Building better castles and gates

Traditional authentication, whether it be castle gates or websites, only really have the client or user proving their identity to the server. But we should be asking for much more security in a modern authentication process. Not only should it have the client prove its identity to the server, but

  1. The server should prove its identity to the client (mutual authentication).
  2. An eavesdropper on the conversation should not be able to learn any secrets of either the client or the server.
  3. An eavesdropper should not be able to replay the conversation to get in at some later time.
  4. Client secrets should not be revealed to the server.
  5. The process should set up a secure session beyond just the authentication process.
  6. User secrets should be unguessable.
  7. User secrets should be unique.

I know that a lot of the things on that list overlap, and solving one often involves solving another. But there are some technical reasons for their separation. Also it makes for a more impressive list when they are broken apart this way.

What’s inside the castle

There may be ways for Oscar (Penelope’s opponent) to get into the castle that do not involve providing proofs of identity to Vincent. Perhaps there are other doors. Perhaps it is possible to tunnel in or or fly over the walls. Perhaps it is possible to hide inside a large wooden rabbit that is brought into the castle. Perhaps someone already inside and trusted is an enemy spy. Requiring that Vincent check multiple factors will not help defend against any of those.

It is 1Password’s end-to-end encryption that defends against those sorts of attacks. Although end-to-end encryption is probably our most important layer of security, it is not the one that I am talking about today. I bring it up because not only is end-to-end encryption our most important line of defense, but because we need to make sure that nothing in our authentication system could weaken that encryption. We don’t want an attack on the authentication system to give the attacker any information that would be helpful in decrypting Penelope’s data. (Don’t worry if that didn’t make sense at this point; it should by the end.)

With end-to-end encryption the stuff in the castle that is valuable to Penelope is useless to Oscar because only Penelope has the ability to make use of it. Penelope has secrets that never leave her side that can transform her pile of useless stuff kept inside to castle into things that are very valuable. Authentication is about proving who you are and being given access to something. Encryption (and decryption) is about transforming stuff from a useful form into a useless form (and back again).

End-to-end encryption means that even if Oscar gets inside, he will not be able to read the data that he finds. Penelope’s data – even within the castle – can only be decrypted using secrets that only Penelope has and which are never revealed to anyone else.

Once more into the breach

There is one extra thing we need to consider to keep all of this secure. And that is whether an attacker, Oscar, who gets into the castle can use the same information that Vincent has in a way that helps him (Oscar) decrypt Penelope’s data.

When Vincent checks to see whether Penelope has provided the correct password, he needs to check against some data stored some place (perhaps in his head). If computer systems worked like those castles then there might be the same password for everyone and Vincent would know it, too. Fortunately, most web services do much better than that. Each person has their own password and the service should not be storing those passwords unencrypted.

Services do not want to store the passwords that are needed to get into the service. Vincent shouldn’t store that Penelope’s password is xyzzy. Having a piece of paper around with all of that data would be dangerous. So Vincent doesn’t actually have those passwords himself; instead he has password verifiers. (Vincent verifies passwords in this story, and Penelope proves her identity. Oscar is their opponent.)

Making a hash of it (is a good thing)

I have to step back from the castle metaphor at this point, as Vincent needs to do some math that wasn’t around at the time. The verifiers that Vincent stores are typically (though not necessarily) cryptographic hashes of the password. The beauty of a cryptographic hash is that it is quick and easy to compute that the hash of “xyzzy” is “mzgC7LrRFCZ90NGkMeV7C8qVkwo=”, but it is pretty much impossible to compute things in the other direction. So in a typical web login system, when Penelope tells Vincent her password, Vincent computes the hash of what she says and then compares that to what he has stored. This way, if Oscar steals the list of these hashes from the castle, the passwords that people use to authenticate remain safe.

But we still have a problem. Even though Oscar can’t compute “xyzzy” from “mzgC7LrRFCZ90NGkMeV7C8qVkwo=” he can use that hash to verify guesses. Oscar can guess “OnlyUlysses4Me” and see what hash it produces. If it doesn’t produce the hash he is checking against, then he tries another guess. If Oscar has the right sort of equipment and a copy of the verifier/hash stolen from the castle, he can make a large number of guesses very quickly. If Oscar knows that Penelope enjoys adventures, he will eventually guess “xyzzy”, and will see that he gets the right verifier.

One password, two secrets

Now those of you still following along might wonder why Oscar would bother trying to discover Penelope’s password to get into the castle if he already managed to get into the castle to steal Vincent’s list. There are many reasons why figuring out Penelope’s password would be useful to Oscar, but the one that we are concerned about here is that it might be useful for decrypting Penelope’s data. Even though Penelope’s data is encrypted using a secret that only Penelope knows, we want Penelope to only have to know one password to get to her data (be able to retrieve her stuff from the castle) and decrypt it once she has retrieved it. This one password is her Master Password.

Her password, xyzzy, is being used for two purposes. Once is for authentication (getting into the castle) and the other is for her end-to-end encryption to decrypt her data. And this is why – even though 1Password’s security is primarily based on end-to-end encryption – we need our authentication system to not give Oscar anything useful for attacking Penelope’s data. We do not want anything we store to aid Oscar in guessing Penelope’s Master Password.

We want it so that even if Oscar gets into the castle and gets hold of Vincent’s list of verifiers he is no closer to getting at Penelope’s secrets. Although SRP gives us many of the security properties we want, it still leaves Vincent holding a verifier. That verifier – if we didn’t take counter measures – could be used by Oscar for checking password guesses even though it isn’t a traditional password hash.

Two secrets, one password

We want the verifiers that we store to be uncrackable. Our solution is Two-Secret Key Derivation (2SKD). Penelope has a secret other than her Master Password. It is her Secret Key. When she first sets up her account the software running on her machine will create an unguessable Secret Key. This Secret Key gets blended in with Penelope’s Master Password all on her own devices.

When Penelope proves her identity to our servers, she is not just proving that she knows her Master Password, but she is also proving that she (well, her software) has her Secret Key. In fact, she is proving that she has a combination of these. That combination is unguessable and so cannot be used to get at the secrets needed to decrypt her data.

2SKD means that Vincent only stores uncrackable verifiers. So there is little that Oscar could do if he stole the list of verifiers. SRP means that neither Vincent or anyone listening in during authentication can learn Penelope’s secrets. And with all of Penelope’s authentication secrets nice and secure, they can also be used for the end-to-end encryption of her data.

A very brief word about SRP

SRP and other similar systems involve proving that you know a secret without revealing that secret. As much as I would love to go more into how that happens, this article has become too long as it is. So let me just say that the client and the server present each other with mathematical puzzles that can only be solved with knowledge of a secret, but solutions to those puzzles do not reveal anything about the secret. And because each puzzle is new each time, someone who records a session cannot replay it later.

I’ve tried to give an overview of how the interaction of three things in 1Password’s design – end to end encryption, 2SKD, and SRP – protect your personal information from whole categories of attacks. These design elements are mostly invisible to people using 1Password. You do not need to know about these things to use 1Password well, but we like to let you know it is there. This is all part of how we at strive to make dealing with passwords both easier and more secure. Although not all of the techniques described here are appropriate for all sites and services, we do hope that we that the ideas discussed here can help improve authentication not just for 1Password but for other systems as well.

More detail about all of this and more is in our 1Password Security white paper.

And so a Happy World Password Day to one and all.

Get to know 1Password Teams: Security Audit & Watchtower

You’ve moved over to 1Password Teams, invited your team, set up custom groups and laid out a recovery plan. Simply by using 1Password, your company is now far more secure than when you started. But how can you know your team is safe from online security breaches? Your teammates could go through their passwords one by one and make them stronger, but there’s a better way: Security Audit.

Read more

Get to know 1Password Teams: Vaults and sharing

What would 1Password be without vaults? They’re where you put your most important information to keep it safe, and they’ve been a core part of the 1Password experience since the beginning. In 1Password Teams, vaults are more useful than ever. Let’s look at how vaults can help you organize and share information within your team.
Read more

Get to know 1Password Teams: Custom groups and roles

As a 1Password Teams customer, you’re in charge of tens, hundreds, or even thousands of people, passwords, and files. Thankfully we have some fantastic tools that give you flexibility and control. Two such tools are custom groups and roles:

  • Custom groups let you organize your staff in a way that makes sense. You might want to put your IT team in one group, your accounts team in another, and sales in a third. Each group has access to the vaults it needs, so new members will have be able to see the right information as soon as they join.
  • Custom roles let you decide who can perform team-level responsibilities like invite people or recover accounts—-without giving them full admin privileges. You can also grant the ability to manage people and vaults, and a lot more. These roles supersede the built-in permissions, so you can give your team members more power, or take it away. It’s entirely up to you.

Read more