Export thread

Like many here, I'm a LastPass user facing many many many many password changes in my future. In trying to decode just how screwed LP users are with this latest breach, I've wondered about MFA's role in protecting our offline password vaults. Does it have one? I've heard from a colleague and read on this forum assertions that MFA will protect stolen password vaults. Yet, in several podcasts covering the most recent LP breach, I haven't heard MFA listed as a mitigation of attacks on user password vaults. It occurred to me that maybe MFA only protects us in an online attack scenario. Support for that theory is that (at least for LastPass) when offline access is allowed, and airplane mode is activated, there is no MFA challenge. I don't know if this is the case with other password managers, but I suspect that MFA can't help with offline attacks regardless of vendor. Does anyone here know for sure?

I think the only MFA that will protect your vault is the secret key system that 1Password (and only 1Password to my knowledge) uses. MFA normally will be unable to be used to add stuff to your encryption key for your vault, as they are mostly just OTP (one-time passwords). All MFA can protect you with is online attacks as you say.

Coffee said:

In trying to decode just how screwed LP users are

Click to expand...

I've posted this math elsewhere, people don't seem to believe me, so I will post someone else's math now.

If your password was longer than 12 chars, and not in a dictionary, you're probably not screwed in any way. Still, cleaning up is a good idea, but maybe you don't need to be compulsive.

Coffee said:

MFA will protect stolen password vaults

Click to expand...

I think there are two things being conflated here.

Forget about your vault master password. MFA is not going to help protect your vault. It's too late for that. But MFA might help you if your vault had a weak password and gets cracked:

For any other password, that is stored IN the vault, if it has MFA and if the MFA info is also NOT in the vault, then that password should have some extra protection because the attacker should need your MFA credential to use it.

PHolder said:

Forget about your vault master password. MFA is not going to help protect your vault. It's too late for that.

Click to expand...

Is that because MFA only protects against online attacks? In other words, don't allow offline access? Stolen password vaults aren't protected by MFA because that's just a control for access to the vault, and not decryption of that vault?

PHolder said:

For any other password, that is stored IN the vault, if it has MFA and if the MFA info is also NOT in the vault, then that password should have some extra protection because the attacker should need your MFA credential to use it.

Click to expand...

I considered storing all of my MFA info in another service. Then I thought about what a pain that would be with the initial setup and everytime I needed to change that information. Do you know anyone doing that, and have/did they keep it up for long? Maybe it's not as much of a pain as I was thinking...

PHolder said:

I've posted this math elsewhere, people don't seem to believe me, so I will post someone else's math now.

Jeremi M Gosney :verified: (@epixoip@infosec.exchange)

@plogan@hcommons.social @supernova@tilde.zone @WPalant @dchest@mastodon.social @bitwarden@fosstodon.org At a hashrate of 1 PH/s (10^15 hash calculations per second) it would take more than 1627 years to crack a random 13 character password (95^13)...

twit.social

If your password was longer than 12 chars, and not in a dictionary, you're probably not screwed in any way. Still, cleaning up is a good idea, but maybe you don't need to be compulsive.

Click to expand...

If I follow you, then the iteration count of one is enough. My two accounts were set to 100.1K iterations, but I know people that had their iterations set to 5K. I have run into anyone personally with it set to 1.

Coffee said:

Is that because MFA only protects against online attacks?

Click to expand...

A second factor is normally (as in the way it is traditionally used in the industry) applied as a means to control how you use the first factor (the password.) It's not part OF the password. So if they have an attack that lets them extract the data/service/info protected, they don't need any password or MFA to get said access. In the case of LP, they got your vault without using your password or being blocked by any MFA you had in place along side of your master password.

If you think about it a certain way, a MFA that modified the password (thus being part of protecting the vault offline) would just be part of the password, and so wouldn't actually be MFA at all.

Coffee said:

storing all of my MFA info in another service

Click to expand...

I use Authy. I dislike their attempt at lock-in, but I still like their product. It too has online synchronization though, so it could one day get hacked too, I guess. I just assume both hacks won't occur at the same time, and so I should have an opportunity to recover if I ever thought I was compromised.

Coffee said:

iteration count of one is enough

Click to expand...

In general, with a long enough password, yes. More can be better, but there comes a time where the laws of large numbers are probably protection enough. Do you really care if your password could be broken in 10x the life of the universe versus 1000x ?

NIST has rules about comparing password strengths. They are normally applied to the keys and not to passwords, but if possible password combinations get larger than 2^128 that is equivalent to what they used to refer to "bank strength". They make these assertions based on the costs involved in theoretically brute forcing a decryption. In any of these assumptions, you need to assume your attacker's strength... but you can make such ridiculously large assumptions that there isn't enough silicon in the galaxy to build that many computers, let alone enough power to run them all. These kinds of assumptions are why I say you should make a quality pass phrase that is 25+ and you'll never lose sleep about the strength of your password again.

PHolder said:

A second factor is normally (as in the way it is traditionally used in the industry) applied as a means to control how you use the first factor (the password.) It's not part OF the password. So if they have an attack that lets them extract the data/service/info protected, they don't need any password or MFA to get said access. In the case of LP, they got your vault without using your password or being blocked by any MFA you had in place along side of your master password.

If you think about it a certain way, a MFA that modified the password (thus being part of protecting the vault offline) would just be part of the password, and so wouldn't actually be MFA at all.

Click to expand...

Best explanation I've ever heard of MFA's part in authentication. Thank you!

Coffee said:

Is that because MFA only protects against online attacks? In other words, don't allow offline access? Stolen password vaults aren't protected by MFA because that's just a control for access to the vault, and not decryption of that vault?


I considered storing all of my MFA info in another service. Then I thought about what a pain that would be with the initial setup and everytime I needed to change that information. Do you know anyone doing that, and have/did they keep it up for long? Maybe it's not as much of a pain as I was thinking...

Click to expand...

There are many different forms of MFA, and some of them would be convenient to store, say, in the notes field in your lastpass entry for that account, but others, by their very nature, require something else: SMS text messages, Yubikeys, and to a certain extent, OTP, although most OTP setups invite you to 'print out and store in a safe place' a set of one-use codes, which can of course, be conveniently stored in the notes field of your lastpass entry for that account. Something else that would be convenient to store in the notes field of your lastpass entry for that account - those pesky 'security questions'. The best way to handle those questions are to make up completely random answers and store those for future reference. The worse thing to do is to actually answer things like your first car, city you got married, etc. with real answers - those can be socially engineered.

PHolder said:

In general, with a long enough password, yes. More can be better, but there comes a time where the laws of large numbers are probably protection enough. Do you really care if your password could be broken in 10x the life of the universe versus 1000x ?

Click to expand...

OK, _this_ is why I haven't sweated too much about this LP breach or those in the past. My master password is random, between 15 and 20 characters long, and has four types of complexity.

I share some client info with a coworker. The recent attention given to iteration count was beginning to concern me. He had only 5K iterations at the time of the breach. Fortunately, his password was long.

I'll make the next version of my master password even longer.

Dave New said:

There are many different forms of MFA, and some of them would be convenient to store, say, in the notes field in your lastpass entry for that account, but others, by their very nature, require something else: SMS text messages, Yubikeys, and to a certain extent, OTP, although most OTP setups invite you to 'print out and store in a safe place' a set of one-use codes, which can of course, be conveniently stored in the notes field of your lastpass entry for that account. Something else that would be convenient to store in the notes field of your lastpass entry for that account - those pesky 'security questions'. The best way to handle those questions are to make up completely random answers and store those for future reference. The worse thing to do is to actually answer things like your first car, city you got married, etc. with real answers - those can be socially engineered.

Click to expand...

Agreed. I store all of those things in the notes field. It's really the only way to retain the mountains of confidential data we need to keep on ourselves, family member, and potentially clients.