For anybody else left wondering, Bitwarden does encrypt (nearly) everything in your vault:
> At Bitwarden we take this trusted relationship with our users seriously. We also built our solution to be safe and secure with end-to-end encryption for all Vault data, including website URLs, so that your sensitive data is “zero trust” secure [1]
I haven't used LastPass in years, but the recent news made me wonder how Bitwarden was handling URLs.
I feel like there should be a law of the internet for this. The more a company asserts that their data is secure and encrypted and you should trust them, the more likely it is to leak and be proven to be massively vulnerable.
It’s fine to store your passwords online for convenience, but as a user, it’s important to accept that it’s no longer your private password and will, at some point, leak.
I definitely feel the opposing law works. When I see a project with a massive disclaimer about "this crypto is not audited, I'm a noob never deploy this anywhere" I'm likely to see better crypto than most of the commercial products I work with, including ones with sales people that talk about unbreakable crypto.
That's a silly term for that. Commercial businesses have the same access to NIST that the military does. Their guidance is even free!
Military grade when we're talking about a screw is a little different. It means that the screw is made and QC'd to a very specific spec/standard.
My next question might be, "Where can I find you on the FedRamp approved list?". To which, I'm sure they'd respond that anything outside the algorithm is not military grade, which is what most attackers will exploit in the end.
> When I see a project with a massive disclaimer about "this crypto is not audited, I'm a noob never deploy this anywhere" I'm likely to see better crypto than most of the commercial products I work with, including ones with sales people that talk about unbreakable crypto.
I'm working on an opensource project for Linux users that needs crypto. Needless to say, I'm not an expert in that domain. I was planning to ask experts for help in reviewing the crypto. Your statement makes me slightly nervous. What is the standard procedure to ensure crypto safety in a software project?
Use available and widely used libraries for the low level crypto parts (e.g. don't code RSA or key generation on your own). Apart from that, get audits if you have the means but I guess using libraries like openssl should be enough for most open source projects.
Understand (before you start writing code) the basic security properties that you want to deliver through use of cryptography. This is usually where most implementers fall over (including the big commercial products).
To give a couple of specific (but non-exhaustive) examples, generally framed in terms of password managers:
- A password manager should protect the identity of the sites the user has saved, the content of the username and password field, and any associated notes. (That's fairly straightforward, most people are likely to agree on this). But what about integrity? Should you use an authenticated cipher mode like GCM? What will you do if the authentication tag fails verification?
- The password should be encrypted such that if a password is re-used across websites, it is not discernable from the ciphertext that this is the case. (Fewer people will think about this, but some will... Using AES in ECB mode isn't enough to prevent this! Lastpass appear to have done this in the early days).
- The key used to encrypt each ciphertext should probably be unique, to reduce any potential impacts of weaknesses in ciphers or cipher modes. Each cipher should use a unique per-instance instantiation as well (i.e. IV, GCM tag, etc.) How do you store and derive these passwords though? That will take you into key derivation functions, and password-based ones, like scrypt/bcrypt/argon2. These can derive a crypto key from a user password. You can then use that key as input to a KDF (with a per-entry salt) to derive the actual AES key used for each entry.
- If you're designing a wire protocol, what properties do you seek? Replay resistance? How do you prevent session resumption type attacks? (don't design a new wire protocol, use something robust like modern TLS!)
98+% of the time, at least in my experience, people who mess up crypto don't understand what goal they are seeking to achieve by using the cryptography, and haven't threat modelled it. Usually this is because regular devs are being asked by "BigCorp" to add "AES 256 crypto" to meet a client tick-box requirement. I would say if you understand how people are likely to seek to break/compromise what you are building, you can then start to design a solution. Expect to read 10x more articles than you expect, and before you start writing any code though.
And don't focus too much on getting an expert to review the code only - you ideally want to get some input reviewing the concept, architecture, understanding of the threat model, and the security properties you want to deliver. I've blown huge holes in crypto systems before, as people did things "nearly" right, but didn't understand the wider application, so were exposing/leaking the key elsewhere etc.
>It’s fine to store your passwords online for convenience, but as a user, it’s important to accept that it’s no longer your private password and will, at some point, leak.
ehh. I store my passwords online but its on a file I encrypted offline with strong password (over 20+ characters) and key. I use keepass which is a locally encrypted and stored password manger, and I store the DB on Dropbox and download it to any of my computers/devices were it is decrypted locally when needed. I don't trust password wallet services ass they all seem to want to do the enryption server side with a reset-able password which really means they have the master password not you, but my set up seems secure enough to me.
> I don't trust password wallet services ass they all seem to want to do the enryption server side with a reset-able password which really means they have the master password not you
None of the popular password managers work this way.
> Recovery Groups
One of the most powerful capabilities that a team administrator has is
the power to assign members to the team’s Recovery Group. In most
configurations the assignment is automatic and Owners, Organizers, and Administrators will automatically be made members of the Recovery Group. In 1Password Families there is no ability to separate the roles of Owner, Administrator, and Recovery Group member; they are all wrapped up as “Organizer.” With 1Password Teams Administrators are given more control, but not all of the underlying flexibility may be exposed to the user.17 17We discovered during our beta testing that it was difficult to make the distinction between Owners, Administrators, vault Managers, and Recovery Group members clear enough for those distinctions to be sufficiently useful. This document describes recovery in terms of the Recovery Group even when the group is not exposed to the Team administrator in those terms.
> Implicit sharing
When a vault is created, a copy of the vault key is encrypted with the
public key of the Recovery Group. The members of the Recovery Group
are able to decrypt the private key of the Recovery Group. Thus from an
exclusively cryptographic point of view the members of the Recovery
Group have access to all of the vaults. Recovery Group members never have the ability to learn anyone’s account password, Secret Key, Account Unlock Key (AUK), or SRP-𝑥. Recovery is recovery of the vault keys; it is not recovery of account passwords nor Secret Keys.
Exactly: 1Password doesn’t have the keys. Recovery works because the vaults are encrypted with the keys of everyone in the recovery group. No “server side” encryption instead of end-to-end.
I have a similar setup, except I use Syncthing. Works fine with Keepass2Android/KeepassXC on both Windows and Linux machines.
Occasionally I might need to do some manual steps (a week ago windows stopped running Syncthing and that caused some conflicts down the road), but most of the time it just works.
How hard is it to store encrypted data that needs a locally held master key to decrypt? Pick any industry... You'd have to be willfully ignorant or outright corrupt to fail your core business promise, wouldn't you?
The average user that LastPass caters to thinks that a "backup" is the reason they were late for work in the morning. LastPass doesn't want to be in a position where they're telling their users, "Sorry you're SOL," if their device breaks and they don't have a second copy of their locally-stored encryption key.
[edit] I guess that's true. I'm not sure who their users are, but obviously not people overly concerned about security. [/edit]
Just because I think it's funny - every time I visit my dad (who's in his 80s) he regales me with his startup ideas. "Why don't you build something that I can put on my glasses so when I lose them I can find them? Whoever invents that would be a billionaire." I say, "Yeah dad, they have that."
"Why don't they make it so I don't have to remember passwords for all these different websites? I could just have one password and it would remember it for everything."
I think I've explained at least a dozen times why I think third party trust is a bad idea; I've had to really refine it down to the level of explaining this to a six year old.
But the salient point here is that even my dad never signed up for LastPass. So who the fuck is signing up for LastPass?
It all depends on how the data are encrypted. With a sensible design capturing the encrypted storage will only reveal the number of encrypted records, rough estimates on their size, and time stamps.
Ideally it would be an opaque blob with no information about the number of records or their size, just the total size and maybe a last modified or accessed time.
Password managers typically offer to store images like document scans. Without per record encryption one needs to send the whole encrypted blob on each modification.
Not necessarily. You can have a write-ahead log which also consists of opaque blobs and which other devices can pull and reconcile on their own. At some point, a whole reconciled version is uploaded.
They’re not worthy of having any law named for them, even a negative one. Really wish there was a Software Hall of Shame where they can go rest in infamy.
> The more a company asserts that their data is secure and encrypted and you should trust them, the more likely it is to leak and be proven to be massively vulnerable.
That's a consequence of the Murphy's law [1].
Very well written. You phrased it perfectly for it to have its place at [2] which is full of this kind of stuff. It's almost like this sentence claims itself the right to appear there. If you read French you might enjoy this website. If not, you might still enjoy the different phrasings of Murphy's law in different languages here [3].
Doesn't necessarily mean it's safe. Say there's passwords accidentally appearing in logs as part of a traceback - even if the passwords are kept encrypted, just having access to the logs is enough. Even if everything is encrypted client-side, it could appear as part of a client crash dump being sent by telemetry. Leaked plaintext databases aren't the only possibility.
Bitwarden caches Web urls as well on its browser extensions.
Sometimes it knows that you have saved login for the specific web page before you have logged in. Certainly LastPass had urls unencrypted for this specific reason - to show users that you have saved login for this page, would you like to login?
It is the endless usablity vs. security battle. Of course, there are better ways to implement this than LastPass has done.
Bitwarden, Keeper ($ but trusted at megacorps), and good ol' PasswordSafe are the safest solutions.
I run BW with Yubikey 2FA and a local hosted sync server.
KeePassX/C perhaps. Vault for secrets management.
Never touched LastPass, 1Password or any of these other mickey-mouse commercial apps that invariably claim "military-grade encryption" or "unhackable" when their fundamental constructions are crap.
I see a lot of people mentioning bitwarden around here; is their actually a technical reason to believe they are better than Lastpass or any of their competition (have they like open sourced all their stuff?).
There’s very little room for failure and learning in the online password safe field, so I generally assume these companies are in one of two states:
> is their actually a technical reason to believe they are better than Lastpass or any of their competition (have they like open sourced all their stuff?).
I choose to use their clients unmodified, along with an instance of the server formerly known as "bitwarden_rs" running in my basement as the sync backend.
https://github.com/dani-garcia/vaultwarden
I still pay them annually for their "freemium" features even though I prefer not to let them host my data.
Do you expose your server to the internet or is it ok to sync devices only when you’re at home? Is every device a replica, if you lose your server can you redeploy it from the data on your device?
Not the parent, but I have been hosting a Vaultwarden instance on the public internet for about two years now.
After learning about certificate transparency logs, I moved the app from a raw subdomain behind a secret URL path. Think “hello.domain.com/correcthorsebatterystaple”.
Is it security by obscurity? You bet. Does it work? Yes. I regularly evaluate the JSON logs emitted by Caddy in a pandas script and so far, no foreign party has even hit that endpoint.
It’s like an extra username of sorts you’d have to know. I’ve always been unsure of where to draw the line when it comes to obscurity. People online are viciously against it, but isn’t a password also just obscurity, if you squint your eyes real good? It’s all secrets users would need to know.
All that being said, I’m thinking of hosting it at-home-only as well. Would be a huge win in security and barely any loss in convenience.
I’d say the things hitting your endpoint are going to be entirely automated scanners that are looking for unauthenticated resources or low hanging common passwords. If you have even a moderately strong password, it’s just noise. I’d be wary about drawing any significant conclusions from logs, because the sophistication of attackers you’ve excluded are quite low.
I’d say defense-in-depth is more about nesting strong cryptographic primitives, than simply adding layers. What you’re trading off for is complexity and convenience vs security. In the URL case, a password is more secure (and treated as such) and lots of care is usually taken to make sure the hashing scheme is timing resistant etc. I don’t know if Caddy makes equivalent guarantees, but I’d be very surprised if path matching was not just a string match/regex/trie. In terms of time to crack, just prepending these characters to the password would give you more protection, because that then has to go through a resource intensive hashing process.
An example of defense-in-depth would be to host at home only. Here, it’s because you’re nesting actual isolation (which is a good security primitive by itself), with a strong password. This gives you protection even if your threat model is “caddy is borked and is letting anyone do anything”.
Now in reality, you can do just about anything and it’ll work (because in the grand scheme, you’re probably not a high value enough target for any high cost attacks). If you secretly happen to be, then you can afford an actual security audit, rather than relying on random info from HN :)
> I’d say defense-in-depth is more about nesting strong cryptographic primitives, than simply adding layers.
I like this insight, thank you.
One rebuttal I have: appending those characters to the password would make it a stronger password, but it wouldn’t add another, wholly different, mode to authentication. It would be the same thing, just harder (and I don’t need a longer password as it stands). What if this mode is flawed in itself? That’s when a wholly different one is desirable.
In that spirit, I had also thought about just slamming http basic auth in front of everything. Even if that basic auth uses weak credentials, it adds to security in a multiplicative/exponential way (multiple passwords/systems), over just a linear one (single but long password). I suppose that’s also what you mean by layering.
Linear/multiplicative stuff is actually quite helpful for discussing the path thing.
Adding a “password” path is actually only increasing your security by a constant factor per character because of the risk of timing attacks (unless you are sure that the path matching algorithm is secure against it now and in the future). Ideally a 2nd layer would guard against it in a multiplicative way (an entirely different with system).
Cryptographically, adding characters to the password rather than to the path is better (because it increases the search space exponentially) than adding characters to the path, which can be brute forced separately per character.
But this assumes a very perfect view of software, where there are no bugs. Once you add a risk model for bugs, then there might be small values of path length where the additional constant factor is better than the multiplicative one that you get from adding characters to your password. So your rebuttal holds, depending on the exact bug risk model you have.
I think nowadays, tailscale/wireguard is really convenient and pretty secure as a 2nd layer. I was averse to self hosting my password manager in the past due to not being comfortable having the consistent time to secure more critical applications, but I might actually move to a world where I host more critical things myself behind a VPN.
I had a at-home-only version once. Then I failed to unlock my vault on my iPhone (FaceID issue or something) and it refused to allow me to enter the master key without first passing the 2FA check with the server (did it delete the local vault or something?!). I had to go home to fix it.
I’d recommend ensuring you have some sort of VPN solution so that you can access your vault away from home, too.
Personally, I just decided to use the 1st party server. I realized that reliable access to my vault is a service I really don’t want to be without due to technical issues in my setup.
I currently have my server at home connected via wireguard to a VPS. On that VPS, I run Caddy and have it reverse proxy back to my server over wireguard.
If I were building it out today I might just use tailscale and be done with it.
I'm not sure about whether every device is a replica of the server. I believe that's the case (given how they behave when the server is offline) but that doesn't figure into my recovery plan.
But in the case of the mobile apps, downloaded from their respective platform's app store, how can you guarantee the code you see on github is the exact same code you're running on your device?
Admittedly this supply-chain-verification is an issue for all mobile app store apps but seems particularly important with something like a password manager.
In a perfect scenario you would be able to use a reproducible build [0], for Android you can actually get Bitwarden from F-Droid [1] which uses those reproducible builds.
For Google play store, there was also that developers needed to sign their apps before releasing to stores, so you knew that it came from developer, but Google removed that when they introduced app bundles. There is still a way to verify if the build is the same as developer provided, but automatic protections that were there are now gone [2]
Looking at that, it doesn't seem like you can actually get Bitwarden from F-Droid? That looks like instructions to set up a third-party repository (hosted by Bitwarden)?
The page didn't mention anything about reproducible builds. (Doesn't mean they aren't using it though, but that would be internal.)
I may be wrong, the idea is interesting but looks more like a password generator and a terrible password manager to me.
You still need to store somewhere informations like url, username, counter, etc. right ?
Can you change the master password without changing all your accounts password ?
If one happens to find your master password, he's basically able to get/generate all your passwords just like a normal pw manager with no 2FA, correct ?
You have it right. This master password derived passwords idea is nothing new. Few people actually use it because it's not actually a great idea for the reasons you listed.
Except or unless your google account gets locked. Any number of reasons and posts HN horror stories exist about other users getting locked out of their lives because of a user account or lack of access thereof
That’s a risk. I pay for my account to try and mitigate this risk so I’m the actual customer, not advertisers.
Google workspaces has a support assisted recovery option. I host dns separately from google as their admin level recovery may require some dns signaling.
Other steps include a yubikey etc . I’ve actually had the experience of losing all my Authenticator codes on an iPhone upgrade which at the time was how I did 2fa - so had to go through recovery for many providers. My top takeaway - if I was paying for service it was possible if sometimes a bit time consuming. If I wasn’t it was hit or miss.
Other tip? Google Authenticator may not backup to iCloud!! I had 20 codes in it including some really hard to fix ones.
Items contain overviews and details which are encrypted separately
by the vault key. We encrypt these separate so that we can quickly decrypt the information needed to list, sort, and find items without having
to first decrypt everything in the vault.
Item overviews include the item fields needed to list items and to quickly match items to websites, such as Title, URLs, password strength indicator, and tags.
Additionally, 1Password makes the extra effort to never even send the URLs of your accounts to their servers. Even with their Watchtower service, which notifies you of breached accounts and websites that support 2-factor authentication, your passwords and website URLs are never sent to 1Password servers.
I had been a very happy customer for years before they started moving to that policy. It's what finally made me set up a vaultwarden instance and migrate all my stuff over.
I didn't like the move to a subscription model, but I'd have sucked that up if I could've continued to bring my own sync.
For those of us that have been using it for long enough, we can still use the "classic" version stuck at v7, but it means being able to self host. no monthly SaaS fees.
From what I can tell, v7 is Intel-only. That means when Apple sunsets Rosetta 2, it’s not going to work anymore. I’ll need to switch to something else before then, but hate Electron, and all the other options seem to use it (and now 1Password does, too).
That's a good catch. I'm still on a MacTel MBP, so this is not something I had ever considered. That's going to be just one more reason I'll keep the current laptop powered up on a shelf in the closet if/when I upgrade to a newer computer.
I would hope not... that term should be reserved to indicate that the data is encrypted on one of your devices and is merely passed encrypted through their servers to your other devices.
So is there any way to verify what this person is saying? I mean, from the way LastPass is evolving it doesn't seem unlikely to me -- but why is this tweet on HN? Is there any supporting evidence aside from an anecdote, does this Twitter account have a strong reputation of being credible, etc.?
Without context, I just don't understand why this anecdotal thread should be considered credible.
Disclaimer: I use FOSS password managers for everything possible but have to use LastPass for some non-personal stuff and I very much dislike it
It seems like a reasonably well written anecdote by someone who has some idea what they're talking about. It could obviously be false, but the consequences if he's right are potentially serious for a lot of HN users who might use LastPass. The consequences if he's wrong are a little extra reputational damage for LastPass, but that seems like a worthwhile tradeoff here.
Not everything posted on HN has to be verified true. The decision calculus here seems strongly in favor of signal boosting it, so that people who need to can take defensive action, even if it turns out to be wrong.
It's like a novice programmer blaming the compiler for a bug in their application. It's very unlikely to be true. What would you have the people who are using LastPass do, stop using it? Because some crypto dude stored their highly valuable keys in a system that literally copies their keys to any system they log into, to systems that are notorious for having very leaky abstractions and vast vulnerability surfaces?
> It's like a novice programmer blaming the compiler for a bug in their application.
The big difference between the two examples is this: LastPass is known to have bugs. Huge amounts of data were stolen from them and we just found out that it was a lot more than we thought.
For all we know, they were storing passwords in the clear somewhere.
Trivia note: the first compiled language I used was PL/I, and the compiler was notoriously buggy and would crash on well-formed programs. Our teacher told us to put do-nothing statements in when this happened (`PUT SKIP(0);` if I recall correctly), and with some trial and error, those would fix it.
> What would you have the people who are using LastPass do, stop using it?
Yes. After their last major breach I exported all my data and deleted all my credentials and account with LastPass. Seeing the details of this breach, I'm super happy I did.
I meant the major breach before this one, I believe that was the one that gave attackers access to their dev environment, which they used to steal the developer credentials they used to make this attack.
I don't agree that was enough of a reason to drop them. An attacker getting access to your dev environment, even if you're one of the largest security focus endeavours, is pretty much an inevitability. Someone's gonna get access to one of your engineers macbooks, no matter what.
The thing that's bad, is that apparently their developers have access to (backups off) production data. That implies that their security infrastructure is not different from regular startups at all so all of their marketing is just bullshit. They didn't sacrifice developer productivity for security on this point, so they can't be trusted to have sacrificed anything for security at any point.
It's a solid point, you really need to rotate all the credentials to be safe. I did that for the important accounts and don't share passwords between accounts. I'm sure there are still a few accounts here amd there that might be at risk.l, especially since it was specifically the backups that were compromised.
That's subjective and has no value in determining whether the post is true.
"Not everything posted on HN has to be verified true. The decision calculus here seems strongly in favor of signal boosting it, so that people who need to can take defensive action, even if it turns out to be wrong."
What? Proven true, no, any sort of evidence, yes. As for taking actions, there's a cost.
Why not? I have a security background. I see nothing wrong with that statement. Although what he actually said was:
"Initially I imagined I was targeted by a 0day or rootkit"
which actually does not make sense, because it implies he thinks those two things are fungible. He's obviously not a security expert, but he's also obviously not totally technically incompetent.
It's quite unlikely someone would risk burning a viable 0day without either going wide (and then we would've heard from a few more people) or going after a well outlined target that would be guaranteed to be worth more than the 0day itself.
The person in question is very wealthy. I know at one point his portfolio was 9 figures. That may have been at the peak of the bull market but I imagine path is still very rich. Is it worth a 0day, still not sure.
I guess my prior based on the way this guy was talking was that he probably had at least 6-7 figures in crypto stolen, which is worth it for a mid tier 0day. Especially if you think it's unlikely to actually get burnt.
To explain your comment a bit: It should be 0 day AND a rootkit, not OR. Plus the rootkit is not always needed or possible.
Also the people talking about “burning zero days”… every time you use an exploit (ignoring the exact meaning of 0 days) it doesn’t become burned by the first person. The hacker could use it on hundreds of people before it’s discovered and patched by whatever software it targets. That could take months.
It can certainly be "or": rootkits can come from your machine's supply chain, and lie mostly dormant for many months or years before activation. Rootkits can get installed after a non-zero-day-entrypoint vector e.g. simply tricking the user into running downloaded malware. etc.
If you have a security background then you know that 0days go for 6-7 figures and it's unlikely somebody would burn one of those on some random dude.
Way to make yourself feel important. It's not that you made some terrible choices yourself, like using a known-insecure password manager SaaS, or putting real money into crypto. Nono, somebody pulled a 0day on me, what can ya do? Shrugs
This. Why would we be critical of LastPass being secretive and/or wrong and then take a tweet at face value?
From one of the tweets:
> I did not download anything. My machines are clean, and I have physical 2fa on everything. None of the links or contracts I interacted with were malicious. Nobody else had physical access to my PC.
Yeah sure. Sounds like my aunt when she messed up her PC and loudly claims "but I didn't do anything!" Surefire sign that she did. Turns out it's true, every time.
I have no idea what this has to do with this discussion, and this just comes off as an ad hominem attack. Flat earthers claim that there's an economic interest in lying to them? And you think that claim is particularly genuine or even similar to this argument?
> You don't know if this person has nothing to lose
It is possible that they have some competing business and are trying to damage LastPass, but there's absolutely no evidence of that, nor any suggestion other than to double-check your credentials and your expected security if you are a LastPass customer. So, if they do have an interest, they're doing a particularly bad job of acting within it.
> Even if they have nothing to lose that doesn't mean they are being honest.
And we're not going to reach 100% certainty of any fact through discussion on a message board. It is interesting that some people spend a lot of effort trying to ensure this obscurity gets injected into the conversation, and it suggests that their own motivations should be questioned.
All in all, on the balance of apparent probabilities, there's more reason to trust this person than not. You can attempt to assail that logic if you like, but I would appreciate it if you stuck to the facts of the argument instead of kicking up dirt.
I personally don't use LastPass due do their history of failures. My point is that the tweet in question and people around here are insinuating that attackers have gained access to unencrypted passwords in the infrastructure of LastPass. This would a new low for LastPass and I would advice to not jump to conclusins gegarding this aspect unless other stories like this pop up, i.e., passwords getting hacked despite being resilient against brute force attacks.
Quite obviously there isn't anything and the handle indicating a crypto hack it's as non-credible as anything can be but some folks on HN still fall for the crypto hype.
This is your regular reminder that all crypto is scam , this is a simple mathematical fact.
This is why Microsoft's requirement to drink a verification can was so genius. Imagine being a hacker and have to drink multiple verification cans to be able to proceed throughout multiple transactions. "Hacker dies from overdose due to ingestion of too much Doritos and Mountain Dew"
Wait, so you're telling me that Cloudflare interstitial is running some PoW check on my client? I always thought that was just a way to let the user know they're being rate limited on Cloudflare's end.
Effectively yes. Not mining bitcoin, but modern bot detection works by asking your browser to do various tasks and comparing the results to a known good sample.
It could be a complex math problem, or another common trick is to purposely trigger bugs like a javascript engine not rounding numbers correctly in edge cases.
The inference that the LastPass leak is responsible is being made purely on the basis that this particular person can't identify any other way the security of their wallet was broken. That seems a very weak basis (essentially, absence of evidence equating to evidence of absence) to make what is really a very strong assertion.
I agree: LastPass has been hot garbage for many years but it still has a significant presence, some guy’s low-value crypto wallets would not be the first we hear about a compromise of LastPass vaults. There are entire companies using LastPass for critical systems.
I absolutely believe it’s possible that LastPass has been compromised more than they’ve let on and I won’t be surprised if we eventually find out vaults are vulnerable, but I don’t believe this is how it would play out.
Sunday the 18th is conveniently around the time of the latest announcement, but not the time of the actual hack. Feels like someone is over fitting.
But if you had a ton of credentials from people, scanning for crypto credentials and trying to use those may be easier/faster/safer to turn into money than system credentials to some random company network.
If the hack of LastPass happened yesterday, sure, but it happened months ago. There are a variety of different attacks that could be executed in that time, and the sooner the attacks are executed, the better — because less time for credentials to be rotated.
I find it implausible that the first hint of vault compromise comes 4 months after the hack and is against a low value cryptocurrency wallet. Especially considering that when LastPass first had issues, there were dozens of people reporting personal experiences of it here on HN — if LastPass vaults are compromised, the internet would be flooded with reports.
I largely agree with you, however it may also be the case that the attackers have been working on cracking vaults quietly since the hack and the announcement made them go after everything they had cracked so far instead of continuing to work quietly. They might have decided the crackable vaults don’t rotate credentials within them often, but it becomes much more likely after the announcement.
They weren't really credentials, but keys. Pop those into any compatible wallet and you control the money now.
If someone had put the key in the URL field (because there is no corresponding URL because it's not a credential), and the URL field was unencrypted, that could account for it.
You would hope, but I've been working in customer/technical support in the crypto industry since early 2017. People are not remotely as careful as you would expect (and hope for) them to be.
This attitude is why a poor person will effectively be put in debtors prison and no one bats an eye. It requires "someone important" before people think maybe it actually happens.
This is quite interesting. A couple of weeks ago, I received an extortion phishing email, but it was directed to a secondary email address that hasn’t been previously compromised. It made it past Gmail’s spam and phishing filters into my inbox.
Maybe a coincidence, but I guess every weird thing that happens is going to raise alarm bells.
I was suspicious of the LastPass concept (storing passwords in a cloud app) when a former employer introduced it some years ago, but they had a strong IT and security culture so I trusted them to make the right choices and adopted it for my personal use.
A few months ago I hsd an issue with my LastPass 2FA device and a policy set by my former employer blocked me from resetting it for my personal account. It was resolved by LastPass, but that was the first strike, and I had spent most of the night extracting my personal account passwords manually from the mobile app, which remained logged in. That was strike 1. This is strike 2.
I’d love to hear the story about bypassing/resetting that 2FA setting? Sounds suspiciously like something that could be social engineered around by a sufficiently skilled attacker?
I am very much of the opinion that if I fuck up my side of 2FA protection, the resources/accounts they’re protecting should be lost forever. (Or at the very least, a co-account holder might be able to reset some things, like my AWS IAM creds or GSuite admin account). If I can ring up and whine at enough support people to get them to hand over my account, so can a sufficiently persistent skilled social engineer…
Any two factor that doesn’t require your firstborn or travelling in person to some frightening building to remove is basically a form of security theater. Most can be removed by support pretty easily just by asking.
Why would support be in the business of removing it just because someone asks? If I needed it removed I could take a call at my official phone number and photograph my actual ID.
My cell provider requires a photo ID in person or a long pin not stored in the same place as other passwords in order to assign my number to a new phone and 2FA to access account.
This raises the bar from knowing my password to knowing my password, knowing my ID, producing a fake facsimile of my ID, stealing my pin from its encrypted container on my desktop, taking over my phone number, then taking over my account.
I don't have a pile of crypto to steal ergo this would be a LOT of work to send spam as me until my email gets flagged. It would be like a heist movie only with the target being the $40 in my wallet. mission impossible themesong begins playing
Basically support just needs to exercise reasonable caution when removing or changing it.
On a balance of risks, your your former employer may have made the right call. The issue is, do you use something that isn't perfect but everybody can use, or do have a substantial portion of tech illiterate people not use anything, which would be an even greater risk.
I think the policy is fine, but since I left my former employer more than a year ago, the policy should have been lifted on my personal account automatically (assuming that my former employer deactivated the work account, which I expect that they did).
Same thing for me with sudden spam emails. But the receive address did not have the customization for me to track it, instead my first name. Not sure if lastpass related but maybe.
BTW one client of mine runs a heavy security operation and they use KeePass.
This is ultimately a predictable outcome for any password manager that stores your credentials on someone else's server.
Just like they say in crypto "not your keys, not your crypto" - it applies here too. Not your storage, not your passwords.
KeePass on an airgapped box, or an encrypted hardware password manager with no network interfaces is best, though frankly, I'd even be more comfortable writing down passwords on paper (at home) than I would be storing them on someone else's server.
I say all this as a big tech red teamer, or, someone who breaches other people's servers for a living.
though frankly, I'd even be more comfortable writing down passwords on paper (at home) than I would be storing them on someone else's server.
100% agreed. Physical access is not something than an attacker, especially one likely to be in an entirely different country or even continent, can easily achieve.
A password manager is probably the worst possible candidate for being a cloud service. "Your entire list of passwords" is the one piece of data you absolutely, positively, do NOT want stored in the cloud. How these things gained such a following is mind-blowing.
Honestly, though, it's not that bad of an idea. Provides just enough convenience for people to use unique, randomly generated passwords for each login. Much worse for a website to leak the credentials you use for a bunch of other accounts. Using a pw manager and 2fa is imperfect but still the sweet spot in my opinion.
The idea of using crypto wallets as canaries is an interesting one, however. I bet you could set that up to only be tripped by a major compromise.
And yes - there is basically no way to actually prove that your passwords on a server aren’t accessible to someone - especially if they can update software.
For personal use, I use KeePass on my "offline box", which is an airgapped machine running Qubes with full disk encryption. KeePass is in it's own Qube, along with a few other offline things in their own qubes (hash cracking, archival storage for old media/files/projects, offline copy of wikipedia, offline maps/nav, tons of old training content for certs, so on and so forth).
Is it inconvenient at times? Yes. But I spend so much time at my desk, that those times aren't super common.
On mobile, my personal daily driver is running GrapheneOS, but I do not keep my passwords on it.
I am unaffiliated with them, and this isn't an endorsement, but I just recently ordered a Mooltipass, which I intend to thoroughly audit. If it's security proves satisfactory to me, I may use one going forward in a limited capacity.
And when I say that I will stop using 1password when the local vault no longer works, people look at me like I'm paranoid and crazy.
I've looked at the white paper https://1passwordstatic.com/files/security/1password-white-p..., I think 1password has a decent security posture for their cloud offering but then there's always the risk of a breach where the attacker controls the site and can intercept your master password through it. Same as what happened with British Airways or Lavabit.
There is always the risk of an attacker infiltrating the company to write vulnerabilities or a government forcing the cloud provider to write malicious code in order to degrade security. That's what the U.S. government almost succeeded at forcing Apple to do in the wake of the San Bernardino case.
A local vault is better than a cloud vault, but if that local vault software is written by a commercial company there's still that risk.
My understanding is the app decrypts the vault locally. I guess they could put out a malicious update but then you’d be impacted whether there was a cloud-free option or not.
Yes, but I think it would be harder to push a malicious update especially since currently 1password doesn't send information on the license when checking for updates. So a malicious update wouldn't be targeted as easily as logging in a web app.
Additionally exfiltrating the data would be harder for a locally stored vault..
Or controls one of the many apps. Every time I install the Firefox extension I wonder if I’m really able to be sure that I haven’t been directed to a compromised version or lookalike.
Having all your keys/passwords on a 3rd party server is something that I've never been willing to accept from a security standpoint. That's what always kept me from using a `hosted` solution. I do get the allure from a multi-user management aspect though.
FWIW. After using it at my previous workplace, I got a 1Password family account.
It’s got my (not particularly technical) wife using unique strong passwords for all her online accounts and made family password sharing easy. I think the convenience of the cloud is key to this.
I get that there’s a security risk that 1Password gets compromised and the app is infected with malware or there ends up being a vulnerability on their encryption scheme but it still feels like a net improvement to my overall online security.
Also MFA can help mitigate the risks of the passwords being compromised.
Is the added security just that Dropbox is a lower value target (possible) and that attackers won't think to look for password databases in Dropbox accounts if they do compromise Dropbox (less likely)? Or is there something more to it?
EDIT: Given the replies below, I should be clear that I'm not interested in comparing to LastPass, I'm comparing to Bitwarden. LastPass had an obviously bad security model that failed to encrypt everything, but Bitwarden does not have that flaw.
Drop box is just the sync mechanism, with keepass' encryption (and their own care to keep the keys safe and not carried on the same medium) being all the protection.
Dropbox is not added security in this setup, it is a natural factor if what is being transferred [the keepass file(s)] is sufficiently secure in itself.
No possibility for a MITM attack (except, I suppose, with a keylogger, but then you've got bigger problems), and absolutely NOTHING outside of encryption, whereas whoever has this leak now knows what users have accounts on what websites, which is a veritable treasure trove.
That plus security through obscurity: no one is presuming you're going to come out of a Dropbox hack with millions of password vaults. Even finding them would be... nightmarish. (Though I suppose you could somehow hack a Dropbox file index database?) The value of a target like LastPass is absolutely insanely high: it's a concentrated honeypot of encrypted vaults.
Plus, the Android app makes using a Dropbox synced folder location fairly trivial, so that works pretty well. And you can set your own number of password rotations, which, while annoying when it takes my phone 5-10 seconds to unlock, realllllllly helps ensure no one else is going to crack this vault if they ever got it.
> No possibility for a MITM attack ... and absolutely NOTHING outside of encryption
LastPass is a disaster, but in theory these benefits are true of Bitwarden as well. They say they encrypt the entire vault, no exceptions, and do the encryption entirely on device.
I can see the honeypot argument, but Dropbox is also a big honeypot for different reasons (tons and tons of plain text information that could be very valuable in the right hands). And I don't think finding the vaults would be as hard as you think it would, because searching for encrypted files should be relatively easy, and any encrypted file is probably worth attempting to crack.
I'm not trying to argue for cloud password managers, I'm totally open to being persuaded and would immediately switch if I were, but I'm really failing to see where the added security is versus Bitwarden. Bitwarden is open source just like KeePassX, so if it did not implement the security model that claims to I think someone would have blown a whistle by now.
No. When you login to LastPass, your password can be taken if LastPass is compromised. You have to trust that LastPass will not do it. If you login to Dropbox, the master password to your keepass database cannot be stolen. You don’t need to trust Dropbox.
In theory, the master password is never supposed to leave your device even with the cloud-based password managers. So, yes, you're trusting that their clients do what they say they do, and I suppose an attacker could hijack the client and offload your password.
That said, the same risk applies to any client you use. Someone could have compromised the latest update of KeePassX as readily as they can compromise LastPass's client. If you don't have automatic updates then that's helpful, but I'm not sure it's producing enough security to be worth the extra hassle.
Having to do it while updating narrows the window of opportunity for sure, but I don't think KeePassX is a more secure target than Dropbox or Bitwarden.
They don't have to get bad code into an MR (though that's one option), they could compromise the website and have it distribute a different binary. If you build it from source you're safe against that, but are you really building it from source?
Also, remember that the same logic applies to Bitwarden: they need the master password and therefore must compromise the client during the window where you update it.
The database is encrypted when at rest; i.e., no plaintext is stored on Dropbox. Assuming your master password is decent, you could plaster the database on a billboard and it would be safe. LastPass, on the other hand, encrypts some information (the actual passwords). The URLs and other sensitive information is stored in plaintext in the cloud. [Final edit. I swear.] As you note, as long as the entire blob is encrypted it doesn't really matter how it's replicated; BitWarden's one-stop-shopping can certainly be more convienent.
But that is the same claim that Bitwarden and 1Password make. Both insist that they don't ever see your master password, which means that your vault security depends entirely on it being good enough. And both encrypt everything.
Assuming that I trust Bitwarden not to lie about their security model, what do I gain by piecing together multiple tools to accomplish the same thing?
(Sorry, I turned around and made an edit, but not before you replied.) KeePass encrypts the entire database, all fields, as one giant blob. LastPass stores URLs and other fields as plaintext; these too can contain critically sensitive information. [Edit: (See I flagged it)] As far as know it wasn't LastPass's client that was compromised--it was their servers/data store.
Their software does see your master password. It may process it locally, it may not. If it's run in web client inside browser, that may change at any second. This may happen due to attack, their mistake, their dependency vulnerability or plain lie on their part. Fundamentally you need to trust them.
In case of keepass and independent sync(doesn't have to be Dropbox), software that sees master password doesn't need access to the internet. Can be even airgapped if you are extra paranoid.
So to sum it up: keepass + sync is better, because there's no single party that is even able to screw up you to the point of leaking your passwords. "Impossible to fail" is better than "they are doing their best, pinkie promise".
Also - why pay recurring fee for yet another cloud storage, when I just need plain encryption software.
> Their software does see your master password. It may process it locally, it may not. If it's run in web client inside browser, that may change at any second. This may happen due to attack, their mistake, their dependency vulnerability or plain lie on their part. Fundamentally you need to trust them.
All of this applies to KeePass, minus the browser extension bit (which is trivial to avoid by not using the browser extension). The only difference is that you can theoretically firewall KeePass from the network, which I'll grant you would make a difference, but the fact that you reserve that for the extra paranoid suggests most don't do that.
> because there's no single party that is even able to screw up you to the point of leaking your passwords
Again, only true if you block network access. If not, you have as many points of failure as with Bitwarden, because only the client needs to be compromised to get both vault and password.
> Also - why pay recurring fee for yet another cloud storage, when I just need plain encryption software.
Bitwarden free is plenty for me right now, so this doesn't play into my calculus.
Personally, I'm not interested in making the switch if I'll have to fiddle with firewalls on all my devices in order for it to be more secure for my current solution. It's not that this conversation is made me think less of KeyPass, it's that I'm yet to see a convincing argument that Bitwarden is worse than what I would end up with in practice by switching.
Still - cloud password managers are built to upload your data to the network and it's much easier to smuggle something, when keepass apart from maybe update check doesn't have any network activity. Someone would spot it pretty fast and that would be instant death for the project. On cloud solutions it may take years to be found, as demonstrated here: https://arstechnica.com/information-technology/2022/06/mega-...
That being said - bitwarden is pretty transparent in what they do, compared to the competition and I'm seriously considering giving it a try (but with self hosted backend).
You do not store the password on a password manager either. LastPass swears up and down that they never see your master password, all encryption happens client side. I can see good reasons not to trust LastPass at their word, but Bitwarden?
Doesn't KeePass use a single database file with no conflict resolution?
I looked at using them but ultimately decided against them, a conflict overwriting a password scares me more than even just using chrome sync and calling it a day.
It does seem to be solvable though. I could see myself using SyncThing+ KeePass if I ever became unsatisfied with BitWarden and I found an app without too many sync issues.
I loved a similar setup when 1Password used to make that easy. I am very grumpy about them bait and switching me to a cloud/subscription model. (But not quite grumpy enough to have done anything about it yet.)
Version 7 is still available on their website to download (if you have a key for it). Oddly enough they still do update it. It's what I use and likely will use until it no-longer works or there is some issue with it.
I kind of agree with you, but on the other hand, they are storing everything you give them using strong cryptography. If you fundamentally don't trust cryptography then none of those passwords you are worried about are worth protecting in the first place. So I'm not sure it's logically consistent to say that such a service should / should never exist on that basis.
Where I do think it resonates is fundamentally it's just a bad idea to centralize things like this. It may be a necessary to construct a commercial business around this, but centralising massive amounts of trust across unrelated entities into ANY party is just a fundamental compromise that shouldn't have to be made. We would all be better off with genuine decentralised infrastructure to make all this work.
What does irritate me is that all these companies are full of "zero trust" marketing spiel but their products always actually end up coming back to placing 100% trust in them in the end.
It's not the cryptography that I don't trust. It's the e2e implementation. I mean we wouldn't be having this conversation if it was just about the cryptography. Also, subscription fees are a turn off.
But you do not have the keys and passwords on that server. Only their encrypted forms. And the master password never leaves your machine(s), the sensitive bits are only decrypted locally.
This is reasonably safe, as long as you're careful with your master password, no different form GPG.
I'd still rather not let anyone have the encrypted versions of my keys/passwords. If the software is compromised then it's reasonable to consider the encrypted data can be brute forced with some time.
I'm not here to argue the merits of encryption. I understand it very well. I'm only considering my own levels of comfort and need to trust a 3rd party as well as pay a recurring fee to store my keys/passwords.
Encryption that can't be brute-forced within centuries, even with a quantum computer, exists for some time, and is not really expensive to apply, especially on such small scales as a password database.
Write yourself a graph of your core account recoveries, don't put those on. Just put your leaf accounts on (those that recover from the core accounts).
I use my own hand-rolled password management system. Everyone told me: "don't roll your own password manager!!"
Here's the thing: yes, my tool is probably less secure than a professional tool, by an order of magnitude. But it's also a far less attractive target for hackers. If you spend an hour to crack my tool, you get one guy's data. If you spend 1000 hours to crack LastPass, you get millions of users' data. The cost::payoff ratio for hacking LastPass is far better.
You can use one of the several password managers of the keepass family. They are local, you can share the encrypted password database with your other devices and maybe it has more features that one's own password manager. But by going DIY you probably learned more about passwords management than the average person.
Right, security advice is always given as though everyone will follow it and it has to work for really useless dummies that don't understand anything about it.
They also say not to roll your own encryption, but if you encrypt your data and then use ssl it does increase security. When there is some bug meaning your ssh key was easily guessable (happened with dsa keys) having that obfuscation will prevent bulk collection from doing things like keyword matching against your data. Doesn't work if everyone does it, but it does work.
Most of the time you gain the most not from state-level impossible to break security, because most of the time you aren't trying to defeat a room full of geniuses all working full time with you as a target.
I use keypassxc xc with the browser plug-in. Also have a very long master password on my yubikey which I long press to enter the master password. The I use one of the cloud drives to sync it. I never liked the idea of entering my passwords into a service like lastpass.
Not only that but there are security best practices you can follow when rolling your own that can keep your data reasonably secure. Enough so that the cost::payoff ratio is even worse and you're that much less likely to be hacked.
Please stop commenting whether you are a LastPass user or not. Some of your profiles on HN have an email address and in general all your comments are public so can be mined, plus "rich techies" could be prime targets for more direct and elaborate phishing campaigns.
For all you know, they are bots or shills to encourage actual users to comment.
Remember this?
<Cthon98> hey, if you type in your pw, it will show as stars
<Cthon98> ********* see!
<AzureDiamond> hunter2
<AzureDiamond> doesnt look like stars to me
<Cthon98> <AzureDiamond> *******
<Cthon98> thats what I see
<AzureDiamond> oh, really?
<Cthon98> Absolutely
<AzureDiamond> you can go hunter2 my hunter2-ing hunter2
<AzureDiamond> haha, does that look funny to you?
<Cthon98> lol, yes. See, when YOU type hunter2, it shows to us as *******
<AzureDiamond> thats neat, I didnt know IRC did that
<Cthon98> yep, no matter how many times you type hunter2, it will show to us as *******
<AzureDiamond> awesome!
<AzureDiamond> wait, how do you know my pw?
<Cthon98> er, I just copy pasted YOUR ******'s and it appears to YOU as hunter2 cause its your pw
<AzureDiamond> oh, ok.
Aren't we assuming at this point that the attackers have the complete customer list? I imagine that it would be way easier for them to have a script query that list directly and search for names and emails to find high value targets, rather than reading through HN hoping for a hit.
This is news to me. Was the customer list also stolen? Specifically, customer records linked to individual vaults?
My concern with anyone identifying themselves as being affected by this breach is that a 3rd party would be able to collect a lot of information about the user for a very targeted social engineering attack. Conversations here often disclose personal information such as approximate age, location, past experiences, hobbies, etc. It's a gold mine for social engineering.
> To date, we have determined that ... the threat actor copied information from backup that contained basic customer account information and related metadata including company names, end-user names, billing addresses, email addresses, telephone numbers, and the IP addresses from which customers were accessing the LastPass service. The threat actor was also able to copy a backup of customer vault data ... both unencrypted data, such as website URLs ...
Given how incompetent they've been, it would be safe to assume that the vault data is linked to customer account information. And because website URLs are included in the package, there is already tons of information for spear phishing, and any LastPass user here is probably already doxxed to the bad actor.
In general, you're right, but I really think that in this case the ship has sailed. The attacker has more information than they could possibly sort through by hand, they're not going to resort to reading forum posts.
I saw a class action filed. If the class is admitted I may opt out, I want compensation for each of the many hours I now have to spend rotating my hundreds of passwords. This is totally unacceptable.
You want compensation for rotating your passwords even though there is no evidence other than this random twitter thread that any of them are comprised?
You wouldn't normally be compensated for your own time lost in a matter that didn't actually cost you money eg actual time not hypothetical time lost from work.
Best to just use pass (https://www.passwordstore.org/) with your own gpg key rather than rely on any 3rd party service. Then set up a git repository on a (free) google cloud instance, (or even use github/gitlab), and you're set to sync your passwords to all your devices.
This is less secure than using keepassxc, 1password, or another application with a 1st party well maintained browser extension.
With keepassxc, 1password, or even chrome's password manager, if a phisher links you to "gmail.scammersite.info", even if it looks exactly like the real gmail login page, browser-integration will not fill in the password field.
With pass, the default flow is to copy the password to your clipboard, and paste it into the password field manually. That allows the above phishing attack to succeed.
For that reason, I would not rely on password store. If you want to control your own database, use keepassxc, and sync the kdbx file with either git, dropbox, or anything else you like.
I am aware password-store technically has browser extensions, but few people use them in practice, and since password-store doesn't have an idiomatic "URI" field for a password, it doesn't actually auto-fill by default in a way that stops the above attack.
As a bonus reason, password-store also leaks filenames (entry names), while keepassxc and most other options do not leak the entry name.
As another bonus reason, using gpg is a fraught pain in the ass, and it's such a sharp and difficult to use tool that it's actually harder to securely make disaster recovery plans.
There is a really good browser extension for pass, called BrowserPass. It has auto fill with phishing protection. There is also a good Android app, called Android Password Store, which does the same for all of my apps. Both use GPG keys stored on my Yubikey.
Passwords are per file. Grabbing a password by a Yubikey touch doesn’t expose other passwords. Per password sandboxing. With keepass, you open the vault most of the time to expose a less important password, and the entire vault is at risk.
Beyond Pass, you should be careful with the browser extensions (and browser in general ). There are a lot of them, never audited.
> Grabbing a password by a Yubikey touch doesn’t expose other passwords. Per password sandboxing. With keepass, you open the vault most of the time to expose a less important password, and the entire vault is at risk.
The entire vault is at risk only if the attacker has a zero-day in the browser extension, or already has local code execution.
In your threat model, which is more likely:
1. you get sent a phishing link and click on it, and then copy+paste into a password field
2. An attacker compromises your browser extension with a zero-day
3. An attacker manages to get local privileges on your computer, is competent enough to exfiltrate your keepassxc database from memory after you unlock it with your hardware token, but is not competent enough to exfiltrate your 'password-store' passwords, or browser session cookies, or whatever
That is way too much work. Doing work means stuff is happening and stuff means sidechannel attacks that someone else hasn't audited, because it's not an integrated product anyone would bother auditing.
In particular, I don't see how 2FA is possible with this, so shoulder surfing is a bigger issue.
I definitely trust Google or BitWarden more than a password I can memorize plus my own constant vigilance.
Ah, I stand corrected, I forgot about trusted hardware based 2FA.
Still, it doesn't allow SMS or email based 2FA as far as I can tell, since that involves a trusted server and doesn't mean anything in a trustless model where the server owner could just add a bypass.
This reintroduces phishing vulnerabilities that current password managers don't have, leaks metadata (which is exactly what's been verified to have happened with lastpass), requires separate management of your gpg keys, and lastly, hosting in git doesn't sync. If two devices change the same password file, you can't merge that.
Maybe this is terrible logic but I would never trust an app that had 120 reviews and what appears to be a single person as the app owner with all my passwords.
No, I think that logic is completely fair. From my experience it is dead simple and works extremely well, however, I think it's definitely good to vet apps in your own way.
If this was true, i feel like it would be a little strange for the attacker to use it to steal a small amount of crypto. Once its revealed how bad this is, there would probably be a small window before people change their passwords, i would assume attackers would either go for a big score before revealing this capability, or they would try to hit everything very quickly. Just hitting a tiny amount of crypto seems odd.
Seems very likely, it's now known (maybe always was) that metadata fields aren't encrypted. If Twitter poster added those keys to a 'metadata field's then they were clear text.
Reminder that in 2015 LastPass was acquired by LogMeIn, who then in 2021 announced it was spinning off back into its own thing, though whether that has happened yet is unclear.
If you look into what LogMeIn (now renamed to “GoTo”) makes… this doesn’t make me feel good about GoToMeetings, GoToMyPC, or join.me.
That's an interesting take, because for many of us, prior knowledge about the insecurity of GoTo products (not so branded then) were evidence that the security of LastPass was at risk.
I used KeePass + Dropbox/Syncthing for years, but eventually gave up. At some point I saved my KeePass db with a newer version (of the software and the DB format), and later found out that the newer software version will not run on an older version of MacOS that I still use on one machine.
I mean, I could maybe update the OS on that machine (not sure--it's over 10 years old) but at that point it was less work and less risk to switch to BitWarden. And the user experience is much better as well.
People keep asking: if you have family and you need partial sharing and full sharing as well as write capabilities on multiple devices at same time without messing up, keepass is insufficient.
That and you get to centrally admin this for others (employees, family members), fine grained access controls for business use, you don't have to host and secure anything yourself (e.g. Bitwarden), pretty good UX on all your devices. I had to use a shared KeepassX file in git for a project and it was a frequent source of problems.
I have >200 unique randomly generated passwords in my Keepass file for various accounts (granted, a lot of them are throwaway accounts). No way I could ever remember those passwords, so any attempt at using that approach would necessitate less secure passwords.
It is highly unlikely that the attacker was able to crack the encryption. It's also highly unlikely that Lastpass had an unencrypted copy of the vault. However we know that all URLs are not encrypted which allows to identify users who have accounts for particular services e. g. cryptocurrency websites. The attacker could mount targeted attacks only on these lastpass users to reduce the risk of raising red flags. For example the attacker can send very convincing phishing mails to target these individuals with 0-day exploits. But an alternative much more scarier scenario could happen if the attacker found a way to extract the lastpass master password by injecting malicious code into the lastpass extension of targeted users. The possibility of this scenario depends if there is a way for lastpass servers to inject code into the browser extension.
While this could be what happened, I suspect otherwise.
For many years, those of us in the cryptocurrency fields have said never enter your keys on a computer. Generate them offline on a hardware device and let that be it. The person making this claim clearly had to enter unencrypted keys into a computer to put them into his laspass vault. There are a number of malware variants that specifically target keys and search things like input fields in web forms and clipboards for those keys.
When I read their most recent email updating about the situation today or yesterday, I did get a definite chill down my spine. I've not used LP for a year or so, but my data (much of it now old) is still stored there, mainly left as a backup as I'd heard some people had some weird issues migrating to other password managers.
I had made a mental note some months back when this first happened I should really go through everything important in my vault and update all passwords to sleep more peacefully at night. I had also made a mental note at the time that if this situation were going erupt into something much worse, it would almost certainly be over the Christmas period when many people are not at work or their computers and it would be the perfect moment for causing maximum chaos and destruction. Looks like I now really need to prioritise that tomorrow. Really not what I wanted to be doing on Christmas Eve...
I'm not too worried because anything important that I have in LP is protected by 2fa. It's notable that the author says his accounts are protected by 2fa, but I don't understand how LP being hacked would allow an attacker to defeat that.
Just for your consideration, I'd bet good money that the 2FA only protects against login credential stuffing, but the vault data is only protected by your master password and can be attacked offline and indefinitely
I mean the individual accounts are protected by 2fa. I have an account or two where I know the password has been leaked but they're so unimportant that I can't be bothered to change the passwords. They still can't get in without my approval.
he said his seed phrases were in lastpass. There is no 2fa protection for private keys if the assets are in his crypto wallet and he's custodying them.
He said there wasn't much value in the wallets. Doesn't strike me as crazy to keep a small amount in something convenient. You see a similar convenience/security trade off made by big players, with immediate transactional needs satisfied by online/hot wallets and reserves held in offline/cold wallets.
I can see it both ways. It is putting all your eggs in one basket. The flip side is your vault is supposed to be protected enough that shouldn't be an issue.
Another comment rightfully points out that the vault itself is only protected by a password. I don't think that's protected enough if it's on cloud storage.
LastPass allows you to delete your account without entering your master password. If their infa is compromised, you don't want to enter your master password to lastpast again it case the hacker planted something in lastpass' client code to snoop entered master password.
What if this tweet was provided as "evidence" of the opposite claim:
> I think the situation at @LastPass may be better than they are letting on.
>
> On Sunday the 18th, four of my wallets were completely safe. There were no losses.
>
> Their seeds were kept, encrypted, in my lastpass vault, behind a 16 character password using all character types.
IOW, the honesty and integrity of the user does not matter. What matters is some form of verification of the cause of a breach, because this single post presents no useful evidence for determining the cause of the breach, most especially ruling out over-the-shoulder attacks.
What has confounded me for a long time is this question: are there no breaches of security cameras? I can spend time in a Starbucks and always see someone enter a password into some device, I do not recall reading that a security camera system has been hacked, yet I would assign an incredibly high value to security cameras in places like coffee shops, airports, hotel lobbies, etc.
Being unable to prove there was not a breach is correct because you are unable to prove there was a breach, meaning there is no useful evidence in the post.
As I demonstrated in what might be called talking past the sale, there are other attacks that have nothing to do with the security of the technologies used.
I don't know the person who originally stated this, but as the popular refrain goes: "security is a process, not a technology."
LastPass-the-company doesn't need to die over this incident, but I can't help but wonder if a kind of corporate panic will stop them from doing what they need to survive it.
I've been using LastPass for years. Looks like I'm going to have to export everything from my LP vault and import it into Bitwarden. Any downsides to Bitwarden that anyone knows of? I'm asking more about convenience, i.e. how well the browser extensions and Android app work and less about security.
I use LastPass at work and Bitwarden (technically Vaultwarden but same clients) at home.
I find that Bitwarden's UI is much less quirky, for lack of a better term. LastPass finds ways to consistently annoy me.
The commonly clicked secrets move to the top, I can see more than two items in the list, it doesn't forget me periodically, and when prompted for credentials I can't cancel it and get in anyway.
You can add multiple sites to the secret, not in some hidden menu in Bitwarden. That's handy for things like AD/LDAP credentials.
If you want to improve your security, don't export from LastPass. Instead, authenticate into each service with the creds in LastPass, change your password in the service, then save the new password into Bitwarden.
In general, one should avoid exporting/importing credentials. Instead reset them and save the new creds into the new place.
Switched from LastPass to Bitwarden some time ago. The only issue I had thus far was exporting the contents out of LastPass. Some of the special characters in some passwords did not export properly. I had to add those items by hand.
As for Bitwarden, I like the UI (iPad, Mac, iPhone) but routinely forget how to generate a new password - the function is buried inside one of the menu options. Other than that, I really like it. And, there is option to host your own vault.
Quick tip: if you have Bitwarden's browser extension installed, you can use Cmd + Shift + 9 (I'm assuming it's Ctrl + Shift + 9 for Windows) to load your clipboard with a randomly generated password: h4!E49vFcGEE%c#$HZ%z*3^5B
Thanks very much. I wanted to hear from others who've made the same switch, so this is really helpful. LP has been pretty seamless for across devices so I wanted to know what to expect with BW.
I moved to bitwarden and was happy at first, but after a while the app UIs were really annoying. They save/update password functions kept messing up and I would lose the password.
I eventually decided that the UI was too clunky to move my whole family onto and opted for 1password. Very happy with that choice.
If this is true there really is such low hope for cryptocurrency. If you can’t store your keys in a service like LP hardened via physical 2FAA. What’s left? Air gapped setups?
Passwordless might be the way to go. We (as a society) have been trying to do 2FA now wherever we can. 2FA can involve an authenticator app but it is easier with a physical key. That physical key by itself can obsolete the password for many uses.
The more numerous the places where we can abandon passwords, the fewer the secrets that we need to keep.
I don't know why, but I'm still a bit afraid of using security key everywhere.
I have an irrational fear of losing/breaking my security key. Even though I know my phone is fine and always with me (as a comparison).
I just set up a whole backup solution for my many self hosted applications, all encrypted with the keys safely in my password manager. Even uploaded to S3, because I figured if I'm paying for it, I could ID-and-support ticket my way to my data even if I lost my AWS credentials.
I don't know how to integrate a security key into this scheme. What to do if it actually gets lost ?
Will I have to use emergency codes for all the accounts ?
Can I make a backup of it somewhere ?
Would that defeat the purpose ?
I'll buy one someday, when I'll have all this figured out.
I think that worry makes sense. It is a good idea to keep a backup. For example, you could get two YubiKeys, use one as your primary, and put the other in a safe place as your backup.
It is a little bit of a hassle. But changing 200 passwords because LastPass was breached is also a hassle.
One option is to have two identical security keys. In general, you can't easily read the secrets from an existing key, but you can overwrite/initialize them to get two with identical data.
The problem with that is that it requires to have all these security keys available in order to enrol them, which is not possible if you want to store one of them in a different secure location. If you have two keys in your pocket, that's not much of a backup; having two identical keys means that you can enrol the one in your pocket and if it gets lost, the copy from your safe works.
This is the answer. The only advantage of passwords is that they’re cheap and universally compatible. PKI based solutions are more secure and more convenient. They cost a few dollars and there are too many standard, though.
Ultimately, I expect the biggest barrier to be mental. People have had mantra about passwords banged into their heads for decades that they have become synonymous with a secure system and people are suspicious when their device just lets them in with little to no friction.
I think lastpass is reputed to be bad compared to competitors like 1password. If you can’t secure your bike with a flimsy Kevlar belt, what’s left? A team of two armed guards?
Do encryption on offline computer with trusted open source encryption solutions. Why do you think bitcoin experts have always said to do everything offline?
I just wish Firefox would integrate Apple’s Keychain. I don’t know if it is even possible or not. But it is such a pain because I really am tired of all these password managers and also security breaches from multiple silos. Medibank has leaked all my data and now I have lastpass to deal with too.
I've been using KeePass for years and have recently switched to Strongbox which is an incredible app/ui to interact with Keepass databases for macOS and iOS.
The database is kept in sync with either Dropbox or iCloud.
I am quite happy that I am only using KeePassXC + Syncthing. My default assumption for these kinds of services is that they will be breached sooner or later.
I tend to stay away from centralized password managers like last pass too risky and too big a target. I use and recommend KeePassXC for local password management. This is a similar problem to keeping your crypto on a centralized exchange vs in a cold wallet. There are trade offs to doing it this way, but to me it is the best and most secure option. I rather control my passwords or keys than some company.
Is there a site or something where you can put in all the devices you own (e.g., iPhone, Mac laptop, tablet, chromebook, etc) and what features you want (e.g., adding a password on one device syncs it automatically to all other devices, offline useage, auto fill of browser form fields, auto saves now username/passwords, etc.) and it will tell you what password manager best meets your needs?
As far as I can tell BitWarden and Google are the two good ones. I use BitWarden.
My reasoning is anything new and experimental is scary, I want something with tons of users that's well established. If the community isn't all over it, it's probably not reviewed enough.
Open source makes stuff a little more trustworthy, but by itself isn't enough.
I also don't want to pay a lot for it, and many are paid.
The two big FOSS ones everyone knows are KeePass and BitWarden.
Keepass uses some single file database last I checked. Terrible for sync as the sync engine won't be able to automatically merge conflicts and you might get hassles.
That just leaves BitWarden, or just using Chrome because it's there, it's easy, and Google seems to be good at protecting you from everyone but them.
A few years ago, I made the decision to delete my LastPass account. At the time, I wasn't sure if it was the right move, but in light of the recent data leak, I couldn't be happier with my decision.
If you're in the market for a new password manager, I highly recommend giving Bitwarden a try. It's open-source and has a strong focus on security and privacy.
A _random_ 16-character password from all character types can't be brute-forced. A password made from common dictionary words, with numbers substituted in with l33tsp3ak, and an exclamation mark on the end, is a different story. Passwords like that would be sitting in precomputed hash lists already.
Ah, we both went on a tangent. The password in question is to the twitterer's LastPass vault, and so a precomputed hash list would be of no use, and since it's an encryption key and not a hash, there is nothing to salt.
I suppose the point was more that faced with many users' LastPass vaults there are more likely and less likely keys -- but they'll still have to try the keys.
I have no conclusions on this but kind of like in court, not the best idea to investigate your own personal breach but I get there is little choice for OP.
In my experience "I didn't click on any suspicious link" and similar user denials are exactly why you don't ask them that during incident response, instead you get them to give you all their browsing/download history/content so you can verify that.
It could be cookie theft (physical 2fa can't stop that) or consent phishing if they use oauth for their main lastpass login. As soon as this was noticed, disk/memory images should be taken of all devices with lastpass ideally so they can be investigated. I don't know if the victim here uses laspass on their phone for example or by new apps they include new browser extensions or updates to existing apps (supply chain compromise).
Being completely ignorant about how this works, why would a LastPass compromise result in passwords being exposed? Surely they themselves don't store unencrypted passwords, but instead the passwords are encrypted by the user's key? Or is this a compromise of the locally installed software?
The passwords are encrypted by a per-user key. That per-user key is derived from a password through a password based key derivation function (PBKDF). In essence, an iterative hashing function.
Many users don't use "good" passwords, so you use a high number of iterations on the KDF, to make it harder to brute-force an account's password.
Lastpass initially used 5000 rounds of KDF for old accounts. That's not a lot, especially today. They increased it over time to 100,100 iterations (which is better).
The data stored in a password vault is encrypted by a per-entry key, derived from this user password. If a user's password is weak, predictable, re-used, etc, then attackers now have an opportunity to decrypt the contents of their vault. Up until now, attackers generally have been assumed to not have access to user vaults, as that requires authentication (maybe including MFA).
No local software has been compromised, but getting a hold of the server-side backups makes it possible to try to brute force user's passwords in a way that was prevented by server-side rate limiting and MFA.
There is also some side information leakage from the server-side copies of users' vaults, like the URLs of websites in a given vault not being encrypted, and vaults being tied to user identities and contact info.
This tweet thread suggests/implies that at least one user has had a password compromised from information held in an encrypted vault. There's no evidence yet of a compromise of the locally installed software, but it emphasises the importance of changing passwords, moving to new wallets if seeds were exposed to Lastpass etc.
Eek. It is quite incredible they didn't have any kind of KDF upgrade system built into the login process, under the guise of "log in again please". And presumably no prominent permanent notification of your 500 rounds of KDF (!!)
It took rather a long time - a couple of minutes - to re-encrypt all my passwords, which presumably is why they didn't do it on login. But yeah, a notification sure would have been nice!
Interesting - I did the same on a bitwarden install just to test it, and it was instantaneous. From memory, BW has a single account key (encrypted by password) to facilitate this process, as well as a method to re-key the account (which would need to re-encrypt everything).
Wonder if Lastpass encrypted everything with the password-derived key directly, necessitating a full re-keying.
As a suggested alternative - I've been very happy with pwSafe. www.pwsafe.info
It's not nearly as convenient as LastPass, but likely more secure. It uses TwoFish with a 256 bit key length, which was one of the finalists for the AES standard.
Password managers should be offline. I use keepass and sync the key file across all my devices using a cloud service. Works great and is the probability that my key file will ever be compromised is very close to zero.
I’m wondering if leaving the URLs in plaintext was actually a good idea, here’s my reasoning:
With _random_ passwords which most LastPass users probably generated, the attacker has no way of knowing if a key resulted in a successful decryption unless they login to a particular site.
If the URLs were part of the encrypted payload though, a quick string check for “http” or “www” would tell them if a key was correct or not during their brute-force attempts. Maybe a silver lining?
What I find concerning is PKDBF was used, even https://en.wikipedia.org/wiki/PBKDF2 quotes PKDBF1 and PKDBF2,and that is recommended to use PKDBF2. Is there any evidence to show that they indeed rolled their own encryption rather than use a de-facto standard AES algorithm? Or is there something that is missing.
I have always used Pass [1], and while it is certainly less convenient, it doesn't really take too much extra effort to self host your passwords in a PGP encrypted git repo. Self hosting has drawbacks of its own, of course.
It was phishing and or extortion of a developer that for some reason had unilateral access to production databases and keys without any higher approval.
Most hackernews readers will have left LastPass after the amount of times LastPass has been in the news over the just 5 years wouldn't they? Genuinely interested if phone is still using it - by choice that is.
And so does sending your passwords to a phone or a home/work pc via chats or email, or using a single password everywhere, or maybe a couple of them with trivial variations. Cloud password managers wouldn’t even exist if people didn’t do much more stupid things to enter their passwords on a different device than the cloud could ever think of.
>And so does sending your passwords to a phone or a home/work pc via chats or email, or using a single password everywhere, or maybe a couple of them with trivial variations. Cloud password managers wouldn’t even exist if people didn’t do much more stupid things to enter their passwords on a different device than the cloud could ever think of.
"You should do something stupid because most people do things that are even more stupid" is not a good argument in my opinion. I've been in the computer/tech space for 30+ years without every sharing a password or doing something stupid with my passwords, and it hasn't ever been any sort of burden. Why is it so controversial among the HN crowd to simply be minimally intelligent and careful with your sensitive information?
May I ask how you accomplish this without any sort of burden? Because from my perspective, managing strong unique passwords for hundreds of accounts across desktop, mobile, servers, and other devices is a major pain and I’m tired of dealing with it.
It’s human nature to take shortcuts and develop bad habits when you’re dealing with a flawed system and poor tools that puts the burden on the end user to manage everything. And if I’m struggling with four decades of experience, how is the average non tech user expected to do it properly?
>managing strong unique passwords for hundreds of accounts across desktop, mobile, servers,
I have a couple of dozen unique passwords. The ones I use most frequently are easily remember with pass phrases and all are written down on a couple of sheets of paper.
>and other devices is a major pain and I’m tired of dealing with it.
You are free to sacrifice security for convenience, but don't cry about it when your security is compromised because you consider maintaining your security too much of a hassle.
>It’s human nature to take shortcuts and develop bad habits when you’re dealing with a flawed system and poor tools that puts the burden on the end user to manage this.
I would argue that outsourcing your "security" to a third party is a shortcut and a bad habit that compromises your security. If you can't be bothered to worry about your own security because you find it too much of a hassle, then you have nobody to blame but yourself when your security is compromised.
>And if I’m struggling with four decades of experience, how is the average non tech user expected to do it?
Most non-tech users don't have hundreds of accounts to manage. I would hope and expect that even non-tech users have the ability to use a paper and pencil, and write down their passwords. At what point are responsible, sentient adults expected to take responsibility for themselves and their own security?
>May I ask how you accomplish this without any sort of burden?
Being an adult who is responsible for yourself is a necessary burden. This is also true for your own security.
For enterprise customers, the usage of SaaS solutions is often:
1) Cheaper to manage than in-house solutions, and
2) A way to outsource and manage risks.
Please reaffirm my choice to pick you as our company password manager years ago before I research the ambiguity of centralized password management and make my own decision.
hah. For years I've been telling people I know to NEVER trust all their security to one-password services. Given so many tech companies penchant for playing stupid and loose with internal security without customers even being aware of it, this kind of thing was bound to happen. All the worse to trust a password vault service under the circumstances.
Too many people who should know better on this site itself kept recommending things like Lastpass... Incredible.
2. there was a problem with the encryption implementation by LastPass. likely this is the reason.
this is why you always encrypt crypto stuff with offline computer using well-vetted tools like VeraCrypt or openssl, and not rely on cloud storage encryption. Only you can do your encryption. relying on others doomed to fail eventually.
this sort of thing is why I append the name of the website + a unique identifier + password, so that I don't have to bother changing my password during such nonsense, ugh.
Doesn't that make your passwords predictable? If you use the same secret for every domain and now if an attacker figures out your one secret then they would be able to find out all your passwords.
A master password is at least generating random passwords though and encrypting the passwords themselves. Let's say your master password gets compromised, but not the password database itself... then attackers would still have no way to access your other passwords. With the method being described, simply obtaining the "secret" makes other passwords known without even needing access to the password database itself.
Eventually, some website you use is going to get hacked. They’ll have stored passwords as plaintext. From there, anyone who wants to hack any of your accounts knows your password format. It’s going to be obvious to them that they just need to replace the domain.
how would they figure out the unique identifier? couldn't you say the same thing about using an arbitrarily unique password and then a password manager. if your password manager is hacked then they'd get the encrypted passwords for all sites you use along with all the personal information.
of course, you'll say, don't use a crappy password manager. and that's correct. same reason I use a separate format for sketchy sites.
for what it's worth my format isn't really as described, but it is similarly deterministic, but not visually so. the cipher is basic enough to do in your head but complicated enough that you wouldn't know from a glance
a real password example for your scrunity:
m0m2a2yiplagsosowgolredd1o2t3c!o!m2
steps:
m a i l g o o g l e d o t c o m
strategy
zip
secret
mypassword123!!
offset (publicly determinable)
0
unique: 2022
m0m2a2yiplagsosowgolredd1o2t3c!o!m2
i use a password manager so the long text generally is irrelevant. the main reason I do this is because I don't feel comfortable needing my password manager. I like being able to figure out my actual password completely independent of a phone or internet or app.
the strategy depends on how sensitive the app is (strategies include: zip, append, vowel-zip, no-vowel-zip, num-zip, all the same but with a reverse-offset). unique is usually something like when I joined, or something determinable from the site and my head.
all of this seems much more complicated than it is. once you understand you could calculate the password in your head in a couple seconds.
It does reduce the search space for a brute force attempt. Depending on how short your identifier is. Also if two sites passwords are leaked it could make someone’s job a lot easier.
By your example, your passwords are a set of fixed or knowable data, plus a unique identifier that in your examples is three characters long. Therefore knowing one of your passwords gives all except three characters of every other password, thus making your effective password length three characters (substitute the actual length of your unique identifier if it's more than three).
Sure, that's slightly better, but you're putting in quite a lot of effort for minimal reward - there still isn't much entropy here compared to the size of the password, and you're relying on security through obscurity (that no-one will work out your method). Password crackers on modern GPUs can chew through many millions of guesses per second so having such a significant leg up would likely make your strategy trivial to break.
Also plenty of perfectly respectable sites have been compromised in the past so your estimation about how safe the site is unfortunately doesn't help much.
I really think you'd be better off using long randomly-generated strings and keeping multiple backups of your password database. There are lots of options that don't put you in the hands of a third party. All (?) sites offer password reset facilities in case of emergency, and you could memorise your email account password so that you can always at least get into that.
the main goal for myself is to be able to have complicated passwords and remember them without a computer. the problem with all password managers is ultimately it must be possible to get them in plain text by design, so if someone gets that they get all of your passwords.
it's deterministic, but obviously I can't tell you the secret ;)
that being said there are a lot of things you could use. you could use information in the whois, you could use the birthdate of the founder of the site, etc.
personally I believe people should use the same password for all sites and then something similar to what I described. though I use a password manager, I do always feel nervous about the implementation leaking out details
This means that if a breach reveals more than one of your passwords, the pattern is easily recognized and you just made ALL your passwords extremely weak. Not a great idea.
> At Bitwarden we take this trusted relationship with our users seriously. We also built our solution to be safe and secure with end-to-end encryption for all Vault data, including website URLs, so that your sensitive data is “zero trust” secure [1]
I haven't used LastPass in years, but the recent news made me wonder how Bitwarden was handling URLs.
[1] https://bitwarden.com/resources/zero-knowledge-encryption-wh...