Live data from Hacker News

I Lost All Faith in LastPass

infosec.exchange

151–160 of 322 posts

Re: I Lost All Faith in LastPass

#152
post #84

> 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…

> Usually security nuts like to override the clear-text string with zeros or random characters before calling free() on it.

If you are worried, you can store the password in a byte array and zero that out.

But further, a buffer overflow is practically impossible with a GCed language (especially a popular one). A programmer using a GCed language cannot write code which has a buffer overflow. That must come from a bug in the runtime itself. Not likely.

As far as I'm aware, every gced language has bounds checks on arrays. Certainly all the popular ones.

> the last thread dying will release the memory for this variable.

Really not how GCed languages work. Memory lifetime is not bound by thread lifetime except in the rare case when memory is bound to a thread (static/global variables).

The majority of GCs on the market are tracing collectors. Memory is periodically collected when it is not longer referenced (mark and sweep). What triggers that collection is a whole host of potentials interactions. How frequently and deep it runs also depends on a lot of application characteristics.

Re: I Lost All Faith in LastPass

#153
post #47

I have been a LastPass customer for over 10 years and I think this January when my yearly subscription ends, I will finally not renewing. I’ve shrugged off a lot of strangeness that has been happening with them as a fledging company’s growing pains. Unfortunately, this incident is the final straw. I think we are going to see a lot more come to light and their lack of any sort of transparency on this is a cardinal sin…

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…

>What I did though was tag all my password with "lp-breach-aug-2022" and then as I go through them and change them, I remove the tag

How did you add the tag, or is it obvious in the UI? I've never used 1Password before but think I'm gonna land there instead of Bitwarden, and I like this idea.

Re: I Lost All Faith in LastPass

#154

When I see people running to 1Password, I'm really concerned. I don't know whether 1Password has somewhat of a following cult here or they're doing some astroturfing in this community. But 1Password claims are the same claims as LastPass used to have. (zero trust, secure, …) And now we're discovering that LastPass was totally lying. We have no way of knowing whether 1Password is telling the truth. For me, my password…

On top of that, they’ve made their client software prettier and slower, but not really more usable IMHO. I migrated to BitWarden and don’t think the user experience is any worse.

Re: I Lost All Faith in LastPass

#155
post #98

Earlier quoted context omitted.

I get it but in this context "authority" means an authority on a particular topic, not like a police officer or something. Appeal to authority becomes a fallacy when you appeal to someone who is not actually an authority on the subject at hand.

But how do you determine if someone is an authority? Our world is filled with epistemological bubbles. One person's expert is another's snake oil peddler.

Right, I don't think we really disagree about anything. "That's an appeal to authority" is not a useful objection, because appealing to authority is often a great idea. "That's not a good authority" is a good objection and often very relevant.

It's sort of like seeing a lot of arguments that rely on false or misleading evidence and deciding that "appeal to evidence" is a fallacy. The choice of authority or evidence is the issue, not the act of appealing.

Re: I Lost All Faith in LastPass

#156

Earlier quoted context omitted.

Appeal to authority is not a fallacy, it's basically a necessity to function in the world.

https://www.grammarly.com/blog/appeal-to-authority-fallacy/

> When you need to support a claim, it can be tempting to support it with a statement from an authority figure. But if done improperly, this could be a logical fallacy—the appeal to authority fallacy.

The key words are: “if done improperly, this could be…” The article goes on the give non-fallacious examples of an appeal to authority. The quality of an implantation will be correlated to experience, so this is an example of a non-fallacious appeal to authority.

Re: I Lost All Faith in LastPass

#158

> 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!)

The arguments people are giving about being able to explicitly call `free` make a lot of sense to me for getting rid of some attack vectors, but it still seems like the security risks of using a memory-unsafe language would heavily outweigh the risks of the garbage collector not clearing strings fast enough?

I know that's not an either-or proposition, there are memory safe languages that aren't garbage collected. But if people aren't talking about those languages, if they're just bringing up C or something...

I am not an expert, I might not know what I'm talking about here at all -- but my instinct is that I would rather see security-critical code written in a garbage collected language than in C. Frankly, I don't trust developers not to make memory errors in C.

Maybe I'm underestimating the risk of the garbage collector not zeroing out variables? Or maybe I'm over-complicating it and the answer is just the obligatory "write it in Rust" refrain so you can avoid both problems?

But I'm also a little surprised to see this line, my impression was that security advice was starting to trend towards recommending GC languages, not away from them.

Re: I Lost All Faith in LastPass

#159
> In fact, if password management is done correctly, I should be able to host my vault anywhere, even openly downloadable (open S3 bucket, unauthenticated HTTPS, etc.) without concern

This is the key point. Properly implemented, you should feel very relaxed if your encrypted data is leaked.

I'm using BitWarden, but 1Password's "secret key" concept is smart, it means your data is still very secure even if your password sucks.

Re: I Lost All Faith in LastPass

#160
post #133
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…

An interesting point and I wonder if there are thoughts on if the JVM should implement flags that do overwrite before gc (obv worse perf but some cases have use for it). Or at the least, let a program implement parts of the gc api and plug it in themselves.

You can with the JVM.

https://docs.oracle.com/javase/9/docs/api/java/lang/ref/Clea...

However, the issue isn't so much that doing that, rather it's that GC will potentially never collect the memory. In the JVM, the GC primarily runs when enough allocations happen. It's not on some timer.

So the concern would then be having a password sitting in memory for hours (or even days) on end.

Post reply on HN