Enigma machine

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

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

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

In this case they said:

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

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

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

Slack 1Password login Slack 1Password extension

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

 

But now back to what is feasible with password hashing.

One way hashing

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

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

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

Guessing versus reversing

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

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

So now let’s correct Slack’s statement:

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

Modified Slack statement.

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

Slowing down guessing

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

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

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

What’s infeasible?

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

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

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

Security parameters

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

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

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

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

Doing time, time, time in an exponential rhyme

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

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

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

Plot with exponential catching up

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

Plot on scale where exponential flattens polynomial

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

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

Quibbling over terminology

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

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

The limits of slow hashes

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

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

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

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

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

1Password 4 for iOS icon

1Password 5.3 for iOS: The Extended Brainiac Edition is out!

This major, free update to 1Password for iOS is so awesome, we thought about pulling a Harry Potter and releasing it in two parts. But when Apple told us Daniel Radcliffe wasn’t available, and they didn’t even have his number in the first place, we just had to give it all to you at once.

A 400 percent better App Extension

1P iOS 5.3 App Extension CC Identities borderYou know how our App Extension can fill Logins into Safari, our own 1Browser, and hundreds of other apps with a single tap? Now it can also:

  • fill Identities
  • fill Credit Cards
  • create new Logins when you’re signing up for new services
  • show all Logins if none are found for the current app (App Extension only)

It’s all in the name of saving you even more time when logging in and now filling long forms and shopping carts.

A brand new Brain

We affectionately call 1Password’s under-the-hood tools and form-filling logic the “Brain,” and we gave it a huge upgrade in 5.3. It’s much smarter about matching websites and subdomains and fills forms even faster.

We need to talk

OPI 5.3 Message Center

There is so much great stuff going on with 1Password that we added a new Message Center to keep you in the know. It brings you 1Password news and tips right in our in-app Settings. Don’t worry, Push Notifications need not apply.

So, so much more

We added Large Type so you can view usernames and passwords in Jumbo Size, and we fixed a couple Zoom Mode bugs and a crash for iPhone 6 Plus users. Truly, there is a mountain of improvements you can check out in the full release notes.

Our free 1Password 5.3 for iOS update is now live in the App Store, so take it for a spin and let us know what you think on TwitterFacebook, and in our newly redesigned forums!

An Open Letter from AgileBits

An open letter to banks

TD Canada Trust made quite a splash recently when it launched its redesigned iPhone app which disabled pasting in the password field. Users who embrace password managers for their online security were quick to point out their … well, ‘unhappiness’ with this decision. TD Canada’s original response to those users was unsettling:

Hi Steve, thx for stopping by. For ur security, your password should be committed to memory rather than using a password mgr. ^SB

The original tweet has since been deleted by @TD_Canada.

For those of us who rely on 1Password (and other password managers) on a daily basis, this advice is completely cringe-worthy … unfortunately, it’s really not all that uncommon in the banking world. Many banking and financial sites implement restrictions on password length, require certain special characters to be present, and put in place various ‘security theatre’ measures on their websites that do little for increasing user security, while ultimately making it more difficult for users to rely on password managers to fill their complex passwords in on the site. Why do they do this? Well, it’s difficult to know for sure, although our Chief Defender Against the Dark Arts does have a theory on the matter.

With the conversation about online security and banking so fresh in everyone’s minds, I thought now would be a great time to send a message out to banks and financial institutions everywhere to encourage them to to take users’ security more seriously. I’m writing this not only as a member of the 1Password team who deals with security issues on a daily basis, but also as a concerned customer who just wants simple and secure access to her data.


Dear banks,

I know that you have my best interests at heart.

I know that you’ve worked hard to put ‘safeguards’ into place (such as disabling pasting into password fields, obfuscating usernames, spreading the login process across multiple pages and “please input the nth character of your password” fields) to thwart various types of attacks.

But the truth is that these ‘security measures’ are not actually helping your users.

Do you know what would really help your users? Long, random passwords.

Using long, random, and unique passwords is the best defense that we, your users, have against attackers. This advice is true for every site we have to sign in to these days … and believe me, we sign in to a lot more than just our financial sites. Keeping 100 or so strong and unique passwords memorized is not only a silly suggestion, it’s nearly impossible for all but the most savant-ish of us. Password managers help us increase our security by remembering these unique passwords for us, keeping them stored securely, and filling them in on websites so we don’t have to.

Many of the ‘security measures’ you have put into place serve only to make it much more difficult for those of us who rely on password managers. Password managers are not your enemy here. In fact, encouraging the use of trusted password managers will do more for your users’ security than any of the measures you currently have in place.

You have an awesome opportunity here. Take the time to educate your users on the value of true security. Encourage users to adopt long, random, and unique passwords that never need to be stored in their brains. Make it easy for password managers to store and fill these secure passwords for your users (in web browsers as well as in mobile apps).

Now, it just so happens that there is a very simple way that you can give your users easy access to their banking data in your mobile apps. We’ve written an App Extension API that can be added to your iOS app in 3 easy steps. The app extension will allow users to select their password manager of choice and fill their complex passwords into your form, with no typing required.

1Password has been giving people control over passwords for almost 10 years now, and it truly is a wonderful thing. Our team built 1Password around the idea that being secure should never be compromised for convenience. We’ve been advocating for stronger, safer passwords for years, and we’d be so happy if you stood with us.

For now, passwords are a necessary evil. Remembering them shouldn’t have to be.

Please help us increase awareness of online security. Your users will be ever-so-grateful that you are taking their security seriously, and you’ll be making their lives a lot simpler too.

Signed, a hopeful user.


Since TD’s original response last week, they seem to have had a change of heart. A tweet from @TD_Canada on Saturday indicates that they are in fact working on an update that will allow copy and paste within their app … and possibly considering integrating password managers.

Hi Rick, we're working on providing our customers w/ the option to use copy/paste & PW managers. No dates to share yet. ^SK

This is incredible news! Without seeing the update, it’s hard to know exactly what they have in store for users, but they have a great opportunity here to set the standard for banking apps and give other financial institutions a secure example to follow. I’m excited to see what they come out with!

If you believe as I do that banks should add 1Password (and other password manager) integration to their iOS apps, please consider sharing this open letter with your bank. #BanksNeed1Password

Password wordcloud from xato.net

When is a password leak not a password leak?

Password wordcloudI’d like to take a moment to talk a little bit about how people who study password behavior go about their job.

In the process, I would like to thank all password researchers and, in particular, Mark Burnett for both his years of excellent research and the help he has provided to other researchers. He is unequivocally one of the good guys, even if portions of the technical and popular press have entirely misunderstood the impact of his support for the research community.

Before getting into any detail, I would like to make it clear that Mark’s posting of 10 million passwords on Monday did not reveal any new information to hackers, and did not enable any new attacks. All of the information he packaged was already public, and Mark’s preparation made it even less useful to bad guys. For details, it’s best to read his own FAQ.

Of course, you, our readers, will all be using 1Password to help ensure you have unique passwords for each and every site and service.

Researching secrets

One of the biggest difficulties in studying password behavior is that people are supposed to keep their passwords secret. Because of this not-so-minor drawback, there are two ways to get real data on people’s behavior.

One way is to conduct experiments and simulations. There is some really exciting research along these lines, particularly from Lorrie Cranor’s group researching Usable Privacy and Security at Carnegie-Mellon University. But there are many others contributing to that research.

One of the advantages of these experiments, which almost no other method offers, is that they help us figure out how well people can use and remember passwords. Of course, 1Password saves you from having to remember all but one (or a very few) of your passwords, but those passwords need to be strong. We rely on the research conducted by the academic community on password learnability, usability, and memorability when offering our own advice on creating better Master Passwords.

The second way to analyze people’s behavior with respect to passwords is to study the data that comes from password breaches. For example, when RockYou was hacked in 2009, the attacker published a list of 32 Cranor wearing RockYou password dressmillion user account passwords. Much of the advice you see today about most common passwords comes from the study of the RockYou data. Note that not all breaches involve revealing passwords. The recent breach of Anthem, for example, didn’t reveal customer passwords.

Pretty much everyone who studies password behavior grabbed a copy those RockYou records. Professor Cranor, who I mentioned above, even made a dress based on the most popular passwords found on in the RockYou data. Although we do not condone such breaches, we all make use of the data if it is published.

It is almost certainly true that only a small portion of such breaches are made public. Many of the criminals would like to keep both the fact of the breach and any passwords they obtain secret so that they can be exploited before people change those passwords. Sadly, the criminals have more data than we do, so they know more about actual password practices than we do.

1Password 1Password window, crediting Mark BurnetOne of the many uses of this sort of data is to figure out what the most common passwords are. Lists like the ‘top 10′ or ‘top 100′ passwords are often published in attempts to shame people to make better choices. But Mark’s earlier publication of the top 10000 passwords has made it into 1Password itself. In addition to other tools and guidelines, we use that list in the Mac and iOS versions when calculating password strength.

For big data sets, like RockYou or Adobe in November 2013, I will usually make a point of getting a copy. That way, I can do my own research on some of these datasets, as well as read about the analyses that others do.

Tracking password dumps

Tweets from @dumpmonThere are smaller data sets published very frequently, but sporadically, on sites like Pastebin. In fact, there is a handy Twitter bot, @dumpmon, that reports them.

To make things more confusing, many of the Pastebin posts make false claims about their data. They will claim that it is new data from, say, Gmail, while in fact it is old data drawn from previously published data. Quite simply, it is a substantial chore to watch for such data, evaluate it, and organize it into usable form. It takes skill, dedication, and analysis to do that.

I’m sure that I am not alone among those who study passwords to say that I am glad that Mark Burnett has been doing that work so that I don’t have to. Mark has been studying these for many years now. He has always shared his research results with the community, and has been very helpful when people (like me) ask him for some data.

When someone asks Mark for some of his data, he has to worry about removing credit card information that may be part of one leak, or revealing information about the site from which the username and password were obtained. Despite the fact that information has already been made public, he correctly does not feel comfortable re-releasing it. This is why he prepared the sanitized list that he released Monday.

What have I learned studying these 10 million passwords?

To be honest, I haven’t really dived into to studying these. I’m lazy efficient and patient, and am waiting for others to publish their results. However, if I don’t see certain types of analyses that I believe would be useful, I’ll roll up my sleeves and take the plunge.

But in playing with these for about 10 minutes, I (re-)learned a couple of things:

  • Modern computers are fast enough that I can actually do much preliminary poking around using AWK.
  • I was able to say “I told you so” to some friends about some clever passwords that were far more frequent than they’d imagined.
  • I confirmed (as I did with the Adobe set), that David Malone and Kevin Maher were correct when they concluded that – despite appearances – passwords frequency does not follow Zipf’s Law.
  • I hadn’t used Transmission/BitTorrent in ages, and no longer needed to seed the FreeBSD8.2 iso (The password list was made available via torrent).
  • Update: Someone actually used “correcthorsebatterystaple” as a password, illustrating the dangers of presenting examples when explaining password creation schemes.

I do not wish to give the impression that I won’t be able to make valuable use of the data. There are a number of interesting analyses I would like to run. In particular, I would like to see if I can identify passwords created by a good password generator, but that will be a long and hard project. Broadly seeing what password creation schemes are the most popular would also be useful. I may use Dropbox’s zxcvbn password analysis engine to make a rough pass at that.

And there is no question that Mark’s collection, tidying, sanitizing, and releasing of this data will help us good guys learn more about password behavior.

Workflow icon

Community Goodie: Workflow + Chrome for iOS + 1Password

Have you discovered Workflow for iOS yet? It joins Launch Center Pro and others in the category of Super Useful Apps that can save you a ton of time doing repetitive tasks or complicated things that span multiple apps. They can also just blow your mind with tasks you didn’t know iOS could pull off.

One of Workflow’s tricks is that it can make your workflows available inside other apps via its own App Extension. Harnessing the true power of this knowledge, 1Password user and Redditor papa-lozarou created a Workflow that searches 1Password for the domain of the current tab right within Chrome for iOS.

 

Picture this: you’re groovin’ along in Chrome for iOS, and you have to log into a thing to do a thing. Instead of switching to 1Password to unlock, manually search, copy, switch back over, and paste your password, you can now simply trigger Workflow right inside of Chrome. From there you can invoke 1Password’s in-app extension, which then automatically searches for the URL of your current tab.

You’ll still have to tap into the item to copy your password, but you’re still in Chrome where you can easily paste it and get on with your bad self.

Let’s give a shout out to Redditor papa-lozarou and Workflow for being just great. On an iOS device, you can download the Chrome workflow here.

Extension-960

Apps ❤ 1Password: They really, really do

The number of apps adding support for our 1Password App Extension for iOS 8 is growing briskly. I know of dozens of apps that are gaining support as you read this, and we are at nearly 100 shipping apps right now.

We are deeply grateful to every developer adding support, and thankful to our users for helping us to spread the word. If you haven’t checked out the apps that are making it easier to create accounts, log in with a tap, and stay secure online, here are some of the latest categories gaining new entries from developers and businesses all around the world.

Finance

Business

Lifestyle

Social Networking

Windows v4 blog

1Password 4.1.0.538 for Windows gets TOTP, more control

Yep, it was a busy holiday season and early 2015 for us. We have a lot planned for 2015, and rolling out support for TOTP—Time-Based One-Time Passwords—to our Windows customers is just the next big step.

Available in our latest Windows update, 1Password 4 for Windows joins our iOS version with support for creating and managing TOTPs. A growing number of services implement them as a secondary layer of security, and you can learn more about this system at TwoFactorAuth.org.

We also packed in support for Terminal Services and Citrix, polished up the Quick Start and Welcome process for new customers, improved the Dropbox vault picker, and improved plenty of other stuff.

You can see the full list of changes in our release notes, or fire up 1Password’s in-app updater to get the details. Let us know what you think on Twitter @1Password and on Facebook.com/1Password, and stay in touch with the AgileBits Newsletter!

1P Pro features

TOTP for 1Password users

1P Pro features1Password 5.2 for iOS and 1Password 4.1.0.538 for Windows are out, and they provide support for using Time-based One Time Passwords (TOTP) in your Logins (note: in iOS, it’s part of our Pro Features). Note that this is not for unlocking 1Password itself, but to aid with logging into sites for which you may be using TOTP, such a Dropbox and Tumblr.

To learn how to have 1Password help you manage your TOTP Logins, go straight to our user guide. If you would like to better understand when and why TOTP is useful for 1Password users, and what to do if you truly want two-factor security, continue reading here.

TOTP countdownI’ve previously written (at excessive length, in some cases) about TOTP in general, but in each instance pointed out that it is of limited utility to 1Password users. This is because such schemes are of most use to those people who have weak or reused passwords. If you are using a strong and unique password for a site, then many of the gains of two-step (or multi-step) verification are not relevant for you.

But “most” is not the same as “all”. There still are some cases where multi-step verification is useful to people using 1Password.

Sometimes you must use TOTP

Sometimes a site or service will simply require that TOTP always be used along with your regular password. Patty (one of my dogs) is working with a research group analyzing the structure of heart worm DNA. When she connects to the lab’s server, she is required to use TOTP.

TOTP example in 1Password for Windows

TOTP example in 1Password for Windows

She has set up an app on her laptop that just constantly displays the current TOTP code. It’s sitting there ticking away all the time her laptop is running. Ideally, it should only be visible when she actually needs it, but she is understandably just trying to save time. Clearly, she could use TOTP more securely if it were available for the Login item within 1Password.

One-timeness? Yes

One-time passwords (the “OTP” in “TOTP”) are useful over insecure networks. Normally, when you submit a password to a site or service, you send the same password each time. Ideally, that connection is well encrypted so that the password cannot be captured when it is in transit. This is why it is very important to:

  • use HTTPS instead of HTTP when doing anything sensitive
  • pay attention to the lock icon in your browser’s address field (indicating HTTPS)
  • heed browser warnings about such connections

But networks are easy to compromise. Recently Molly (my other dog) was at the Barkville Airport. When she connected to Wifi, she saw several open wifi IDs. One was BVT-access, and the other one was “Airport Free Wifi”. As it turned out, BVT-access was the legitimate one, but she connected to Airport Free Wifi. Airport Free Wifi was actually a laptop operated by Mr Talk, our neighbor’s cat.

Mr Talk is using SSL-strip on his rogue wifi hotspot. If Molly isn’t paying close attention to the HTTPS status of her browser’s connection, she can send things unencrypted over Mr Talk’s network while thinking it is a secure connection. I should probably point out that Molly lacks the discipline to pay close attention to anything other than a squirrel or rabbit. This way, Mr Talk can capture Molly’s passwords in transit to the servers and save them for later use.

That is one of several ways that passwords can be captured in transit. The point of one-time passwords is that they are not reusable even if they are captured in transit. In this way, TOTP provides a meaningful defense against plausible attacks even though there is nothing “second factor” about how it is being used.

Second factor? No

We need to make the distinction between one time passwords and second factor security. One time passwords are often part of second factor security systems, but using one time passwords doesn’t automatically give you second factor security. Indeed, when you store your TOTP secret in the same place that you keep your password for a site, you do not have second factor security.

However, you still have the benefits of the one-timeness of TOTP codes.

Systems like TOTP are sometimes used as part of second (or multi) factor authentication systems. But this is far from their only usage. To be truly second factor, the TOTP secret (from which the one time password is generated) must not be stored on the same device that you use the regular password on.

Let’s consider an example. Molly has a Tumblr where she posts pictures of the squirrels she is after. So far, she has been using the Authy app on her phone to manage TOTP. If she never logs into to Tumblr on the same phone, then she is using her phone as a second factor. But if she is also using Tumblr from her phone and has had to use her one time password from there, then there is no second factor.

In general, there is a reason why many services that offer TOTP refer to it as “two-step verification” instead of as “second factor authentication”. The security that such sites seek to gain from this is not in the second-factorness; it is in the one-timeness. In particular, many of the sites and services that offer or require two-step verification with one time passwords are doing so because many of their users have weak or reused passwords. Although that should not apply to 1Password users, there are other benefits to one time passwords as I discussed above.

If you really want true two factor

If you would like to turn a site’s offering of TOTP into true two-factor security, you should not store your TOTP secret in 1Password (or in anything that will synchronize across systems). Furthermore, you should not use the regular password for the site on the same device that holds your TOTP secret.

Put simply: the device that holds your TOTP secret should never hold your password if your aim is genuine two factor security.

Personally, I don’t think that following that practice would be worthwhile for anything but a very small number of special circumstances, in which case, you should probably be using a specialized second factor device instead of something like a phone. But not everyone shares my opinion on this, and if you have a need for true second-factor security for some particular site or service, you should take that into account before adding a TOTP secret to 1Password.

For everyone else, if you find the one-timeness of TOTP worthwhile on its own (or are required to use it), 1Password’s new support in v5.2 for iOS and v4.1.0.538 makes it easier to use than ever.

1Password 4 for iOS icon

1Password 5.2 for iOS: The Awesomesauce Edition is here

OPI 5.2 jar of AwesomesauceThe holiday season may be over, but we saved your best present for last! Well, at least the best present with ‘AgileBits’ printed on it somewhere. 1Password 5.2 for iOS is now making its way to the App Store, and we even saved you the time to unwrap it.

(Get it? Because software is digital and therefore impossible to wrap with paper.)

This free update goes out to our new customers and Pro feature owners. To start, we added our first-ever Login Creator, a really slick new tool that makes it easy, dare I even say fun, to add your existing Logins to 1Password and get a feel for how much time it can save you.

Login Creator has a polished workflow for hundreds of sites and services, and we hope it makes getting started with 1Password even easier.

1P iOS Login Creator

For our Pro feature owners, let’s start with a new One-Time Password tool. This helps you sign into a growing number of services (like Amazon and Tumblr) that support a secondary, randomized password for that extra… je ne sais quoi. You can learn more about One-Time Passwords at TwoFactorAuth.org.

1P iOS OTP

Pro owners can now also delete attachments from the item editor and add many new custom field types like addresses, dates, and month/year.

Rounding up this release are plenty of additions in the 1Password App Extension, design, sync, Accessibility, and translation departments. You can check out the full iOS changelog if you want all the details or skip straight to the App Store and pick up the latest and greatest 1Password for iOS!

While you’re there, please take a minute to give us a great review—it helps more than you may know! Finally, let us know what you think of this release on Twitter and Facebook, and stay in touch with the Agile Newsletter.