evilthought Wrote:Makes you wonder what else is screwed up with their software that is not yet known. This was inexcusably bad.

evilthought Wrote:Unless some fundamental weakness in AES algorithm is discovered, there is no way brute force will ever break AES if natural laws of physics are valid.

Those two statements completely contradicts each other in this context.. yet they are given about the same product.!!!

Unfortunately, you don' understand the two sentences. In the first case, they are brute forcing the *user* password (not AES key). Your password is hashed into AES key (256 bit AES password). These user passwords are not 256 bit and can be brute forced. If they are weak passwords., they could be brute-forced even in less than a second. In this case, adding hashing iterations (the process that makes user password into AES key) will slow down the brute force attack. This is so well known and basic. That's why I said how Lastpass could have missed something this elementary?

In the second case, they are brute forcing AES 256-bit key itself. That is impossible, and I am sure it will stay impossible forever. AES might (or might not) get broken, but for sure it won't be broken by bruteforce. Adding a random number (like "70" years) is pretty meaningless here.

That graph shows hashing algorithms are getting cryptographically better overtime. With the older ones , people fond collisions more easily. The newer ones are cryptographically stronger. In any case, even if there are collisions (two different passwords result in the same key), I am not sure it makes that much difference to Lastpass security. That might be a problem in other application, like in digital signature where hashing algorithm is used to verify the authenticity of a digital message (like email).

evilthought Wrote:In the second case, they are brute forcing AES 256-bit key itself. That is impossible, and I am sure it will stay impossible forever.

Is that quote supposed to mean anything? I said brute-forcing 256-bit encryption is physically impossible, and if AES is ever broken, it won't be by brute-force. If it happens, It will be due to some mathematical flaw in the algorithm, which can happen even 10 years (if it ever happens). Doesn't have to be 70 years. The hashing algorithm (which is not encryption) links that you posted have mathematical issues that result in collisions, i.e two set of inputs result in the same key. That has nothing to do with brute force, or AES encryption. That just means that these hashing algorithms should not be used to verify the authenticity of digital documents.

The so-called Landauer limit implied by the laws of physics sets a lower limit on the energy required to perform a computation of kT · ln 2 per bit erased in a computation, where T is the temperature of the computing device in kelvins, k is the Boltzmann constant, and the natural logarithm of 2 is about 0.693. No irreversible computing device can use less energy than this, even in principle. Thus, in order to simply flip through the possible values for a 128-bit symmetric key (ignoring doing the actual computing to check it) would theoretically require 2128 − 1 bit flips on a conventional processor. If it is assumed that the calculation occurs near room temperature (~300 K) the Von Neumann-Landauer Limit can be applied to estimate the energy required as ~1018 joules, which is equivalent to consuming 30 gigawatts of power for one year. This is equal to 30×109 W×365×24×3600 s = 9.46×1017 J or 262.7 TWh (more than 1/100th of the world energy production). The full actual computation—checking each key to see if you have found a solution—would consume many times this amount.

Even quantum computers (if they are even practical to build), won't be able to brute force 256 bit. They will weaken 256-bit to 128-bit, but that still remains impossible.

Now that doesn't AES can never be broken. It however can't be broken by brute force.

By early March, before this paper was released 100% password changes were utilizing 500 rounds as the default, the roll out was staged over the last 4 months where that percentage was gradually increased to reach 100% on password changes and new users. The product generally has had the capability for the last 8 months which is why you were able to utilize these new rounds without any update to all the extensions and phone apps you use, but our testing cycle was long. It was simply unlucky that the researcher didn't fall into the 500 rounds pool as the new user percentage was growing, and they've acknowledge it is currently working for them with 500 rounds on the app released last November.

We've of course been planning this roll out far longer than 8 months ago. Changes like these take a lot of time to do correctly across the large numbers of devices / platforms / OSes / phones / tablets we support. The fact that we were able to just make this live and adjustable per user to a level they feel comfortable with is a testament to all the work and planning we've been doing on this.

Since it's now adjustable for users to choose the rounds it's easy to increase the number of rounds as computers and GPUs continue to get faster which was really the point -- be ready to handle the future.

jonat Wrote:Do you have data on how often people change their master password? I don't change it on a regular basis - after all, it is supposed to be "the last password i have to remember".

We have stats on it, some do it much more than others, other not very often.

You can change your rounds without changing your master password, that was one of the key things we added: http://helpdesk.lastpass.com/security-o ... ns-pbkdf2/ that means you can continue to use the same password while gaining the benefit of making your password computationally tougher to crack.

Yes, I know that - and that's how I ran into the iOS bug if one also has the option checked to require reentry of the master password on various events. I was hoping that the fix for that would be available from iTunes by now, but no... Does the iOS app use the Apple UDID and if so, is that the holdup?

I asked because you seemed to assume that you'd get to 100% using the higher iterations through normal password turnover. That seems contradictory to the LP motto.