[HN Gopher] How did LastPass master passwords get compromised?
___________________________________________________________________
How did LastPass master passwords get compromised?
Author : bmichel
Score : 235 points
Date : 2021-12-30 09:31 UTC (13 hours ago)
(HTM) web link (palant.info)
(TXT) w3m dump (palant.info)
| rexreed wrote:
| Out of curiosity the meaning of "credential stuffing" doesn't
| jibe with what I would assume the term would mean. Why isn't the
| more obvious "password reuse" term not preferred? I would assume
| credential stuffing would mean something to do with pushing a
| bunch of credentials into a system and overloading the credential
| system somehow, rather than simply being "reusing a password that
| was found on a third party site".
| yellowstuff wrote:
| "Credential theft occurs when attackers breach a system and
| steal users' access credentials -- usually ID and password. The
| ID is most commonly the user's email address. Credential
| spilling is when those credentials are made available to other
| criminals. Credential stuffing is the large scale use of
| automated means to test stolen passwords against other
| unrelated websites."
|
| https://www.securityweek.com/credential-stuffing-successful-...
|
| The term "credential stuffing" is a bit counterintuitive for me
| as well, but I guess it fits the pattern of credential attacks.
| "Password reuse" has other meanings, so would be less precise
| as a technical term.
| rexreed wrote:
| The use of obscure and unintuitive terms would seem to hurt
| the objectives of security proponents to explain how systems
| have been compromised. If you tell me my credentials were
| "stuffed", I'm going to assume it was some technically
| sophisticated attack using some exploit or system
| vulnerability. If you tell me my password was simply stolen
| and posted on a website, and they're just brute force trying
| the password on all the systems, I'm going to know that my
| password has been compromised and some cybercriminals are out
| there using bots to try them everywhere.
|
| In the first, case, I'd feel less empowered to do something
| about it. In the second case I'd be more aware of all the
| databases with old passwords in it and never reuse a password
| twice. (if that's what's happening).
| jcrawfordor wrote:
| I agree that the security industry has a problem with
| inventing new terms when they don't contribute to
| understanding. I do think there is some nuance here though
| to "credential stuffing" vs "password reuse" - credential
| stuffing is a description of the _exploit_ while password
| reuse is the _vulnerability._ In other words, password
| reuse is a user behavior that doesn 't directly cause
| unauthorized access. "Credential stuffing" is described
| from the perspective of the service provider, which sees an
| attacker "stuffing" many thousands (often hundreds of
| thousands over time) of credentials into their product to
| see if any of them work. Of course only a tiny fraction do,
| but that's enough to create a big problem. It's usually not
| clear where the stuffed credentials came from, it may be a
| check to see if compromised passwords from other websites
| were reused, but more often credential stuffers just try a
| "top 100" password list against every user they can
| enumerate---so password reuse per se or a compromised
| credential list may not even be involved, just use of
| common passwords.
|
| Researchers will sometimes modify services to log password
| attempts in plaintext in order to try to determine where
| stuffed credentials are coming from, but for obvious
| reasons it's not advisable to do this on a "real" service,
| so it's usually hard to know exactly what's going on---
| although the set of attempted usernames can sometimes give
| you a good hint, for example it's not at all unusual to see
| credential stuffing attacks where the attacker hasn't even
| enumerated users and is just trying common usernames. Some
| of these common username lists are kind of eccentric and
| you can recognize which one an attacker is using by some of
| the odder entries on it. I've had instances where googling
| a particularly weird username out of authentication logs
| just turned up exactly the perl script the attacker was
| using, uploaded to some compromised webserver where Google
| got wind of it somehow. I assume the username list it was
| using was originally from some real system but had been
| copypastad until it no longer had any relation to the
| original source. A lot of common password lists are like
| this as well.
|
| The term "credential stuffing" should be viewed as a term
| of art and not used in communications to the public, but I
| do think it's useful because it describes a phenomenon
| which is different from, and may or may not involve,
| password reuse by users.
|
| As a semi-related but amusing anecdote, there was for a
| time a fairly large-scale SSH credential stuffing effort by
| a botnet whose operator had made a mistake and mixed up the
| "username" and "password" fields in their credential list.
| Many SSH servers saw thousands of attempts with various
| usernames like "letmein123" and password "root" or "admin".
| I suspect the actual root of the problem was that they'd
| concatenated credential lists, not realizing they were in
| different formats. They may have even gotten the credential
| list that way, these things get passed around in really
| haphazard ways.
| sunshinekitty wrote:
| I stopped using lastpass a couple years ago now due to ill-
| communicated master password leaks, ever-rising fees, and buggy
| UX.
|
| This seems par for the course, I can't imagine any credible
| company or keen user actually using lastpass at this point.
| simooooo wrote:
| rob74 wrote:
| Don't know about the fees, but I fully agree about the buggy
| (and confusing) UX. I certainly wouldn't use it if my employer
| didn't force me to...
| herodotus wrote:
| Update: https://blog.lastpass.com/2021/12/unusual-attempted-
| login-ac...
| 40four wrote:
| What are the chances these emails were actually sent out in
| error, like Lastpass claims? It's not in-plausible, but I also
| take it with a grain of salt.
|
| To be fair to them, I don't think we've seen any reports of folks
| password DBs _actually_ being compromised. Just a lot of presumed
| failed attempts.
|
| If the e-mails _were_ sent in error, then it's all much to do
| about nothing. If the master passwords were actually compromised,
| then the system still successfully protected the clients password
| assets.
| joenathanone wrote:
| For whatever it is worth, the same day people started getting
| the emails someone attempted to login to both my outlook.com
| account and Steam account using the correct passwords and I got
| a 2FA alert, that has never happened before and then the next
| day I also got an alert from Lastpass.
|
| Could be some crazy coincidence but what Lastpass is saying
| isn't adding up.
| unicornfinder wrote:
| Sums up my feelings really. I genuinely think that what they're
| saying is probably true, that these emails were sent in error
| (and I have to say I don't envy their teams at all in having to
| deal with the fallout from this), but it's also entirely
| understandable that many people will have been justifiably
| spooked to the point where they probably won't continue to use
| their services now.
| wubbert wrote:
| This is exactly why I have never used LastPass, and have always
| stuck with KeePass (and KeePassXC). It is much more secure to
| keep all of my passwords locally than in the cloud.
| SavantIdiot wrote:
| This argument has never made sense to me. Keeping an encrypted
| password file in the cloud or locally makes no difference.
| There exists no computer system than can crack an AES256
| encrypted document. The weaknesses are in the protocol. Storing
| the encrypted database in the cloud and downloading it is the
| same as storing it locally if the decryption protocol is
| performed locally. If the decryption was done in the cloud I
| would agree with you, but that is not the case, so the two are
| the equivalent.
| md_ wrote:
| > There exists no computer system than can crack an AES256
| encrypted document. The weaknesses are in the protocol.
|
| Well, or in the human-chosen passphrase. There are plenty of
| systems that can brute force an 8-character alphanumeric
| password run through PBKDF2 for 100,000 rounds.
|
| Per https://support.1password.com/pbkdf2/, that costs...about
| $60k.
|
| So keeping the ciphertext safe is in fact a very reasonable
| precaution, especially if you have a fairly short input
| passphrase or are not using a ton of rounds of key
| stretching.
| twicetwice wrote:
| I simply use a 40ish character passphrase. My primary
| attack vectors are keyloggers/local malware and
| browser/extension vulnerabilities, which also apply to a
| local ciphertext.
| SavantIdiot wrote:
| You are correct: if the password used to create the key is
| trivial, then there definitely exists hardware that can
| guess AES256 passwords even if a KDF is used weakly.
|
| I'm not sure how to read that table. Is that really the
| cost for a 100,000 iteration PBKDF2?!?
| md_ wrote:
| I have not checked 1Password's math--they just come up in
| the results for "PBKDF2 cost of brute forcing". ;)
|
| But yes, it matches my intuition--brute forcing human-
| strength keys is surprisingly cheap. (And I don't know if
| they're taking into account the discount if you have
| custom ASICs for this, defend against which is the
| argument made for scrypt instead.)
| Sebb767 wrote:
| > Storing the encrypted database in the cloud and downloading
| it is the same as storing it locally if the decryption
| protocol is performed locally.
|
| The problem is that, with web-based password managers, you
| are not only downloading the database, but also the code to
| decrypt it. A locally installed Keypass requires your PC to
| be compromised, whereas for LastPass it is sufficient for
| their servers to be compromised (while not avoiding the
| problem if you are compromised, either).
| afiori wrote:
| The main feature that cloud solutions provide is the ability to
| share passwords to specific teams and users within an
| organization.
| AnIdiotOnTheNet wrote:
| Even then there are locally hosted solutions like
| VaultWarden.
| ryanjkirk wrote:
| PassBolt comes to mind.
| jmull wrote:
| > "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 decided on the conclusion before any
| analysis was done.
| ViViDboarder wrote:
| The additional justification there seems to ring true to me at
| least. If you had machine access, why not download the database
| from the "trusted" (compromised) machine? Why not extract the
| plain text passwords when they unlock their vault? How would it
| impact users who hadn't logged into their accounts in years?
|
| Malware doesn't seem to fit to me.
| jmull wrote:
| Consider if you have key logger logs you'd like to profit
| from. What do you look for? Login credentials is a good
| idea... which login credentials should you target? Password
| manager credentials seem like a good idea, since that gives
| you full login details for anything else else you might want.
| gruez wrote:
| But if that were true you'd expect a bunch of other account
| compromises?
| smorgusofborg wrote:
| If it is a group accumulating passwords via extensions it
| would make a lot of sense to me if they planned to sell them
| like credit card data on bulletin boards.
|
| I don't think individual financial accounts would sell that
| well without really knowing if you have the necessary
| associated email accounts, etc to delay detection of a fraud.
|
| I also don't think such groups are necessarily sophisticated
| enough not to have someone slip up at stage 2 of their plan,
| give away a few accounts to boast, etc, etc.
| helloworld11 wrote:
| I never trusted or used LastPass and others of this type for this
| very reason. Powerful passwords created by a single central
| expert source? Sounds great, very secure, except for the little
| tiny detail of that source being broken wide open despite its
| claims of excellent security. It's impressive how many supposedly
| tech-oriented people on this very site and its comments I've
| frequently seen recommending such an obviously insecure way of
| keeping you private stuff protected. This not to mention the
| possibility of collusion with certain alphabet agencies.
|
| It's like data management in general: If you don't uniquely,
| personally control it, you don't really control it.
| jeremyjh wrote:
| For the majority of people it is still better than the only
| alternative they would actually use: using the same password in
| a lot of different websites. This way there is only one company
| that can completely compromise you, instead of dozens.
| dang wrote:
| Ongoing related thread: _Unusual login activity was due to bug_ -
| https://news.ycombinator.com/item?id=29737973
|
| Recent and related:
|
| _LastPass Login Attempted Activity Blocked - More Information_ -
| https://news.ycombinator.com/item?id=29731317 - Dec 2021 (12
| comments)
|
| _LastPass says no passwords were compromised following breach
| scare_ - https://news.ycombinator.com/item?id=29723319 - Dec 2021
| (68 comments)
|
| _LastPass users warned their master passwords are compromised_ -
| https://news.ycombinator.com/item?id=29716715 - Dec 2021 (313
| comments)
|
| _Ask HN: How did my LastPass master password get leaked?_ -
| https://news.ycombinator.com/item?id=29705957 - Dec 2021 (508
| comments)
| NickBusey wrote:
| Just one of the many reasons I self host my password manager.
| Bitwarden hosted via HomelabOS.
| Dedime wrote:
| This whole LastPass kerfuffle has solidified my choice to
| continue using FOSS + self hosted password managers only. If my
| passwords get stolen, I'd rather be responsible for the loss than
| wait for a company to put out a squirrely statement.
| yonixw wrote:
| I was self-hosted enthusiast myself, until I found out that
| self- _updating_ is not fun, not always compatible and thus not
| secure*. And therefore, I take the hard pill of SaaS even if
| security wise, it is hard to swallow.
|
| *Not secure: It will always catch you off guard, and will
| require a lot of work, so you will postpone it which is, not
| secure.
| bth wrote:
| I've received the email about login attempt from
| replies@m.lastpass.com even though I've removed my account 24h
| before that. When I try to login, I'm getting an error that my
| account doesn't exist. Maybe this is a phishing attack after all.
| ptmvp wrote:
| Same thing happened to me. I contacted support and they
| confirmed my account had been deleted, but I'm still uneasy..
| [deleted]
| SavantIdiot wrote:
| I use a YubiKey with LastPass. But it seems that still wouldn't
| help with "pass the hash", correct?
| mizzao wrote:
| I've found LastPass to be increasingly buggy and less reliable as
| time goes on. Do they have security problems as well? Should I
| switch to a different service as a paying customer (for me and my
| family?) If so, any recommendations?
| palant wrote:
| I've written about their security story a while ago here, not
| much has changed since AFAIK:
| https://security.stackexchange.com/questions/45170/how-safe-...
|
| The trouble is that the majority of their competitors isn't
| great either. I used to recommend 1Password, but another
| knowledgeable security researcher isn't really fond of them.
| mattwad wrote:
| Been using Bitwarden and it works great, at least for
| personal use. And Authy for 2-factor
| jumperabg wrote:
| Were there any breached sub-accounts/credentials?
| syvanen wrote:
| So this blog seems to completely ignores LastPass statement from
| 2021-12-28:
|
| > 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.
|
| Source: https://blog.lastpass.com/2021/12/unusual-attempted-
| login-ac...
|
| Source2:
| https://twitter.com/troyhunt/status/1476296988001849345?s=21
| softwarebeware wrote:
| Well...the word "likely" is a weasel word and not very
| comforting.
| palant wrote:
| I haven't seen it when I wrote the article. However, the
| formulation is vague enough that it could mean anything. Maybe
| the alerts were sent out by mistake which would be good news.
| But they don't quite say that. Their statement might also mean
| that they rather disabled legitimate alerts so that people
| don't get concerned. So they might have "cured" the symptoms
| without addressing the actual issue.
|
| It certainly isn't reassuring that they keep talking about
| credential stuffing, even though it's quite unlikely to be the
| culprit here.
| tuwtuwtuwtuw wrote:
| What's the difference between "triggered in error" and "sent
| out by mistake" then? In this context they seem like the
| same..
| palant wrote:
| The difference is the word "likely" which means as much as
| "we have no idea."
| [deleted]
| Ansil849 wrote:
| LastPass's statement is extremely vague. _Why_ were these
| alerts triggered in error? What error triggered them?
| tuwtuwtuwtuw wrote:
| The lack of that specific information doesn't make it vague
| in my view.
|
| If I tell to that the world appears to be shaped as a globe
| then that statement isn't vague just because I don't explain
| _why_ it appears shaped as a globe.
| aflag wrote:
| It's vague because we don't know why you consider it to
| appear to be a globe. Did you fly in a rocket and saw it or
| do you just think that round is the perfect shape and God
| wouldn't create the world in any other way?
| tuwtuwtuwtuw wrote:
| That's not what the word vague mean though. If you make
| up your own definitions of words then it's not worth
| discussing with you.
| Ansil849 wrote:
| This isn't some abstract argument about your view of the
| world. This is a blogpost about a potentially very serious
| system fault. Customers want to know what the root cause of
| the fault was, so that they can evaluate whether to
| continue to do business with the company or not. It's very
| cut and dry.
| _aavaa_ wrote:
| That statement is too squirrelly for me to trust if my
| passwords were stored with them.
|
| "SOME of these security alerts" "were LIKELY triggered" "HAS
| BEEN solved" (Emphasis mine)
|
| How can the issue be definitely solved if you aren't sure that
| they were actually triggered in error, if they were in error
| then it's only some of them.
| contravariant wrote:
| I've definitely used that exact wording when ALL of the
| problems were DEFINITELY triggered by something but I still
| didn't fully understand how.
| singlow wrote:
| I think they are sure they triggered some of the errors.
| However they may not be able to identify which ones were
| caused by their bug and which ones were legitimate attacks,
| which probably happen at some rate each day.
|
| If you are a customer, and you received this message, you
| should definitely change your master password and probably
| rotate your stored passwords. You don't know if your email
| was real or not.
|
| However, it explains why so many users were getting this
| message recently in a plausible way, that is not too hand-
| wavy except for their dodgy track record. Its not the level
| of transparency I would expect from Mozilla or even Reddit,
| but its par for the course.
|
| You should probably migrate to another password store. I
| moved away a while ago for other trust reasons, but this
| particular incident on its own is not that concerning to me.
| cortesoft wrote:
| That is the wording they have to use, right? They can't be
| certain that ALL the people who have seen these emails are
| caused by the buggy email notification code... I am sure some
| legitimate notifications were also sent out during the time,
| so how would they know if any of those were caused by
| something else?
| dwattttt wrote:
| It's not the wording they could use if they were sure that
| at least one alert was sent in error; then they wouldn't
| say it was likely, they'd say they know there were
| erroneous alerts. As it is, they're just speculating the
| alerts were wrong, which bodes very poorly.
| md_ wrote:
| It's easy for me to imagine how you get here.
|
| - Eng are still writing the postmortem
|
| - Marketing want to put out a statement
|
| - Eng know or suspect a bug exists that can trigger spurious
| notifications, but don't have sufficient logs to be able to
| reconstruct if that bug was in fact in play in production
|
| - Legal advises not to say anything definitive that they
| can't stand behind later
|
| I don't see any of that as particularly damning or malicious.
| "We aren't yet sure, but have a suspicion and are still
| investigating" can come out like the LastPass blog post when
| run through the PR filter.
| shkkmo wrote:
| Then why not say:
|
| "We have identified and fixed bugs that could result in
| incorrect masterpassword use notifications being sent but
| we have not yet been able to determine which if any of the
| recent wave of notifications were caused by those bugs. We
| are still investigating the issue".
|
| Instead of communicating clearly around a serious security
| incident they are using mealy mouthed PR speak which does
| nothing to improve their image.
| md_ wrote:
| Sure, I'm with you, but this is pretty par for the course
| on incident comms.
| ajb wrote:
| No, they say "As a result, we have adjusted our security
| alert systems and this issue has since been resolved."
|
| They are claiming they know what the bug was.
| mcguire wrote:
| Not necessarily. That could be read as them simply
| turning off the alerts (ideally, until they figure out
| and fix the bug).
| joenathanone wrote:
| They *need* to go into great detail if people are
| supposed to trust them with their digital life. That
| statement isn't nearly enough.
| foobiekr wrote:
| After all the problems with lastpass, who was even
| trusting them at this point?
| joenathanone wrote:
| I could see if you were a big company, trying to migrate
| a bunch of users and retrain them on a new password
| manager would be costly, there are probably admins out
| there looking for any reason not to make the move, but at
| this point, I think they have lost all credibility.
| _aavaa_ wrote:
| Be that as it may, which I have my doubts about since they
| are quite definitive about the problem being solved, I
| don't want a PR filter from the company that I would trust
| with my passwords.
|
| What I want to know is have I been compromised or not, the
| PR saves face at further expense of users (if they truly
| have been compromised).
| tuwtuwtuwtuw wrote:
| > What I want to know is have I been compromised or not,
|
| They have been extremely clear that they have not found
| any signs of compromise. Did you miss that?
|
| Of course no company can technically guarantee that they
| have not being compromised. If you are looking for
| someone telling you at any point they are 100% confident
| no user accounts have been compromised, then you will
| pick a company lying to you.
| aflag wrote:
| They should be able to explain why so many people
| received the email though. Was there a fault in the
| notification system or not? Are they going to send
| messages to the individuals which received the
| notification in error?
|
| I get that direct evidence of a leak is difficult.
| However, a sudden surge of master passwords being known
| by third parties in uncorrelated accounts is a very good
| evidence that something happened. If that's not what
| happened, then what happened exactly? Was it really a bug
| in the notification system? Do they have evidence that
| the password used in the blocked login attempts weren't
| really the actual master password?
|
| There is a lot of things they can do to show they are on
| top of things.
| tragictrash wrote:
| combine that with lastpass' history of security mistakes,
| the people in on hn claiming that they didn't reuse the
| master password, and the press releases gas lighting
| their users, I'm not buying their story for a second.
| _aavaa_ wrote:
| I did not miss that. But it's harder for me to read that
| as a technical statement and not more PR after the rest
| of the PR.
|
| I also agree with you about the 100% confidence about not
| being compromised. Perhaps my previous statement was too
| black/white. I don't want PR or placating statements, I
| want a transparent status report without weasel words and
| which exhaustively covered the different cases (e.g. SOME
| of the messages were sent in error. what about the rest?
| Are the rest routine compromises that happen normally? Or
| was there a spike in compromised accounts?)
| [deleted]
| abarringer wrote:
| "likely" "some", weasel words. Corporate marketing speak for we
| have no idea what happened so dream up some scenario that
| sounds plausible and do a press release.
| dehrmann wrote:
| Some of the emails were probably real, and they just happened
| to have been when there was supposedly a issue. That can't
| part be definitive.
| willis936 wrote:
| Which is exactly what you say when facing an existential
| crisis. If you have a master password leak you either:
| 1. lie about it and the truth never comes to light 2. lie
| about it and get caught and the consequences are the same as if
| you came clean
|
| If LP suffered a master password leak then there is no benefit
| to telling the truth.
| imwillofficial wrote:
| Except earning trust with the customer, in a line of business
| that is built entirely on the customer trusting you to manage
| things properly.
| mgraczyk wrote:
| One advantage of telling the truth is that you don't go to
| prison for fraud.
|
| When evaluating this kind of conspiracy theory, it's
| important to consider the number of people who would have to
| remain silent for the conspiracy to survive, and to consider
| how much it would cost to keep that many people silent. In
| this case, it's at least a few dozen so I think it's fair to
| assume that such a lie would not survive very long.
| jjav wrote:
| > In this case, it's at least a few dozen so I think it's
| fair to assume that such a lie would not survive very long.
|
| This is a very unlikely expectation. Employees are under
| NDA so nobody will talk publically about it unless one of
| them feel so strongly about it to sacrifice their career
| (they'd certainly get fired, and being sued for breaching
| the NDA isn't going to make finding a new job easier).
|
| Employees at all companies keep quiet about bugs like these
| all the time, that's the most common outcome.
| devwastaken wrote:
| Tech companies are not held liable by the justice
| department or any other federal org. It's against their
| interests because they now depend on these services to
| operate. Which is why you will never see Amazon, Google, or
| Microsoft sued in any damaging capacity for the obvious
| fraud they commit. That being fake products, reviews,
| promoting scams, antitrust, etc.
| paulcole wrote:
| you'd need a microscope to see the overlap in the vein
| diagram of people who lie at work and the people who go to
| prison for lying at work.
| imwillofficial wrote:
| This is broken thinking built on faulty assumptions. There
| are countless examples of massive conspiracies and secrets
| never leaking.
| nmca wrote:
| Can you provide some? I have previously only heard
| "santa".
| noah_buddy wrote:
| JFK, 9/11, and Epstein spring to mind for major
| conspiracies. I think anyone with a head on can see the
| government bodies tasked to investigate those affairs
| were rife with conflicted interests, duplicitous
| individuals, and some intent that they should be as
| narrow investigations as possible. Those secrets have
| been kept or at the very least the limited hangout worked
| so well that people think only nuts question them.
| imwillofficial wrote:
| Sure, I do contracting work for the military. There are
| hundreds of millions of secrets kept every day with
| hundreds of thousands of people keeping their mouths
| shut. Leaking is exceedingly rare.
| atty wrote:
| You have not provided any evidence or examples, just a
| "trust me", which is essentially worthless. Also, there
| is a difference between a secret and a conspiracy.
| Secrets can survive for a long time, whereas history
| suggests that conspiracies rarely, if ever, succeed long
| term.
| imwillofficial wrote:
| Well, you know that the military has a lot of secret
| stuff you know nothing about right? Let's use Area 51 as
| an example. Leaks like Snowden or Manning are a drop in
| the bucket compared to the total amount of secrets that
| were not leaked.
|
| As far as examples of successfully kept secrets, I can't
| give those, because I'm in on it.
|
| All a conspiracy is, is a group of people keeping a
| secret.
|
| As far as conspiracies not being successful long term,
| history tells us no such thing. Conspiracies with tons of
| people are successfully kept every single day, only to be
| discovered decades later when something is declassified
| for example.
|
| You can never prove if a conspiracy to keep a secret is
| not successful if you never knew it existed.
|
| Am I making any sense?
| colejohnson66 wrote:
| The military has a much bigger threat of prison for
| _yourself_ than a company that the investors sue
| imwillofficial wrote:
| Oh absolutely. My point was strictly the assumption that
| many people can't keep secrets. Depending on ideology,
| reprisals, or personal ethics (good and bad), secrets can
| be kept by a startlingly large group of people.
|
| I've seen estimates as high as 10% of the population of
| east Germany were spying on their neighbors.
| colejohnson66 wrote:
| I agree. Humans like sharing things, even if they
| shouldn't. We're bad at keeping secrets. I was just
| making the point that your claim of leaks in the military
| isn't _necessarily_ comparable to a leak about a company.
| You do have a point about the large numbers of service
| members - that would raise the chances of something
| happening.
| aflag wrote:
| They are indeed different. But if they were compromised,
| it doesn't mean that all employees there know. It would
| probably be a handful of engineers only. Maybe one day
| one of them will make a blog post with all the details,
| however, there are more incentives to keep their mouths
| shut than otherwise. If they come publicly about this,
| they will get a lot of unwanted exposure (which most
| people don't like), they will certainly lose their jobs,
| they will have to talk about that in every job interview
| they do, they will likely get sued due to NDA breaches,
| etc which will actually prevent them from being hireable
| in many places (specially security firms). So, it's much
| easier for these people, if they morally object this, to
| just quit, find another job and move on. They'll likely
| tell their friends and family not to use lastpass, but
| that will only travel so far.
| tragictrash wrote:
| enron maydolf haliburton its literally everywhere you
| look
| mgraczyk wrote:
| Those all broke, that's how you know about them
| dreae wrote:
| Then how do we have the examples?
| imwillofficial wrote:
| I'm not sure I understand your question. Can you state it
| in a different way?
| tibbetts wrote:
| A few dozen, most of whom took a job at a security firm and
| one might imagine are the type reluctant to maintain a lie
| like this.
| jazzyjackson wrote:
| The consequences of "Mea Culpa, please reset your master
| password" seem much less existential than denying and
| eventually being revealed as untrustworthy.
| jonny_eh wrote:
| > eventually being revealed as untrustworthy
|
| Replace "eventually" with "maybe".
| ohyeshedid wrote:
| I'm curious how that balances with everyone sharing random IP's
| from attempted account access. Where did those addresses come
| from? Why are users seeing them? Did the bug they're talking
| about cause bad data to be pushed to users dashboards?
| tuwtuwtuwtuw wrote:
| Several people have reported that if you tried to log on from
| a new IP with incorrect master password, then you got an
| email saying that someone tried to log on using your master
| password even though that was not the case.
| ohyeshedid wrote:
| I was referring to the IP's being shown to users.[1]
|
| So then; Is the bug also responsible for pushing bad data
| to the users dashboards? If this is really a bug, it's a
| complicated one. I'd be curious if those IP's are still
| being shown on the users end.
|
| [1]: https://news.ycombinator.com/item?id=29705957
| tuwtuwtuwtuw wrote:
| What "dashboards" are you referring to? I have not seen
| any dashboards in LastPass.
|
| Why would it need to be a complicated bug? It could be as
| simple as:
|
| If UnkownIP OR InvalidMasterPassword Then
| LogAndSendNotication
|
| Instead of:
|
| If UnkownIP AND InvalidMasterPassword Then
| LogAndSendNotication
|
| Please tell me why it needs to be a complicated bug.
| ohyeshedid wrote:
| I don't have a link handy, nor currently familiar with
| LP's site or extensions:
|
| The part of the site that shows the recent connections to
| your account, with IP's. People were sharing those IP's
| and thoughts in the linked thread.
|
| That data came from somewhere; if it's related to this
| bug then this bug is also pushing incorrect data into
| other parts of the service. It's also entirely possible
| that it wasn't a bug, and instead a security issue, and
| that data is correct, and they're bending words to play
| it off as just a bug.
|
| I can understand a bug triggering a warning system, but
| when it's also presenting related data in the account
| security logs; it's either a complicated bug or there's
| more to the story.
| tuwtuwtuwtuw wrote:
| > it's either a complicated bug or there's more to the
| story.
|
| I showed you pseudo-code which could trigger this issue.
| It was trivial code which could cause it in practice. Yet
| you claim it must be complicated or more to the story. I
| have no idea why you feel that classifying a request in a
| certain way must be caused by a complicated bug - very
| strange.
|
| I think you're into FUD-mode now because even after being
| shown wrong, you continue to spread misinformation.
|
| Also, you are referring to LP functionality which to my
| knowledge doesn't even exist, and when asked you say you
| don't know the software being discussed.
|
| Very strange behavior by you.
| ohyeshedid wrote:
| Your example would've caused a much larger response, no?
| By most accounts, it didn't trigger for most users, so a
| simple flub like that should've triggered on more
| accounts.
|
| I'm viewing this through the lens of multiple days of
| differing social groups poking at this, and the
| crowdsourced information that's yielded.
|
| > ...shown wrong, you continue to spread misinformation.
|
| You haven't shown anything wrong: neither of us know what
| actually happened. nor am I spreading misinformation, nor
| making statements as to what happened; I'm questioning
| it. Is there some reason you're so accusatory?
|
| > Also, you are referring to LP functionality which to my
| knowledge doesn't even exist, and when asked you say you
| don't know the software being discussed.
|
| [1]. I haven't touched LP in, ehhh, 10ish years, and it
| was a feature even back then.
|
| [1]:
| https://support.logmeininc.com/lastpass/help/lastpass-
| accoun...
| SloopJon wrote:
| 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/
|
| 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-...
| 42jd wrote:
| When I was doing some research into building an app that
| encrypted data similar to these cloud password managers, I
| encountered OPAQUE[1] which seems to be the ideal way to
| perform authentication and securing a master encryption key. It
| is an asymmetric PAKE that also has a step for providing a
| salt. This removes the need to do what LastPass does with
| treating the first hash as a password. There is a great article
| from Cloudflare on how it works[2], and a working
| implementation of the spec in rust[3].
|
| [1]: https://github.com/cfrg/draft-irtf-cfrg-opaque
|
| [2]: https://blog.cloudflare.com/opaque-oblivious-passwords/
|
| [3]: https://github.com/novifinancial/opaque-ke
| stingraycharles wrote:
| Which to me begs the question: then why hash client-side at
| all? What are the threats it protects against?
| chrisfosterelli wrote:
| This sort of scheme is common so that you do not have to
| share the encryption key with the provider. You derive two
| keys from your plaintext password: one used for
| authentication and one used for encrypting / decrypting the
| blob. This way, Lastpass can authenticate you without having
| to see the key to decrypt your data.
|
| Not sure the specifics of how lastpass implements this but
| this is a really common approach for end-to-end encrypted
| apps.
| necovek wrote:
| I wouldn't say it's so you don't have to share the
| encryption key with your provider (you achieve that with a
| separate encryption key), but rather so you can use a
| single memorable secret for both login to the provider and
| local encryption.
|
| As in, the idea is that it is used to save you from having
| two secrets which might be more or less easy/hard to
| remember.
|
| It's a UX improvement (which might be a security
| imorovement _on average_ too).
| stingraycharles wrote:
| Oh I see, so the master password is like a seed for
| multiple things: the password hash, but also e2e encrypting
| the passwords.
|
| That makes complete sense, thank you for the answer.
| chrisfosterelli wrote:
| No problem! If anyone is curious for more on this
| pattern, Firefox Sync had a great blog post breaking down
| their implementation:
| https://hacks.mozilla.org/2018/11/firefox-sync-privacy/
| foobiekr wrote:
| Hashing client side has a non-cryptographic benefit of making
| all passwords a fixed length. This, in turn, helps avoid
| accidents with bcrypt misuse.
| SavantIdiot wrote:
| From what I understand: you still need the master password
| locally to decrypt the individual passwords. A hash won't
| provide that. All you're doing here is logging into LastPass.
| 8organicbits wrote:
| 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 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.
| faeyanpiraat wrote:
| But then malware on the user's machine could catch that
| password.
|
| There is no 100% solution to this.
| 8organicbits wrote:
| Different problems need different solutions. I don't think
| I've ever seen a solution that solves 100% of all problems.
| This doesn't stop me from trying to improve security where
| I see opportunity.
| benlivengood wrote:
| Use client TLS certificates and let the browser handle
| credential management, including at-rest encryption. Or use
| FIDO2 hardware. There are many options available but for
| probably familiarity reasons the vast majority of users and
| browsers didn't go down that path, and neither did website
| owners.
| 8organicbits wrote:
| I've only seen client certs used in contexts where an IT
| department assigns them to employees. Has anyone had
| success with these on public facing websites?
|
| Extra hardware seem cool, but I've also rarely seen people
| using them. I'm guessing the added cost is a deterrent.
| grogenaut wrote:
| before the current wave of password managers most people
| didnt use more than one password. they made it easy
| enough for people to use. now theyre everywhere. the
| things you list above are the new oddball ui issues,
| smooth them out a but amd people will use them too.
| chrisfosterelli wrote:
| There's little security advantage to doing this other than
| some obscurity, because a well informed attacker can still
| implement all the same attacks:
|
| * An attacker with access to the database will know they can
| reduce the "hashing algorithm" to two sequential hashing
| algorithms and still bruteforce a series of plaintext
| passwords to check to see if the hash matches what is in the
| database.
|
| * An attacker with access to the plaintext network
| communications or app server can just store and replay the
| second hash to login
|
| * An attacker with access to the client machine can grab the
| plaintext password still
|
| Lastpass does this is for end-to-end encryption reasons,
| where it is useful, but for standard apps I don't think it
| would be.
| yuliyp wrote:
| It does prevent inadvertent logging of passwords, though:
| no piece of software on the server side will have the
| user's password in memory at any point. Which does mean the
| user's actual password (if they're reusing passwords) stays
| more secure (by "more secure" I mean "has a lower
| probability of leaking to a malicious actor", not
| necessarily "has some additional security properties").
| chrisfosterelli wrote:
| Ah yes that's a good point. It can still leak the
| "password" that's used for authentication so it doesn't
| protect their account on that service but logs wouldn't
| leak the original password that might be reused elsewhere
| so it could protect their account on other services
| marginally more.
| 8organicbits wrote:
| If we add client side hashing, it does nothing to prevent
| hash replay attacks. Agreed.
|
| However, it prevents the attacker from immediately trying
| the same raw password on other sites (i.e. credential
| stuffing). They would need to perform additional offline
| attack of the first hash. This adds cost to something that
| would have previously been trivial.
|
| Given that about 65% of users reuse passwords and 76% don't
| even use a password manager [1], I think that slowing down
| credential stuffing attacks is important.
|
| Protecting against some attacks is valuable even if you
| don't protect against all attacks. Layered security.
|
| 1. https://services.google.com/fh/files/blogs/google_securi
| ty_i...
| chowells wrote:
| Your analysis seems to overlook an important detail in that
| first bullet point - dictionary attacks are only feasible
| when the KDF is fast. Authentication servers tend to
| require the KDF to be fast so they aren't constantly
| performing a denial of service attack on themselves. What
| people are looking for is a way to make the combined KDF
| slow by pushing most of the work to the client side. If
| this succeeds, you have made dictionary attacks very
| difficult without making your authentication process a
| denial of service vector.
|
| The web browser ecosystem makes this a pretty hard task,
| unfortunately. You need fallbacks that weaken the process
| to the point where it is basically useless in a lot of
| cases. But the goal of a client/server split in the KDF is
| actually quite sensible. The client side does the large
| amount of work to protect users from dictionary attacks.
| The server side does a relatively much smaller amount of
| work to protect itself from being easily exploited if its
| hashes are exfiltrated when the hashes aren't themselves
| vulnerable to dictionary attacks.
| chrisfosterelli wrote:
| This is an interesting point. I'd be inclined to ensure
| that the server side hash is still _at least_
| independently expensive enough as would be desirable for
| plain text, but then using the client side hash to go
| above and beyond computationally seems reasonable to me.
|
| I would wonder though -- there's obviously a practical
| limit on user experience for waiting for computation, and
| is there really fast enough implementations available to
| the browser within that limit that would foil what a
| dedicated attacker could compute in proper hardware for a
| dictionary attack? You'd also have to consider if it's
| really _that_ expensive to just throw more hardware at a
| server side hash. I guess it 'd depend on the browser,
| whether the attack is targeted, and how big the
| attacker's budget is that you're considering.
|
| Either way, if this was the goal and the team considered
| those factors then still felt it was worth the effort of
| doing so I would think it seems reasonable, though it's
| probably not something I'd make standard practice in my
| own apps.
| chowells wrote:
| Yeah, I can't really justify using this in browsers
| because their capabilities vary so widely. Logging in
| shouldn't take 10 minutes on a 5-year-old feature phone.
|
| But I can see using a split KDF for some high-security
| system where the clients all have a known minimum spec.
| necovek wrote:
| Everything you explain points at no need to do client side
| hashing: what exact attack vector would be stopped by having
| it? (The only thing you bring up is reuse of passwords, but
| then you explain how that would be easily exploited if server
| was compromised, and it's even easier if client is)
|
| I would imagine most developers unfamiliar with encryption
| would assume that client hashing is sufficient and not bother
| with server side hashing which is the only one that ensures
| privacy in case of compromise on the server side (nothing
| really stops client side compromise).
| kodah wrote:
| WASM will do what you want.
|
| You can certainly have client side JS produce a hash using
| some other credential as the salt and then encrypt the
| information server side. What you _really_ lose is the
| ability to do low cost comparison, because most password
| hashing is done deterministically. Instead you would need to
| retrieve the record, decrypt with the server side key, and
| finally compare.
| palant wrote:
| 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.
| wwkeyboard wrote:
| They claim to have 30,000,000 users but we've only seen a
| handful of reports about this, why such a small percentage?
| Wouldn't someone with a full list of passwords want to
| exfiltrate as much data as possible before it became obvious
| they had the creds?
| WarOnPrivacy wrote:
| There are ways this scenario could manifest. The person
| submitting the passwords could have purchased them on the
| darkweb and may be figuring out how to use them. We'd be
| seeing the trial+error part of their learning curve.
| palant wrote:
| First of all: I don't think that all accounts are affected.
| For example, my own account didn't receive this message.
| Assuming that indeed a logging server was compromised, we
| don't know under which conditions the password hash is
| logged. Maybe it's only people who used the web interface to
| log in, or only people who changed their master password, or
| people who hit a particular error condition.
|
| Second: People only notice the failed login attempts. I don't
| know what exactly this attack looks like, but I doubt that
| the point is triggering these alerts for as many people as
| possible. They rather want to log in successfully, meaning
| without any alerts being produced. Who knows how often this
| happened without anybody noticing?
|
| Finally: We only know about people who were concerned enough
| about these alerts to write about it on Hacker News (or in
| some cases Twitter). That's a tiny fraction of all LastPass
| users.
| f38zf5vdt wrote:
| Whoever first gets a hold of the password hashes would need
| to bruteforce individual entries or cross-check them against
| known leaks for reuse, which takes time. It's natural that
| they would only go after high value targets like famous
| people, cryptocurrency users, etc, then resell the database
| after they got as much value out of it as possible.
| jacquesm wrote:
| Good write up. They have been in full PR deflection mode rather
| than to actually engage those users to which it apparently
| happened in dialogue to try to nail down the root cause and
| were much too quick with their denial of their own involvement
| for that to be believable.
| WarOnPrivacy wrote:
| There might be a cluster of old accounts in play and perhaps a
| smaller cluster of newly created or newly changed accounts.
| This hints at the possibility of more than one bad actor.
|
| It's possible the old accounts could be some old stock sold on
| a darknet forum and are being bundled in with the newer
| hashes/pwds. It's also possible that the entity harvesting the
| newer hashes/pwds isn't the same one who is amateurishly
| attempting to access the accounts.
|
| Note: Lastpass's geolocation may be off (even more than usual
| for geolocation) as some of the IPs are in ownership dispute
| and all of them may be for VPNs.
| palant wrote:
| Yes, the sample is rather small to draw conclusions from. The
| biggest concern however are the people who got the
| notification again after changing their master password. It
| just doesn't make sense if credential stuffing is what we are
| talking about.
| trajcek wrote:
| Thanks for writing this up! After reading LastPass' very vague
| response, they did not inspire confidence for me to stick
| around as a paying customer.
|
| I am unsure if this is too small of a compromise for them to be
| able to a) care or b) spend resources on investigating or that
| they just don't know what's happening.
| palant wrote:
| It's vacation time, they simply don't have the people on site
| to investigate the issue quickly. So far not surprising, and
| certainly intended by the timing of this attack.
|
| That their first reaction is to downplay rather than to admit
| that they don't know much yet - that's rather typical of
| LastPass unfortunately. Sadly, with this approach they aren't
| exactly an outlier in the industry.
| overlordalex wrote:
| 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 compromised by an unauthorized third-party as a
| result of these credential stuffing attempts, nor have we found
| any indication that user's LastPass credentials were harvested
| by malware, rogue browser extensions, or phishing campaigns.
|
| > 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.
|
| [0] https://blog.lastpass.com/2021/12/unusual-attempted-login-
| ac...
| palant wrote:
| The formulation is vague enough that it could mean anything.
| Maybe the alerts were sent out by mistake which would be good
| news. But they don't quite say that. Their statement might
| also mean that they rather disabled legitimate alerts so that
| people don't get concerned. So they might have "cured" the
| symptoms without addressing the actual issue.
|
| It certainly isn't reassuring that they keep talking about
| credential stuffing, even though it's quite unlikely to be
| the culprit here.
| WarOnPrivacy wrote:
| >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 rate an email). It
| isn't fully spelled out tho.
|
| LP spends most of the blogpost going on about bad user
| practices - which feels a lot like gaslighting in this
| context.
|
| edit: I'm leaning toward accepting LP's incomplete, forced
| explanation and that hackery isn't in play here.
| GavinMcG wrote:
| > 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 response to the full login, which of course wasn't
| blocked. The former seems more likely to me.
| tialaramex wrote:
| I agree that it's more likely review misses a change that
| results in spurious "Correct master password" emails than
| say, a change that lets people log in as you without the
| correct password.
|
| 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?
| marcosdumay wrote:
| > LP spends most of the blogpost going on about bad user
| practices - which feels a lot like gaslighting in this
| context.
|
| 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.
| kurthr wrote:
| You say that the LastPass protocol is subject to hash replay
| attacks (my description). I'd be surprised if there wasn't some
| time dependent pepper (e.g. challenge/response) in the hash,
| since this seems like a huge vulnerability, and storage of the
| hash allows for off-line attacks. Normally, I'd think diffie-
| hellman for this.
| palant wrote:
| No, there is nothing. The complication with
| challenge/response schemes is that the server doesn't know
| the master password - it only has that one hash, so it's
| always comparing against it. There are PAKE protocols which
| work around this issue, but LastPass didn't implement any of
| them (probably for historical reasons already, I think
| LastPass is older than most of these approaches).
|
| Normally, it isn't such a huge vulnerability. TLS encryption
| is there, so nobody should be able to catch that hash in
| transition. And even if they did, the most sensitive data is
| encrypted so that you still need the master password. Still,
| this is rather suboptimal.
| InspiredIdiot wrote:
| Can you explain how PAKE would help here? Going just off
| Wikipedia, it is a key-establishment protocol "based only
| on their knowledge of a shared password". So I would expect
| that the shared password is the master password or its hash
| and the parties are the user and the LP server. So wouldn't
| using PAKE require the server to know your master password
| or its hash? That sounds the same as before. Is the idea
| that they both know the hash only transiently (instead of
| the server knowing it persistently as it does today) and
| then establish some other key which they use after that?
| palant wrote:
| No, modern PAKE protocols work without the server
| actually knowing the password. The server has a
| "verifier" that lets them tell whether the client's
| response to a given challenge is correct. I'm no expert
| on this topic but
| https://blog.cryptographyengineering.com/2018/10/19/lets-
| tal... is a good start.
| goldcd wrote:
| I'm suddenly very grateful for Lastpass wanting to charge me, and
| me leaving
| joenathanone wrote:
| I moved when they raise their prices, I just wish I had deleted
| may account....
| skarz wrote:
| Passwords were NOT compromised.
|
| It is hackers using existing compromised email/password
| combinations on brute force attempts at Lastpass.
|
| That is why your Lastpass password should be a password that you
| have not nor will ever use on any other site.
| jerf wrote:
| I'm not sure we can concretely say there was no compromise.
|
| However, at the moment I'm not satisfied that a compromise has
| been demonstrated, either. As near as I can tell, nobody has
| reported a _compromise_ , just suspicious emails. That's not
| enough evidence to prove a _compromise_.
|
| LastPass' response, so far, adequately covers what we've
| actually seen.
| latortuga wrote:
| Plenty of folks who reported getting this email from LP,
| including myself, reported that they used a strong unique
| passphrase for LP only.
| tuwtuwtuwtuw wrote:
| LastPass wrote that there was a bug causing these emails to
| be sent.
|
| That may be correct, because several persons have reported
| reproducing that issue before the LastPass fix - they have
| written that they logged on with incorrect password while
| using an IP from another country and still got the email that
| their master password was used.
| roozbeh18 wrote:
| OP blog suggests users receiving similar email even after
| changing their master password. two possibilities for LP.
| either their servers were hacked and hashed master passwords
| were dumped somewhere or as LP said, system error due to a bug.
___________________________________________________________________
(page generated 2021-12-30 23:00 UTC)