Critics: Substandard crypto needlessly puts Evernote accounts at risk

Security experts are criticizing online note-syncing service Evernote, saying the service needlessly put sensitive user data at risk because it employed substandard cryptographic protections when storing passwords on servers and Android handsets.

The scrutiny of Evernote's security comes two days after Evernote officials disclosed a breach that exposed names, e-mail addresses, and password data for the service's 50 million end users. Evernote blog posts published over the past few years show that the company protects passwords and sensitive user data with encryption algorithms and schemes that contain known weaknesses. That is prompting criticism that the company's security team isn't doing enough to protect its customers in the event that hackers are able to successfully compromise the servers or end-user phones.

The chief complaint involves Evernote's use of the MD5 cryptographic algorithm to convert user passwords into one-way hashes before storing them in a database. Use of MD5 to store passwords has long been frowned on by security experts because the algorithm is an extremely fast and computationally inexpensive way to convert plaintext such as "password" into a unique string of characters such as "5f4dcc3b5aa765d61d8327deb882cf99." MD5 makes an attacker's job of cracking the hashes much easier by allowing billions of guesses per second, even on computers of relatively modest means.

By comparison, the use of slow algorithms such as bcrypt, which Twitter uses to protect its passwords, adds considerable time and computing requirements to the task of converting the hashes into the underlying plaintext passwords. Even when hashes are generated using cryptographic salt to add randomness—as Evernote says it does—MD5 is still considered a poor choice.

"When you can do five billion [guesses] per second on one GPU, the salting doesn't make that much of a difference," Adam Caudill, a security consultant and software developer, told Ars. "You need something else, something like bcrypt, scrypt, or PBKDF2 to slow things down so you can't do 5 billion [guesses] per second."

In a blog post from 2011, Evernote engineer Dave Engberg seemed oblivious to this well-understood truism.

"In the case of a purely back-end MD5 hash," he wrote in response to a reader challenging the MD5 choice, "any hypothetical attacker doesn’t have access to either the output (the MD5 hash) or the original input (the user’s password and our salt), so there really isn’t any productive attack based on MD5 vulnerabilities."

Of course, the attackers who gained access to Evernote servers did have the ability to read the MD5 hash, we now know. Server breaches such as the one that hit the company are precisely the reason passwords aren't stored in plaintext to begin with. By requiring attackers to crack the hashes, the practice buys the breached company and affected end users time to reset passwords before the compromised data can be used to gain unauthorized access to accounts. In the case of Evernote, much of that benefit is lost, since the use of MD5 speeds up the cracking process.

To Evernote's credit, the security team appears to have caught the compromise quickly, and the service reset user passwords before the data could be used to hijack accounts. But given the high incidence of password reuse—the average Web user maintains 25 separate accounts but uses just 6.5 passwords to protect them—the hashes exposed in the Evernote hack could still be used against tens of millions of account users unless they change the corresponding passcodes on any other sites that used them. Evernote's decision to employ MD5 means those users have less time to reset those passwords than if the site used a more suitable algorithm.

Caudill criticized Evernote for other security omissions as well. For instance, the Evernote app for Android smartphones stores user passwords in encoded form using a scheme known as XOR. As a result, hackers who gain physical access to a phone, depending on the specific model, may be able to extract the passcode in a matter of minutes and then use it to gain unauthorized access to the Evernote account. He has also released a short script that streamlines the extraction process. In stark contrast to the Evernote design, standard practices call for login credentials to be stored on smartphones as an encrypted token or as a one-way hash.

Caudill also criticized Evernote's use of the RC2 cipher to encrypt sensitive user data. RC2 fell out of favor in the late 1990s, after researchers devised a simple attack that makes it relatively easy to extract the key used to secure the underlying data.

As online services try to convince us to trust them with more and more of our sensitive data, they have a responsibility to employ state-of-the-art software and techniques to harden their systems to hacking and minimize the damage when compromises do happen. Those consuming such services would do well to follow the example of security researcher Troy Hunt and call on them to publicly disclose their password storage regimen.

In an e-mail, Evernote spokeswoman defended the security of the service.

"We think our password storage systems are secure, both in terms of the encryption algorithms and other measures, but we'll be reassessing every detail in response to this breach and will will continue to stay up to date with the technology," she wrote. "We were also planning on rolling out optional two-factor authentication to all of our users later this year and are accelerating those plans now."

Scott also said Evernote engineers are planning a "significant upgrade" to the optional client-side encryption protection for later this year. She went on to say that an update planned for later this week will remove the current password-storage mechanism in the Evernote app for Android handsets. Security permissions allow the information to be accessed only by the app itself and to those with root permissions to the device.

Promoted Comments

1) Your server will be breached...eventually and inevitably.2) Single-factor authentication must use "slow" hashes.3) Two-factor authentication will become preferred, so prepare for it now.4) Upper-management suits will cut your budget, perhaps drastically, perhaps slightly, but inevitably your ability to keep up with the latest exploit updates will fade with time. This point is likely the greatest weakness of all as the budgetary "death of a thousand cuts" is the most insidious subverting influence of all.5) Using another authentication service (e.g. Google+ Sign-In), while not a perfect solution, may be preferable to maintaining one of your own.

88 Reader Comments

As online services try to convince us to trust them with more and more of our sensitive data, they have a responsibility to employ state-of-the-art software and techniques to harden their systems to hacking and minimize the damage when compromises do happen. Those consuming such services would do well to follow the example of security researcher Troy Hunt and call on them to publicly disclose their password storage regimen.

You know, reading the title made me wonder.. since there are so many sites out there that have suffered vulnerabilities or security snafus (account data store in plaintext ala PSN, unencrypted passwords stored in plain text, weak hashing algorithms used to protect passwords, the list goes on), very technically, at least from a grammatical standpoint, to have shabby security on your site/service is perfectly normal.

When every day you hear about a new security exploit or company not doing something they would have learned in security 101, unfortunately, that has become the "standard". Sad isn't it?

There is an associated problem with this sort of breach that I haven't yet seen discussed anywhere - how many people who spend significant time on the internet actually know all the places they've got an account?

Since I saw the Evernote article earlier, I went and checked to see if I had an account there, and it turns out I do. Worse, I apparently created it way back before I entirely did away with the concept of a "default" password for accounts I didn't really care about. Now someone has that password, and it may well be in use at any number of sites I've completely forgotten I ever signed up for.

I'd be willing to bet lots of people, even people who are security conscious now, have this kind of "hole" in their past. And I don't know of a good way to address the problem. Obviously, using unique passwords (and a password manager; the lack of a good one is what caused me to have a default password five, six years ago) going forward is necessary. And cleaning up all the accounts you can think of to use a unique password.

But that still leaves some unknown number of places vulnerable, with some amount of your information there vulnerable, and no way I can think of to even begin to try and track all those accounts down.

No matter the hashing method, the strength of the password is the most important factor.

If you have a 10 character password (and let's say that it's only a mix of upper-case and lower-case letters, plus the number 0-9), they'd have potentially brute force 62^10 passwords. Event at 5 billions guesses per second which is 423 trillion passwords per day, it would still take 1942 days to brute force all of the passwords (more actually, since that assumes that you know that the password is exactly 10 characters).

Granted that doesn't mean that your password, wouldn't be among the first few trillion that are guessed.

The point is still: no matter what a hashing mechanism that a website or an application uses, it always pays to have a secure password. Even if you just take a password and pad it with zeros (e.g.: bunnies000000000000) that's still an entirely different hash and it add enough complexity to make it muc, much, much harder to crack (especially compared to just "bunnies").

Well, somebody didn't do their job correctly. I think part of the problem here is that security is something that programmers feel like they can read up on and become competent in as a side-skill, and that is becoming less and less possible. Security has evolved so rapidly and become so tricky that it is really now a specialty.

Bottom line: Now is the time for developers out there to recognize that if they have a requirement for real security, in the future they need their code reviewed by real security experts (and re-reviewed periodically, since things change quickly). Painful, but necessary, since so many times it has been demonstrated that even a tiny subtle misunderstanding of security practices is all it takes to blow a whole as big as the great outdoors in your security.

edit: That said, it is still inexcusable that a good programmer in today's world didn't know about the widely publicized problems with hashing passwords with md5. I haven't even been programming much recently and I've read at least 5 or 6 articles explaining this problem. This is not an obscure issue anymore, and there is no excuse anymore for any competent programmer to not know it. All you programmers out there reading this: look inside yourself, and if you didn't already know about this- be afraid. Very afraid.

This is ridiculous, how can programmers in this day and age still be making security errors like this and risking customers info. There's a whole wealth of information on the internet on how to do things properly and a huge number of publicized hacks to learn from...do people just not care or think about what they write any more?

That being said I commend them for quickly spotting the hack and disclosing and handling it in the right way (lockout & reset), but shouldn't have happened in the first place.

Every time I see a breach like this, it just boggles my mind that there isn't some kind of common open source 'password vault server' software that companies can run.

Such a software would have a strong design goal of never letting the password hashes out of storage, and only being reachable one user account at a time over some kind of simple, hardened interface. I'm thinking a pre-configured VM image with a stripped down distro, strong internal security, etc.

A 'passwords secured by XXXX' badge would go a long way to identifying more trust worthy sites.

Storing user passwords in a SQL database, or otherwise that also stores the rest of the site content, seems doomed to forever be exploitable to me..

The average Web user maintains 25 separate accounts but uses just 6.5 passwords to protect them

Wow, I'm so glad I just got 1password. I was bad, I was using at max 3 passwords, mostly similar, and over 50% were just using one password. Fortunately I'm not learning too late how flawed the "1 good password for everything" really is. Next step, get the wife to use it.

Since we're talking about yet another major online service that was compromised, it's an excellent reason to use an offline password manager+cloud (like KeePass+Dropbox) instead of an online one like LastPass.

If LastPass gets hacked, all your passwords are compromised. Single point of failure.

If your cloud gets hacked, the intruders have an encrypted file that they still have to crack for every user. If keepass gets hacked, they still have to break into your cloud to get the passwords. Minimum of two points of failure.

1) Your server will be breached...eventually and inevitably.2) Single-factor authentication must use "slow" hashes.3) Two-factor authentication will become preferred, so prepare for it now.4) Upper-management suits will cut your budget, perhaps drastically, perhaps slightly, but inevitably your ability to keep up with the latest exploit updates will fade with time. This point is likely the greatest weakness of all as the budgetary "death of a thousand cuts" is the most insidious subverting influence of all.5) Using another authentication service (e.g. Google+ Sign-In), while not a perfect solution, may be preferable to maintaining one of your own.

I don't understand the criticism of the Android app. If you're telling an app to remember your password then there's nothing but security-by-obscurity happening under the hood and you've committed your password (or a proxy for your password) to the phone. Whether it's XOR or AES, it must be reversible to login to the server automatically.

Yes. You're taking about brute force attacks (as neither would be in a dictionary). So it has to guess every password as the characters would be anything (e.g.: 11111111111111111 or Qas*^$df08q23#$534;1408aSD_*4).

Now if someone ran parallel cracks, one with only lower case a-z, another with lower-case and upper-case a-z, and another with lower-case a-z with the digits 0-9... etc... that would passwords with limit character sets much more volunerable.

In which case all ten-character lower-case password hashs could be cracked in a day @ 5 billion a second... why assume that everyone has a secure password, go after the low-hanging fruit first.

But in the example that you gave both have the same character sets and the same length, so they'd be equally difficult to crack.

Yes. You're taking about brute force attacks (as neither would be in a dictionary). So it has to guess every password as the characters would be anything (e.g.: 11111111111111111 or Qas*^$df08q23#$534;1408aSD_*4).

Now if someone ran parallel cracks, one with only lower case a-z, another with lower-case and upper-case a-z, and another with lower-case a-z with the digits 0-9... etc... that would passwords with limit character sets much more volunerable.

In which case all ten-character lower-case password hashs could be cracked in a day @ 5 billion a second... why assume that everyone has a secure password, go after the low-hanging fruit first.

But in the example that you gave both have the same character sets and the same length, so they'd be equally difficult to crack.

I don't think that is entirely true. If the brute force truly generated guesses randomly, you would be correct, but I don't think most of them do that. They use huge lists of common password modification rules, and padding with lots of a single character is almost certain to be one of them. So common "low entropy" strings would be checked before high-entropy strings in a good password cracker.

I don't understand the criticism of the Android app. If you're telling an app to remember your password then there's nothing but security-by-obscurity happening under the hood and you've committed your password (or a proxy for your password) to the phone. Whether it's XOR or AES, it must be reversible to login to the server automatically.

No it doesn't. There are a number of schemes that enable your phone to establish that it has/had the password but that do not allow recovery of the password. Reversibility is NOT required.

If LastPass gets hacked, all your passwords are compromised. Single point of failure.

I think you misunderstand how LastPass works -- your passwords are encrypted with your master password, and only decrypted client-side, so even if they have a breach, they still have to figure out your master password. The level of security is approximately as good as KeePass+Dropbox (though a longer term hack that allowed someone to capture passwords by re-programming the LastPass browser extensions/etc would make it less secure, admittedly, but if you use the Dropbox software, a keylogger could be slipped into that just as easily).

In stark contrast to the Evernote design, standard practices call for login credentials to be stored on smartphones as an encrypted token or as a one-way hash.

If you store creds using encryption, you have to have a key. Embedding a key in your application binary is just obfuscation, not encryption, and is functionally the same as XORing the password. And if you make the user enter a password for the key, then you might as well just make them enter their creds.

As for storing creds under a one-way hash, how exactly are you going to reverse the hash? And if you just plan on sending the hashed password, then the hashed password *is the password*, and you're storing the effective password in plaintext.

So basically, Dan doesn't know what the fuck he is talking about here. Standard practice is to NOT STORE creds on a smartphone.

Yes. You're taking about brute force attacks (as neither would be in a dictionary). So it has to guess every password as the characters would be anything (e.g.: 11111111111111111 or Qas*^$df08q23#$534;1408aSD_*4).

Now if someone ran parallel cracks, one with only lower case a-z, another with lower-case and upper-case a-z, and another with lower-case a-z with the digits 0-9... etc... that would passwords with limit character sets much more volunerable.

In which case all ten-character lower-case password hashs could be cracked in a day @ 5 billion a second... why assume that everyone has a secure password, go after the low-hanging fruit first.

But in the example that you gave both have the same character sets and the same length, so they'd be equally difficult to crack.

I don't think that is entirely true. If the brute force truly generated guesses randomly, you would be correct, but I don't think most of them do that. They use huge lists of common password modification rules, and padding with lots of a single character is almost certain to be one of them. So common "low entropy" strings would be checked before high-entropy strings in a good password cracker.

You're forgetting that a modification rule only applies to a dictionary password (how can I add a modification rule to a password that isn't in a dictionary... I have no idea what I'm applying a modification rule to).

Brute force means just that: it tries every possible password, often sequentially. It applies no additional logic, because it's guessing everything possible.

Also if your passwords are salted, then even a dictionary attack would fail, and they'd have to brute force them all.

I don't understand the criticism of the Android app. If you're telling an app to remember your password then there's nothing but security-by-obscurity happening under the hood and you've committed your password (or a proxy for your password) to the phone. Whether it's XOR or AES, it must be reversible to login to the server automatically.

No it doesn't. There are a number of schemes that enable your phone to establish that it has/had the password but that do not allow recovery of the password. Reversibility is NOT required.

The problem is that the user is not authenticating *to the phone*, but rather *to a remote server*. So the app has to present the actual login credentials to the remote server.

Just tested this myself and unfortunately it is correct:return_to=http%3A%2F%2Farstechnica.com%2F&username=spuffin&password=REMOVED&login=Login

Ionitor wrote:

daggar wrote:

If LastPass gets hacked, all your passwords are compromised. Single point of failure.

I think you misunderstand how LastPass works -- your passwords are encrypted with your master password, and only decrypted client-side, so even if they have a breach, they still have to figure out your master password. The level of security is approximately as good as KeePass+Dropbox (though a longer term hack that allowed someone to capture passwords by re-programming the LastPass browser extensions/etc would make it less secure, admittedly, but if you use the Dropbox software, a keylogger could be slipped into that just as easily).

Just because LastPass claims your passwords are encrypted with X level of encryption doesn't necessarily make it so. At least with KeePass you can look at the source and your password database to evaluate its encryption. To daggar's point, if LastPass gets hacked all hackers need to do is crack one password (your LastPass login) and then they will have access to all of your other passwords. It certainly is putting all of your eggs in one basket so even if LastPass is doing everything correctly, you better be using a damn good password.

I don't understand the criticism of the Android app. If you're telling an app to remember your password then there's nothing but security-by-obscurity happening under the hood and you've committed your password (or a proxy for your password) to the phone. Whether it's XOR or AES, it must be reversible to login to the server automatically.

No it doesn't. There are a number of schemes that enable your phone to establish that it has/had the password but that do not allow recovery of the password. Reversibility is NOT required.

The problem is that the user is not authenticating *to the phone*, but rather *to a remote server*. So the app has to present the actual login credentials to the remote server.

So yes, the scheme does in fact have to be reversible.

NO. It does not. Your point is correct if the sever interface is such that the phone emulates a person with a web form, etc. But that would be dumb. Any sane phone/server interface will be designed so that the phone can prove that it has/had the credential.

Put another way, if the only thing the server accepts is the actual password, then reversibility is indeed required. But that is a horrible server interface. Very, very bad as in "never, ever do things this way"

If LastPass gets hacked, all your passwords are compromised. Single point of failure.

[...]

I absolutely agree with your point regarding usage of password managers but I don't think that you are right about the LastPass vulnerability. As far as I understand their system, all data is stored using 256bit AES encryption and all encryption/decryption happens on the client side. The master password is stored as salted hash using PBKDF2-SHA256 - which as I understand from the article above is state of the art.

It would only be a single point of failure if any of the user data would be stored unencrypted, no?

If LastPass gets hacked, all your passwords are compromised. Single point of failure.

I think you misunderstand how LastPass works -- your passwords are encrypted with your master password, and only decrypted client-side, so even if they have a breach, they still have to figure out your master password. The level of security is approximately as good as KeePass+Dropbox (though a longer term hack that allowed someone to capture passwords by re-programming the LastPass browser extensions/etc would make it less secure, admittedly, but if you use the Dropbox software, a keylogger could be slipped into that just as easily).

You're right. I didn't understand that.

I think that the decentralized nature of KeePass is still a security benefit, since there are different cloud configurations/program versions/etc to work with, compared with the LastPass which is essentially a monoculture. That's is a smaller difference, however, compared to the one I was describing.

NO. It does not. Your point is correct if the sever interface is such that the phone emulates a person with a web form, etc. But that would be dumb. Any sane phone/server interface will be designed so that the phone can prove that it has/had the credential.

Put another way, if the only thing the server accepts is the actual password, then reversibility is indeed required. But that is a horrible server interface. Very, very bad as in "never, ever do things this way"

Let me show you how horribly wrong you are.

You protocol is to have the user authenticate to the phone, then have the phone authenticate to the server. You are correct that the user can authenticate to the phone without reversibility. However, for the phone to authenticate to the server, the app must have some credentials which it presents to the server. There is no way for the app to do so except for the app to store these credentials on the phone. However, if they are on the phone, then these app creds are only one binary dump away from being leaked into the wild.

Once the app creds have leaked, then Eve can impersonate *any user*; she just authenticates to the server using the app creds, claiming to be Bob. There is no way in your protocol to prevent this.

Well, somebody didn't do their job correctly. I think part of the problem here is that security is something that programmers feel like they can read up on and become competent in as a side-skill, and that is becoming less and less possible. Security has evolved so rapidly and become so tricky that it is really now a specialty.

Bottom line: Now is the time for developers out there to recognize that if they have a requirement for real security, in the future they need their code reviewed by real security experts (and re-reviewed periodically, since things change quickly). Painful, but necessary, since so many times it has been demonstrated that even a tiny subtle misunderstanding of security practices is all it takes to blow a whole as big as the great outdoors in your security.

edit: That said, it is still inexcusable that a good programmer in today's world didn't know about the widely publicized problems with hashing passwords with md5. I haven't even been programming much recently and I've read at least 5 or 6 articles explaining this problem. This is not an obscure issue anymore, and there is no excuse anymore for any competent programmer to not know it. All you programmers out there reading this: look inside yourself, and if you didn't already know about this- be afraid. Very afraid.

There isn't really a need for security specialists for most things. Any competent developer has known for years that MD5 is a stupid idea.

Every time I see a breach like this, it just boggles my mind that there isn't some kind of common open source 'password vault server' software that companies can run.

Such a software would have a strong design goal of never letting the password hashes out of storage, and only being reachable one user account at a time over some kind of simple, hardened interface. I'm thinking a pre-configured VM image with a stripped down distro, strong internal security, etc.

A 'passwords secured by XXXX' badge would go a long way to identifying more trust worthy sites.

Storing user passwords in a SQL database, or otherwise that also stores the rest of the site content, seems doomed to forever be exploitable to me..

It is really trivial to deal with passwords correctly. But there also are ready-made solutions in most web frameworks and Mozilla has built BrowserID, which can either be run standalone or used through Persona, the instance of BrowserID Mozilla themselves run.

Exactly. Permissions an app request from me in the first place is the *first* of many critaeria I use to decide whether I want to install an app or not. Despite all the glowing reviews of Evernote and how it was a "must-have", when I saw the permissions to which I had to agree, I abstained from installing it. People need to be more critical of the information "required" by an app before installing it, that would force them to be more behaved, but currently I suspect most people install without a care about the persmissions they grant.

There isn't really a need for security specialists for most things. Any competent developer has known for years that MD5 is a stupid idea.

I disagree only because lots of developers don't know anything about security. They might just find a library and say "hey this will do the hashing for me, sweet!" and off they go.

Sometimes even if YOU think that your code is secure, if you don't know anything about hacking you might not realize that you have plenty of volunerabilities. Even if the passwords used SHA-256, someone still managed to obtain the hashes... so there was a lack of security somewhere else too.

LastPass gets hacked, all your passwords are compromised. Single point of failure.

Please don't spread misinformation. If Lastpass gets hacked, the hackers are not not going to know the master password that you use to encrypt all of your passwords. Only you know that password. They will have an encrypted database of passwords that will take decades to decipher.

If you use one or more of the multifactor authentication methods they support, like the open source Google Authenticator, then even if they do somehow magically divine that password out of thin air they won't know your authenticator code.

Put another way, if the only thing the server accepts is the actual password, then reversibility is indeed required. But that is a horrible server interface. Very, very bad as in "never, ever do things this way"

Let me show you how horribly wrong you are.

You protocol is to have the user authenticate to the phone, then have the phone authenticate to the server. You are correct that the user can authenticate to the phone without reversibility. However, for the phone to authenticate to the server, the app must have some credentials which it presents to the server. There is no way for the app to do so except for the app to store these credentials on the phone. However, if they are on the phone, then these app creds are only one binary dump away from being leaked into the wild.

Once the app creds have leaked, then Eve can impersonate *any user*; she just authenticates to the server using the app creds, claiming to be Bob. There is no way in your protocol to prevent this.

This is why the app must present the actual user creds to the server.

I think you may be overlooking a scenario where the actual user credentials do not need to be presented to the server and yet the application doesn't need global trust: once the user is authenticated the first time, the app is provided an security token that is used by that app until the user either logs out on the device or logs into another device and explicitly logs out some/all other devices using the same user credentials.

This enables credentials to be "saved" but without persisting the real user password and without requiring the server to trust the application. Of course, if the device is compromised, the attacker can authenticate as the user until the user revokes that device's access. In this case, it's best if there's some second authentication factor required to allow password changes and/or device access revocation, and even then, if the device also grants password-free access to that second factor (e.g. email account), the user is in trouble.

Concerning keeping one's own passwords safe, I've been using Password Safe, largely because it was designed by Bruce Schneier. And with a Yubi Key, so two-factor authentication.

I do not use anything like Dropbox; I don't need it because I take a laptop almost everywhere. I understand that if my hard disk crashes without backup, I'm screwed, and if I forget my pass phrase, I'm screwed. I have good backups, including non-cloud offsite backups. I have a good pass phrase that I'm very unlikely to forget.

Sadly, I'm just now beginning the migration to full use of Password Safe.

OK, for personal safety, is there a password manager that people would recommend?

I'd prefer something offline, that would store all of my passwords, along with any additional info I would need for each site like security questions or something, in a single encrypted file that I could easily back up to a flash drive, but wouldn't have to be worried if the flash drive got lost, because it would be so well protected.

Just because LastPass claims your passwords are encrypted with X level of encryption doesn't necessarily make it so. At least with KeePass you can look at the source and your password database to evaluate its encryption. To daggar's point, if LastPass gets hacked all hackers need to do is crack one password (your LastPass login) and then they will have access to all of your other passwords. It certainly is putting all of your eggs in one basket so even if LastPass is doing everything correctly, you better be using a damn good password.

If LastPass is lying about how they encrypt passwords then they've opened themselves up to a lintany of legal problems for no good technical reasons other than to fool people. That is a ridiculous accusation.

If LastPass gets hacked and they guess your password and if you haven't tied the account to Google Authenticator (basically if you did the bare minimum to get an account), then you, quite frankly, deserve to have your passwords exposed. You probably used a master password like HelloKitty or some other such inane idea when you were clearly told at the outset that ONLY YOU know this password and that you should not pick a password that is easy to guess.

It's been awhile since I signed up for LastPass but I'd hope that at a minimum they require passwords of a certain minimum length, not all lowercase, including digits, special characters, etc.

It should be said that password strength is irrelevant in these cases. Once the server your data is on got hacked, it's been exposed. It doesn't matter if your pass was good, that sentry was simply bypassed.

Password strength only matters for encryption, say your LastPass or SpiderOak vaults. Because here, breaching the server doesn't get the attacker much.

For non-encryption web accounts, the important security measure to abide by is to use a DIFFERENT PASSWORD (and possibly username) FOR EVERY ACCOUNT. Because only then a security breach on one server doesn't cascade to possibly every other server.

That's why LastPass and 1Password are the future. Not because you should always use 16-character random passes - nobody's brute forcing an online form anyway - but because you should have 64 different passes for 64 different websites.And you wanna stay away from dumb choices like 'iloveyou' or 'letmein', just in case someone targets you specifically. Password reminders are evil, btw.

OK, for personal safety, is there a password manager that people would recommend?

KeePassX has been my best friend for years now. Word of advice though if you decide to go with it: The defaults number of "encryption rounds" is way too low (50,000) for modern computers. Increase it. A lot. The higher the better, and check when you open your file on the slowest device on which you are going to be using it if you are comfortable with the delay. I have to wait long seconds on my slower devices, but the peace of mind gained is worth the wait. Talking about it, why not, I will just kick it up again!