1 |
On Wed, Feb 17, 2021 at 3:01 AM Dale <rdalek1967@×××××.com> wrote: |
2 |
> |
3 |
> I suspect a lot of users are going to be moving from Lastpass because of |
4 |
> this change. If their service was far better then people may pay it. |
5 |
> Thing is, it isn't. As was pointed out in a couple things I read, they |
6 |
> have been hacked in the past. What was taken was encrypted but still, |
7 |
> they got hacked. |
8 |
|
9 |
So, while I echo most of the sentiments in this thread already so I |
10 |
won't repeat them, I do try to be careful about how I look at past |
11 |
reports of hacks. |
12 |
|
13 |
Important considerations are: |
14 |
1. Why were they hacked? |
15 |
2. What did they do when they were hacked? |
16 |
3. What were the consequences? |
17 |
4. What is likely to happen in the future? |
18 |
|
19 |
When it comes to security the future is much more important than the |
20 |
past. We look at the past as a predictor of the future. However, you |
21 |
have to always keep this in mind. |
22 |
|
23 |
One thing I admire about Lastpass is that when they were hacked, they |
24 |
immediately went public with it, disclosing at all times what was |
25 |
known and explaining the impact to customers as best as they |
26 |
understood it. They took steps to get users to change passwords/etc |
27 |
which would protect them if the encrypted data was cracked in the |
28 |
future. The way they handled the incident definitely made their |
29 |
customers safer. |
30 |
|
31 |
Likewise as best as anybody can tell the consequences of the breach |
32 |
were very limited. They ensured that customer vaults had solid |
33 |
encryption, which gave them defense in depth - the breach of the |
34 |
encrypted data wasn't able to be leveraged into a breach of the |
35 |
unencrypted password data inside. |
36 |
|
37 |
These should both be seen as factors in their favor, and it is the |
38 |
sort of thing that you can't really see until somebody is actually |
39 |
hacked. |
40 |
|
41 |
I think one of the more concerning issues for their future was the |
42 |
change in management when logmein bought them. I think people had |
43 |
concerns about the new management. |
44 |
|
45 |
I definitely like that bitwarden is FOSS. One concern with ANY of |
46 |
these web-based tools is that while they may very well be securely |
47 |
implemented, the fact is that the actual code is remotely managed. At |
48 |
any time somebody who obtains control over their infra could push out |
49 |
updates that cause your client to compromise your data in a number of |
50 |
ways. This requires more sustained control than just a quick snatch |
51 |
of the encrypted cloud password store, but it is definitely a risk, |
52 |
whether the code is FOSS or not. After all, Gentoo is FOSS, but if |
53 |
somebody was able to gain control over the repositories/keys/etc they |
54 |
could push literally anything in an update to your system, and unless |
55 |
you're looking very carefully at your ebuilds you could have arbitrary |
56 |
code running as root in no time. Obviously that is something infra |
57 |
and the portage design tries to make unlikely, but it is definitely a |
58 |
threat model really for any software distribution of any kind. The |
59 |
automated nature of updates to these cloud-based password managers |
60 |
makes these sorts of attacks potentially easier to pull off (though |
61 |
I'd they would have resources dedicated to detecting a compromise like |
62 |
this and mitigating it). |
63 |
|
64 |
-- |
65 |
Rich |