Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I Lost All Faith in LastPass

infosec.exchange

Post reply on HN
Print view View original

221–230 of 322 posts

Re: I Lost All Faith in LastPass

#221

Post by jve »

geocrasher wrote: post #11

After reading this, I acted on a decision I was on the fence about. I already have moved to Bitwarden and like it a lot better, but this post prompted me to go into LastPass and actively delete my account. The next thing to do will be to start changing passwords. As with most of us, that's a project of serious scope that I do not look forward to.

I'v migrated maybe 2 years ago and deleted LP account. But I'm now wondering if that delete REALLY wiped off my account? Including some long-term backup or something? Has anyone asked LastPass? Anyone here with internal knowledge?

I may never find out for sure, even if I ask LastPass...

Re: I Lost All Faith in LastPass

#222

Post by EMIRELADERO »

maccard wrote: post #131
EMIRELADERO wrote: post #24

Earlier quoted context omitted.

If a document alone lends credence to their claims, the source code would do wonders. It's not about public contributions, it's about transparency and good faith.

Why do you trust the source code is actually what they deploy to your device, or that what they build isnt linked against extra libraries, maybe even internal library?

It's a matter of trust and good faith. You could apply the same dichotomy to actual FOSS programs.

Re: I Lost All Faith in LastPass

#223

Post by nebulous1 »

rtev wrote: post #202
nebulous1 wrote: post #167

Earlier quoted context omitted.

Also how, say, firefox's password manager compares. I've tried to look up technical comparisons before but found them unconvincing (making clearly outdated or incorrect claims). You can get the standalone managers compared to each other, but the non-standalones are missing.

I do know the answer to this - Firefox is not an acceptable alternative to a strong password manager. Local admin can dump any passwords from Firefox, and I think a user can even dump their own passwords from Firefox on windows and Linux.

They do have a "primary password" these days which I believe encrypts the locally stored passwords and the locally stored sync key.

Re: I Lost All Faith in LastPass

#224

Post by aflag »

acatton wrote: post #161
aflag wrote: post #115

Earlier quoted context omitted.

You should be able to know all the references to a variable, if you are careful when writing your program. Also, you could write a destructor that scrambles the memory location before the object is collected. However, you would still not have control over copies that the GC may decide to make and it is a bit trickier to force a free, since the GC is in no obligation of freeing an object as soon as it has no more refe…

> You should be able to know all the references to a variable, if you are careful when writing your program. The issue is: what if thread A and thread B hold a reference to the password variable? And you don't know in which order they will execute. In which thread do you scramble the password before releasing the variable reference? From what I understand, OP's point is: because of the nature of C, you have to know w…

One possibility would be to reference a password variable always from t he same thread. But even if you use multiple threads referencing the same memory location, you could make some of them weak references (which the GC doesn't take into account when deleting the object) or you could make sure you stop referencing them in both threads and force the GC to run on that object. The destructor could handle the scrambling.

Re: I Lost All Faith in LastPass

#225

Post by Fire-Dragon-DoL »

metabagel wrote: post #102
Fire-Dragon-DoL wrote: post #83

Earlier quoted context omitted.

I just did the migration (to 1password though, sorry the lack of tags is very bad for organization), 6 years old customer. Key points: - Refresh the website list from the extension before starting, ideally clear the extension cache first (will sign out) - export from the extension - attachments and password history are not exported - there is a lastpass-cli that will help you export attachments - there is a hacked to…

>> Key points: - Refresh the website list from the extension before starting I didn't understand any of your explanation of how to migrate from Lastpass to 1Password.

Sorry I didn't realize the formatting was way off, I'll write a better message in a minute

Re: I Lost All Faith in LastPass

#226

Post by m000 »

I jumped the LastPass ship a couple of years back. There had been some security incidents at that time, but they could still be downplayed.

What drove me away was the lingering impression that they were more focused in figuring out how to monetize their product, rather than improving it: E.g. one year feature X required a $1/m plan, next year it was free, and the third year it required the $5/m plan. At the same time, their apps/extensions seemed sluggish and stagnant.

That didn't exactly inspire trust in a product that is essentially the gateway to most of my online activities.

Re: I Lost All Faith in LastPass

#227

Post by 0cf8612b2e1e »

manmal wrote: post #68
joshe wrote: post #30

Earlier quoted context omitted.

Which people? I've been very reluctant to use their cloud solution as I trust Dropbox more for security. So I still fight 1password to keep the vault stored in Dropbox. I figure there are maybe 4 organizations who are active enough to prevent a full download of all their user's data. Google, Dropbox, Amazon, and Facebook. (Maybe Apple, but they seem lethargic.) Because they store all the passwords to all of our servi…

Vaults stored in Dropbox could be brute forced if an attacker ever gains access to the ciphertext. The 1P service mitigates this by adding a random key as salt that’s stored locally (iOS keychain/browser storage). That key never leaves your device (authentication is done via zero knowledge proof), so the master password is virtually impossible to brute force right now, even with a very weak master password. I can hig…

> Vaults stored in Dropbox could be brute forced if an attacker ever gains access to the ciphertext.

I’m sorry, but could you expand on this? If I leave my encrypted password vault on Dropbox’s servers, then of course they could attempt to brute force it. I thought the entire point of the encrypted vaults is that brute forcing is computationally infeasible, but technically possible.

Re: I Lost All Faith in LastPass

#228

Post by AgentK20 »

acatton wrote: post #84
jrochkind1 wrote: post #46

> I'm less thrilled about it being written in a garbage collected language What are the security problems with garbage-collected languages? (not being sarcastic, don't have an agenda, I have no previous knowledge on this, and am not a security expert. Just had never heard this suggested before, and am curious what he meant. Legit question!)

Usually security nuts like to override the clear-text string with zeros or random characters before calling free() on it. This way, if this chunk of data stays in memory (which is most likely the case with libc's free()) it cannot be read by exploiting a buffer overflow. With garbage collected language, programmers don't know when their variable is "free()ed", since it could be held in multiple thread, and the last t…

Another thing to note about garbage-collected languages (like Java with the G1 collector) is that blocks of memory will often be *copied* to other parts of the physical memory as part of compaction phase [1] (see quote), in order to be able to provide large segments of sequential space. Since the GC is designed with performance in mind rather than security, the original copies are not zero'd as part of this compaction, and instead their raw data will potentially stay in memory indefinitely until overwritten by another part of the application, and will not be zero'd upon termination of the application. Because of this, even with meticulous tracking of references and "raw" memory access only, GC'd applications can leave traces of secrets on memory. There may be workarounds for this by exclusively using "Unsafe" methods, but that drastically limits your API-interoperatility with libraries and such.

> G1 reclaims space mostly by using evacuation: live objects found within selected memory areas to collect are copied into new memory areas, compacting them in the process. After an evacuation has been completed, the space previously occupied by live objects is reused for allocation by the application.

[1] https://docs.oracle.com/en/java/javase/18/gctuning/garbage-f...

Re: I Lost All Faith in LastPass

#229

Post by aflag »

kmeisthax wrote: post #168
aflag wrote: post #115

Earlier quoted context omitted.

You should be able to know all the references to a variable, if you are careful when writing your program. Also, you could write a destructor that scrambles the memory location before the object is collected. However, you would still not have control over copies that the GC may decide to make and it is a bit trickier to force a free, since the GC is in no obligation of freeing an object as soon as it has no more refe…

In most GC languages, the String type itself is not a managed handle to a single memory buffer, but a reference into a whole copy-on-write datastore. So you can't even scramble the underlying memory - mutating the string to erase it will not zap the original, it will just create a copy. Your best bet is to ensure no references to the password string exist - including in library code you may use, which means constant…

You don't need to use the String type for your sensitive data, though. You can create your own type that acts the way you want.

Re: I Lost All Faith in LastPass

#230

Post by eastbound »

aflag wrote: post #115
acatton wrote: post #84

Earlier quoted context omitted.

Usually security nuts like to override the clear-text string with zeros or random characters before calling free() on it. This way, if this chunk of data stays in memory (which is most likely the case with libc's free()) it cannot be read by exploiting a buffer overflow. With garbage collected language, programmers don't know when their variable is "free()ed", since it could be held in multiple thread, and the last t…

You should be able to know all the references to a variable, if you are careful when writing your program. Also, you could write a destructor that scrambles the memory location before the object is collected. However, you would still not have control over copies that the GC may decide to make and it is a bit trickier to force a free, since the GC is in no obligation of freeing an object as soon as it has no more refe…

Nono, a lot of GCs copy the whole known variables to a new area, then delete the old area in bulk (“but it consumes twice as much memory!?” yes, but it’s very efficient - doesn’t require tracking). Therefore you may have a constant char[] and it could still be in 2 places in memory.
Post reply on HN