[HN Gopher] I worked at LastPass as an engineer
___________________________________________________________________
I worked at LastPass as an engineer
Author : luu
Score : 369 points
Date : 2022-12-25 09:57 UTC (13 hours ago)
(HTM) web link (twitter.com)
(TXT) w3m dump (twitter.com)
| leftcenterright wrote:
| Perhaps using a pepper should be a key principle for such use
| cases?
|
| - https://dropbox.tech/security/how-dropbox-securely-stores-yo...
|
| - https://en.wikipedia.org/wiki/Pepper_(cryptography)
|
| Their payouts for reported bugs under bug bounty program have
| been very low, for a service used at the scale of Lastpass I
| believe this is just not ideal.
|
| > Points - $5,000 per vulnerability
|
| - https://bugcrowd.com/lastpass
| KMnO4 wrote:
| $5000? I think it should be in at least the same order of
| magnitude what the black market would pay for a leak.
|
| Most people wouldn't sell data for $40,000 if the bug bounty
| was $35,000. But that lastpass leak is worth many tens of
| thousands more than the $5000 (average payout of $450) offered.
| bogomipz wrote:
| The poster states:
|
| >"If you had a legacy 5000 rounds or 10000 rounds, the # of
| rounds can't just be increased server side. Changing that would
| mean a new key is derived. So older users likely still have a
| pretty low number of pbkdf2 rounds which makes them more
| vulnerable to brute forcing"
|
| Can someone say about how long would it take for an attacker to
| brute force a pbkdf2 master key with 5000 or 10000 rounds?
|
| Looking at their blog post from a few days ago they state:
|
| >"The threat actor may attempt to use brute force to guess your
| master password and decrypt the copies of vault data they took.
| Because of the hashing and encryption methods we use to protect
| our customers, it would be extremely difficult to attempt to
| brute force guess master passwords for those customers who follow
| our password best practices. We routinely test the latest
| password cracking technologies against our algorithms to keep
| pace with and improve upon our cryptographic controls."[1]
|
| Can someone say did they notify customers who had legacy accounts
| that used 5000 or 10000 iteration pbkdf2 master keys? They sure
| don't seem to mention anything remotely like that in their
| incident report.[1]
|
| In the above paragraph "best practices" is a link to the URL that
| fails to mention anything about selecting or periodically
| increasing the number of pbkdf2 iterations.[2]. If this weren't
| bad enough you are interrupted from reading their important
| incident report by a pop up asking you to sign up for their
| mailing list. Is an incident report really an appropriate place
| to use for marketing purposes? Are they really this shit of a
| company?
|
| [1] https://blog.lastpass.com/2022/12/notice-of-recent-
| security-...
|
| [2] https://support.lastpass.com/help/what-is-the-lastpass-
| maste...
| krimpenrik wrote:
| I hope LastPass wil burn. What a shitty software, besides these
| Security notifications, which Geels like is the 3th or 4th this
| year. Their software sucks to use.
|
| We work in Salesforce so lots of logins with login.sf.com. i have
| to always. 1 search credentials in plugin 2. Search credentials
| again to copy OTP.
|
| Most my colleagues miss setting the seed of OTP correctly cause
| it feels like you are done when entering but you still have to
| save it at the bottom.
|
| Lots of times it asks to overwrite (update) client X credentials
| with client Y
|
| In our admin cobsole, half of the usernames are not visible, just
| white space, so when i Need changes i need to click around and
| find that setting page, which is poor UI but then gamle on every
| whitespace to give the right permissions to user X.
|
| Moving to BW is high on my list for 6 months plus. But too busy,
| will make time to my now. Bye. Don't comment a lot but truly LP
| is one of the only pieces of software I really hate.
| vxNsr wrote:
| Ya their OTP story kinda sucks
| [deleted]
| aborsy wrote:
| You shouldn't use a weak password in your password manager, and
| rely on KDF. Even if the server is not hacked, the company could
| snapshot vaults and crack them offline.
|
| KDF is not a substitute for a good password.
| filleokus wrote:
| While I agree with you that users should have a strong master
| password, the vendor is in a really privileged position and
| could do much more than just attempting to crack vaults
| offline.
|
| Why bother with cracking the vault when you can just modify the
| javascript sent to report back the master password? Especially
| if you only do targeted attacks, and/or heavily obfuscate the
| phoning home, the chances of getting away with it is probably
| pretty high.
| drexlspivey wrote:
| Why would the company want to crack your vault..? If they want
| your logins they can just push an update on the client app that
| skips encryption altogether.
| aborsy wrote:
| Because a company is not a single entity, rather hundreds or
| thousands of peoples. Some of them may wish to get your
| passwords, for instance, a disgruntled employee who might
| want to publish large number of passwords online (or provide
| access to attackers).
|
| Yes, they might also use other techniques as well, for
| example, push a bad update if they have such privileged
| access. However, that's relevant more in targeted attacks;
| you can't really push a bad update to everyone before getting
| caught quickly. Also, often several people have to sign the
| code (in the case of non-JavaScript code), and there is log
| trail.
| argella wrote:
| I had a last pass account three years ago but shut it down. I
| used the remove account options on their website if I recall. I
| wonder if they kept my vault sitting around on their servers or
| if it was truly removed.
| waboremo wrote:
| Judging by how sloppily they handled everything else, maybe
| it's best to submit a GDPR delete account email.
| eddsh1994 wrote:
| I'm pretty sure any info this person has from 7+ years ago can be
| anecdotal at best; who knows what's changed, what he's forgotten,
| what he's misunderstood, etc...
| shmittywerben wrote:
| Is 1password more secure?
| Egoist wrote:
| In my opinion, 1password is definitely more secure. 1password
| generates a key when registering which you cannot restore. So
| not only an attacker need to know your password, they also have
| to know the generated sequence. This is helpful for people who
| tend to use easy to break passwords.
|
| 1pasaword is not perfect, but it's far better than lastpass
| jeffrallen wrote:
| I left LastPass when it was bought and migrated to 1Password. I
| have not had a breach notification since.
|
| Just sayin'.
| entelechy0 wrote:
| [dead]
| dzikimarian wrote:
| Today it might be, tomorrow they might be acquired by someone
| with all your data. Then in a year they may focus on
| monetization more than security.
|
| Get something that writes data in open format and does not
| interfere with how you store it. Eg. Keepass with some privacy
| focused file storage.
| scrollaway wrote:
| Keepass is fantastic but it is unsuitable for many things,
| such as multi-user/teams. The browser integration is also
| very much not something I trust, unlike 1Password's.
|
| 1Password has a fantastic track record.
|
| Yes, tomorrow, their incentives might change. But the data is
| copied and available locally; if they start fucking with user
| data, we will see it coming.
|
| Security is a lot about trust and trade-offs. This includes
| trusting someone who has shown themselves to be trustworthy,
| even if they might not be trustworthy tomorrow.
| luma wrote:
| Maybe, but we'll never know because you've just traded one
| cloud solution for another. You cannot audit their code and by
| handing over all your passwords, you've just made your entire
| digital life dependant upon their continued financial success.
|
| I cannot fathom why anyone would look at the situation today
| and decide that the solution is more of the same.
|
| Get an offline password manager and keep your valuables out of
| the cloud. I like Keepass, but there are plenty of FOSS
| solutions out there that allow you to actually own your data.
| spikej wrote:
| Most likely for the convenience that it offers. Getting non-
| technical family members to actually use KeePass, etc is next
| to impossible.
| [deleted]
| malepoon2 wrote:
| 1Password does encrypt URLs. It also requires an extra Secret
| Key [0] in addition to your password. This makes it much, much
| harder to use the data even if encrypted vaults were stolen.
|
| They also have a development team that's very active. Lastpass
| had been coasting for years.
|
| [0] https://support.1password.com/secret-key-security/
| ilyt wrote:
| They've been coasting pretty much since buyout
| mdaniel wrote:
| Look, I hate the "new" 1Password as much or more than most,
| but to say they're coasting is disingenuous; just last week
| they published their "op" plugin system allowing running
| "gh" and "glab" and a bunch of other common commands as
| subprocess of their "op" binary to inject the api tokens. I
| think the SSH Agent behavior is also post-money
|
| They've also listen to our bitching about requiring the
| master password every 2 weeks even with biometrics turned
| on, and rolled that back to a configurable setting
| the_lucifer wrote:
| They're talking about last pass buyout. Not 1password
| fossuser wrote:
| Hasn't tptacek said to avoid lastpass on here (in favor of
| 1Password) for the last ten years?
|
| I don't know if he ever got into the details of why (maybe he
| couldn't for contract reasons or something), but his judgement on
| it looks accurate.
|
| I'd be curious what his thoughts are, or if the risks he was
| talking about back then we're unrelated.
| tptacek wrote:
| It's literally a bot autoresponse on our Slack, and I didn't
| put it there. Don't give me too much credit; it was a widely-
| held opinion.
| nequo wrote:
| Do you know what the basis of that opinion was? As an
| outsider, how do I know that 1Password is managing its own
| security better than LastPass has?
| mdaniel wrote:
| I'll copy my reply to a similar "but how do outsiders know
| they're not cheating us?" comment:
|
| They do what any reasonable security company does, and call
| in vendors who have _negative_ incentive to lie:
| https://support.1password.com/security-assessments/
|
| I was especially impressed by the Cure53 ones, where they
| were provided access to the source code: https://bucket.agi
| lebits.com/security/Cure53-1PW18-report.pd...
| tptacek wrote:
| It would be weird for a security assessment not to
| include source code access.
| dfdz wrote:
| One key feature of 1Password is the use of a secret key in
| addition to a master password.
|
| See page 10 [1] which explains how the secret key provides
| extra entropy (which makes it much harder to brute force a
| user who choses a weak password). Also see Story 1 on page
| 11 [1].
|
| [1] https://1passwordstatic.com/files/security/1password-
| white-p...
| iamthemalto wrote:
| Interesting, have your recommendations changed?
| warrentr wrote:
| Curious what you think of dashlane. Personally I find 1pw UI
| patterns a bit annoying and dashlane somewhat better
| EMM_386 wrote:
| I somehow sadly signed up for LastPass only about a month ago,
| after (briefly) reviewing options.
|
| I have a rather long pass phrase. That should theoretically mean
| that even with my vault, brute-forcing this is out of the
| question and everything is still business as usual?
|
| If that's the case I'll sleep easier at night than the thought of
| trying to move everything _yet again_ to another password manager
| and handle (what are strong) password resets at places like
| Google .... _shudder_.
| spmurrayzzz wrote:
| If you signed up only a month ago, that means your pbkdf2
| iterations were set to a non-trivial value (presumably the
| default 100100, but you can verify this in advanced settings).
| This insulates you very well against brute forcing.
| talkin wrote:
| Urls and some other fields are stored plaintext. So yes, you're
| safe from bruteforcing passwords. But still lost privacy /
| doxxing / spear fishing info.
| jeffrallen wrote:
| Let's pour one out for the devs who still work there and are
| working over Christmas to deal with this.
|
| May they say "F this, I quit" and we hire them.
| nirvgorilla wrote:
| That's why you never use last pass and instead use something
| local on YOUR drives like Keepass.info.
|
| This is what you get for using services and not doing things
| yourself. Local, local, local.
| api wrote:
| Why do people use AES-ECB? I keep seeing this when even the
| Wikipedia entries explain very well what's wrong with it. It's
| not like AES-CTR or even a decent block chained mode like CBC is
| hard to use.
|
| Cryptographic libraries shouldn't even expose it except in a
| subpackage or namespace called "hazmat."
| tptacek wrote:
| It is (or was) the default mode, and, unlike CTR, you don't
| need anything more than a key to use it; no nonces, no IVs, no
| parameters. Put yourself in the shoes of someone who doesn't
| know much about cryptography, and it's a natural choice.
| api wrote:
| Hmm... so poor defaults strike again. Makes sense if you know
| nothing that simple AES-ECB seems to work and has the
| simplest API of any of the modes.
|
| But then I'd have to say... why is a company doing a secure
| password saver not employing anyone who knows the very basics
| of how to use cryptography? :)
| Strom wrote:
| > _why is a company doing a secure password saver not
| employing anyone who knows the very basics of how to use
| cryptography?_
|
| Because that isn't important for success. Perception is
| reality. Very few people can tell the difference between
| good and bad crypto work. So instead of wasting money on
| that, invest it into something that is understood by more
| of your customers. It's a sad reality.
| jfoster wrote:
| I understand that the security of customer data is the focus, but
| is it yet known how access was gained?
|
| I ask because I presume LastPass put a heavy emphasis on
| security, yet this still happened. Is there a 0-day still out
| there in the hands of very malicious actors and not yet patched?
| catalypso wrote:
| It seems that it was a social engineering attack. From their
| notice: https://blog.lastpass.com/2022/12/notice-of-recent-
| security-...
|
| > some source code and technical information were stolen from
| our development environment and used to target another employee
| Semaphor wrote:
| 7000...
|
| Just exported my vault, and will see if there's anything relevant
| in there (I haven't used LP in 7 years, but I probably have some
| unimportant-ish passwords in there from back then)
|
| Until now, I had forgotten that they still had my data :/
| pydry wrote:
| I really thought this was the worst lastpass breach:
| https://hackaday.com/2016/08/01/lastpass-happily-forfeits-pa...
|
| The worst part was the reward. $1000 is a sick joke.
| GrabbinD33ze69 wrote:
| I understand the connivence, but I still don't get why one
| would want to expose their pw manager to something like an
| internet browser.
| Nextgrid wrote:
| That's why I hang onto 1Password - at least on macOS and
| Safari, the browser extension just calls the native client -
| the actual UI (where you enter your master password and then
| select which credential to auto-fill) is managed by a
| separate process. The worst a compromised browser can do is
| prompt the UI to display and provide a suggested domain to
| pre-select.
|
| Unfortunately I believe that's Safari-only and even then they
| seem to be aiming to move away from it - all non-Safari
| extensions are a "fat" client called 1Password X where the
| entire logic (and thus the sensitive data) is within the
| browser.
| GrabbinD33ze69 wrote:
| Interesting. Something that is off putting regarding
| lastpass is the complete lack of a native client, it
| strikes me as pure laziness & complacency. Maybe lastpass
| does in fact run natively, outside of the broswer, but
| requiring a web browser is ridiculous. I'm aware there's a
| native app for windows, but it's horrific.
| Sebb767 wrote:
| Technically this was a bug, not a breach.
| DisjointedHunt wrote:
| The hackers got access to their dev environment and source code
| back in August and used that information to hit them harder this
| time around: https://blog.lastpass.com/2022/12/notice-of-recent-
| security-...
|
| We may not be seeing the whole picture yet, but very concerning
| that the dev environment had access to Production database
| backups stored in a manner that was easily decrypt-able :/ The
| whole point of a Dev environment in a security focused company is
| that you reduce the surface area for access and failure.
| cj wrote:
| Re: dev environment containing database backups, here's the
| full text on that point from the blog:
|
| > some source code and technical information were stolen from
| our development environment and used to target another
| employee, obtaining credentials and keys which were used to
| access and decrypt some storage volumes within the cloud-based
| storage service.
|
| It sounds like they didn't literally have backups in the dev
| environment (which would be absolutely terrible if they did).
|
| I'm guessing they learned enough about the architecture from
| the dev environment to social engineer their way into getting
| someone to give them credentials to production.
| EVa5I7bHFq9mnYK wrote:
| I had a lastpass account years ago, but cleaned my database and
| changed passwords to all my accounts after the first breach. Is
| there a chance Lastpass keeps old copies of my database archived
| somewhere?
| tomhallett wrote:
| An increasing number of data saas companies store your
| database/warehouse credentials so they can connect directly, Ie:
| Postgres/snowflake host, port, user, password, etc.
|
| That information is long lived (unlike tokens which expire) and
| you need to use the real value (unlike the hash of a password).
| Are there resources/books which cover the (many) best practices
| to keep that information safe?
|
| Things like: separate database/microservice, separate vpc?,
| encrypt the database, filter those fields from logs, etc etc etc.
|
| Is a service like aws lambda actually more secure then using a
| paas (heroku/fly/render) vs ECS (where there might be slower turn
| around times to _actually_ bump /patch CVEs than the aws lambda
| team would take?).
| wernerb wrote:
| I'm not sure what you are asking. For any reasonable
| service/Saad this is by far not te norm for end user
| credentials. They are always hashed, hopefully salted and with
| a strong algorithm.
|
| Administrator credentials are harder yes. Something like
| hashicorp vault can be made to fit any company (custom backend
| plugins). For most stuff it already has backend plugins
| available (ssh, any rdbms). The open source version I have seen
| can fit a large fintech startup no problem.
| barbazoo wrote:
| Aaaaaand the fraudulent charges on my cc started. Coincidence,
| maybe but unlikely. I sincerely hope LastPass burns to the ground
| and never recovers.
| Inhibit wrote:
| How many programmers work on last pass? From a solo coder with no
| specific interest in cryptography I wouldn't find this kind of
| flaw odd.
|
| From a large development team whose sole product centers around
| encryption? It seems strange to get it this wrong. What leads to
| that might make a good business case study.
| tasuki wrote:
| Interesting, my intuition is exactly the opposite of yours: I'd
| expect a solo coder to get it right more than a large
| organisation full of people with different incentives and
| priorities.
| semicolon_storm wrote:
| Exactly, these flaws feel like the kind of thing that pops up
| due to a conflict between product UX people and security
| people. Surely they had at least 1 engineer who was aware
| that unencrypted website URLs, EBC Mode, and not upgrading
| work factors was a bad idea. They just likely lost out to
| some product owner who thought displaying favicons, detecting
| reused passwords on the server, and not bother the user to
| upgrade on login were more important than security.
|
| At big companies, too often do the people in charge of the
| product seem to forget what core product really is.
| malepoon2 wrote:
| It's not a large development team. I moved away from them years
| ago because support for FIDO keys for example was always
| "coming soon" and still isn't there. They've been coasting for
| years and this breach doesn't surprise me at all.
| weird-eye-issue wrote:
| I've used a Yubikey with LastPass for several years
| malepoon2 wrote:
| Yes but they don't support the WebAuthn/FIDO2 standard. The
| Yubikey option they have is less secure because I think
| it's OTP under the hood, so it doesn't protect against
| phishing.
| hotpotamus wrote:
| I suspect most of the work of a password manager goes into the
| other features. At one point (not sure if they still do),
| Lastpass had a feature that could auto-rotate passwords for you
| for select sites. From watching it attempt it once or twice, it
| looked like it was done with scripted screen-scraping which
| must have been tedious to develop and maintain. Also providing
| form filling functionality seems like it took a lot of work.
| AdmiralAsshat wrote:
| I'm pretty pissed that when LP upped the iteration count for new
| accounts, they didn't _tell_ legacy users that they should
| consider changing it themselves. I had an old account which was
| almost certainly 500 or 5000, and I 'm fairly certain that I
| changed it myself at some point to a larger, different value. But
| at the time I figured a value like 100,000 would slow the process
| to the point of being unusable.
| raverbashing wrote:
| Yeah I don't know how "old" it has to qualify for the iteration
| upgrade but I've heard of some people still having it as 5k iters
| even with an active account
| cshimmin wrote:
| Can confirm :(
|
| Edit: because I was (until very recently) a daily active user
| and had niter=5k. Didn't even know about this setting until the
| hack.
| blowski wrote:
| Off on a tangent here, but I downvoted this comment because
| it doesn't really add anything. On what basis can you confirm
| it? Do you work there? Do you have deep expertise in the
| domain?
| optionalsquid wrote:
| A straightforward reading of their comment is that they can
| confirm because they have an active account with 5000
| iterations. That would certainly explain the frown.
|
| It's not like you need to work at LastPass or have deep
| expertise in the domain to look at your own account.
| cshimmin wrote:
| "I've heard of some people still having it as 5k iters even
| with an active account"
|
| I can confirm because I am one such person. Honestly
| thought that would come across from context but I'll edit
| to clarify.
| byhemechi wrote:
| Not encrypting the URLs is just such a baffling choice, i
| honestly don't understand how that ever happened.
|
| Also, as far as i can tell with some very basic maths based on
| running hashcat on my 3070, if you have a big long password on
| your vault, even with very few rounds of pbkdf, your actual
| passwords should be safe.
|
| I think 1Password's use of an extra "secret key" would be a huge
| save in a situation like this, where every encryption key is
| automatically very long
| [deleted]
| bpicolo wrote:
| 1Password has had a phenomenal security story. This is Lastpass
| breach what, like #4?
| gioo wrote:
| Look at lastpass' wikipedia page, they have been collecting a
| security incident after another since 2015.
| ilyt wrote:
| _to be fair_ they are by far biggest, and for all we know
| other might had incidents that they just covered up
| coder543 wrote:
| Citation needed on "biggest". 1Password appears to have
| comparable revenue to LastPass, but it is hard to pin
| down clear sources. Since you seem to have sources, it
| would be nice to see them. Number of users is even harder
| to pin down since you never know what a company counts as
| a "user". Someone who forgot to delete their account from
| years ago could easily be counted if the company is
| looking to inflate user counts.
|
| Even if they were 100x the size of the next competitor,
| they would not get a free pass for the obvious technical
| failures of their implementation, which have nothing to
| do with the number of users. The entire vault should be
| encrypted, end to end. The number of PBKDF2 "rounds"
| should automatically have increased, even for old users.
| These are huge oversights that fundamentally undermine
| their credibility.
|
| As far as coverups at other companies go, that would be
| _some coverup_ to avoid any whistleblowers leaking
| things. Unless it was very recent, this is very unlikely.
| People take cybersecurity seriously, and counting on
| every employee to participate in a coverup of a serious
| breach is unlikely to go well.
| azinman2 wrote:
| 1password only somewhat recently began pushing a cloud
| product. It's been locally stored for years. Gotta make
| that monthly revenue somehow...
| gigel82 wrote:
| > Not encrypting the URLs is just such a baffling choice, i
| honestly don't understand how that ever happened.
|
| That's obviously a design choice in order to extract data that
| can be monetized.
| roflyear wrote:
| Also you can migrate them to a longer round setting the next
| time they use that key - or require some users to relog in or
| something.
|
| This seems like business and product getting in the way of good
| decisions. Again.
| ziml77 wrote:
| That extra key is something I love about 1Password's security.
| It ensures that even people who pick poor master passwords are
| well protected. And even though I have a strong master
| password, the key is a good extra comfort for me.
| FatActor wrote:
| The secret key bothers me. A lot. Where do you store this
| mission critical piece of data? This is a value you cannot
| memorize (unless you are Rain Man) and it can be used to gain
| access to your account. The whole point of a password manager
| was to avoid this kind of vulnerability. Gives me the
| willies. It's basically a return to post-it notes.
| majikandy wrote:
| Lastpass
| jiveturkey wrote:
| it's stored in icloud storage
| devrand wrote:
| But you need both the master password _and_ the secret key.
|
| Even if you write it down on a post-it note, you now need a
| physical attack to access it on top of whatever attack you
| needed for the master password.
| CharlesW wrote:
| > _Where do you store this mission critical piece of data?_
|
| Some suggestions: https://blog.1password.com/where-to-
| store-your-emergency-kit...
| lynndotpy wrote:
| You need the secret key _and_ password to gain access.
|
| The key is 38 characters long, which is certainly within
| the range of human memory, if you're inclined to memorize
| it.
| procinct wrote:
| Admittedly, I'm not very knowledgeable with this type of stuff,
| but would they have chosen to do this so that the browser
| extension can still show the user when a login is available
| without the user having to authenticate (they then authenticate
| to get the login details)
| nicce wrote:
| This is likely the reason. Other providers like BitWarden
| caches the urls for certain time on client side. Even if you
| lock vault, extension can suggest that here is available
| login for certain period.
| froggertoaster wrote:
| This comment is a plug for Bitwarden.
| avsteele wrote:
| Can someone knowledgeable explain how the number of iterations
| affects account security for this breach?
|
| OK higher is better sure, but is moving from 5K iterations to
| 100K per the recommendation a similar precaution to adding 1,2,3
| digits to the master password?
| pornel wrote:
| Number of iterations is directly proportional to the time and
| cost of cracking the master password. For the old vaults it's
| 20 times faster/cheaper to crack the master password by brute
| force.
|
| The best precaution is to never use LastPass. If you used
| LastPass, the safe course of action is to change all your
| passwords that were in LastPass, and use a better password
| manager this time.
| GrabbinD33ze69 wrote:
| Define "old" in this context. Is old considered 7 years ago,
| around when this guy was an employee at logmein?
| avsteele wrote:
| If linearly proportional then it is approximately equal to
| one extra character. OK, thanks.
|
| I'm not sure to whom the rest of your response is addressed,
| this was a technical question.
| bawolff wrote:
| PBKDF isn't really considered best practise at all, really.
| Current best practice is to use a memory hard function like
| argon2, which makes GPUs ineffective at bruteforcing.
|
| Adding a digit to a password can depend. Adding a 1 to the end
| of a password is such a well known thing that its basically
| useless because that's the first thing people try as its so
| common. Ultimately though, you are basically correct in a
| bruteforce scenario. However most password attacks involve a
| bit of knowledge about what the person likely choose, so the
| effect depends on what that knowledge is.
|
| Keep in mind if you have a strong password (say 16 character
| randomly generated, never reused elsewhere) its not going to
| matter how many iterations as it will never be bruteforced even
| if the worst possible hash was used. This sort of thing
| protects people who use weak or maybe mid-tier passwords.
| ReptileMan wrote:
| KeepassXC with a keyfile and syncthing ...
| Swiffy0 wrote:
| Makes me think if survivorship bias (or similar) applies here.
| While it's not fun to see LP having a lot of incidents in its
| history, maybe those could be viewed as something that has made
| LP stronger over the years?
|
| I'd be more worried about a password manager that has never seen
| any security incidents - is it because there really aren't any,
| or that they haven't been caugh? Surely a security incident on a
| password manager serves as a major motivation to harden shit up?
| pornel wrote:
| No, it always had worse track record than all competitors.
|
| It's owned by a Private Equity firm, which means cutting all
| costs and selling hard until there's no money left to squeeze
| out of the corpse.
| dgacmu wrote:
| They didn't fix known weaknesses (unencrypted urls, no auto
| upgrade of the key cipher) after those previous incidents. At
| some point one has to come to the opposite conclusion...
| crisp wrote:
| https://threadreaderapp.com/thread/1606428769731878913.html
| i7c wrote:
| Since it was backups that got leaked, does it affect ex-users?
| antiframe wrote:
| I deleted my account over 12 months ago. I never assume that my
| data was deleted and changed my important (not all) passwords
| when I did so. I'm now going to go through every password in my
| current password manager that's older than the LastPass
| deletion date and scrutinize them again.
| ttul wrote:
| Yes, it would be good for LastPass to let us know the answer
| to this very simple question. Not to mention, why haven't
| they already notified everyone whose data was taken in the
| breach?
| gigglesupstairs wrote:
| I am curious about this too. I deleted my account last year.
| anshumankmr wrote:
| People are joking about obvious bad choices like Excel, but I am
| really not sure what is really safe anymore. For example, I am
| using Dashlane, should I change it? If so, how?
| jb3689 wrote:
| A notebook under my bed seems to have fewer attack vectors than
| anything on a networked device
| yreg wrote:
| Ye, but then you can log in only when you are home and lay in
| bed.
| antiframe wrote:
| That's a feature, not a bug.
| GrabbinD33ze69 wrote:
| I don't understand why tech savvy people are doubting the
| security of a pw manager with a strong master pw; this wasn't a
| failure caused by a flaw in the concept of a pw manager itself,
| but by a company's shitty implementation and design (I mean
| c'mon, certain fields were encrypted but others weren't, and
| they didn't make it super obvious?).
| TillE wrote:
| People are...very confused if their reaction to this is
| "cloud password manager bad". If only well-encrypted data
| were leaked, it really wouldn't be a big deal.
|
| A properly designed online password manager is an extremely
| safe choice.
| GrabbinD33ze69 wrote:
| Exactly... of the relatively tech savvy people I know who
| use this incident as some sort of vindication for their
| choice to not use a pw manager, are the same people who
| either store passwords in plaintext electronically, or
| write them down but use passwords that have a weak keyspace
| and are under 10 chars. I'm pretty sure I read an article
| from a month ago wherein 4 rtx4090s could chew through the
| hashes of 8 char passwords with a strong keyspace in a few
| days or hours.
| GrabbinD33ze69 wrote:
| To add to my comment, if one's response is to point out it's
| difficult to trust the company's opsec, handling of your data
| etc then use something like bitwarden. If a fully open src
| online pw manager doesn't calm your nerves, self host it.
| Saris wrote:
| The safest choice is KeePass since it's designed well for
| security, and stores your database locally.
| anshumankmr wrote:
| I have two OSes on my laptops and both iOS and Android, so I
| can probably manage except maybe on my office laptop. My
| parents are a part of my family plan and I don't see them
| being able to use it.
| otachack wrote:
| Separate your work and personal data, including passwords.
| That way if you ever leave the job it's and simple as
| leaving the password manager entity and not having to clean
| out your personal bank of passwords.
| luma wrote:
| Keepass is FOSS and there are compatible clients for
| basically every OS you might think of, including IOS,
| Android, OSX, Windows, and Linux. It does not include
| multi-device sync, but it works nicely with other solutions
| that provide that function. So drop in your preferred file
| sync solution (ideally, cloud-free) and you're all set.
| [deleted]
| bawolff wrote:
| > If you had a legacy 5000 rounds or 10000 rounds, the # of
| rounds can't just be increased server side. Changing that would
| mean a new key is derived. So older users likely still have a
| pretty low number of pbkdf2 rounds which makes them more
| vulnerable to brute forcing
|
| Kind of unclear but i think this implies that lastpass doesn't do
| some and reencrypt on login. Are they saying its just people who
| havent unlocked there vault in a decade, or are they saying all
| old users have this? If the latter this is really poor design.
|
| > Lots of vault entries may be encrypted with ECB mode AES-256.
|
| Wtf wtf wtf. This would be considered wildly insecure even by the
| standards of the 80s
| t0mas88 wrote:
| ECB mode somehow still gets used, Zoom also did it. I think
| this is a result of many developers not knowing much about
| encryption and then selecting the simplest option from their
| language's standard library.
| bawolff wrote:
| Zoom at least has the excuse that its more convinent if you
| are possibly dropping frames and need random access
| decryption (still really not acceptable). LastPass does not
| even have that.
| robryk wrote:
| CTR with no authentication is strictly better than EBC with
| no authentication in that case. Similarly, CTR-then-MAC
| (with MACs being e.g. per packet) is strictly better than
| EBC-then-MAC.
| upofadown wrote:
| Missing (or duplicating) a block in the CTR (counter)
| block cipher mode messes up the alignment of the count.
| Then everything after that comes out as random garbage.
|
| CTR is not a very robust block cipher mode...
| robryk wrote:
| As long as you simply transmit the count in the packet
| this is not an issue. You mostly have to do that anyway,
| because packets can be reordered and you want to stitch
| them together in order (with holes).
| owenmarshall wrote:
| Because I always want to identify the solution when we point
| to the problem:
|
| https://doc.libsodium.org/
|
| http://noiseprotocol.org/
| eternityforest wrote:
| Also TLS and SSH for data in transport.
| kodah wrote:
| That's correct. That means they didn't have a workflow for
| batch reencryption on login, must less a workflow for annually
| increasing rounds.
| Philip-J-Fry wrote:
| I just checked my old account and it was configured to be 5000.
| I changed it and re-encrypts the data and uploads it, and then
| forces you to login again, presumably to do server side part.
|
| Seems weird that they would have the number of rounds fixed
| from the time of account creation though. Surely it would be
| possible to increase the number of rounds over time.
|
| Edit: I should add that I have logged into this account within
| the past year or two. So if they're supposed to increase over
| time, it ain't worked.
| brianshaler wrote:
| This is pretty wild. When you rotate your master password and
| it re-encrypts everything, that's a perfect opportunity to
| use a new iteration count. If they didn't want change the
| value for user's who were at an old default value, they at
| least could have nagged "your account is using an old/low
| value for an encryption setting, click here to use the latest
| recommended default"
|
| Of course, changing it now won't do any good with regard to
| previous leaks.
| fluidcruft wrote:
| I have a really old account (pretty sure I started using it
| ~2010) and I use lastpass essentially daily. I've never
| looked at that setting and I see that mine is set to 100,100.
| So it's migrated sometime. But I do also have some vague
| memory of a lastpass incident years ago where there was a
| prompt that they wanted to re-encrypt everything
| preemptively.
| arka2147483647 wrote:
| > Seems weird that they would have the number of rounds fixed
| from the time of account creation though. Surely it would be
| possible to increase the number of rounds over time.
|
| Well, No. In metacode, pbkdf2 works something like:
| derived_password = pbkdf2(real_password, salt, 5000, ...);
| Encrypt(vault, derived_password);
|
| (See Wikipedia for more details
| https://en.wikipedia.org/wiki/PBKDF2)
|
| Point being, you can only change the number of rounds if you
| re-encrypt the vault, and you can only do that, if the users
| participates by giving their password to first un-encrypt it
| during that process. So it cannot be done silently in the
| background.
| gregmac wrote:
| It's possible to silently do this as part of logging in.
|
| I've done this with normal login for several (legacy)
| systems I've worked on, migrating users from md5 or sha1 to
| better algorithms.
| d1str0 wrote:
| Theres a big difference. If you're hashing a password for
| storage you end up getting the password first.
|
| LastPass NEVER gets your master key server side. All
| encryption is done locally.
|
| Also, hashing a password is extremely quick. To unencrypt
| the full vault and re-encrypt it does take an amount of
| focused time.
|
| Might not be able to be done "silently" in the
| background, but obviously LP should have been forcing an
| upgrade on login.
| coder543 wrote:
| > To unencrypt the full vault and re-encrypt it does take
| an amount of focused time.
|
| The entire vault _should not_ be encrypted directly with
| the user 's password. That would go against standard best
| practices.
|
| See this comment written hours before yours, right under
| the comment you replied to:
| https://news.ycombinator.com/item?id=34127993
|
| There is no "big difference" here, and it could be done
| trivially during login. The fact that it would be done
| client side instead of server side is a very minor
| implementation detail.
| jchw wrote:
| You don't need to re-encrypt the entire vault, just
| whatever you're using the PBKDF2-derived key to hide. In
| most situations, you'd use it to encrypt another, separate
| key. In that case, it can be readily upgraded at any time,
| including during login.
|
| Conceptually, it's not very different from how password
| hashes are updated, just that you need to re-wrap some
| other key as well simultaneously. Since the rest of the
| vault is unaffected, it's OK if the transaction fails: the
| old parameters will work with the old wrapped key, so all
| you need to do is ensure that the transaction is atomic.
| (Usually don't even have to do anything to ensure that if
| you just use the same database table/object.)
| [deleted]
| tzs wrote:
| > Point being, you can only change the number of rounds if
| you re-encrypt the vault, and you can only do that, if the
| users participates by giving their password to first un-
| encrypt it during that process. So it cannot be done
| silently in the background.
|
| I think there might be a way to update it without having to
| wait for the user to supply the master password, at least
| if their web login works like most, although it would
| require some additions to the database and their server
| side vault storage.
|
| According to the documentation I found the master password
| you create when you make your account is the master for
| both logging in to your account and for encrypting your
| vault.
|
| To handle its use as a login password they probably have a
| table somewhere that contains: email,
| salt1, hash1(master_password,salt1)
|
| I'll assume that they want to update both the login
| password hashing difficulty and the vault decryption
| difficulty.
|
| To handle updating login hashing they could change that
| table to contain for accounts that have logged in or been
| created after the difficulty change: email,
| salt2, hash2(master_password, salt2), NULL
|
| and for accounts created before the change that have not
| yet logged in: email, salt2,
| hash2(hash1(master_password, salt1), salt2), salt1
|
| For the vault storage, they'd have to change it so that
| instead of just singly encrypted vaults, Encrypt(vault,
| derived_pass), it can also store doubly encrypted vaults,
| Encrypt(Encrypt(vault, derived_pass), derived_pass2).
|
| When they do the change, they would change existing vaults
| to double encrypted, with derived_pass2 =
| hash1(master_password, salt1).
|
| When someone logs in for the first time after the change,
| they supply master_password. The server would see from the
| login hash table that salt1 is not NULL meaning they are an
| un-upgraded account. It could then compute
| temp = hash1(master_password, salt1) pwhash =
| hash2(temp, salt2)
|
| and see if that matches the hash in the login hash table.
| If it does the login is successful, and it can (a) generate
| a new salt and update the login hash table to contain:
| email, new_salt, hash2(master_password, new_salt), NULL
|
| and (b) use hash1(master_password, salt1) to remove the
| double encryption from the vault, use master_password to
| decrypt the vault, and then re-encrypt with a new derived
| password with the new upgraded work factor.
|
| NOTE: the above is based on documentation of theirs that
| says you use the master password for logging in to your
| account. However other documentation of theirs says that
| the master password is never sent to their servers.
| mvonballmo wrote:
| Agreed, it requires user-participation. However, LastPass
| could be proactive about this, perhaps including the number
| of rounds in its security check. It could tell you that
| your legacy account should be updated and guide you through
| it. That would be helpful. I have the standard 100,100
| iterations, but had no idea that this was a feature I had
| to keep track of.
| Philip-J-Fry wrote:
| I'm aware you can't do it silently in the background. But
| they can prompt the user to input their password. And
| you're already prompted when signing in on different
| devices or at regular intervals when the vault locks. Seems
| fairly easy to me from a UX point of view.
| bawolff wrote:
| It's also not really an obscure issue. For example, the owasp
| password cheatsheet talks about the need to increase the work
| factor over time - https://cheatsheetseries.owasp.org/cheatsh
| eets/Password_Stor... . I would hope that password manager
| software would at least know the things that end up on
| "cheatsheets"
| crazygringo wrote:
| Yup mine was 5000 too. I'm baffled as to why they don't force
| an upgrade on everyone the next time they log in.
|
| Old accounts that haven't been touched in years, sure. But
| active accounts being used daily? This is really
| unfathomable.
| mattm wrote:
| Mine was also set to 5000
| vegardlarsen wrote:
| Mine seem to be set to 1 iteration, screenshot here:
| https://snabelen.no/@vegardlarsen/109575002998425618
|
| My account is very old, but this was hidden behind advanced
| settings. And I have used this account daily since I created
| it. Not having this increase from their end seems very
| unprofessional.
| IgorPartola wrote:
| Why is this even a setting exposed to users? Shouldn't this
| be entirely up to them to manage the correct work factor?
| crazygringo wrote:
| 100% agreed. Paying for a major brand password manager, you
| should assume that you are paying for them to always keep
| the security totally up-to-date with best practices. The
| idea that you are somehow responsible for finding an
| obscure setting not just in "Account settings" but in a
| separate "Advanced settings" that defaults to hidden, and
| knowing the appropriate number to set it to, boggles the
| mind.
| SyzygistSix wrote:
| [flagged]
| brookst wrote:
| "But look, you found the notice, didn't you?"
|
| "Yes," said Arthur, "yes I did. It was on display in the
| bottom of a locked filing cabinet stuck in a disused
| lavatory with a sign on the door saying 'Beware of the
| Leopard.'"
| thechao wrote:
| There's an entire novella of Arthur just _finding_ this
| notice, right? It could be serialized into three one hour
| episodes of Dent, queuing & requeuing and just talking
| to others inqueue.
| babyshake wrote:
| It's because bikeshedding emphasizes customization and easy
| to demo features over the type of design that actually
| helps most users.
| roflyear wrote:
| Bc product people are hilarious!
| Someone1234 wrote:
| Why not both?
|
| Keep in mind that this is a trade-off, it requires more
| computational power AND battery, so giving users access to
| the leavers makes sense (e.g. power users with nice
| equipment can pump up the number).
|
| That being said I do agree that it is up to the vendor to
| set AND enforce a new higher minimum. If someone logs in
| with 5K rounds, it should be changed to the new default
| (100k).
|
| On a related note Bitwarden also allows users to configure
| this. I recently increased mine to 150K rounds.
| mfer wrote:
| Having the controls is great if you're a technical person
| who knows what to do with them.
|
| 99.9%+ of people aren't that technical person. Safe
| defaults need to be used and kept up to date for them.
| IgorPartola wrote:
| I think it should allow you to change the schedule on
| which it increases the rounds, not set the actual number.
| It should tell you how many rounds it currently is at and
| how it will increase but the setting most people will
| want is High Security, Very High Security, Ludicrous
| Security.
| kodah wrote:
| Because changing the number of rounds requires reencryption
| and it doesn't sound like they had a workflow for prompting
| batch reencryption other than through the setting.
|
| Ideally they'd manage that number and prompt the user to
| change it over time.
| Gasp0de wrote:
| It's not that difficult to do though? Just implement a
| mechanism that re-encrypts when the user enters their
| password.
| kodah wrote:
| I agree, there's workflows they could've built to solve
| this problem. I wasn't defending them in the slightest.
| hejaodbsidndbd wrote:
| [dead]
| cshimmin wrote:
| Yeah I was a daily user until about a month or two ago.
| Didn't even know about this setting, and I still haven't
| figured out how to change it in the mobile app. But mine is
| definitely set to 5k. Still in the process of changing all my
| passwords...
| SyzygistSix wrote:
| Old(er) users. This is the kick in the ass I needed to switch
| to something else.
| [deleted]
| aaron695 wrote:
| [dead]
| wernerb wrote:
| This is such a non-issue. You build in flags in the clients
| that are server activated "needs-reencrypt". After login (local
| client) flag is read from server and logic begins. You notify
| the user their vault needs stronger encryption. They can choose
| to continue and enter password, skip for now or ignore for 1
| month (or something more reasonable).
|
| The point is you explain why you do this. Start the message
| with "We care about your encryption" and go from there to
| explain that they need you to upgrade because the don't know
| your master key, they need your help to do it.
|
| Adding this kind of behavior should be their core business.
| Apparently it's not.
| [deleted]
| bbbbb5 wrote:
| >Wtf wtf wtf. This would be considered wildly insecure even by
| the standards of the 80s
|
| For this particular use-case? Hardly.
|
| Since an attacker can easily use any login form of their choice
| as an oracle for password reuse, ECB mode can't really
| introduce significant issues here.
| nequo wrote:
| What do you mean by "use any login form?" I don't understand
| this phrase.
|
| If the attacker has an encrypted vault, what is the login
| form there for them to use and detect password reuse?
| bbbbb5 wrote:
| These vaults conveniently come with unencrypted URLs of the
| login forms associated with each password. An attacker who
| discovers the plaintext of one password can trivially
| attempt to reuse that against all of the forms.
|
| Incorrect password attempts are essentially free, so ECB
| revealing reuse does not meaningfully help the attacker.
| nequo wrote:
| Oh I see. That makes sense.
|
| But for the attacker to try one of my passwords in a
| login form, they do need to have that password cracked
| already, which means that they already have my master
| password. But if they have that, they can decrypt all of
| my passwords, and the login forms are of no use.
|
| Am I misunderstanding something here?
| bbbbb5 wrote:
| >Am I misunderstanding something here?
|
| No, not at all. The point is that while ECB is a silly
| choice, it does not make it easier for the attacker to
| crack your vault. It does allow the attacker to see if
| you're reusing passwords, but does not reveal to the
| attacker what those passwords are.
|
| On the other hand, If the attacker were to discover one
| of your passwords from _another source_ , they'd be able
| to confirm reuse anyway by simply attempting to use that
| password on other websites.
| ilyt wrote:
| Yeah it also struck me as bizzare. When client-side app has
| master key entered it it could just opportunistically upgrade
| that
| FreakLegion wrote:
| _> Wtf wtf wtf. This would be considered wildly insecure even
| by the standards of the 80s_
|
| You aren't wrong, if true that's certainly a mistake on their
| part. Practically speaking though as long as the passwords are
| randomly generated it probably doesn't matter, i.e. if you
| think about what the IV and chaining are doing in CBC. ECB is
| just as good for encrypting a _random_ stream of bits; CBC just
| makes sure the bits are random before passing them into the
| cipher. Of course the optics are still terrible.
| cmeacham98 wrote:
| While you're correct:
|
| 1. In real life, passwords aren't random. Password manager
| users are probably less likely than average to make this
| blunder, but I'd still be willing to bet _the majority_ of
| lastpass's customers do.
|
| 2. Even if you personally have all random passwords, would
| you really want to use a product made by people who made this
| level of a noob mistake? I used to pay for LastPass premium,
| now my account is deleted, my passwords are changed, and my
| money goes to Bitwarden instead - and every time I hear about
| Lastpass I don't regret this decision.
| FreakLegion wrote:
| I suspect that even non-random passwords here are fine,
| again practically speaking (edit: and given certain
| assumptions, to be clear, like no reuse), but haven't sat
| down and proved it.
|
| Obviously this isn't an endorsement of LastPass. Everything
| about their protocols is disappointing. Even if the
| encryption issues turn out to be of the well-that-was-a-
| dumb-choice-but-you-don't-need-to-panic variety, it's
| because they got lucky, not because they were good.
| cmeacham98 wrote:
| > and given certain assumptions, to be clear, like no
| reuse
|
| Maybe I wasn't obvious enough, but this is the
| problematic assumption. When I say "non-random password",
| that's what I mean: a reused password.
|
| Almost everyone I know reuses passwords (sometimes with a
| slight variation, but 90% of the password the same), and
| my day job is a software engineer. I'd be willing to be
| at least half of Lastpass's users have at least 1 reused
| password.
| FreakLegion wrote:
| That was a hasty edit on my way out the door this
| morning. Reusing a password doesn't make it easier to
| decrypt here, it just helps with some secondary tasks,
| like validating decryption output (since ECB isn't
| authenticated). This is rather indirect, though -- not a
| great example. A better example would've been the
| password fitting in a single block (<= 16 characters).
|
| The reason I suspect even non-random passwords might be
| mostly fine[1] is because there's no oracle and passwords
| are generally short. There's not much there for someone
| to hang their hat on. It's only a hunch, though; if
| tptacek for example says something different, I'd believe
| him.
|
| 1. Meaning: No need to cancel Christmas. You can deal
| with it later. Not meaning: ECB is as strong as CBC or
| whatever.
| bbbbb5 wrote:
| Given that any login form can be used to rapidly confirm
| password reuse it's hard to see how ECB introduces new
| issues here.
| tptacek wrote:
| Attackers don't generally control the login forms, but
| they do have the LastPass vaults, so this response
| doesn't make much sense.
| bbbbb5 wrote:
| Attacker doesn't need to control the login form to use it
| as an oracle to confirm password reuse.
| tptacek wrote:
| Reuse of what? If you're assuming the attacker already
| has a valid password, the list of URLs they use it also
| irrelevant, as is the password vault. Just do what real
| attackers do and hit every single known login page on the
| Internet with it.
| bbbbb5 wrote:
| That's exactly what I'm saying :)
|
| If the attacker doesn't have the valid password, the
| knowledge that two different sites share the same
| password isn't exactly game-changing. And if the attacker
| does have the password, they'll figure out where it works
| regardless of access to LastPass db.
| tptacek wrote:
| It's not nothing, and it's weird to be strident about it,
| but the obvious problem here is the offline cracking of
| the vault passwords; this isn't worth arguing about.
| bbbbb5 wrote:
| > It's not nothing, and it's weird to be strident about
| it
|
| To an outsider, hearing people talk about how LastPass
| used Very Bad ECB mode makes it sound like a fuckup with
| immediate and dramatic effect on the security of their
| passwords, that isn't exactly true.
|
| Nobody should have been using LastPass, but we can still
| be realistic about the threats facing those who did.
|
| > but the obvious problem here is the offline cracking of
| the vault passwords; this isn't worth arguing about.
|
| Of course not, but that's a completely separate issue
| from their choice of AES mode.
| cmeacham98 wrote:
| Knowing you reused the same password between your Amazon
| and $CompromisedWebsite accounts (but nowhere else, maybe
| you set them up the same day) gives attackers a
| significant advantage over having to try every password
| they have on every website.
| bbbbb5 wrote:
| I don't think this is a significant advantage, the cost
| of an incorrect password attempt is essentially zero.
| Trying "every password they have on every website" for an
| individual will still be a very small set of passwords to
| try.
| Shaanie wrote:
| I could see password reuse being used as a reason for
| trying brute force/dictionary attacks. E.g. You see that
| a user has used the same password on Coinbase as X, which
| could indicate that the user isn't using randomly
| generated passwords and therefore be potentially
| vulnerable to such attacks.
|
| Kind of a long shot though.
| cmeacham98 wrote:
| Attackers generally aren't targeting a specific
| individual, they got a dump of X million passwords from
| some compromised website. Being able to connect those
| directly to working accounts rather than having to burn
| IPs and get them rate limited and/or banned trying duds
| _is_ valuable information.
|
| If you have some attacker after specifically you, yes
| this information is of less use to them, because they
| will have tried every password of yours they have on
| every website already hoping you reuse passwords.
| DennisP wrote:
| The whole point of a password manager is so you don't have
| to remember passwords. Why wouldn't you use unique random
| passwords? It even generates them for you.
| taikahessu wrote:
| If you create some new account on mobile, the workflow is
| messy. If you are on schedule like ordering a ticket, you
| just quickly try to get the job done.
|
| You need to know the specific order how to create the
| password for a new site. Otherwise it was just easier to
| plow through with your favourite memorised combination.
|
| At least I found it hard to do with Lastpass on mobile.
| Now I've tested it with Bitwarden and 1Password 8, they
| seem to do a better job with it.
| wpietri wrote:
| At least in my case, the first time I used a password
| manager it learned my existing ones from my browser, and
| many of those were non-random. From that point forward I
| used generated passwords, but I'm sure I still have
| hundreds of legacy ones that I didn't bother to go and
| change because the sites didn't matter that much to me.
| thechao wrote:
| It'd be nice if, when I logged in to a site, my browser
| would casually mention if the pw is reused, or not. Now-
| a-days, I just habitually check my pw on login to make
| sure it's random. For the SO & kiddos, I manually reset
| all the financial & identity defining pws (Google,
| Amazon, FB).
| [deleted]
| minusf wrote:
| this would bite me in the worst possible moment when i
| need to login to somewhere and i lost my phone/battery
| dead/company hacked/etc.
|
| i have been using keepass(xc) since it's been around and
| i dont use random passwords. every year i create a
| formula that creates all my passwords and i put these in
| the vault. it also enforces password rotation. losing the
| vault i can still come up with any of my psswords just by
| remembering the formula.
|
| for company server services it's a different story, i
| generate wholly random strong passwords and store them in
| the offline vault.
|
| edit: typos
| ilyt wrote:
| That looks like a lot of work. I just backup the password
| list separately from time to time
| [deleted]
| rzimmerman wrote:
| Also it's not clear that the same AES key is used for all
| secrets. If it's URL- or tag-derived using the master
| password then it's only bad for long secrets (more than 32
| bytes) that aren't random data.
| Leo_Verto wrote:
| To add onto this, the reason ECB mode is so horribly bad, is
| that it produces the same cyphertext for blocks with the same
| plaintext.
|
| This allows an attacker to detect repeating plain text
| segments, e.g. reused passwords.
|
| The Wikipedia article on block cypher modes illustrates this
| problem rather well [1].
|
| [1]:
| https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation...
| zinekeller wrote:
| ECB Penguin! (https://words.filippo.io/the-ecb-penguin/)
|
| Also, I've just learned that the quintessential file has been
| recently replaced. I understand the need for a higher
| resolution file, but I'm still a bit sad.
| evandale wrote:
| Hah, that first tweet is classic https://xkcd.com/1053/ and
| I'm one of the 10000 today :) Today is the first time I've
| seen the penguin!
| bbbbb5 wrote:
| >This allows an attacker to detect repeating plain text
| segments, e.g. reused passwords.
|
| This is hardly a problem, any login form will also allow an
| attacker to do this.
| ilyt wrote:
| ... actually that might be a "feature" for them, they do have
| duplicate password report, I had assumed that's just based
| off decrypted ones on client side but they might be just
| using ECB for that
| eternityforest wrote:
| How is AES ECB even possible? You would have to actively choose
| to do that. It's more effort than something like libsodium.
|
| Have they not heard of the first rule of crypto being "You
| probably aren't qualified to do it, use libsodium or TLS or
| SSH" yet? Why are they messing with cipher modes themselves?
| tptacek wrote:
| Their encryption code predates libsodium, and ECB was (on
| many platforms still is) the default mode --- also, the only
| mode that doesn't require confusing extra parameters.
| eternityforest wrote:
| It's an utterly useless mode though unless you add your own
| confusing extra stuff. It was probably a bad plan to make
| that the default.
| GrabbinD33ze69 wrote:
| The red flags were fairly evident 2 years ago, even to someone
| like me who's not very observant; if I recall correctly, their
| android app was found to have tracking mechanism purely used for
| marketing purposes etc. Really? Trackers in a password manager,
| something that should be quite private. Combined with a few data
| breaches they had over around 2 years ago, I couldn't recommend
| them to anyone in good conscience.
| aix1 wrote:
| > their android app was found to have tracking mechanism purely
| used for marketing purposes
|
| I'd be curious to read up on this. Would you happen to have a
| link to some coverage of this?
| GrabbinD33ze69 wrote:
| It's been a minute but here's the first thing that pops up,
| I'm pretty sure this is what I'm thinking of.
| https://www.pcmag.com/news/lastpass-android-app-
| contains-7-t... Again, imo trackers in a pw manager is
| unacceptable.
| jmholla wrote:
| Here's an article I found on it [0] and a direct link to the
| report [1] which shows 7 trackers. The latest report [2]
| shows that is down to 5.
|
| For comparison, BitWarden's report shows 2 [3] and
| 1Password's shows none [4].
|
| [0]: https://www.tomsguide.com/news/lastpass-android-app-
| tracking [1]: https://reports.exodus-
| privacy.eu.org/en/reports/165465/ [2]:
| https://reports.exodus-
| privacy.eu.org/en/reports/com.lastpas... [3]
| https://reports.exodus-
| privacy.eu.org/en/reports/com.x8bit.b... [4]
| https://reports.exodus-
| privacy.eu.org/en/reports/com.agilebi...
___________________________________________________________________
(page generated 2022-12-25 23:01 UTC)