11–20 of 189 posts
That logic doesn't really make sense. Malware might make hacking LastPass accounts unnecessary, but it would still be highly desirable (one target gives you everything else).
Frankly, it feels like OP decided on the conclusion before any analysis was done.
> We then take that value, and use a salt (a random string per user) and do another 100,000 rounds of hashing, and compare that to what is in our database.
https://blog.lastpass.com/2015/06/lastpass-security-notice/
While it's true that the client-side hashing means that LastPass never sees your plaintext password, the first hash effectively becomes the password. Then it's on LastPass to treat it as such, which they claim to do by hashing it again.
Edit: another link describing the use of PBKDF2:
https://support.logmeininc.com/lastpass/help/about-password-...
> "First of all, malware provides a level of access that makes hacking LastPass accounts unnecessary. If it can intercept or extract the LastPass master password, it can do the same for all other passwords as well." That logic doesn't really make sense. Malware might make hacking LastPass accounts unnecessary, but it would still be highly desirable (one target gives you everything else). Frankly, it feels like OP dec…
Earlier quoted context omitted.
>Our investigation has since found that some of these security alerts, which were sent to a limited subset of LastPass users, were likely triggered in error. As a result, we have adjusted our security alert systems and this issue has since been resolved. This added bit hints that these emails were erroneously sent in response to the wrong password being attempted against the master account (which normally doesn't rat…
> erroneously sent in response to the wrong password being attempted against the master account This seems likely. After the original HN post, I went to delete my LastPass account as I've been using Bitwarden for several years. I initially used the wrong password, but then successfully logged in. I got the alert email in question, so either it was sent in response to the wrong password (incorrectly) or it was sent in…
It could also happen that there's always been a low frequency bug (e.g. 1 in every 50000 failed login attempts is mistakenly treated as "correct master password" and triggers email) but the nature of it was triggered more recently by some change in attacker behaviour.
e.g. imagine your bug is, if the failed login occurs just after the top of the hour, a variable somewhere has recently changed and this is mistaken as "correct master password" even when it isn't, so the email goes out. Somebody at LastPass finds this bug, it's happening maybe 2-3 times per month, no big deal, P3 give the new engineer trainee something interesting to look at in 2022.
But meanwhile bad guys discover the timeout they've been fighting resets hourly. Instead of one attempt every ten seconds per IP address in the botnet they're using to try phished credentials, they can do 360 attempts in the first 10 seconds of the hour, then do something else with the botnet for the rest of the hour. Now most of these attempts hit that bug, and suddenly dozens of spurious emails per hour are going out to your users. Ouch. Now, who is going to explain to the big boss that this is the same bug you triaged as P3 last month?
The article suggests that hashing (PBKDF2) is done client-side only, and that LastPass stores this hash directly. If true, this is very bad. However, LastPass claims that PBKDF2 is also used server side: > We then take that value, and use a salt (a random string per user) and do another 100,000 rounds of hashing, and compare that to what is in our database. https://blog.lastpass.com/2015/06/lastpass-security-notice/…
Unfortunately the only way I know how to implement that is to have the server send JS down to the browser that instructs it to perform the hashing. For certain types of compromises server side, the attacker would just modify the JS to get the unhashed password. I'd also need to fall back to pure JS hashing for old browsers (5% users?), so there's a UX concern if I perform lots of rounds.
I kind of wish there was a different password HTML field that could run the client side hashing without JS, so the browser would manage that. Ideally using different UX so the user understands they are using a "safe" password field. The end result would be to deny access to the raw password, which is likely reused on multiple sites.
Earlier quoted context omitted.
What is your opinion of the analysis from LastPass themselves?[0] It seems to have been some internal alerting that went wrong, which does happen from time to time. > Our initial findings led us to believe that these alerts were triggered in response to attempted “credential stuffing” activity [...] We quickly worked to investigate this activity and, at this time, have no indication that any LastPass accounts were co…
>Our investigation has since found that some of these security alerts, which were sent to a limited subset of LastPass users, were likely triggered in error. As a result, we have adjusted our security alert systems and this issue has since been resolved. This added bit hints that these emails were erroneously sent in response to the wrong password being attempted against the master account (which normally doesn't rat…
He spends most of the post dismissing user error. That looks very reasonable to me, as those are the most likely issues by a large margin.
I am the author of this article. I’ve kept it short, some points made there could have been expanded considerably. So if there are questions, feel free to ask here.
The article suggests that hashing (PBKDF2) is done client-side only, and that LastPass stores this hash directly. If true, this is very bad. However, LastPass claims that PBKDF2 is also used server side: > We then take that value, and use a salt (a random string per user) and do another 100,000 rounds of hashing, and compare that to what is in our database. https://blog.lastpass.com/2015/06/lastpass-security-notice/…
I wish there was a good way to implement this sort of double hashing in web apps. Doing the extra salted hash client side ensures that the value the server sees is globally unique, even when the user is reusing passwords across sites. Unfortunately the only way I know how to implement that is to have the server send JS down to the browser that instructs it to perform the hashing. For certain types of compromises serv…
There is no 100% solution to this.