Hi Jeff,

Thank you for contacting us. While I'm not entirely sure how data is stored in LastPass, from what I've read, one of the big problems is that the data stored in their cloud system was only encrypted with the user's account password. Now I say this admitting I don't know their security model in full, I only know very little based on some articles I have read. If indeed the user's data was literally encrypted with only the user's account password, that could cause many problems for people with weaker passwords. The biggest problem is that a weak password can be cracked within minutes using a brute force attack.

The main differentiation between mSecure's and LastPass's security model is that mSecure does not encrypt the user's data with their account password. You can find more details about our security model here: mSecure’s Security Model - Secure by design

The short explanation of the article above is that the data stored in mSecure, both locally and in the cloud, is not secured with your account password. Instead, every account has what is known as an account key, which is a very long and totally random key. This key is used to encrypt your data and is never stored in your mSecure account or anywhere in our system. This, like LastPass claims for their system, is a "Zero Knowledge" architecture. In other words, we do not have the information to get access to any of the data stored in the mSecure Cloud, or anywhere else for that matter. The only one who has the information necessary to decrypt the data is the user who owns the account. The problem in LastPass's case is having zero knowledge about a weak password does not make a user's data secure from server breaches. Sure, the company doesn't know what key was used to encrypt the user's data, but the key is so weak that it only takes seconds or maybe a few minutes to successfully brute force attack the weak encryption.

To guard against brute force attacks, rainbow tables, etc., the account key in mSecure is a totally random, computer generated key. It's incredibly strong and is not tied to the user's account password in any way. The account key is only delivered in an encrypted form when you first set up your account, so it is never sent in a readable, non-encrypted format. To respond directly to the LastPass breach, our system was created so that even if the mSecure Cloud was hacked, the data stored in it is impervious to brute force attacks. Not that we wouldn't notify our users (we would notify everyone), but if the data was stolen, there is realistically no way it could ever be used, because the encryption is as strong as it is. Even with the fastest of computers, it would take millions of years to figure out the encryption key through brute force. Since the keys are random and computer generated, rainbow tables have no effect on the security. The only way to break through the encryption, which is provided by AES-256, is to simply guess at it again and again until the data is decrypted. There are simply no shortcuts to readable data if you can't decipher the account key used to encrypt the data.

No problem at all Jeff. Please do let me know if you have any other questions.

@JW Thank you for your input on this. I was not aware of the other security issues LastPass had. Knowing all what we went through to create our account / cloud system, it's really unbelievable to me there was ever a system created that wasn't fully covered by AES-256 (or some other highly trusted, commercially verified encryption algorithm). Again, I'm no expert on their cloud system, but some of the things I have read, if true, are quite eye-opening.

For your question, we use an open source cloud server called Parse, so, like most, we didn't engineer the account system. You can find out more at https://parseplatform.org/ if you're interested in that type of information. Parse uses "bcrypt" for the user's account password security.

@JW For the Parse Platform, the GridStoreAdaptor is actually deprecated functionality. Can you explain what you're hoping to have accomplished by having that feature enabled?

Also, for bcrypt, we use the settings that Parse offers by default, and the number of rounds are determined programatically. In looking at the code, I can see that the work factor will always be greater than 10. In the end, we don't rely on bcrypt nor the strength of your mSecure account password to protect your information. If your account password is strong, then it will be safe with the bcrypt hasing applied to it. If it's weak, like "12345" or "password" or some other short number sequence or normal dictionary word, nothing will be able to protect that password.