By targeting large numbers of users, attackers increased their chances of success.
See full article...
See full article...
Dashlane explains how attackers managed to download encrypted password vaults
- Thread starter JournalBot
- Start date
Unfortunately changing the main password won’t do any good if they already have the data encrypted with the old one. Only changing the individual passwords for the services will help. This is why I prefer to keep my password database off someone else’s server.
Upvote
61
(75
/
-14)
Yes, exactly. That's the reason for the advice to also change "the contents of any of the recovered Dashlane vaults."
Upvote
46
(47
/
-1)
Upvote
-2
(7
/
-9)
Unless I'm missing something, it will prevent the threat actor from downloading and decrypting the vault all over again. Yes?
Upvote
50
(52
/
-2)
Wasn’t their ability to download the database dependent on brute forcing the 6 digit code, not the master password? If they could do it again, changing the master password would prevent them from decrypting it again, if they figured out the password the first time. So maybe some limited benefit there. But if they’re able to do this twice (or even once), it’s probably time to use a different password manager.
Upvote
19
(21
/
-2)
I won't argue with that. But I'd also posit that it would be a major mistake for the 20 affected users not to change their master password.
Upvote
55
(55
/
0)
That's fair, but honestly this makes me feel a bit reassured about it, given:
I've always taken it as a given that any vault is at risk, but I've also taken it as a given that my strong password and the encryption on it would protect it probably for the rest of my life but at least long enough to change all my passwords. At least in my own life the #1 risk factor for me in the past was re-using passwords, which almost let someone into a retirement account, and that got stopped by 2FA (another important lesson!). So yah, risk, convenience, personal risk assessments, all that play into what people are comfortable doing.
Maybe if they checked "remember this device" or "don't prompt for a code" then they'd "just" need to crack the password. But Dashlane needs to change it so that you don't get the vault with just the code. I don't remember how BitWarden works offhand, but I feel like you need to log in (with a password and 2FA) before you can do anything.
edit: well obviously Dashlane will have canceled those nefarious device registrations too so that wouldn't work. So yah, definitely an overabundance of caution.
Last edited:
Upvote
19
(19
/
0)
It sounds like everything worked as it should in this situation, which is refreshing for once. They only got a minute number of vaults before being locked out, and cracking the vaults is complex enough that the users can change all the passwords before it's probable they are cracked. Can't ask for much more without going to post-it notes.
Upvote
45
(46
/
-1)
I agree. But strangely, Dashlane's incident write up does not include any instructions to the 20 affected users. Almost all of its FAQ is directed at unaffected users which makes it very confusing to read. I guess since the victim pool is only 20 users they think its fine to put remediation steps in direct communication with them.
Upvote
9
(10
/
-1)
Man, am I glad that when I finally decided to take the 'password manager' plunge as a systems admin that I elected to not use a cloud based keystore.
KeypassXC + Syncthing for the win.
KeypassXC + Syncthing for the win.
Upvote
-5
(13
/
-18)
Too much hassle on the mobile devices.
Been using 1Password for over a decade and its been rock solid. Not saying it cannot be breached, but I am comfortable with the measures I have taken.
Upvote
49
(51
/
-2)
That kind of feels like the big un-asked question. Someone could just get a big list of emails and spray them all and some will be Dashlane users and most won't I guess, but some of the wording in their comments make it sound like this was targeted to their users.
Edit: one issue with the LastPass hack was that the metadata was unencrypted so the hackers could prioritize (and they seemed to have prioritized cryptocurrency). It costs real money and resources to brute force those vaults and I imagine having a large selection of random vaults actually isn't necessarily all that great since you run the risk of most of them being people's ArsTechnica logins, or even bank logins that are further protected by 2FA (and since banks suck it's probably weak SMS 2FA but your goal here was easy money, not having to start digging into people's lives to get phone numbers and stuff). I bet the targeted Dashlane accounts had something in common that made them known attractive targets.
Last edited:
Upvote
10
(10
/
0)
Exactly why I decided to go with KeePass and not with one of the hosted services.
It's validating to see the positive result of opsec and infrastructure decisions made all those years ago
Upvote
-9
(6
/
-15)
Changing all the entries within the vault would also be quite a task. I've got well over a thousand in BitWarden with a fairly significant chunk of them high risk if compromised.
Upvote
14
(14
/
0)
I don't understand why they were able to download the vaults without knowing the master passwords. I get that they were attacking the process for enrolling a new device, but I don't understand why that process doesn't require the master password prior to providing the vault. Unless they're trying to prevent the master password from ever hitting the server, so they provide the vault with a 2FA code but without the master password?
*edit: not sure why I'm being downvoted here. Not severely, but come on. It's like people can't even be ignorant of something and try to ask people who are more knowledgeable.
*edit: not sure why I'm being downvoted here. Not severely, but come on. It's like people can't even be ignorant of something and try to ask people who are more knowledgeable.
Last edited:
Upvote
15
(20
/
-5)
The master password would be hashed on your device and that's what's sent. If we don't trust that process, well, all of internet security is broken then, isn't it?
Upvote
5
(6
/
-1)
The master password is to decrypt the vault. The 2FA code is to enroll a new device so it can access the vault.
Scenario: you go on a canoe trip and your phone falls overboard. It was the one device authorized to access your Dashlane account. You get a new phone, get on your computer, contact Dashlane via your registered email address, and get them to enroll the new phone. Dashlane sends a challenge to your email, and you send the response from the new phone. Voila -- access restored.
But in this case, the attackers ignored the challenge and guessed the response, and did this across Dashlane's entire user base, with the idea that if they use the same 6 digit code, it's likely to be correct for a subset of the responses -- they don't care which customers.
Upvote
21
(22
/
-1)
Forgive this question if it seems too obvious but the brain has been a bit mushy today.
The explanation given for spreading out the attack across multiple accounts seems off.
Even if the 2FA has only 1M possible combinations (000000-999999) then even of you hit say 1000 accounts, each attempt still has a 1:1000000 chance to work not 1:1000 given that there should be enough randomness across all 1000 2FA attempts that no 2 2FA values would be the same. Account 1 2FA should have no knowledge of account 2 2FA and so on.
I understand that spreading out the attack would go under rate limiting thresholds for the request but it still seems that getting the right 6 digit combination still comes down to plain dumb luck.
I do have a few issues with how Dashlane is setup for this:
1 - 2FA valid for 3 hours, given the sensitivity of the data, that should be limited to like 10 minutes , basically a window much smaller than 3 hours.
2 - This function should be rate limited to like 3-5 attempts before lock out, even if the code is valid for 3 hours, you can't use all 3 hours to try.
3 - How many of these requests can be carried out at one time, seems like that should be rate limited as well for the function overall. After all, how many requests to share vaults seems reasonable. After meeting the limit a simple error stating this function is currently not available would suffice for most users given they could try again after some interval of time.
Is it reasonable to assume within a few minutes 1M users would want to share their vaults?
Fixing both of these would have made it even harder to get 20 vaults. Limit how long this process is available to complete before being shut out. Just document the limit, most users would not even be bothered by the limits. After all 20 is still a really big number for this context.
If I were sharing access to my vault (which I would NEVER do), the person I am sharing with is either sitting right next to me or we are on the phone at the same time and I initiate the process - not the other way around. This way I am validated as I want to share before starting the sharing process. The process would then only take a couple of minutes.
The explanation given for spreading out the attack across multiple accounts seems off.
Even if the 2FA has only 1M possible combinations (000000-999999) then even of you hit say 1000 accounts, each attempt still has a 1:1000000 chance to work not 1:1000 given that there should be enough randomness across all 1000 2FA attempts that no 2 2FA values would be the same. Account 1 2FA should have no knowledge of account 2 2FA and so on.
I understand that spreading out the attack would go under rate limiting thresholds for the request but it still seems that getting the right 6 digit combination still comes down to plain dumb luck.
I do have a few issues with how Dashlane is setup for this:
1 - 2FA valid for 3 hours, given the sensitivity of the data, that should be limited to like 10 minutes , basically a window much smaller than 3 hours.
2 - This function should be rate limited to like 3-5 attempts before lock out, even if the code is valid for 3 hours, you can't use all 3 hours to try.
3 - How many of these requests can be carried out at one time, seems like that should be rate limited as well for the function overall. After all, how many requests to share vaults seems reasonable. After meeting the limit a simple error stating this function is currently not available would suffice for most users given they could try again after some interval of time.
Is it reasonable to assume within a few minutes 1M users would want to share their vaults?
Fixing both of these would have made it even harder to get 20 vaults. Limit how long this process is available to complete before being shut out. Just document the limit, most users would not even be bothered by the limits. After all 20 is still a really big number for this context.
If I were sharing access to my vault (which I would NEVER do), the person I am sharing with is either sitting right next to me or we are on the phone at the same time and I initiate the process - not the other way around. This way I am validated as I want to share before starting the sharing process. The process would then only take a couple of minutes.
Upvote
1
(4
/
-3)
That's brilliant - if they go to threaten you with the convenient wrench, the password they need is literally at hand. No need to rely on memory, or mishearing, or whatever... just make sure it's an unambigious font.
Upvote
12
(12
/
0)
Why not have you download the Dashlane app and "log in" with your master password (which would be hashed and transmitted via HTTPS? They don't even want the hashed password on their servers?
Upvote
4
(5
/
-1)
My math teachers would like a word about randomness and probability of unrelated events.
(I'd avoid 000000 and 123456 because it's already in use for my luggage, but any random number will do, even if they all randomly happen to be the same number)
Upvote
6
(8
/
-2)
That all makes sense, but it still seems weird to me that authenticating with the password isn't part of the process to receive the vault. It doesn't seem like it would significantly complicate the process of sending the vault, and the user has to have the password to decrypt it anyway, so may as well prove they are who they say they are by having them provide the password? I feel like I'm missing something.
Upvote
6
(8
/
-2)
The service providing the vault doesn't (and shouldn't) know the vault password. You could give the service its own, different, password, but then you'd have to worry about users mixing the two up or reusing the same password for both.
Upvote
12
(13
/
-1)
That would be horrible from a security perspective because now you are letting Dashlane potentially read the contents of your encrypted vault. You don't want that to even be a possibility. The decryption of the vault and validation of the master password needs to take place on your device. A separate account password might not be a bad thing so that enrolling a new device doesn't rely only on your email address and a pin.
Upvote
17
(17
/
0)
And that's exactly why I use 1Password instead of all the other alternatives. That case and the recent LastPass data leak prove that relying only on a master password to encrypt a password vault is very, very risky. 1Password uses a master password AND a separate secret key to encrypt the vault.
1Password's security design continues to be proven right and remains the only cloud-based password manager I would use and trust. Here is their security white paper, if anyone is interested.
Upvote
15
(15
/
0)
I think you can hash the password and use it for key derivation. The service can't get your password (and thus derive a key) from your hash. I think that's the normal way to do it, like BitWarden is also zero trust but you still authenticate with the password. Deviating from norms has a bad habit of presenting new unforseen risks. Like here.
Upvote
2
(3
/
-1)
In light of recent events, I enabled 2FA with an authenticator app. No more email codes. Does this help with spraying? Not sure, as it's still a 6-digit code, but at least I can't accidentally click the "authorize" button in an email I did not request.
Upvote
-1
(1
/
-2)
If I’m reading this correctly, it’s a code sent by email, not a standard TOTP implementation that is app-agnostic.
This means that Dashlane should be able to change it to 8+ characters and maybe include letters as well.
That should be enough to mitigate this specific attack.
Interesting to see what their response will be.
This means that Dashlane should be able to change it to 8+ characters and maybe include letters as well.
That should be enough to mitigate this specific attack.
Interesting to see what their response will be.
Upvote
7
(7
/
0)
Another mitigation would be to use a Dashlane-specific email address that is not public. E.g. soomeone@gmail.com becomes someone+mydashlaneacct123@gmail.com. Or use ProtonMail's random email feature to generate a random address and only use that for Dashlane. I might move to the latter.
Upvote
7
(7
/
0)
Would a Yubikey have helped. Dashlane works with Yubikey & would require new device to be secured with the hardware key and I think could be part of the master password. Backup key not a bad idea if you like canoes.
Upvote
4
(4
/
0)
I'm sure there are ways to do it without sending the password to the service but it still seems like a bad idea. There's no reason the "account password" needs to be linked to the vault master password. If there's a problem with the hashing process or what ever process they use then it could still result in compromise of your vault master password. Much safer to just keep the master password a strictly local thing.
Upvote
5
(5
/
0)
I don't use this particular service so I don't have any insight into how it works but if the attack involved registering a new device, wouldn't mitigation necessarily begin with de-registering any unknown devices, then changing the master password, then changing the passwords recorded within the vault?
Upvote
1
(1
/
0)
The problem is that it isn't really a password. It's a decryption key.
Upvote
2
(2
/
0)
Upvote
5
(5
/
0)
I thought the same thing. And, made a similar comment in the original article. However, according to Dashlane you can't use a FIDO2 security key for 2FA. You CAN use it to protect and decrypt the web vault but that seems to leave other options such as mobile apps unprotected. I'm not a Dashlane user, and I'm not in the market for a new password manager, but this seems like a big limitation to me. I wouldn't be recommending Dashlane to friends and family until all clients and authentication can be protected by a FIDO2 security key.
If you use an online password manger I'm an absolute believer in protecting it with a hardware security key. If you sync something like KeePass XC by utilizing a cloud provider, I think that cloud provider should be similarly protected.
Upvote
2
(2
/
0)