Should You Ditch LastPass?

LastPassSteve Thomas, aka Sc00bz, has brought up some very interesting issues about the LastPass password monitor that are causing some confusion so I thought I’d give another perspective on the issue.

Summary of Steve’s points:

  1. When you use the LastPass web site to login to your account, your web browser will first send a hash with a single iteration, no matter how many iterations you have set for your account. It isn’t until this hash fails that the browser tells the user the correct number of iterations to use.
  2. LastPass has a default setting of 500 iterations (at least at that time, now it recommends 5000 iterations).
  3. The extension should warn you if it is going to send a hash with fewer iterations than what you have set.
  4. LastPass does not encrypt the URLs of sites stored in your password database

LastPass hashes your password rather than sending the plain text to the server when you login. The algorithm it uses is sha256(sha256(email + password) + password). This hash, while not necessarily insecure, can be cracked in a reasonable amount of time with ordinary hardware, unless the user has a relatively strong password. It isn’t until after this single iteration hash is sent that the LastPass server responds and tells the browser exactly how many iterations it should use; hash is sent again using the correct number of iterations. More iterations means it will take much more time to crack your password. A good minimum number of iterations is 5,000. If you go too high with the number of iterations, some clients such as mobile phones may be very slow logging in.

This is an issue that certainly should be addressed, but it is not serious enough to warrant abandoning LastPass

The mitigating factors here are:

  1. You are logging in via SSL so the primary threats here are a MitM attack with spoofed SSL certificates, a government warrant, or a government spy agency.
  2. They still need to crack your hash so if you have a very strong password, even a single iteration hash could provide a reasonable amount of protection.
  3. A second factor of authentication, country restrictions, blocking tor logins,  restricting mobile access, and other settings still protect your account from unauthorized logins, unless the attacker is able to obtain your stored hashes through hacking, warrant, or spying.

One thing I might also add is that the server is telling the client how many iterations it expects, so this does make an attack much easier if someone acquires your hash.

My opinion is that this is an issue that certainly should be addressed, but it is not serious enough to warrant abandoning LastPass altogether unless your inpidual threat model includes the NSA or other government agencies. The LastPass plugin should identify when someone is logging in to LastPass via the web login and provide the client-side script with the correct number of iterations. The server should never respond with this at all. However, if someone is logging in through a web browser that doesn’t have LastPass with their account data installed, the server sending the number of iterations is the only option.

The only proper solution here is to have your primary login different than the decryption login, at least for accessing the web interface if not everywhere. That way, the number of iterations is never publicly revealed and sending a single iteration hash would be unnecessary. Other companies such as RoboForm use this method. I have always wanted this feature and I would highly recommend LastPass implement this if it is feasible.

As for the other points, the default iteration count mentioned in number 2 has been addressed and the warning mentioned in number 3 would be a good thing to add if it already hasn’t but this would not be possible if using a web browser with your LastPass account installation.


As for encrypting URLs mentioned in number 4, LastPass’s response was that this is necessary to grab favicons. Although unencrypted URLs may not be an issue, there certainly are scenarios where you would want these encrypted. LastPass should make this an option for the user.

LastPass does provide strong security controls, although there clearly is room for improvement. If you do not find LastPass to be secure enough, the only reasonable alternative I would recommend is KeePass, which puts you in complete control over your data while still being quite usable. I would not recommend ditching LastPass, but I would recommend that LastPass address these issues. I would also recommend that Steve Thomas keep up the great research he provides to the community.

I have not heard a recent response from LastPass on these issues but would love to hear from them. I will update this post if and when I do.

Disclosure: I am a LastPass user and I get a free month of premium service whenever someone clicks on banners located on this site. I have no affiliation with LastPass and receive no other compensation from the company. 

Pafwert: Now Open Source

PafwertMore than 15 years ago I started working on a unique password generator that eventually evolved into a small program I now call Pafwert.

Pafwert is an unique tool to help you to select strong passwords that are easy to remember. Using strong entropy, tens of thousands of seed words, more than a hundred patterns with endless variations, and following password best practices, Pafwert can help you to select very strong passwords that are surprisingly easy to memorize. We have all seen random password generators, but Pafwert is very different.

Of course, while I still recommend using a password manager and generating completely random passwords, there are plenty of passwords we need to remember that we just aren’t able to save in a password manager. That is where Pafwert comes in.

Pafwert uses familiar patterns and a variety of memorization techniques to help you create strong passwords that are also easy to remember. Keep in mind that you don’t have to use the passwords exactly as it spits them out, you can use it simply as a tool to spark your own imagination when creating your passwords.

Pafwert is actually much more complex than it appears on the surface and generates passwords based on patterns and wordlists that you can customize. It then runs these passwords through a number of filters to obscure them just enough to make them unique. Yes, I probably wasted many thousands of hours overthinking this thing. Nevertheless, over the years it has gotten buried on my web site and largely forgotten (although I still use it myself every day).

I thought it was about time to update this tool and open source it (under the Apache license) to share it with the community. I would like to see it updated with new features and maybe even ported to PHP, but for now the code is there for anyone to play with. Note that I began work on this version of the code in 1999 so it is written in Visual Basic 6. That means that few of you will have the tools to do anything with the program itself (although I do have a complete dev environment in a VM if someone is serious enough about working on it).

If you would simply like to download the latest compiled version to install yourself, you can always grab it at or you can check out the source code at GitHub.

If you want to get a taste for the complexity of this tool, you may want to spend a few minutes and read the Pattern Guide.

Hopefully someone can find this useful, if you do, let me know!

Pafwert – Smart Password Generator
4 forks.
0 open issues.
Recent commits:


Now eBay Wants in on Password Patents

I wrote a couple months ago about the many attempts to patent various methods of checking passwords. Now eBay wants in on the game with United States Patent Application 20120284783. Here’s their summary:

A proposed password is decomposed into basic components to determine and score transitions between the basic components and create a password score that measures the strength of the proposed password based on rules, such as concatenation, insertion, and replacement. The proposed password is scored against all known words, such as when a user is first asked to create a password for an account or access. The proposed password can also be scored against one or more previous passwords for the user, such as when the user is asked to change the user’s previous password, to determine similarity between the two passwords.

Reading through the claims, this is by no means novel or innovative and there certainly is plenty of prior art for this. Want to help prevent yet another abuse of the patent system? You can post any evidence of prior art on this Ask Patents post.


RSA’s Distributed Credential Protection: Yeah They Are Overselling it a Bit.

RSA recently announced their new Distributed Credential Protection (DCP) product which they proudly tout as a “revolutionary” way to secure user credentials. But looking closer (especially at that $160,000 per license price tag), I’m not so sure this product will do much to protect anyone’s credentials.

But let me say this first, the technology itself is absolutely brilliant. Without getting into the details of threshold cryptography (there’s an excellent article by Peter S. Gemmell on page 7 of this PDF), what it does is allow you to split up a secret into any number of parts but you only need a specified number of parts to reproduce the data.

“…let me say this first, the technology itself is absolutely brilliant”

It’s kind of like how you see nuclear missile launches in movies: two people have to insert and turn their keys at the same time to initiate the launch. But threshold cryptography is even more advanced, it would be like handing out 5 keys but you only need any 2 of them to fire the missile. What makes the technology so cool is that it gives you redundancy, integrity, and secrecy but no single piece is useful for obtaining the secret. This technology has many uses in cryptography (it would be perfect for Bitcoin) but I think that RSA’s claim that it will revolutionize password protection is greatly overstated.

The problem is that yes, you are splitting up credentials into multiple parts but all of those parts are components of the same system. It would be like handing both missile launch keys to the same person. Yes, someone would have to steal both keys, but if they can steal one from you couldn’t they just steal the other?

Now one of the claims RSA makes is that if you suspect that an attacker has compromised one of the databases, you can immediately randomize and rescramble the pieces so when they grab the second database the data is useless. So yeah if you happen to catch an attack right after an attacker grabs the first bundle of data but before they grab the second bundle, and you are able to immediately identify all points of intrusion and lock out the attacker so they can’t go back in and re-grab the first bundle, then yes this will work. What are the chances of that happening? Slim to none.

Splitting the databases into two locations is not particularly helpful because both must be accessible to the web server, which is usually the point of entry in these types of attacks, and therefore if an attacker can access one database they can likely access them both. Again, it’s like handing both keys to the same person.

The thing is that RSA’s DCP product is addressing the wrong problem with the wrong solution. The reason most companies get their data leaked is because they have poorly secured their public-facing servers and applications and that they don’t follow best practices for storing user credentials. Both of these problems already have solutions and any organization would be better off spending their money on some code audits and pen-testing.

The fact is that if you have problems with hackers getting into your databases, I think you will still have problems even after shelling out $160,000 for DCP. If you don’t have that problem because you have proper security controls and practices already in place, chances are you don’t even need DCP.

To be fair I have to mention that I have not seen or reviewed this implementation in depth so I could in fact be completely wrong with my criticisms. Perhaps this system could be deployed in such a way that it is much more resilient than I am supposing. And certainly RSA acknowledges that this product is just one layer in a multi-layered defense-in-depth strategy. But I still come back to the fact that you are giving both keys to the same person.

What I would like to see is this technology implemented in a much smarter manner. For example, distributing credentials across multiple distinct trust authorities. For example, it would be a great way to overcome many of the weaknesses and distribution issues we see with SSL certificates. Having multiple holders of a secret not only better protects the secrets but upholds integrity in the case a small number of authorities are compromised. This technology could be helpful for preventing insider attacks and would be useful if you have your servers at third-party data centers that you may not completely trust. There are also some legal advantages with having databases distributed across multiple jurisdictions. And hey, if this technology prevented just one attack, in the absence of other attacks it would probably be worth the expense.

There are many other areas that could greatly benefit from threshold cryptography, but splitting credential storage within an organization is probably not one of them. The concept of a black box authentication appliance (although this is vm-based) is a great direction to be going, considering how many organizations simply don’t implement credential storage correctly, but they seem to be overselling (and overpricing) what this product really can accomplish.



Is Mozilla’s Persona the Authentication System That We’ve All Been Waiting For? Probably Not.

Last week, Mozilla announced the first beta release of Persona. Persona, formerly called BrowserID, is a personal authentication system that aims to eliminate passwords to log in to web sites. Of course, you still need one master password to log in to Persona, but it takes care of every site login after that. Persona is definitely interesting, but it likely won’t be signing any death warrants on passwords just yet.

The problem with Persona…is that the stuff that makes it so cool is also what exposes it most to attack.

How Persona Works

One thing that Persona has going for it is that on the surface it is relatively simple. When it comes to authentication, simple is good. Here is a simplified explanation of how it works:

  1. You visit a site and that site asks for your identity.
  2. Your browser goes to (or whatever identity provider you use but for this example I will use and asks you to enter your email address and password.
  3. Once authenticated, signs your public key, basically giving you a seal of authenticity that’s good for 24 hours.
  4. Your browser creates a document called an identity assertion, signs it with your private key, then sends that and your signed public key to the site you want to log in to.
  5. The site looks at the document, verifies that it was signed by you, verifies that your signature was signed by, and then verifies that’s signature was signed by a trusted authority such as Verisign or Thawte.

Note that the identity assertion is valid only for that one site, only from your current web browser, and only for the next 24 hours. At any time, however, you can logout and invalidate all currently stored sessions.

What Makes Persona Great

One thing that makes Persona unique is that the site you visit doesn’t need to communicate with directly, meaning that never knows what sites you are logging in to. Another big advantage is that it is solely based on your email address, which is much easier to remember than an OpenID URL, and which means that you can easily remain as anonymous as your email address allows. Even better, Persona is distributed so if you own your domain you can be your own identity provider.

Persona is built on a concept that inherently protects your privacy puts you in control of your identity.

Mozilla Persona

But There Are Problems

Like any authentication system, Persona does need some serious real-world testing to prove itself and work out the bugs. The problem with Persona, however, is that the stuff that makes it so cool is also what exposes it most to attack.

For example, there is the signing key at the identity provider. Normally you want the strictest safeguards  to protect any signing key. Some signing keys are so important that they are not even stored on network-accessible computers. The problem here is that in order to sign user certificates, you would need to allow the web server to access the private signing key. That usually means storing it on the web server itself.

We have all seen the news reports of user passwords stolen from a server and dumped on the Internet. But what happens if someone grabs a signing key? Basically it means they can sign any request and therefore log in as any user to any site that uses Persona. Yes, that is a pretty big issue. If I ran an identity provider, I would be terrified of taking my eyes off the monitoring consoles.

Another big vulnerability is the web browser itself. Of course, if someone’s browser is infected with malware, they already have some serious issues. But what makes Persona especially vulnerable is that such malware could do more than intercept passwords–it could authenticate it to any web site you use with Persona without any intervention on your part as long as your are logged in to Persona.

Yet another significant issue is that there is way too much room for error in implementing Persona. We have learned by now that if people can get it wrong, they certainly will get it wrong. Persona relies way too much on the implementation which means we will no doubt see plenty of vulnerabilities with identity providers, browsers, and relying parties.

A good example of this we can see on itself. When you login, it first asks for your email address to see if you are a valid user, then if you are it prompts you for your password. The problem with this two-step approach is that it makes it vulnerable to account harvesting. You always have to ask for email and password together and if one is invalid you never say which one it is.

Despite it’s potential flaws I do still like Persona. I don’t think it is the technology that will save us from having to remember passwords, but it is an important step in the evolution of secure authentication. What we learn from it is that emails are better than URLs as identifiers. We learn that it’s good to do stuff on the client side to ensure user privacy. We learn that we can easily leverage long-established and well-tested technologies without having to invent something new on the crypto side of things. Unfortunately, we also learn how incredibly difficult it still is to do authentication right.


Want to Block Common Passwords? Sorry, That is Patented

I always enjoy browsing through password-related patents to see all the flawed, silly, or outright dumb ideas that people come up with in an attempt to improve how we authenticate ourselves in the digital realm. What amazes me though is how many patents I encounter that have been granted for some of the most obvious, well-known and ordinary techniques we use in the authentication process. In fact, every imaginable aspect of password selection, authentication, storage, and recovery seems to be covered by one or more patents. Continue reading “Want to Block Common Passwords? Sorry, That is Patented” »

6 New Password Rules

Considering the increasing attention passwords have been getting lately, I thought it was about time we sit down and establish some new rules to define exactly what is a password. After all, so much of our personal lives, finances, and identities rely on these obscure jumbling of letters, numbers, and punctuation.

1. Password, 1234, letmein, and anything else that you see on this common passwords cloud are not passwords.

Recently I took my son over to a friend’s house and when we got there we found he lived in a gated community that required a PIN to enter. My son was about to call his friend when I told him, “I got this.” I reached over and entered 1234 and the gate promptly swung open. Yeah my son was very impressed at my hacker skills, but the fact is that 1234, 12345, or even 12345678 are not strong enough to be considered passwords.


2. If you google your password and get more than 10,000 results, it is not a password.

It’s really simple, if your password shows up that many times in Google, your password is not a password it is a dictionary or common wordlist word.

3. If your password is 8 characters or less, it is not a password.

An 8-character password just isn’t strong enough these days to be considered a password. Most 8-character passwords consist of a dictionary word or name with a couple numbers added to the end. These are incredibly easy to crack and will not stand up to a brute force attack no matter what type of encryption used. If your password is 8 characters long, you might have a PIN, but it certainly is not a password, which is probably why banks seem to love limiting password length to 8 characters. I recently explained just how much of a difference there is between an 8-character password and a 10-character password, but maybe this would illustrate it better:

8 Character Password

This is the equivalent of an 8-character password

6 Character Password

This is the equivalent of a 6-character password











4. If you use it on multiple sites, it is no longer a password.

Considering the huge number of passwords hacked and dumped on the internet every single day, I would hope that most of us have learned that you simply cannot reuse the same passwords on multiple sites. You are better off never even considering using the same passwords everywhere because it is easy to fall into that habit.

Just to illustrate why this is such a big deal, there are people such as me who collect passwords. Here is a list of all the passwords I have for the username bonehead. Now if I know that there is a user named bonehead on a web site, I can try all of these passwords and chances are surprisingly good that one of these passwords is correct. Why is this such an effective technique? Because everyone reuses their passwords on multiple sites.

5. If a password is older than 3 years, it has expired and is no longer a password

I know some of you get really attached to your passwords, but it is time to start using a password manager and changing those very old Hotmail and PayPal passwords.  You wouldn’t eat 3-year old food, so don’t use a 3-year-old password.

6. If you tell someone your password, it is no longer a password

Certainly sometimes it is necessary to share an account, but there is no excuse for telling someone your personal passwords, and this includes writing them down and sticking them on your monitor. If you have trouble doing this, one trick is to set your password as some phrase that reveals some highly personal or embarrassing fact you would never tell anyone–problem solved!

So come on people, we really can make passwords that really are passwords. Passwords don’t need to be totally random and they don’t always have to have numbers, capitals, and punctuation, but they do need to be long, unique, and secret!





My Advice: Just use a Password Manager

For years I have advocated using long, memorable passwords using a variety of different memorization techniques. Humor, repetition, common suffixes, memorable phrases, and other methods are great for creating long passwords that are easy to remember.

But now my philosophy has changed: now I say just go ahead and use a password manager and generate long, random passwords for each online account.

While I still use my own easy-to-remember passwords for sites where I often need to enter passwords manually, the bulk of the passwords I create now are long, random passwords that LastPass generates for me. Even five years ago it was possible to manage and memorize ten or twenty unique passwords, but the world has changed and it is not uncommon for a typical web user to have dozens if not hundreds of online accounts.

With so many large web sites becoming victims of public account dumps, it is now more important than ever that you never reuse the same password anywhere. Tools such as LastPass or KeePass make the process of creating, managing, and entering passwords so simple, there is hardly any reason not to use one of these tools.

Yes, you can come up with fancy patterns or methods of creating unique passwords for each site, but it just is not worth the effort and pattern-based passwords tend to be shorter than they should be. Passwords are more vulnerable to attack than ever; you should never create a password less than 10 characters but use 20 or more if the system lets you. Managing this many strong, unique passwords is almost impossible to do now without the help of a password manager.

Yeah, I kind of miss making new clever passwords, that was always the fun part of creating new accounts. On the other hand, it is still kind of fun seeing how long a password each web site lets me create. My record so far: 128 characters, and it was a dumb recipes site.



Analyzing the XKCD Passphrase Comic

I rarely see any discussion of password strength without seeing th XKCD comic below brought up to illustrate that a long pass phrase is better than a shorter random jumble of characters. Since this is something I have been arguing for fifteen years, this is something I do agree with, although adding a little more randomness and complexity is still necessary.

XKCD: Password Strength

(XKCD: Password Strength - Creative Commons Attribution-NonCommercial 2.5 License.)

In 2006 I wrote Pafwert, a random but smart password generator, to illustrate this concept. Pass phrases are easier to remember, easier to type (we type in whole words), and are generally much stronger passwords. My philosophy has always been that length is more important than any other factor for password strength.

But not everyone agrees. Most often the argument against the pass phrase technique is that since the password is made up of 4 whole words, basically this isn’t that much different than a 4-character password, you just need to adjust the brute-force tools to work with whole words instead. While this is somewhat true, it doesn’t take much to turn this technique into something extremely effective.

How Strong are Pass Phrases?

To determine password strength, we generally determine how many passwords have similar characteristics. In other words, if finding a password is like finding needle in a haystack, the critical question is how big is that haystack?

To do the math on this, we need to determine how large a set of words the average English-speaking user would likely choose from. Some English language dictionaries include well over 150,000 words but most linguists agree that the average-intelligence English speaker has a vocabulary of somewhere between 7,000 and 15,000 words.

What is misleading about these numbers is that dictionary words are only a small part of our vocabulary. Consider these other non-dictionary words:

  1. Proper nouns such as McDonalds, Lady Gaga, Instagram, JQuery, and possibly hundreds of thousands of other words that are part of our daily vocabulary.
  2. Domain names like,, and thousands of others.
  3. Popular slang and social jargon (see your average Facebook post).
  4. Alternate spellings, leetspeek, etc.
  5. Acronyms such as WWW, CISPA, SSN, WWII, and SMS.
  6. Words from other languages
  7. Programming language elements and function names
  8. And don’t forget written-out numbers, you will never find “1,276,209″ in a dictionary and there are millions of those.

Forget dictionary words, our vocabularies are HUGE.

So how many actual words do we know? It is impossible to say but a very conservative estimate would be a minimum of about 25,000 words. Realistically this number is much higher than this but we will use 25,000 here just for illustration.

Now if we are picking 4 random words from a set of 25,000 words the number of possible combinations is 25,0004 or  390,625,000,000,000,000 (noted as #1 on the table below) which is about the strength of a 9-10 character alphanumeric password (see this chart). But passwords are case-sensitive and we often capitalize one of the words so realistically we are talking about 50,000 words or 50,0004 or  6,250,000,000,000,000,000 possible combinations (noted by #2 on the table below) which is about as strong as a 10-11 character alphanumeric password.

What’s interesting to note is that even a 3-word phrase results in 125,000,000,000,000 possibilities so even that would be roughly equivalent to a 7-8 character alphanumeric password which is the most commonly-seen password.


Making Them Even Stronger

Now most people have already developed techniques to make passwords stronger by adding some numbers or otherwise mutating that word so that it would not appear in a dictionary. That is why we often see passwords like dr@gon or freddy2000. Now these are very weak passwords by themselves but if you use this same technique in a pass phrase you can make them much stronger.

Remember, we are dealing with numbers that grow exponentially so a technique that is mediocre with a short password is incredibly effective with a long password.

Now consider the following pass phrase:  Picking at 200 p1ckles

Or this one:  I’m alway sthe first

Or this one:  How bout the 0xFC?

It’s a simple technique and a minor change but by doing this we have greatly expanded our 50,000 words. Many password cracking tools are very good at generating word permutations and can very quickly create and try hundreds of variants of a single dictionary word. But when you multiply that times 4 words, the numbers grow very fast.

Say, for example that for each of our original 25,000 words there are approximately 100 different mutations. That means we now potentially have a vocabulary of 2,500,000 words. And 2,500,000^4 equals 39,062,500,000,000,000,000,000,000 possible combinations of 4-word phrases (shown as #3 on the table above) which is stronger than a 14-character alphanumeric password.

So yeah, the XKCD recommendation is valid. And all you have to do is add a few simple mutations to make that method incredibly stronger.

93% of the Top 10,000 in the LinkedIn List

I would like to welcome LinkedIn to the not-so-exclusive club of major web sites that have experienced major password leaks. Like any other major leak it is hard to visit any forum or tech blog without seeing some mention of it. And like any other leak my inbox is starting to fill up with press requests for comments.

But what is interesting here is that there’s nothing interesting here. It’s the same thing we have seen so many times in the past and surely will continue to see.

One thing that highlights this, brought up to me by blogger Johnvey Hwang, is that 93% of the passwords in my Top 10,000 passwords list appear in the LinkedIn hashes dump. Here it is in his words:

I was curious as to what percentage of the most common passwords were present in this dump, as a proxy for gauging the password choices for a supposedly more professional population. A quick search led me to security guy Mark Burnett, who maintains a list of the top 10,000 most used passwords across the internet. He admits to some skew caused by a significant amount of sourcing from adult websites, but I don’t think it really matters.

The fact that such a large number of the LinkedIn passwords appear on the top 10,000 list certainly does help validate my data but more importantly it shows that despite all we have learned, very little has ever changed.

Here are some other interesting facts Johnvey discovered about the list:

  • 7,142 of the most common passwords were present
  • 546 of the most common passwords were not present
  • 2,312 of the most common passwords were too short for LinkedIn’s 6 character minimum

I think that 93% is an amazing number, yet again, the biggest story here is that nothing really has changed.



I personally have three LinkedIn accounts that I maintain. None of those three passwords appear on the list. Apparently the list is not complete, but the question now is what criteria put those particular passwords on the list.