all the speculation in that thread about how the password could have been leaked reminded me of a post earlier this year that drastically changed my view on password managers. (also generated a lot of discussion here)
Some guy did an long analysis and figured for most purposes you are as well to use the built in ones in Chrome or Firefox. Personally I kind of like Bitwarden.
I'm not inclined to run anything that's remotely related to password security in a browser extension (I do use the Firefox built-in password manager to simplify logging in to sites like this one, where I have no money at stake and nothing much to lose but my pride).
For high-value logins, I use Passwordsafe. It's annoying; the scroll behaviour is annoying, and it's Windows-only, which is sad. But it's resolutely local and un-networked, and I'm confident that my secrets are well-protected by my (complex, long, memorized) master password.
Assuming you're talking about pwsafe 3, it's not Windows-only. I am actively using a Java implementation on MacOS and rely on my Android app for frequent use. Password file is synced across devices via a cloud drive provider. Works great, and I'm in control. (I also rotate my password file + master password every few months.)
Self hosting sucks for an average user, and terrible for a mobile user. It is possible to have hosted password solution that is secure, so why not use it?
This is basically the same "cloud" vs "on-prem" debate. Cloud won, I think.
That is not selfhosting. Selfhosting means web/cloud applications maintained by the users. Technically Syncthing is selfhosting but Keepass variants are not. So your setup is not really selfhosting because you are not hosting Keepass in the webserver.
I installed Keepass on my windows desktop along with iCloud drive sync. I keep my Keepass database in my iCloud directory. I can now use this Keepass database on my iPhone (via Files app), on my Macbook (iCloud Drive). Any changes made are automatically synced daily.
Is that really too difficult? And yes, it does "just work".
Bonus: Any passwords stored in my iCloud Keychain are also synced to my Windows Chrome instance via Apple's 'iCloud Passwords'[1] plugin.
For what it's worth, my attempt at using Keepass drove me away because the password database kept becoming conflicted, necessitating a merge. Keepass' options for dealing with conflicts were to "accept mine" or "accept theirs", but I'd often end up in situations where the conflict went sideways and I lost my login completely.
In the end I was running the conflict resolution command once every couple days.
Normally I wouldn't mind, but the only time the warning comes up saying that my db file is conflicted is when I need to enter a password in... which is the last time I want to be dealing with this.
This was Keepass with the db file on Dropbox, by the way. Not sure how Syncthing would handle it differently, but it wouldn't have anything to do with merging db files if they go out of sync.
are you able to sync your keepass database to your windows machine? i need to add this one drawback for people to keep in mind. and also because it happened recently and made hn frontpage. apple can decide to suspend your account for one reason or another. it is very rare but can definitely happen.
Securing a server is hard for the average user. But in any case LastPass uses E2EE so if the password was compromised that's most likely on client side, and for this self-hosted or not would make no difference.
It's about convenience vs security, and specifically, auto-filled passwords across devices and applications. Anything that provides such a feature will be inherently less secure than an encrypted file.
If LastPass and others are to blame for anything, it would possibly be their marketing around the this tradeoff, though I think they avoid direct misrepresentation by just avoiding the issue completely.
Selfhosting solution is not always the answer. It can be effective if everyone knows how to set it up. However, I imagine 90% (I want to say 99.99%) of world population don't have knowledge or the skill to set it up.
I tried selfhosting in the past and it is painful process to set it up since I don't have an experience with it and the documentations on selfhosting are barely minimal. I tried selfhost an RSS Reader (FreshRSS) through webserver that are closed off to the public network. It is rewarding BUT frustrating experience for me beacuse of how much it needs to be functional. And don't forget the difficulty of setting up a CA for the HTTPS (SSL/TLS), it is PITA to set it up and it kept having problems. I am considering Caddy server since it generates its own CA automatically. Their documentation are not beginner-friendly and requires some prior knowledge to set it up.
Self-hosting is slightly better as you are not creating a honeypot. But it’s not inherently more secure against client-side attacks (browser extensions, mobile apps), and adds its own attack vectors (put a contaminated version on DockerHub).
So original article is down, but this sounds like people who used the same password as their master and in some _other_ service that has been leaked. ie a user who's lastpass master pass is same as their facebook. Very different from having LastPass leak master pass. Is this the same issue or a case of LastPass not getting the situation?
> I guess they have no incentive to admit a breach
It's an interesting game: Reputation is essential to their business. Admitting a breach will harm their reputation, denying it and then getting caught will harm it a lot, but denying it without being proven wrong will probably harm their reputation less (than an admission).
Personally, I'd rather trust a provider that admits a breach, provides transparency, demonstrates good incident response, and hasn't shown complete incompetence from the breach than a provider that has credible rumors of a breach and no good explanation, but I think I'm in the minority here.
Notably, TeamViewer had one of these "rumors but denying a breach and claiming credential stuffing" cases (they later admitted that they also had an earlier but unrelated intrusion that they kept secret for three years, which doesn't help). I think that if it was more than credential stuffing (that's a big if, the credential stuffing explanation is plausible), the strategy worked much better than admitting a breach.
obligatory: I use passwordstore.org by Jason A. Donenfeld and its local, relatively easy to use, works with git, and free. Too niche for hackers to take interest I hope.
I used to use pass, and while it’s fine if you’re primarily a terminal user, it’s much less convenient if you’re dealing with Windows or mobile devices. Instead of fiddling with git and gpg (which is super painful on Android), I just use KeePassXC on desktop (Windows/Linux/Mac), Keepass2Android on Android, and sync my database via OneDrive. KeePass gives me search, storage of metadata and even attachments, simple copying, and auto-type. Much friendlier than pass ever could be.
> Some customers have also reported changing their master passwords since they received the login warning, only to receive another alert after the password was changed.
Must be a compromised browser extension at this point.
> To make things even worse, customers who tried disabling and deleting their LastPass accounts after receiving these warnings also report [1, 2] receiving "Something went wrong: A" errors after clicking the "Delete" button.
Is there anything more infuriating than this type of error message?
Ditto - I recently switched to BitWarden and kind of forgot that I was still giving it a self determined "trail period." This certainly kicked that trail period into my new current password manager.
If you Google for the error message you'll find that this behavior has been there for several years. I guess they just don't care about the usability in his part of the process. I tried deleting an account with dev tools installed and the web server gave HTTP error 500 (internal server error). I think the JavaScript just bails out at that point.
I had the same when deleting my account 3 years ago. LastPass is hot garbage and LogMeIm are the perfect home for it being a dumpster fire of a company.
>Must be a compromised browser extension at this point.
The previous thread had password never typed, copied or used for years. Unless we are talking about multiple vector, otherwise browser extension doesn't fit most of the reported scenario.
>Must be a compromised browser extension at this point
Just for fun, I downloaded the official LastPass chrome extension. The zip file is 32MB before unzipping, and it has 426 separate *.js files, total of 25MB of javascript. That should be a fun audit.
Edit: To be clear, nobody has said the LastPass extension is compromised, though that is one possibility.
Edit #2: Some of the larger js files do have a fair amount of the size as arrays of localized text, error messages, lists of numbers, etc. But it is still a lot of JS.
File count is not a good metric of complexity nor is an indicator of the quality of an application. There is a good chance a lot of that are packages that have been packaged up into the extension. Lastpass itself is not a super trivial application, either.
I think for a security application you want to reduce your exposure as much as possible, and one way to do so is reducing the amount of dependencies in your application. I think a high dependency count is orthonogal to that.
Nitpick: "orthogonal" would mean "independent of"; that is, a high dependency count has no effect on exposure. I think you might have meant "antithetical", meaning "in opposition to".
To be fair, orthogonal just means something that’s at a right angle to another line. I’ve heard people refer to something that is opposite, or an antonym to parallel (or in sync) as orthogonal.
Seems like a pretty good metric of complexity to me, particularly when it comes to a security audit. Having a lot of packages packaged up in the extension corresponds to having a lot of source code you have to vet, lest it be an avenue of attack.
"total of 25MB of javascript" is a good metric of the complexity of the application's code, and correspondingly the difficulty of auditing it (I'd say 25 MB of JS code make it infeasible).
File count and general "bloat" is an indicator of the quality of the engineering in the product. Especially for a security product _minimalism_ should be evident -- nobody with good security sense would want or allow anything not truly necessary to the product's functionality to be included.
There's a lot of room between "super trivial" and "needlessly complex" -- it shouldn't be either.
Trusting a cloud-based third party with my passwords is a non-starter for me.
I posted the GP, with the sizes, etc. I think they do have a somewhat hard problem to solve though. They probably also want to minimize remote calls so that the extension is functional offline, is more secure, etc. Which would drive the size up, especially with localized errors, etc.
> Just for fun, I downloaded the official LastPass chrome extension. The zip file is 32MB before unzipping .. total of 25MB of javascript.
For (a totally bogus but hey) comparison, I'm shipping products which include the Linux kernel, userland (busybox plus a pile of scripts and some daemons & other utilities), "the application" (two-three hundred thousand lines of C maybe?) plus deps (including sqlite, crypto libs, etc.) and the compressed image that contains all of this easily fits in 16MB SPI NOR flash with a few megs to spare.
If you measured the proportion of localized text and images in the 25MB of javascript mentioned above, please post these numbers. Otherwise nothing's been explained.
There's 4.3 megabytes of plain text in the KJV bible. Is LastPass' localization longer than the bible?
> Must be a compromised browser extension at this point.
In their 2019 breach, JS on arbitrary pages was able to access the contents of LastPass' own extension to obtain the last used username/password combinations. [0]
As, today, the extension now contains 25Mb of JS, making it difficult to audit, I wouldn't say that it has to be someone else's fault until proven.
For me I was able to reset my account (which removes all data) but not delete it. It appears to be an issue with their WAF blocking requests to the account deletion endpoint.
I did not get any email about login attempt, but deleted my old Lastpass account as a precaution anyways, and also received this error. No confirmation of deletion via email. However, I'm not able to log in anymore, and attempts to get master pwd hint via email don't work either, so I believe it's more or less deleted.
The whole service pretty much started to deteriorate after being bought. We have daily issues with initial logins taking maybe five minutes. I've also experience being told that my account was a "Free user" and I had zero password. Not something you want to see when working for a company that has 1000+ passwords in Lastpass.
Highly recommend 1Password with Yubikey/TitanKey protection. This means even if somebody had your master password and private key, they'd need a Yubikey to access your 1Password account from a new device. It's pretty much fool-proof unless you're kidnapped and held hostage.
I mean, if your threat model is such that you need to consider kidnapping and being hit with a wrench, as opposed to just a drive by breach, then you should in fact account for that appropriately.
I can smash your door in, or simply break a window. The difference is you’ll definitely know I did it. But unless you in the routine of checking your lock pins for scratchmarks, you probably wouldn’t know if someone picked the locks.
What if you’re in another country and your devices get stolen? Should you bring the Yubikey to travel? What happens if there’s a fire at your house and the Yubikey is destroyed?
So is the recommendation to get something like 3 keys and keep them in different safe places and bring one when you travel? I’ve been considering getting a Yubikey. Do they work on mobile?
Edit: Looks like some Yubikey work via nfc for mobile.
Yes, you should always have at least two and keep one in a reasonably fire resistant safe. You may want to enroll multiple and keep them in other places too, but you can't enroll a key you don't have so things like a safe deposit box are not useful for the average case.
I guess try to follow 3-2-1 backups as closely as possible:
3 copies of your 2-factor, 2 different mediums (a Yubikey and recovery tokens printed on paper), at least 1 in a different location (safety deposit box, trusted family members house, etc).
>You may want to enroll multiple and keep them in other places too, but you can't enroll a key you don't have so things like a safe deposit box are not useful for the average case.
That seems like a usability nightmare. Are there plans to improve this? Hardware wallets for cryptocurrencies seem to have it solved. You can keep multiple copies of the keys around (ie. multisig wallets) for maximum security, or you can write down the private key of the device you have and store it somewhere safe. In either case you can retain the public keys so you don't need access to the device if you want to send funds to them (or in the case of authentication tokens, enroll them).
Because each hardware key is unique, this is not a feature currently available nor likely to become available. Each token from the yubikey is not (readily) linkable to the key itself since the underlying secret is opaque and can't be exported, so tricks like Shamir's aren't readily possible.
Yubikeys do solve a lot of use cases very well but that is a downside to them. That is probably still a good tradeoff for most consumers.
>Because each hardware key is unique, this is not a feature currently available nor likely to become available.
You don't necessarily have to do it crypto wallet style and have the private key be exportable. Just adding a public key export (on the security token side) and a way to enroll a token by its public key (on the browser/website side) would allow you to enable 2fa without having to make a trip to the safe deposit box (either to store your backup codes, or to fetch your backup token for enrollment).
>Each token from the yubikey is not (readily) linkable to the key itself since the underlying secret is opaque and can't be exported
That's not an issue. You can derive more ECDSA public keys from a single master ECDSA public key[1]. The corresponding private keys can only be derived using the corresponding master ECDSA private key, and the generated public keys can't be linked back to the master ECDCSA public key. Bitcoin hierarchical deterministic uses this property to generate wallets that don't need regular backup (all your addresses are derived from one key) and apple's find my network uses something similar.
It looks like Yubikey supports ECDSA keys as of 5.2.3 (Yubikey 5+ devices) and will export the public keys and allows private key signing so this should be possible. It will be an irregular yubikey flow code wise but user wise will appear normal.
For FIDO (and thus WebAuthn, and thus to make this actually practical beyond a toy that only works for some particular Yubico product) the keys are random per enrollment. This is intentional because it means that you can't be tracked, since "your" key on Facebook and "your" key on GitHub are no more related to each other than "my" key on Facebook is to "your" key on GitHub.
Google have apparently some plans to address this problem in the medium term. Adam Langley has written vaguely on this subject before. In the short term, their priority is the trick he wrote about most recently - if your Android phone is enrolled as a Security Key with Google, and it's signed in to Google because it's an Android phone, and you use Chrome on a desktop, which is also signed into Google, the Chrome can use Bluetooth to determine if the phone is physically nearby and if so propose to authenticate your desktop Chrome to a remote web site using the Android phone. Elegant, albeit not suitable for those who fear lock-in.
>This is intentional because it means that you can't be tracked, since "your" key on Facebook and "your" key on GitHub are no more related to each other than "my" key on Facebook is to "your" key on GitHub.
I get the motivation behind it, but the mechanism I proposed in the last comment still preserves those properties? Each site would still get its own derived ECDSA public key. The master ECDSA public key would only be shown to the user and is to be kept within the browser. If a user wants to enroll a not-present security token, the browser will take the ECDSA public key and derive a public key to present to the site, so the site still can't track users using security tokens.
To complete enrollment you need to know the corresponding private key, live.
The relying party says "I am some.example and I want to enroll a Security Key, but, not ones which recognise these huge random-looking IDs that are already enrolled: 12345678, 34561234. I also picked this random nonsense XYZXYZXYZ. Go for it" and your browser talks to your Security Keys until it finds one that isn't already enrolled, gets that one to sign the appropriate message and sends back, "I am a web browser, I checked that you are some.example. I picked my own random nonsense XXXZZZ, and a Security Key picked public key ABCDEF, then to prove it knows the private key it signed this message for some.example mentioning XYZXYZXYZ and XXXZZZ and with bitflags it understands enough to know what it's signing. It says the resulting credentials have random-looking ID 98765431. Thanks". /s/Security Key
If the Security Key cost less than a low-end Yubikey, it has no storage. That random-looking ID is in some sense your private key for the site, but suitably encrypted, e.g. with AES in Galois/Counter Mode, so that the device needn't remember it, when a site asks keys to authenticate, it must provide the ID they're authenticating against, and so they can do AES GCM, figure out if they minted this ID, and if so recover the private key and authenticate. This is fiendishly clever, but so far as I can see renders your idea impossible.
If you have questions about why the WebAuthn protocol works the way it does, it seems like you'd want to first read the protocol in detail and then if you still have questions ask its maintainers.
I had 2fa enabled on my LastPass account, but didn't have access to the phone anymore. I clicked a link, LP sent me an email, and I was able (through that email) to remove 2fa.
It doesn't make their 2fa completely useless, but it's not great.
That sounds fine to me tbh. It's worth knowing, but it's not weak. Email is a pretty good 2FA in terms of security, it's just not great in terms of usability, so it makes for a good fallback.
Attacker with MP + email access is pretty severe.
I wish more services used email as a 2FA instead of SMS.
Keeping my secrets store on someone else's computer is simply not compatible with my threat model.
Yes, they say it is encrypted, and I believe them and believe they're competent.
But competent people write vulnerable code all the time, disastrously bad hires happen (see Unifi), and companies go bad. You can't un-disclose information stored with them, only laboriously invalidate it.
What's your personal threat model? I'm always trying to balance the risk of a party focused on security vs the minimal effort I'm likely to put into it. I don't want to be a story about the guy that lost their password to a wallet or anything else important. I used to be able to reliably remember complex passwords reliably but finding that's no longer the case, now only shorter intermittently used ones based on how often I have to use "reset password".
I’ve decided that besides a password manager, all of my passwords will also have a number at the end, like 8 (simple, easy to append manually in a password field. Now the password manager has to get defeated AND my own small personal salt value will have to be known.
Now you know that there is some sort of salt. That isn't helpful to an attacker trying to cryptographically crack a password if they already have the password database.
This is a good idea that's never occurred to me. I guess you could also consider it like having one password for all your accounts, except salted with some random string from your password manager
1password has been audited a bazillion times. They're E2EE. They're cheap. Your master passwords aren't stored on their servers. Neither is your key information.
The only thing I pay for is the managed hosting, but in theory it's not much different than anything else properly designed (e.g. bitwarden) aside from the obvious things, such as OSS-ness.
The only relevant CVEs are relatively mild compared to LastPass.
> Your master passwords aren't stored on their servers. Neither is your key information.
...and, those are the only things that really matter for an attacker. Encrypted data (assuming reasonably strong encryption) is useless without the key.
I’d wager you could survey 100 cryptographers and at least 90 would say the AES-256 primitive itself will never be practically broken, even by large-scale quantum computers. Related-key attacks aren’t realistic or practical.
Properly encrypted data is worthless unless you intend to get the keys somehow. Breaking industry standard encryption schemes shouldn't be in your threat model.
I still use an older version of 1Pass specifically so I can run things locally. Sometimes, I wish I was ignorant to all of this stuff and could just be a plebe out in the wild using all of the convenient software out there. Just take the blue pill and put me back in the matrix. The knowing of all of this stuff just makes life so much more difficult.
Easy thing to suggest. However, in my experience, as soon as I decide to use a program after researching it, take the time to switch over to it, that company will then switch to a cloud based whatever. Here we are again at the same spot different name.
I'm in the same boat. I've used lastpass for years and tried a few alternatives over the time but they fell down when it came to providing access to my "vault" on different systems or architectures. The biggest benefit is lastpass generating and storing random passwords for every site and application without me having to cut and paste a thing, and having it easily accessible.
That said, if their closed-source browser extension is leaking my master password to random websites I'll cut them out of my life tomorrow.
Ever since 1password removed local vaults I am looking / waiting for a decent alternative. I also wonder what the impact of that move was on enterprise users, as they don‘t have hosted version.
LastPass has had a history of security incidents (no company can completely avoid incidents, but if security is literally a primary part of your value, you shouldn’t be having so many).
Even worse, they have a history of doing hand-wavy corporate non-explanations for what actually happened in these incidents. The antithesis of being responsible and respecting users in the modern day.
To be fair to LastPass/LogMeIn, they're a company handling a lot of valuable information (passwords/form-fill data/card numbers/notes etc.) - and they're one of the biggest out there.
You'd expect them to be one of the more targeted companies just because of the 'treasure' they hold - hence the more security breaches.
An “Ask HN” was just trending about this yesterday (https://news.ycombinator.com/item?id=29705957). Sounds like a good reason not to trust any third party service with my password database to me.
I’ve always taken the route of managing my own local Keepass DB & key files. Sure it’s more cumbersome, but it prevents me from having to decide whether or not to trust some third party vendor or not.
I know 100% that I’m in full control and I’ve never put my DB or key file in the cloud. I can sleep sound knowing that whatever password service, or file sharing service, somehow getting compromised, cannot endanger one of my most valuable assets
I recommend this every time a similar news item gets posted. Password Safe (designed by Bruce Schneier). I use the iOS and Linux apps and keep them synced via DropBox. Been around for years (I've been using it almost as long). Still getting updates. Still works.
https://pwsafe.org
I've been doing this for years too.
I recently bought two yubi keys and now don't rely on a master password for it.
However now I'm scared I could lose my yubi keys.
I wish there was an integrated solution for this approach. Both programs are relatively hard to use in isolation, for "civilians"; combining them is pretty hard.
Password management, afaik, still needs a zero-knowledge cloud-agnostic solution that is easy to set up and run. There are the big boys (1password, bitwarden, LastPass) and then there are local-only solutions; in between, where the sweet spot should be, there is only a bunch of hacks. The issue is monetization - the incentives for that side are towards centralizing.
>I know 100% that I’m in full control and I’ve never put my DB or key file in the cloud. I can sleep sound knowing that whatever password service, or file sharing service, somehow getting compromised, cannot endanger one of my most valuable assets
What's the risk of keeping the keyfile/password on your device(s) but uploading the database to the cloud? Assuming your keyfile has enough entropy (eg. 256 bits), your database is good as useless without the corresponding key file.
Because something like this break will happen, and the fewer suspects the better. Maybe the code to upload the encrypted version is buggy, maybe the code hits a bug that uploads the private key to Dropbox... there are all sorts of "maybes", no matter how remote. If the file never touches, eg, Dropbox's servers, then there's zero possibility the break happened because of something related to Dropbox. Maybe the keys used are weak in some manner that is later discovered.
Do you own assessment of all of the "maybes", and come up with your own conclusion and practices. Someone else's hard drive is not to be trusted, but it is convenient.
For a personal password manager, that works ok, although syncing between multiple devices can be complicated and is sort of what I do, but it is much more difficult when you need to manage shared password for a team. At the very least you need some sort of locking mechanism to prevent accidentally overwriting someone else's change. And you also probably want an audit log, admin override capabilities, ability to grant different levels of access to different groups, etc.
Pass with a git repo satisfies some of those requirements, but it isn't very user friendly for non-technical users, and fine grained access controls and groups is tricky.
You can search "lastpass project zero" to see a pattern of specific examples of how LastPass does not seem to have a well-organized approach to security.
That doesn’t prevent them from being open & honest about what caused a security incident and what they’ve since done to ensure they’re highly secure.
Furthermore, I’d argue that Firefox & chrome password managers probably have several orders of magnitude more passwords stored (and therefore much more highly targeted), yet they don’t seem to have annual security incidents. And you can’t even pay for those products.
People stealing passwords are probably doing it to eventually make money. Criminals could save themselves a ton of work by just directly hacking the banks, yet we don’t hear about highly regular complete compromises there.
Furthermore, if operating a password manager service puts a huge kick-me sign on your service, why don’t the other password managers have plenty of incidents?
>Users must also devise a master password to unlock the encrypted passwords stored by the password manager. This is similar to a master key. It is generally accepted that master keyed locks are less secure than non-master keyed locks. If the master password is exposed, then confidence (in all the passwords that it unlocks) is lost.
1. In a perfect world, having a master password is worse than having independent passwords. However, realistically you can't remember that many passwords, so in practice you end up reusing passwords across sites. Using a master password in this case is a worthwhile tradeoff.
2. on most password managers, you need access to both the database (either through the web, or as a file) and the master password to compromise its contents. Even if your password was "hunter2" or something, your accounts would probably be fine.
>DPG
Deterministic password generators/managers have problems of their own. Their main draw is supposedly the lack of state to keep track of, but realistically you still need to sync stuff (eg. usernames, site identifiers, password formats, counters), so that dream is never realized.
>1. Never store passwords. Rather, generate them as needed based on user input. The need to backup, synchronize and properly encrypt passwords is removed. There is no master password that immediately unlocks all of the other passwords. There is nothing to become lost, stolen or corrupt.
I can't tell whether this is satire or not. The author dunks on other password managers for having a "master password that immediately unlocks all of the other passwords", but his program literally has the same flaw? At least with traditional password managers you need access to the database and the master password.
This is framed so negatively toward LastPass, which is unfortunate. They stopped all usage of correct passwords they believed were compromised, which is exactly what I'd want them to do in this situation. Them warning users their master passwords are compromised is a good thing! Yet it's framed as though they're admitting to something.
"However, users receiving these warnings have stated that their passwords are unique to LastPass and not used elsewhere." That's really hard to verify. I think most users would say that rather than admit they re-used passwords (or used similar passwords that were easy to reverse engineer). Since there only seems to be 2-3 reports of this, and they're self-reported and not cited, it doesn't seem like LastPass was compromised.
I'm not saying I like LastPass (I use 1Password and find LastPass to be much worse), but I haven't seen any indication at this point that LastPass has been compromised at all.
(To be clear, it's very possible I'm wrong and this message won't age well. But so far, it seems like LastPass is doing its job, and I'd want to see more than this before jumping on the blame-LastPass bandwagon.)
Unfortunately the only password solutions I would recommend at this point are 1Password for something turn key, and BitWarden if you want to self host.
Agreed, and I highly recommend 1Password. But just because they've had problems in the past doesn't mean the framing of this article is fair. The title made me think everyone's passwords were compromised due to a leak or hack, when in reality the article is a rehash of a HN post from yesterday.
The official story from LastPass and the claims of the reporters are in direct conflict. Either the master passwords were reused and this is credential stuffing, or there is actually a LastPass breach affecting all users.
One [incident] reporter claims they changed their master password and had a breach attempt using the new password. If that is true that is extremely alarming.
There could be some malware targeting a LastPass extension or app cache somewhere, but that is groundless theory on my part.
The LastPass extension can be told to remember your master password. They say it's not recommended. We might be seeing the result of people opting to store their master password and something that exploits this.
>Since there only seems to be 2-3 reports of this, and they're self-reported and not cited, it doesn't seem like LastPass was compromised.
There are now over 20 in the original HN [1] thread. ( Excluding reports from Reddit and Twitter ) From password never used since 2017 to account newly created in the past few months. OP has full Bio, Links and Credential, others have long history on HN and karma points. I did at one point suspected a PR attack on Lastpass, ( sorry guys ) but that is somewhat unlikely.
Of course, this doesn't rule out a malware running wild.
It's negative because something's up and they haven't given a good explanation.
> They stopped all usage of correct passwords they believed were compromised
Immediate question: how the heck would they know which passwords are compromised, if it wasn't a compromise on their end? From the information provided, the only thing they have is the IP & geolocation data, which isn't going to be reliable when the attacker(s) are using VPNs. For everyone whose account was protected by blocking access from odd region, how many are there whose accounts were quietly accessed and no email was shot off to warn the owner?
They are claiming that the master password was used on some other (compromised) service, but they provide zero evidence for this. And if they don't know your passwords, how on earth do they know that you've reused them on a compromised service? Can they name that service? Has anyone yet found a service every affected user has in common? I haven't seen that.
> "However, users receiving these warnings have stated that their passwords are unique to LastPass and not used elsewhere." That's really hard to verify.
That is true, but there are so many reports now that it's really hard for me to believe they were all dumb enough to reuse their master passwords elsewhere and are also bullshitting us on HN.
> I haven't seen any indication at this point that LastPass has been compromised at all.
Neither have I, but I still believe it to be a plausible explanation. I don't think we have a "smoking gun" or a site/service/extension that is common to everyone who reported this thing happening to them.
I'm not here to defend LastPass, but there are some rational answers to the questions you're asking, a lot of them having to do with human psychology.
First thing's first, and yes I am "victim blaming" when I say this: 60% of users reuse their passwords. [0,1] It's a widespread problem. Maybe that number is lower for a technical site like HN, but I have encountered technical people who do not practice what they preach.
>how the heck would they know which passwords are compromised, if it wasn't a compromise on their end?
You can check for a compromised password the same way you check if a password is valid, both without having stored the original password in plaintext. You have a list of known-compromised hashes and see if the hashed password is in that list. [2]
>For everyone whose account was protected by blocking access from odd region, how many are there whose accounts were quietly accessed and no email was shot off to warn the owner?
None based on my experience with the service. Each time you login from an unrecognized device or IP, you receive an email and have to confirm the login. It's good hygiene to check the access logs, although I've been dirty in that regard.
>They are claiming that the master password was used on some other (compromised) service, but they provide zero evidence for this. And if they don't know your passwords, how on earth do they know that you've reused them on a compromised service? Can they name that service?
No. And they probably won't ever be able to. And probably neither will anyone else. See [2].
>That is true, but there are so many reports now that it's really hard for me to believe they were all dumb enough to reuse their master passwords elsewhere and are also bullshitting us on HN.
Well I can imagine a few things going on. Like that 60% reuse number in [0], there are probably a lot of people who did reuse their master password. I'd be embarrassed myself to admit I reused a password and it got compromised (correction: I have reused passwords and have been compromised, luckily not in a damaging way). You're kind of exemplifying that point by calling someone who would do that "dumb enough".
The other group of people who really didn't reuse their passwords may have done something I did a few weeks ago - forgot I was connected with a VPN. I SSH'd into a server, saw a weird IP and freaked out. Then after 15 minutes of investigation, I realized duh I was just connected through a VPN in Europe.
>bullshitting us on HN
I'd be careful about this assumption. I have seen people bullshitting here. I won't go as far as outright denying that people haven't reused their passwords, but I am always a little skeptical of things like this (i.e. where people say one thing because they're embarrassed about being associated with the other). It has certainly heightened my senses.
>I don't think we have a "smoking gun" or a site/service/extension that is common to everyone who reported this thing happening to them.
As has been theorized elsewhere, it's very possible we're seeing early signs of the results of the log4j exploits.
I'm in wait and watch mode to see if LP really is compromised.
> You can check for a compromised password the same way you check if a password is valid, both without having stored the original password in plaintext. You have a list of known-compromised hashes and see if the hashed password is in that list.
That would require them to store password hashes unsalted and using the same hash function & number of rounds as the online dumps of compromised hashes. If that's what's going on, then that would be good reason to immediately abandon said program.
Password databases are supposed to encrypted, so without the master password they also won't see see the rest of the hashes in the db to see if they reused the master password. So no, they won't know which passwords are compromised unless there are some absolute design disasters going on.
> None based on my experience with the service. Each time you login from an unrecognized device or IP, you receive an email and have to confirm the login.
Ok, that is good to hear. Still, they shouldn't have any way to really know which passwords are compromised. I guess they could have blanket-rejected all logins from unknown IPs and make the claim above (putting some PR spin on it). That'd be quite meh.
> No. And they probably won't ever be able to. And probably neither will anyone else.
Then they should not make a statement saying so, because it is bullshit until proven otherwise. If they don't know how these passwords got compromised, they should say as much. But they've determined:
"LastPass investigated recent reports of blocked login attempts and determined the activity is related to fairly common bot-related activity, in which a malicious or bad actor attempts to access user accounts (in this case, LastPass) using email addresses and passwords obtained from third-party breaches related to other unaffiliated services."
If that isn't bollocks, then I'm really curious how they determined anything. And if they actually didn't determine anything, then I really don't think they should post a statement like this.
> Well I can imagine a few things going on. Like that 60% reuse number in
> duh I was just connected through a VPN in Europe.
> I have seen people bullshitting here.
All plausible theories. If it were one or two people, I'd consider "user error" a very likely explanation for this (it wouldn't be the first time someone freaks out and it turns out to be nothing). But right now, 20+ different people on HN? To be fair, many of these are green (that's a bit suspicious but I'd totally understand wanting to protect identity when admitting your passwords may have been breached) but we also have quite a few old users.
I just have a really hard time believing such a number of pebcaks all of a sudden come in swarms and lie on HN about using a random password that was written down and never used anywhere else (or such). That would be unprecedented here. One or two, again I'd consider it, but this is too many for me. I think if people here reused their passwords, got it compromised, and were embarrassed about it, they probably wouldn't announce it at all or at least they wouldn't fabricate a lie. As much as I think there are dumb and embarrassed people out there, I just don't buy that everyone here is lying.
Also, reusing any random password is not at all the same as reusing your master password. I'm sure someone will reuse that too but it's quite different level. I reuse plenty of passwords for irritating services that mandate a login but which I don't care much for. I'd assume the frequency of reuse among technical users would be far less than 60%.
> As has been theorized elsewhere, it's very possible we're seeing early signs of the results of the log4j exploits.
That sounds again plausible, except for the cases of people who got theirs compromised even though they haven't used it in years. Who do y...
>That would require them to store password hashes unsalted and using the same hash function & number of rounds as the online dumps of compromised hashes.
Even if you don't have the precomputed hashes, you can still bruteforce using a wordlist.
>Password databases are supposed to encrypted, so without the master password they also won't see see the rest of the hashes in the db to see if they reused the master password. So no, they won't know which passwords are compromised unless there are some absolute design disasters going on.
You don't need access to the database to pull this off, just a wordlist obtained from prior dumps/leaks.
True. And I guess that's the only way LastPass could be certain these passwords have been reused (assuming everything else works as they say). If they did that, then IMO it would be very nice of them to point out which dump(s) these passwords were found in.
Like the accidental VPN possibility: did anyone consider the recently released Apple iCloud private relay feature as a potential reason for receiving these notification? It may present a different IP/country to LastPass when actual users log in.
Apparently this just started yesterday. If someone's LastPass account has been successfully compromised since then, we might not hear about it until that person logs into another account and discovers funds missing.
Nah, I think the accounts get deleted but no one bothered testing the form. After all, this funnel won't convert into precious $$, so what's the point of maintaining it?
(I removed my account recently and got the same error message, everything seems to be gone now)
I jumped ship from LastPass when they changed their subscription model so that I'd be paying for features that had previously been free. I'm now using Bitwarden for personal use and 1Password for work and I'm a fan.
I previously tried offline password managers but syncing the files between devices and such was a huge pain.
This has to be a security issue with LastPass, right? Something like an as-yet unidentified usage of Log4j.
> Some customers have also reported changing their master passwords since they received the login warning, only to receive another alert after the password was changed.
This sounds to me like either a widely-compromised browser extension (LP itself?) or LP infrastructure.
Several years ago, I chose LastPass, bought it, and did all the set up. Then they were acquired by someone I didn't trust, so I immediately switched to 1Password, and never regretted it for a second. If 1Password sold out, I'd switch again, in a second.
While this is a good approach at a high level, it's also worth pointing out that the usage should not be based on trust.
You should evaluate if you're comfortable using this or that password manager even if they were aquired by the most evil company you can think of. If the design is solid, it shouldn't matter since the evil company shouldn't be able to compromise anything. If it does matter, then you shouldn't be using that software no matter how much you trust the company (because regardless of trust, they're still subject to secret court orders etc.)
Yes, but password manager vendors seem to insist on moving towards cloud subscriptions, instead of "buy it once and you host it", which means you are somewhat dependent on them. If 1Password keeps pushing this direction and makes Dropbox sync stop, I'm SO outta there.
Is there anything like lastpass that has TOTP + password remote backup that has a chrome plugin and an android application? I'm getting to the point where I'd love to switch off.
I use KeepassXC on my desktop OS's, storing my database on a NextCloud instance. Android can R/W that same file using the KeePassDX app (available on either the Play store or F-Droid). I can store TOTP keys in my Keepass database as well. My browser has an extension that lets me autotype the username, password, and TOTP codes.
I know storing my TOTP passphrase along with my un:pw combo isn't as secure as keeping them in separate locations, but my threat model is just to stop someone with only my un:pw.
If you decide it's time to switch, consider switching to Keepass(-compatible software), with the DB file hosted via WebDAV (which you can either self-host or have hosted by a multitude of low-cost providers).
This will give you nice conflict resolution if accessing (modifying) the file from multiple machines.
There are clients available for all platforms. I use:
Keepass (Windows), Macpass/ Keeweb/ Strongbox (MacOS), StrongBox (iPad) and Keepass2Android (Android, this one's fantastic!).
Confession: I store all my passwords in a plaintext file on my local desktop.
I'm sure some people will look at me very funny for doing this, but it seems to me that I have both fewer hassles logging in and fewer breaches than people using more "secure" methods (like handing your passwords over to LastPass's mystery Chrome extension).
Think about today's threat landscape and tell me I'm wrong. I may not be more secure in every possible situation, but I'm more secure in the situations that cause the vast majority of breaches today.
The number of times my home's been broken into: 0 (and based on news, virtually all of burglars are just looking for jewelry, wallets, and similar stuff and they won't bother trawling through your papers for passwords).
The number of times I've had devices on my network that run some hastily put together vendor firmware that was last updated six years ago: too many to count.
The number of times I've had to rush to update/patch my own computers to fix a newly disclosed remotely exploitable vuln: quite a few.
The number of times I've actually witnessed attempts at trying to exploit said remote vulns: too many to count! Sometimes mere hours after I've patched my stuff.
The number of times I've known I've had malware: at least a couple times (admittedly long ago, back when I ran Windows..).
I just don't trust keeping personal passwords on online connected computing devices. And password managers are a very lucrative target today (plus it tends to be all eggs in one basket for most people!).
I do keep passwords for employer's stuff in a password manager but not on the same device(s) I use said passwords on; even if you had malware on my work laptop, you wouldn't get my master password, nor would you be able to grab my password database. Passwords are also not stored on any third party service.
The price I pay is a relatively minor inconvenience. (I do have plans for something more convenient though!)
It's a free open source app that runs on your local machine and stores your passwords locally - never uploads your passwords to a server. But it does this securely.
And you can run it on multiple machines (and phones) and transfer the passwords (the vault) without ever uploading anything to servers.
If you like to have synced database between devices with minimal risk of exposure I would recommend setting it up to use a master password AND generated key file. I do this, then sync my database to cloud/butt and just keep my key file offline and on device only.
Edit: I believe you can also use a FIDO/U2F key (yubikey, google titan, etc.) in place of a key file but 2 password lock is great even if someone guesses your master password, the database is still useless without the 2nd key.
Thanks for the tip! I will look into it. I am curious to find out how it syncs without servers. (I assume this is not an incredibly hard problem but we are just not used to doing things without "the cloud" these days)
Use any service you want, Syncthing, Dropbox, etc. Keepass is smart about saving. If the DB is modified in the background while it's open, it will merge your changes rather than overwrite.
Personally, I keep my file on Google Drive and download it wherever it's needed. It does require a bit of manual tracking to ensure I've got the latest file, but I've only got about a handful of devices that I need it for, and even if I don't have the latest version of the file, it just means I might be missing a password for a particular service, and I can quickly download the latest anyway.
Obviously it's not as nice as having a cloud service, but it's open-source and doesn't require trusting a third party, which I like.
I do this, though I encrypt with GPG and a password. When I open the file, Emacs prompts for the password. It's pretty convenient, honestly, and I use the same system for sensitive notes, etc.
If you want to store you passwords locally, then at least use something like Keepass or KeepassXC. It's far from a perfect solution as it's still vulnerable to targeted attacks when it's being used if your computer is compromised. But at least they're not store in plain text. Also password auto-typing and generation are nice to have.
You can sync the encrypted files to your phone or other computers.
This is why newer versions of MacOS require you to grant permissions for an application to access folders in your user account. If you keep the keepass database in a folder like "secure", then no other program will be able to get to it. On Linux, there are a ton of ways of implementing something similar.
KeepassXC requires authorizing a plugin, and authorizing specific sites before it releases a password.
I see nothing wrong with using a plaintext file on your computer, that’s likely going to be safer than using a cloud based solution for a desktop computer that only you access, especially if you don’t have remote access.
Important questions might be how secure is your computer (encrypted HD, multiple users, etc), what incoming services have you enabled (ssh?), does your computer ever travel (is it a laptop, is it prone to loss or theft), and how secure is your apartment/house (is a robbery plausible).
The main thing a desktop file is, for most people who use password managers, is inconvenient. Without some kind of remote access at home, it might mean not having access to passwords when doing errands or traveling, any time when not physically at home. But with remote access, the password file access does become riskier, that does become cloud access where you’re responsible for the security of all methods of remote access (are any ports open you don’t know about?).
Having my password manager on my phone has been incredibly useful at times.
Yeah, if hackers got to your plain text file, they probably also installed a keylogger and clipboard scanner, in which case they have all your passwords, lastpass or not.
Inherently less secure than an extension that fills the passwords, as it relies on you checking the URL correctly, while an extension will only fill it when the origin is correct, which means you are less likely to be phished (although a security key is even better for that).
Meh... you're just looking at one threat, and one that isn't remotely likely in my reckoning. I don't think I've ever been phished. It's very easy to spot.
The one that springs to mind was the one that changes the contents of the page while it's in the background to a google log in page—very sophisticated and not something most people were prepared to spot, as people think of following a link as the moment of vulnerability.
Tons of people who are very aware and capable have been phished successfully. If you think it isn't likely, you are likely vulnerable.
"Not very likely" is just obviously not true—phishing is a very common attack, and companies like Google have adopted security keys to protect against it.
One of the reasons I haven't moved over to NeoVim is because they removed this feature, because supposedly it's not perfect or something. So sure, the NSA may be able to still be able to extract my passwords if they arrest me and take my computer, but the point is that random people won't be able to.
It's encrypted on my computer by Open Source software that I can trust. I used to use LastPass, but it was clearly a sinking ship ever since it was bought by LogMeIn.
325 comments
[ 3.7 ms ] story [ 283 ms ] threadhttps://news.ycombinator.com/item?id=27407603
For high-value logins, I use Passwordsafe. It's annoying; the scroll behaviour is annoying, and it's Windows-only, which is sad. But it's resolutely local and un-networked, and I'm confident that my secrets are well-protected by my (complex, long, memorized) master password.
Doesn't match what people claim here
This is basically the same "cloud" vs "on-prem" debate. Cloud won, I think.
I installed Keepass on my windows desktop along with iCloud drive sync. I keep my Keepass database in my iCloud directory. I can now use this Keepass database on my iPhone (via Files app), on my Macbook (iCloud Drive). Any changes made are automatically synced daily.
Is that really too difficult? And yes, it does "just work".
Bonus: Any passwords stored in my iCloud Keychain are also synced to my Windows Chrome instance via Apple's 'iCloud Passwords'[1] plugin.
[1] https://chrome.google.com/webstore/detail/icloud-passwords/p...
In the end I was running the conflict resolution command once every couple days.
Normally I wouldn't mind, but the only time the warning comes up saying that my db file is conflicted is when I need to enter a password in... which is the last time I want to be dealing with this.
This was Keepass with the db file on Dropbox, by the way. Not sure how Syncthing would handle it differently, but it wouldn't have anything to do with merging db files if they go out of sync.
I have written a CLI tool in Rust called keepass-diff that may help you with this: https://github.com/Narigo/keepass-diff
are you able to sync your keepass database to your windows machine? i need to add this one drawback for people to keep in mind. and also because it happened recently and made hn frontpage. apple can decide to suspend your account for one reason or another. it is very rare but can definitely happen.
Mainly with compromised\rogue updates, you push a malicious update to customers and then get access without needing to compromise the hosts.
Very similar to a supply-chain attack.
It's about convenience vs security, and specifically, auto-filled passwords across devices and applications. Anything that provides such a feature will be inherently less secure than an encrypted file.
If LastPass and others are to blame for anything, it would possibly be their marketing around the this tradeoff, though I think they avoid direct misrepresentation by just avoiding the issue completely.
I tried selfhosting in the past and it is painful process to set it up since I don't have an experience with it and the documentations on selfhosting are barely minimal. I tried selfhost an RSS Reader (FreshRSS) through webserver that are closed off to the public network. It is rewarding BUT frustrating experience for me beacuse of how much it needs to be functional. And don't forget the difficulty of setting up a CA for the HTTPS (SSL/TLS), it is PITA to set it up and it kept having problems. I am considering Caddy server since it generates its own CA automatically. Their documentation are not beginner-friendly and requires some prior knowledge to set it up.
It's doable. I managed to teach a 50+ year old to do it.
I still self-host.
Neither way “must” they have stored your master password.
It's an interesting game: Reputation is essential to their business. Admitting a breach will harm their reputation, denying it and then getting caught will harm it a lot, but denying it without being proven wrong will probably harm their reputation less (than an admission).
Personally, I'd rather trust a provider that admits a breach, provides transparency, demonstrates good incident response, and hasn't shown complete incompetence from the breach than a provider that has credible rumors of a breach and no good explanation, but I think I'm in the minority here.
Notably, TeamViewer had one of these "rumors but denying a breach and claiming credential stuffing" cases (they later admitted that they also had an earlier but unrelated intrusion that they kept secret for three years, which doesn't help). I think that if it was more than credential stuffing (that's a big if, the credential stuffing explanation is plausible), the strategy worked much better than admitting a breach.
[0] https://f-droid.org/packages/dev.msfjarvis.aps
Must be a compromised browser extension at this point.
> To make things even worse, customers who tried disabling and deleting their LastPass accounts after receiving these warnings also report [1, 2] receiving "Something went wrong: A" errors after clicking the "Delete" button.
Is there anything more infuriating than this type of error message?
I stopped using LastPass a long time ago, but this has definitely put them on thin ice for me, I won't be recommending them going forward.
From 2019: https://www.reddit.com/r/Lastpass/comments/afmfop/cant_delet...
From 2020: https://twitter.com/jowouters/status/1222438393981886464
There's a ton of those posts. Some in the official LastPass forum as well, and the response from LogMeIn was basically that the account was deleted.
(It's of course crappy, just saying that this behavior is nothing new and probably just something they don't care about enough to fix..)
The previous thread had password never typed, copied or used for years. Unless we are talking about multiple vector, otherwise browser extension doesn't fit most of the reported scenario.
Impending company changes also raises the possibility of an insider attack.
Just for fun, I downloaded the official LastPass chrome extension. The zip file is 32MB before unzipping, and it has 426 separate *.js files, total of 25MB of javascript. That should be a fun audit.
Edit: To be clear, nobody has said the LastPass extension is compromised, though that is one possibility.
Edit #2: Some of the larger js files do have a fair amount of the size as arrays of localized text, error messages, lists of numbers, etc. But it is still a lot of JS.
And how did this breached exactly happen?
File count is not a good metric of complexity nor is an indicator of the quality of an application. There is a good chance a lot of that are packages that have been packaged up into the extension. Lastpass itself is not a super trivial application, either.
There's a lot of room between "super trivial" and "needlessly complex" -- it shouldn't be either.
Trusting a cloud-based third party with my passwords is a non-starter for me.
For (a totally bogus but hey) comparison, I'm shipping products which include the Linux kernel, userland (busybox plus a pile of scripts and some daemons & other utilities), "the application" (two-three hundred thousand lines of C maybe?) plus deps (including sqlite, crypto libs, etc.) and the compressed image that contains all of this easily fits in 16MB SPI NOR flash with a few megs to spare.
There's 4.3 megabytes of plain text in the KJV bible. Is LastPass' localization longer than the bible?
https://www.gutenberg.org/cache/epub/10/pg10.txt
i wonder if any of that is log4j ( :
> Is there anything more infuriating than this type of error message?
Well the other classic move by webshits is to have you stare at a spinner indefinitely.
In their 2019 breach, JS on arbitrary pages was able to access the contents of LastPass' own extension to obtain the last used username/password combinations. [0]
As, today, the extension now contains 25Mb of JS, making it difficult to audit, I wouldn't say that it has to be someone else's fault until proven.
[0] https://bugs.chromium.org/p/project-zero/issues/detail?id=19...
Some of our skulls are so thick you’d need at least a $10 wrench
You can be forced to disclose your secrets but you will know they were compromised, that's encryption doing its job.
There's a world of difference in knowing.
I can smash your door in, or simply break a window. The difference is you’ll definitely know I did it. But unless you in the routine of checking your lock pins for scratchmarks, you probably wouldn’t know if someone picked the locks.
Edit: Looks like some Yubikey work via nfc for mobile.
3 copies of your 2-factor, 2 different mediums (a Yubikey and recovery tokens printed on paper), at least 1 in a different location (safety deposit box, trusted family members house, etc).
That seems like a usability nightmare. Are there plans to improve this? Hardware wallets for cryptocurrencies seem to have it solved. You can keep multiple copies of the keys around (ie. multisig wallets) for maximum security, or you can write down the private key of the device you have and store it somewhere safe. In either case you can retain the public keys so you don't need access to the device if you want to send funds to them (or in the case of authentication tokens, enroll them).
Yubikeys do solve a lot of use cases very well but that is a downside to them. That is probably still a good tradeoff for most consumers.
You don't necessarily have to do it crypto wallet style and have the private key be exportable. Just adding a public key export (on the security token side) and a way to enroll a token by its public key (on the browser/website side) would allow you to enable 2fa without having to make a trip to the safe deposit box (either to store your backup codes, or to fetch your backup token for enrollment).
>Each token from the yubikey is not (readily) linkable to the key itself since the underlying secret is opaque and can't be exported
That's not an issue. You can derive more ECDSA public keys from a single master ECDSA public key[1]. The corresponding private keys can only be derived using the corresponding master ECDSA private key, and the generated public keys can't be linked back to the master ECDCSA public key. Bitcoin hierarchical deterministic uses this property to generate wallets that don't need regular backup (all your addresses are derived from one key) and apple's find my network uses something similar.
[1] exact mechanism is described here: https://bitcointalk.org/index.php?topic=19137.msg239768#msg2... starting at "Type-2 is a bit less obvious [...]"
Google have apparently some plans to address this problem in the medium term. Adam Langley has written vaguely on this subject before. In the short term, their priority is the trick he wrote about most recently - if your Android phone is enrolled as a Security Key with Google, and it's signed in to Google because it's an Android phone, and you use Chrome on a desktop, which is also signed into Google, the Chrome can use Bluetooth to determine if the phone is physically nearby and if so propose to authenticate your desktop Chrome to a remote web site using the Android phone. Elegant, albeit not suitable for those who fear lock-in.
I get the motivation behind it, but the mechanism I proposed in the last comment still preserves those properties? Each site would still get its own derived ECDSA public key. The master ECDSA public key would only be shown to the user and is to be kept within the browser. If a user wants to enroll a not-present security token, the browser will take the ECDSA public key and derive a public key to present to the site, so the site still can't track users using security tokens.
The relying party says "I am some.example and I want to enroll a Security Key, but, not ones which recognise these huge random-looking IDs that are already enrolled: 12345678, 34561234. I also picked this random nonsense XYZXYZXYZ. Go for it" and your browser talks to your Security Keys until it finds one that isn't already enrolled, gets that one to sign the appropriate message and sends back, "I am a web browser, I checked that you are some.example. I picked my own random nonsense XXXZZZ, and a Security Key picked public key ABCDEF, then to prove it knows the private key it signed this message for some.example mentioning XYZXYZXYZ and XXXZZZ and with bitflags it understands enough to know what it's signing. It says the resulting credentials have random-looking ID 98765431. Thanks". /s/Security Key
If the Security Key cost less than a low-end Yubikey, it has no storage. That random-looking ID is in some sense your private key for the site, but suitably encrypted, e.g. with AES in Galois/Counter Mode, so that the device needn't remember it, when a site asks keys to authenticate, it must provide the ID they're authenticating against, and so they can do AES GCM, figure out if they minted this ID, and if so recover the private key and authenticate. This is fiendishly clever, but so far as I can see renders your idea impossible.
This seems like the main blocker. Why is that required? In theory all the site needs is a public key to verify against.
The Yubikey OTPs work if Yubikey is connected to a phone via USB (Type-C). Not sure about Fido/U2f etc though.
I had 2fa enabled on my LastPass account, but didn't have access to the phone anymore. I clicked a link, LP sent me an email, and I was able (through that email) to remove 2fa.
It doesn't make their 2fa completely useless, but it's not great.
Attacker with MP + email access is pretty severe.
I wish more services used email as a 2FA instead of SMS.
Keeping my secrets store on someone else's computer is simply not compatible with my threat model.
Yes, they say it is encrypted, and I believe them and believe they're competent.
But competent people write vulnerable code all the time, disastrously bad hires happen (see Unifi), and companies go bad. You can't un-disclose information stored with them, only laboriously invalidate it.
The only thing I pay for is the managed hosting, but in theory it's not much different than anything else properly designed (e.g. bitwarden) aside from the obvious things, such as OSS-ness.
The only relevant CVEs are relatively mild compared to LastPass.
Give them some credit.
...and, those are the only things that really matter for an attacker. Encrypted data (assuming reasonably strong encryption) is useless without the key.
> The only thing I pay for is the managed hosting
Funny, I was happy to pay them until they removed my ability to store it myself.
edit:
> CVEs are relatively mild compared to LastPass
LP is not the relevant comparison. The relevant comparison is an encrypted store on my laptop.
Sometimes the devil you know, you know?
That said, if their closed-source browser extension is leaking my master password to random websites I'll cut them out of my life tomorrow.
So it’s not just bots trying passwords from other database leaks
The whole premise of LastPass is that they can’t even decrypt your master password. It’s pretty concerning that this is happening.
If hackers can get your master password, then _all_ of your passwords are at risk
Even worse, they have a history of doing hand-wavy corporate non-explanations for what actually happened in these incidents. The antithesis of being responsible and respecting users in the modern day.
You'd expect them to be one of the more targeted companies just because of the 'treasure' they hold - hence the more security breaches.
I’ve always taken the route of managing my own local Keepass DB & key files. Sure it’s more cumbersome, but it prevents me from having to decide whether or not to trust some third party vendor or not.
I know 100% that I’m in full control and I’ve never put my DB or key file in the cloud. I can sleep sound knowing that whatever password service, or file sharing service, somehow getting compromised, cannot endanger one of my most valuable assets
Not sure what I can do about that.
Password management, afaik, still needs a zero-knowledge cloud-agnostic solution that is easy to set up and run. There are the big boys (1password, bitwarden, LastPass) and then there are local-only solutions; in between, where the sweet spot should be, there is only a bunch of hacks. The issue is monetization - the incentives for that side are towards centralizing.
What's the risk of keeping the keyfile/password on your device(s) but uploading the database to the cloud? Assuming your keyfile has enough entropy (eg. 256 bits), your database is good as useless without the corresponding key file.
Do you own assessment of all of the "maybes", and come up with your own conclusion and practices. Someone else's hard drive is not to be trusted, but it is convenient.
Pass with a git repo satisfies some of those requirements, but it isn't very user friendly for non-technical users, and fine grained access controls and groups is tricky.
Furthermore, I’d argue that Firefox & chrome password managers probably have several orders of magnitude more passwords stored (and therefore much more highly targeted), yet they don’t seem to have annual security incidents. And you can’t even pay for those products.
People stealing passwords are probably doing it to eventually make money. Criminals could save themselves a ton of work by just directly hacking the banks, yet we don’t hear about highly regular complete compromises there.
Furthermore, if operating a password manager service puts a huge kick-me sign on your service, why don’t the other password managers have plenty of incidents?
https://www.go350.com/posts/the-design-flaws-of-password-man...
>Users must also devise a master password to unlock the encrypted passwords stored by the password manager. This is similar to a master key. It is generally accepted that master keyed locks are less secure than non-master keyed locks. If the master password is exposed, then confidence (in all the passwords that it unlocks) is lost.
1. In a perfect world, having a master password is worse than having independent passwords. However, realistically you can't remember that many passwords, so in practice you end up reusing passwords across sites. Using a master password in this case is a worthwhile tradeoff.
2. on most password managers, you need access to both the database (either through the web, or as a file) and the master password to compromise its contents. Even if your password was "hunter2" or something, your accounts would probably be fine.
>DPG
Deterministic password generators/managers have problems of their own. Their main draw is supposedly the lack of state to keep track of, but realistically you still need to sync stuff (eg. usernames, site identifiers, password formats, counters), so that dream is never realized.
>1. Never store passwords. Rather, generate them as needed based on user input. The need to backup, synchronize and properly encrypt passwords is removed. There is no master password that immediately unlocks all of the other passwords. There is nothing to become lost, stolen or corrupt.
I can't tell whether this is satire or not. The author dunks on other password managers for having a "master password that immediately unlocks all of the other passwords", but his program literally has the same flaw? At least with traditional password managers you need access to the database and the master password.
"However, users receiving these warnings have stated that their passwords are unique to LastPass and not used elsewhere." That's really hard to verify. I think most users would say that rather than admit they re-used passwords (or used similar passwords that were easy to reverse engineer). Since there only seems to be 2-3 reports of this, and they're self-reported and not cited, it doesn't seem like LastPass was compromised.
I'm not saying I like LastPass (I use 1Password and find LastPass to be much worse), but I haven't seen any indication at this point that LastPass has been compromised at all.
(To be clear, it's very possible I'm wrong and this message won't age well. But so far, it seems like LastPass is doing its job, and I'd want to see more than this before jumping on the blame-LastPass bandwagon.)
https://www.mcafee.com/blogs/enterprise/cloud-security/lastp...
Unfortunately the only password solutions I would recommend at this point are 1Password for something turn key, and BitWarden if you want to self host.
One [incident] reporter claims they changed their master password and had a breach attempt using the new password. If that is true that is extremely alarming.
There could be some malware targeting a LastPass extension or app cache somewhere, but that is groundless theory on my part.
As you mention yourself at the end, there are other plausible explanations (e.g. malware on the machines).
If it is something like a keylogger, not so much.
There are now over 20 in the original HN [1] thread. ( Excluding reports from Reddit and Twitter ) From password never used since 2017 to account newly created in the past few months. OP has full Bio, Links and Credential, others have long history on HN and karma points. I did at one point suspected a PR attack on Lastpass, ( sorry guys ) but that is somewhat unlikely.
Of course, this doesn't rule out a malware running wild.
[1] https://news.ycombinator.com/item?id=29705957
> They stopped all usage of correct passwords they believed were compromised
Immediate question: how the heck would they know which passwords are compromised, if it wasn't a compromise on their end? From the information provided, the only thing they have is the IP & geolocation data, which isn't going to be reliable when the attacker(s) are using VPNs. For everyone whose account was protected by blocking access from odd region, how many are there whose accounts were quietly accessed and no email was shot off to warn the owner?
They are claiming that the master password was used on some other (compromised) service, but they provide zero evidence for this. And if they don't know your passwords, how on earth do they know that you've reused them on a compromised service? Can they name that service? Has anyone yet found a service every affected user has in common? I haven't seen that.
> "However, users receiving these warnings have stated that their passwords are unique to LastPass and not used elsewhere." That's really hard to verify.
That is true, but there are so many reports now that it's really hard for me to believe they were all dumb enough to reuse their master passwords elsewhere and are also bullshitting us on HN.
> I haven't seen any indication at this point that LastPass has been compromised at all.
Neither have I, but I still believe it to be a plausible explanation. I don't think we have a "smoking gun" or a site/service/extension that is common to everyone who reported this thing happening to them.
First thing's first, and yes I am "victim blaming" when I say this: 60% of users reuse their passwords. [0,1] It's a widespread problem. Maybe that number is lower for a technical site like HN, but I have encountered technical people who do not practice what they preach.
>how the heck would they know which passwords are compromised, if it wasn't a compromise on their end?
You can check for a compromised password the same way you check if a password is valid, both without having stored the original password in plaintext. You have a list of known-compromised hashes and see if the hashed password is in that list. [2]
>For everyone whose account was protected by blocking access from odd region, how many are there whose accounts were quietly accessed and no email was shot off to warn the owner?
None based on my experience with the service. Each time you login from an unrecognized device or IP, you receive an email and have to confirm the login. It's good hygiene to check the access logs, although I've been dirty in that regard.
>They are claiming that the master password was used on some other (compromised) service, but they provide zero evidence for this. And if they don't know your passwords, how on earth do they know that you've reused them on a compromised service? Can they name that service?
No. And they probably won't ever be able to. And probably neither will anyone else. See [2].
>That is true, but there are so many reports now that it's really hard for me to believe they were all dumb enough to reuse their master passwords elsewhere and are also bullshitting us on HN.
Well I can imagine a few things going on. Like that 60% reuse number in [0], there are probably a lot of people who did reuse their master password. I'd be embarrassed myself to admit I reused a password and it got compromised (correction: I have reused passwords and have been compromised, luckily not in a damaging way). You're kind of exemplifying that point by calling someone who would do that "dumb enough".
The other group of people who really didn't reuse their passwords may have done something I did a few weeks ago - forgot I was connected with a VPN. I SSH'd into a server, saw a weird IP and freaked out. Then after 15 minutes of investigation, I realized duh I was just connected through a VPN in Europe.
>bullshitting us on HN
I'd be careful about this assumption. I have seen people bullshitting here. I won't go as far as outright denying that people haven't reused their passwords, but I am always a little skeptical of things like this (i.e. where people say one thing because they're embarrassed about being associated with the other). It has certainly heightened my senses.
>I don't think we have a "smoking gun" or a site/service/extension that is common to everyone who reported this thing happening to them.
As has been theorized elsewhere, it's very possible we're seeing early signs of the results of the log4j exploits.
I'm in wait and watch mode to see if LP really is compromised.
[0]: https://spycloud.com/password-reuse/
[1]: https://www.troyhunt.com/password-reuse-credential-stuffing-....
...
That would require them to store password hashes unsalted and using the same hash function & number of rounds as the online dumps of compromised hashes. If that's what's going on, then that would be good reason to immediately abandon said program.
Password databases are supposed to encrypted, so without the master password they also won't see see the rest of the hashes in the db to see if they reused the master password. So no, they won't know which passwords are compromised unless there are some absolute design disasters going on.
> None based on my experience with the service. Each time you login from an unrecognized device or IP, you receive an email and have to confirm the login.
Ok, that is good to hear. Still, they shouldn't have any way to really know which passwords are compromised. I guess they could have blanket-rejected all logins from unknown IPs and make the claim above (putting some PR spin on it). That'd be quite meh.
> No. And they probably won't ever be able to. And probably neither will anyone else.
Then they should not make a statement saying so, because it is bullshit until proven otherwise. If they don't know how these passwords got compromised, they should say as much. But they've determined:
"LastPass investigated recent reports of blocked login attempts and determined the activity is related to fairly common bot-related activity, in which a malicious or bad actor attempts to access user accounts (in this case, LastPass) using email addresses and passwords obtained from third-party breaches related to other unaffiliated services."
If that isn't bollocks, then I'm really curious how they determined anything. And if they actually didn't determine anything, then I really don't think they should post a statement like this.
> Well I can imagine a few things going on. Like that 60% reuse number in
> duh I was just connected through a VPN in Europe.
> I have seen people bullshitting here.
All plausible theories. If it were one or two people, I'd consider "user error" a very likely explanation for this (it wouldn't be the first time someone freaks out and it turns out to be nothing). But right now, 20+ different people on HN? To be fair, many of these are green (that's a bit suspicious but I'd totally understand wanting to protect identity when admitting your passwords may have been breached) but we also have quite a few old users.
I just have a really hard time believing such a number of pebcaks all of a sudden come in swarms and lie on HN about using a random password that was written down and never used anywhere else (or such). That would be unprecedented here. One or two, again I'd consider it, but this is too many for me. I think if people here reused their passwords, got it compromised, and were embarrassed about it, they probably wouldn't announce it at all or at least they wouldn't fabricate a lie. As much as I think there are dumb and embarrassed people out there, I just don't buy that everyone here is lying.
Also, reusing any random password is not at all the same as reusing your master password. I'm sure someone will reuse that too but it's quite different level. I reuse plenty of passwords for irritating services that mandate a login but which I don't care much for. I'd assume the frequency of reuse among technical users would be far less than 60%.
> As has been theorized elsewhere, it's very possible we're seeing early signs of the results of the log4j exploits.
That sounds again plausible, except for the cases of people who got theirs compromised even though they haven't used it in years. Who do y...
Even if you don't have the precomputed hashes, you can still bruteforce using a wordlist.
>Password databases are supposed to encrypted, so without the master password they also won't see see the rest of the hashes in the db to see if they reused the master password. So no, they won't know which passwords are compromised unless there are some absolute design disasters going on.
You don't need access to the database to pull this off, just a wordlist obtained from prior dumps/leaks.
I don't believe this happened though.
https://support.apple.com/en-us/HT212614
(I removed my account recently and got the same error message, everything seems to be gone now)
I previously tried offline password managers but syncing the files between devices and such was a huge pain.
> Some customers have also reported changing their master passwords since they received the login warning, only to receive another alert after the password was changed.
This sounds to me like either a widely-compromised browser extension (LP itself?) or LP infrastructure.
You should evaluate if you're comfortable using this or that password manager even if they were aquired by the most evil company you can think of. If the design is solid, it shouldn't matter since the evil company shouldn't be able to compromise anything. If it does matter, then you shouldn't be using that software no matter how much you trust the company (because regardless of trust, they're still subject to secret court orders etc.)
I, for one, wouldn't use any security-critical software where the client isn't open source.
(The server side doesn't matter for security for the same reason trust in the company shouldn't matter. No secrets should leak to the server.)
I know storing my TOTP passphrase along with my un:pw combo isn't as secure as keeping them in separate locations, but my threat model is just to stop someone with only my un:pw.
YMMV
This will give you nice conflict resolution if accessing (modifying) the file from multiple machines.
There are clients available for all platforms. I use: Keepass (Windows), Macpass/ Keeweb/ Strongbox (MacOS), StrongBox (iPad) and Keepass2Android (Android, this one's fantastic!).
https://en.wikipedia.org/wiki/LastPass#Security_issues
I'm sure some people will look at me very funny for doing this, but it seems to me that I have both fewer hassles logging in and fewer breaches than people using more "secure" methods (like handing your passwords over to LastPass's mystery Chrome extension).
Think about today's threat landscape and tell me I'm wrong. I may not be more secure in every possible situation, but I'm more secure in the situations that cause the vast majority of breaches today.
The number of times my home's been broken into: 0 (and based on news, virtually all of burglars are just looking for jewelry, wallets, and similar stuff and they won't bother trawling through your papers for passwords).
The number of times I've had devices on my network that run some hastily put together vendor firmware that was last updated six years ago: too many to count.
The number of times I've had to rush to update/patch my own computers to fix a newly disclosed remotely exploitable vuln: quite a few.
The number of times I've actually witnessed attempts at trying to exploit said remote vulns: too many to count! Sometimes mere hours after I've patched my stuff.
The number of times I've known I've had malware: at least a couple times (admittedly long ago, back when I ran Windows..).
I just don't trust keeping personal passwords on online connected computing devices. And password managers are a very lucrative target today (plus it tends to be all eggs in one basket for most people!).
I do keep passwords for employer's stuff in a password manager but not on the same device(s) I use said passwords on; even if you had malware on my work laptop, you wouldn't get my master password, nor would you be able to grab my password database. Passwords are also not stored on any third party service.
The price I pay is a relatively minor inconvenience. (I do have plans for something more convenient though!)
It's a free open source app that runs on your local machine and stores your passwords locally - never uploads your passwords to a server. But it does this securely.
And you can run it on multiple machines (and phones) and transfer the passwords (the vault) without ever uploading anything to servers.
If you like to have synced database between devices with minimal risk of exposure I would recommend setting it up to use a master password AND generated key file. I do this, then sync my database to cloud/butt and just keep my key file offline and on device only.
Edit: I believe you can also use a FIDO/U2F key (yubikey, google titan, etc.) in place of a key file but 2 password lock is great even if someone guesses your master password, the database is still useless without the 2nd key.
Obviously it's not as nice as having a cloud service, but it's open-source and doesn't require trusting a third party, which I like.
You can sync the encrypted files to your phone or other computers.
KeepassXC requires authorizing a plugin, and authorizing specific sites before it releases a password.
Important questions might be how secure is your computer (encrypted HD, multiple users, etc), what incoming services have you enabled (ssh?), does your computer ever travel (is it a laptop, is it prone to loss or theft), and how secure is your apartment/house (is a robbery plausible).
The main thing a desktop file is, for most people who use password managers, is inconvenient. Without some kind of remote access at home, it might mean not having access to passwords when doing errands or traveling, any time when not physically at home. But with remote access, the password file access does become riskier, that does become cloud access where you’re responsible for the security of all methods of remote access (are any ports open you don’t know about?).
Having my password manager on my phone has been incredibly useful at times.
My threat model is 100% aimed at remote attacks/hackers. I could not care less about law enforcement. I also use a hardware backed second factor.
A computer will always do a better job at generating\remembering passwords.
hardware 2FA is definitely a good idea.
The issue is when you want to access that paper remotely or on the go. Then it becomes a really bad method.
Not necessarily. See https://xkcd.com/936/
Tons of people who are very aware and capable have been phished successfully. If you think it isn't likely, you are likely vulnerable.
"Not very likely" is just obviously not true—phishing is a very common attack, and companies like Google have adopted security keys to protect against it.
One of the reasons I haven't moved over to NeoVim is because they removed this feature, because supposedly it's not perfect or something. So sure, the NSA may be able to still be able to extract my passwords if they arrest me and take my computer, but the point is that random people won't be able to.
It's encrypted on my computer by Open Source software that I can trust. I used to use LastPass, but it was clearly a sinking ship ever since it was bought by LogMeIn.