What’s in a PR statement: LastPass breach explained
palant.info
palant.info
not to be overly vindictive, as I understand the near impossibility of running a perfectly secure service at absolutely enormous scale…but does anyone else feel LastPass should shut down the businesses, refund customers, and help them migrate to a new service? You are just not the organization for this job.
And yet here we are.
Network effects and monopolistic (anti-competitive) features allow bad companies to survive today. Monopolistic practices are probably a worse problem today than in the 1920s.
In the 1920s governments used regulation to break up huge firms and defeat advantages due to cost of capital (hard to start a new railroad in the 20s because the cost of trains and tracks was just so high.) Today, cost of capital is relatively less important, and things like switching cost and bundling and people valuing their time and convenience are bigger factors. We need anti-trust/government regulation to address those.
(For example, in the case of password managers, imagine if there were laws requiring publicized security audits and seamless migration to a new service of customer's choice. A competitor to Lastpass might have arrived by now.
Sundar Pichai being asked about if someone is handpicking search results comes to mind, as an illustration
Where is the the duopoly, and who's being forced out of the marketplace due to lack of government regulation of password managers?
Should a firm with a history of these types of problems lose out to competition organically? Sure, but there is no binary “losing out tot he competition” switch that just gets flipped one day.
This is part of the reason why I get so frustrated with the laissez faire mindset/meme.
Crucially, these models don't actually state that the companies that do the best job will win out, but that the most profitable ones do.
The problem arises when screwing over the user is more profitable than doing it properly.
That's why the tech industry is so ethically corrupt today. There's very little regulation to make dark patterns and sloppy security practices more costly than they are profitable.
on the other hand i almost see this as similar to the groups of people who swarm towards televangelists, who sign up to donate their last dollar to a millionaire who's scamming them for everything they're worth
if you trust it, then maybe falling for it is the best thing for you, to learn this lesson the hard way :/
I get where you're coming from, and ultimately agree. But I doubt anyone at LastPass on the business side agrees - to them this is just another PR snafu. The business continues to chug along regardless of how many catastrophic breaches they go through. I think they see these numerous issues as a cost of doing business vs. having a critical broken product offering.
Again I agree, but, I doubt they're going to change their ways this late in the game.
LastPass has proven they have no business safekeeping anyone else's credentials. Anyone who cares a modicum about their security will have migrated off. But migrating off is a HUGE pain (people will need hours to update hundreds of passwords), and LastPass's announcement just days before Christmas was obviously done so that your average Joe would just miss it.
So LastPass will be able to continue collecting subscription revenue from users who were too busy or just not paying attention to the news, despite the fact that they really should be giving refunds to everyone who depended on their service.
It took less than 10mn to migrate to Bitwarden. What do you mean by migrate?
Even if you stayed on LastPass(!), you should still do that, right? It's a penalty for LastPass compromising them.
I think others have posted on HN that they experienced the same last year when they attempted to migtate.
So you may have exported in 10m, but do not assume you got everything, go through the list and make sure everything is there (including verifying the contents).
The meta information (which user account belongs to which team, which team has what kind of access {none,read-only,read-write} to which folder) is not trivial to migrate.
- 1P has a multi-layered approach: The master key + random key (+ salts) decrypt the user's private key, which in turn is used to decrypt the vault key (because the user's public key was used to encrypt the vault key). The vault key is used to decrypt the vault's items (each individually). Giving a new member access to a vault is done by encrypting the vault key with that member's public key. (I guess that's the same for LP)
- 1P encrypts all field contents. BTW metadata (e.g. URIs) and content fields are encrypted separately, such that the former can be decrypted faster for UI and search purposes.
- 1P uses the Secure Remote Password protocol, which allows clients to authenticate with the 1P server without ever sending the actual password. Instead, during account creation, a derived key ("v") is sent from the client to the server that will be used to generate a shared secret during every authentication (without sending "v" again). "v" has been salted with the user's email address. So, by arriving at the same shared secret as the client, the server can be sure of three facts: 1) The user entered the correct master key, 2) the user's device has the correct random key in store, and 3) the user's given email matches the email that was defined when creating the vault. In the paper they write that this authentication process is actually the reason why 1P requires a random key in addition to the master key: It's impossible to brute-force the master key even if an attacker gains access to "v".
- Vault recovery with 1P prevents the team "admin" from receiving the recovered vault's data (they do learn the vault key though, that's a necessity).
- 1P are constantly evaluating whether stronger encryption schemes (e.g. elliptic curve, or, further out, post quantum crypto) need to be implemented, and if such an update happens, they have already mapped out how vaults are upgraded. I think they increased PBKDF2 passes from 10k to 100k without breaking anything. IMO a higher pass count would be better, but that would make for a quite slow UI.
It's what I've spent the last few days doing (hundreds of passwords), but then again, I'm also moving to bitwarden.
Sure it’s more cumbersome when it comes to syncing between devices, but it’s really not a big deal. One or twice a month I will combine my DBs from all my devices ok one machine, use the built in ‘merge’ functionality, and redistribute the I updated DBs back out to each device. It might take 10 minutes.
But I can rest assured that I’m the only one who has a copy of my DB/ key files, and a breach of _blank_pw_manager_ service can’t compromise my secrets. Highly recommend KeyPass. It’s free and open source, with high quality community ports available on every platform. https://keepass.info/index.html
Last year my father unexpectedly passed away. All his stuff was on lastpass. Thankfully we had emergency access setup, and I was able to get into all his accounts 2 days later. It was an exceptionally important part of the transition phase, and without it we would have experienced significant financial harm.
How would KeyPass deal with the same type of situation?
Edit: as a site note, have used keepass + file on my (vpn reachable) synology for like 10 years, never had any issues. I use it in linux, android, ios and windows.
I don't have one currently but perhaps I should.
Said items are titles to my vehicles and home, my marriage license, the will of a family member I've been entrusted with, birth certificates for my self and family members, and a couple of keepsakes for the kids that I'm very long on. It only costs me about $80 per year, and it brings me a lot of peace of mind. I have photocopies of all those docs at home, because you rarely need the real thing.
The bank I use maintains a list of people I allow to access my box along with their physical signature. When I needed to access my box, I had to sign in with a pen, on paper and show my ID. They compared that signature with the one I gave when I first obtained the box. I was granted access if they matched. If someone else came in with the key but their name wasn't on the bank's list or the signature didn't match, they wouldn't allow access to the box.
So make sure people you want to be able to access the box are on that list (which means they will have to go to the bank to provide a signature ahead of time.)
I am not saying we do this right. I certain have to "sharpen the pencil right" but the point is this should not be an afterthought.
You give someone a copy of your password, your key file (that is, your long-ass password), or both, if both are required.
If you want to duplicate the "Give people time to refuse the request for access" part of LastPass's feature, then retain a lawyer to hold the copies for you and -after receiving a request for them- release them after an agreed-upon period of time (or if they get a proper death certificate or whatever).
It's frustrating, but the fact that 1Password's emergency kit is primarily intended and documented for me to use, and incidentally happens to enable account recovery for my heirs as well, means that they won't use it. One look at the documentation and they'll write it off as techie stuff that I was into that they won't be able to understand. With LastPass, there's stuff online specifically explaining that it's intended to provide access for family members in case of death, and I think that is reassuring enough that they'll stick with the process until they figure it out.
Your family sounds fun to be around.
1Password emergency kit is pretty well-designed, all things considered. It's a neat, single-page PDF with all the necessary information[0] (URL to login, email address/password, and the security key as text or QR Code for easy setup). I guess a link to a sort of tutorial/guide of how to use it to recover the account would be a welcome addition, but I find the format to be pretty solid.
It's pretty hard to find information on lastpass version of the feature. What does it look like? According to their documentation of the "Emergency Access" feature, it claims to be a one-time access[1]? What happens after that access, do you just lose your access forever? That seems much worse than the 1password emergency kit!
[0]: https://i.1password.com/media/1password-emergency-kit.png [1]: https://www.lastpass.com/features/emergency-access
The rest of my accounts should die when I do.
For the financial companies, the process varied greatly by company. Some were OK, others were terrible, some flat out didn't work. The bottom line is that this isn't a super common business flow for them and its not something they make money on, so it gets very little attention. When you actually need to go through it you realize its a very difficult process.
Oh and it always takes a LONG time, even with the better companies. Easily months to get everything fully done.
For longevity a CD / DVD might last longer, but even then those are 30 years on average.
Just to offer a counter anecdote, I had a flash drive fail with my kdbx file on it and it was a monumental pain in the ass to recover from because I didn't have backups. Have backups. Especially for critical passwords that lock you out of everything. Flash drives do fail. Statistical failures SPECIFICALLY mean that some people will not fail, but that doesn't mean failures don't happen or that they're unlikely/uncommon.
I only have very low end flash drives (like the free ones you get at trade shows) fail on me. None of the decent ones I've bought (Kingston, generally) ever failed. I still have my various 4G, 8G, 16G, 32G drives I've bought along the years, all still work fine.
The only one that failed were used continuously plugged, or to write a lot (like recording audio), and very low-end with that.
It likely failed due to the nature of its transit (in my pocket, with my keys) but that's kinda the point. I think it's worth pointing out to those who haven't really investigated your "always plugged in" is the known failure of flash drives. Flash storage does has a fairly well documented write/erase cycles in the realm of like 10k-100k cycles. While the data should still be readable, its pretty easy for bad controllers and bad filesystems (most flash drives use fat32 which is a bad filesystem) to fail a write and corrupt data.
I think the main issue I have with a "do it yourself because you can't trust the cloud" mentality is that this advice usually comes from people who have done their homework as you have. It'd be dangerous to apply "just do x" advice without those conditions as it's a bit more nuanced and it can really put people in bad situations. I've seen this same thing with people who use a NAS over cloud storage and then it fails and they discover just what the monthly cost of cloud storage actually paid for. It'd be like telling home owners "just don't have a fire" and instead of paying for insurance, but not talking about the money you set aside and fire mitigation systems you invested in.
I can't imagine my parents wanting me to be locked out, and I can't imagine wanting my children to be locked out. Things like personal correspondence usually stop being private once someone is deceased, and indeed, are one of the few ways to get you know your ancestors.
I'm not American by birth, but I've lived in America long enough to understand both values. I don't think either way is better, but this strong emphasis on privacy (with family) is a very Western phenomenon. In most places, families have far fewer internal secrets.
What's especially odd is how much more Google and other corporations are allowed to know about Americans than families. For me, it's backwards.
Other things were also required. E.g. my father had a small business. It was big enough that it had real income and we wanted to keep it going, but not big enough that there was tons of redundancy for this type of event. Without having his passwords the business would have ground to a halt in 2 weeks (payroll). Add to that all sorts of business accounts (domains, mail, accounting, etc, etc) and having this emergency access turned out to be the key to keeping things going.
Even his personal email - he would have wanted us to have access, but how does he give access without just giving us his PW? Turned out that emergency access was the perfect solution.
Anyway even delegating it to a notary imho isn't near as much of a possible security issue than having an SaaS store all your auths online & them having a system in place to grant third party access.
Emergency access is a human problem. Seeking a technical solution to a human problem is just asking for trouble. This is why lawyers and customer service will always be necessary.
It would be great if someone can succinctly destroy that idea :D
Firefox, Chrome, and Edge also allow you to import passwords between browsers natively. I'm not saying that I recommend relying on the browser-based password manager (personally I use KeePassX), but I wouldn't advise against it for the reason you're describing. Just sharing some info! Please let me know if I'm mistaken on any of this.
Firefox doesn’t allow you to import a CSV in its default config. You need to enable it (it’s straightforward) and there is a guide here: https://support.mozilla.org/en-US/questions/1328161
Then you can import to eg Safari to have it all in iCloud Keychain.
And besides, if it was your private domain, you could submit that to google (I didn't follow up, but perhaps they spared the nuke for regular folks who just used their custom domain with gmail)
I am more worried not having access to my REGULAR Gmail account, with none to contact with, rather than G Workspace.
i have 1 vault with any important things and the other one just has everything else and i don't need to worry as much about the security of it or worry about where its stored and if that's secure.
its also great not having to type in a long master password just to get the login details for some small forum where it really wouldnt be a huge deal if somebody got access that vault. half of passwords in that vault are there mainly because i want them to be autofilled, not because i need to keep them secure
I'll have to pull changes if anybody added entries but: - Db lies on our own encrypted servers instead of someone elses cloud - access within the team is easily managed via ssh - I'll have a commit stream telling me if anybody added sth and what - can't easily fuck anything up in those shared records, have to consciously commit changes - when we rotate master pw we clean the repo
The db file on my Mac is shared with iCloud and is acted as the master file. All updates happen on the mac and the rest of the clients just sync and do read only. It has been working well.
All my website passwords are saved in firefox account so I rarely need to update the db file.
https://password-manager.soft-wa.re/
At this point it's mainly a fork&merge of some previous work.
If you find any issues with the data please submit a PR.
Edit: I am standing on the shoulders of giants. Take a look at the contributors page. I am taking what was previously a blog post, and giving it some extra attention with the current going-ons. https://blog.kamens.us/head-to-head-comparison-of-password-m...
Some of y'all have already found a few issues, I will work through them, and submit a "Show HN" once I get it to that point. So take everything here with a grain of salt. And if you do know better, please submit a PR here:
I don't know what would lead you to believe there's any syncing restriction from 1Password, but if that is your experience it's almost certainly a bug, since to the very best of my knowledge 1Password doesn't engage in hostage-taking like that
Minor bug: I unchecked “CLI,” and still got this row:
> CLI export includes attachments
Would be happy to submit a PR, but I couldn't find a link to a repo and couldn't find the code on GitHub.
I have some internal tools at work where you need to specify the domain, and some where you don't. Having two separate entries for these scenario is annoying, as I gotta update the password on both when I change it.
There are also sync issues (items created in the desktop app won’t appear in the browser extension unless I restart my browser), which aren’t occurring under Windows nor macOS.
„Poor“ Linux support absolutely does the situation justice.
Is there any password manager out there besides keepass that isn't cloud based?
1) How's it do at syncing / conflicts?
2) In the Android app, do you know if there's a way to use the fingerprint feature without storing your master password or an encrypted derivative of it to non-volatile memory?
For those scratching their heads at #2, it's motivated by my lukewarm trust of vendor-implemented components of Android Keystore. Some competing apps address it by making you authenticate with the full password the first time after boot (or after the app is closed by the user / memory management system / configurable timeout) and just tie your fingerprint to an "unlock" pin of sorts that only works when the database is "hot".
I know the Android Lastpass client would often prompt for a Master Password if it hadn't been used in a while, then let Fingerprints unlock it. I assumed it did something similar but haven't deep-dived the implementation.
Regarding 2), no I don't know but good question. Using the same master password is annoying as you don't type the same on mobile
Plenty of good choices.
The duality of putting off design decisions until later, and also feeling like your current design is extremely personal (I've seen some projects where the maintainer immediately disregards a lot of proposals design wise because it's "good enough", as if that person just called their baby ugly), can make trying to make any progress on FOSS project feel horrible.
It's a very interesting problem space I feel. There's so much room for improvement.
First, developers have a different fundamental perspective on interfaces than most people. They view interfaces as a wrapper that you use to interact with the important part: the application. To regular users, the interface is the application. I can't tell you how many times I've seen things like customizable color themes or ill-conceived typeface changes be the primary product of a developer-initiated "UX review," largely because they didn't know how to identify actual usability problems and wouldn't know how to craft solutions even if they did. If it persists long enough, maintainers don't just see their interfaces and user paths as flawed but good enough: they assume the mitigation techniques they've developed to work around a bad interface are best practices.
Second, art school freshmen subconsciously trying to prove their competence to themselves give the harshest and least useful critique and often take constructive critique as a personal affront. That phenomenon seems generalizable: critique about things we're less confident in makes us feel more insecure than critique of things we're more confident in. If someone proposed replacing a core piece of the architecture with something different, they'd be confident enough to look at it and rationally decide if it's beneficial. Conversely, when developers see redesign proposals about interfaces they were never confident in to begin with, they get defensive, and design proposals get dismissed or bikeshedded to complete buggery.
I think these two things imbue the FOSS development world with indifference to, or even distrust of designers. You only need to briefly look at threads on HN focused on design or interface to see the open disdain many developers have for designers. "Ruined by designers" is a pretty common refrain. Despite our unicorn reputations, I know lots of designers/developers, and every one that I can recall at the moment contribute to FOSS... just never as designers because the process is so irritating. Myself included. It's just not worth the amount of work that goes into a competent design proposal, noting that I would implement it personally, only to have it summarily dismissed by people with false confidence in their analysis.
Just like security, design is one of these things where snake oil salesmen are everywhere, to the point that finding a good one without becoming a designer yourself is hard. I also notice you identify as an artist, not a psychologist, which seems the wrong approach to me.
So what will happen if I let designers loose on my program? They might have real insight and improve things a lot. Or maybe they'll go all artsy and put lipstick on the pig, leaving me with an even worse program in lovely pastels? Or maybe they'll dumb down an interface in an attempt to create a granny-safe rocket launch pad, leaving the actual rocket engineers frustrated? Or they'll just move stuff around for the sake of moving stuff around, creating a lot of busywork and forcing user retraining without any upside. I've seen all these things happen.
So what is your advise to this dev? How do I get designers that actually improve the design?
Create a design document that new members can reference, copy, and base changes from. Figma is a great tool for this, but even if you don't have a design in place, even an open github issue or notion page stating the pulse of the project is great. What is the brand, why are the colors the way they are, who is the main user of the project, what are current discomforts about the design? It's hard to propose design changes (beyond micro issues) when designers have absolutely no idea what was actively chosen and what was a throwaway idea. This design document isn't just for designers! Developers also need it, especially front end developers who would need to know important things like hey we do not have access to images beyond 50x50 from the API.
I feel as though these two can go a very very long way with designers. They aren't silver bullets by any means, especially not designers who aren't developers at all, but it can go a long way to encourage larger creative solutions.
Oh and A/B testing! You don't have to have a grand official A/B system (although there are quite nice systems these days), even releasing a change but explicitly asking users for their feedback on it can go a very long way in improving trust on the team and moving design decisions away from "personal taste" and onto "this change caused a 30% drop in purchases" objectivity.
Look up examples of design proposals for user interfaces. Unless it's critically important, aesthetics won't even be part of the equation at first... Core User Interface design is no more related to decoration than development is. Most UI design proposals deliberately use low fidelity block-outs and wireframes to avoid getting sucked into a useless cul-de-sac about Joe hating Green and Jane hating helvetica.
The process of interface design should involve users directly, have sound reasoning you can interrogate, and work directly towards solving problems. There should be defined user paths or user stories or storyboards that address the problems your users solve with your software, and the easiest, most efficient, must intuitive way for them to do it. Every element should have a reason for being where it is and working like it does for the users who need it to work like that. If it involves a change, that needs to be justifiable.
Have them slap together a quick prototype, even if it's a series of still frames. If you see something that works less efficiently than it did previously, well that user story needs to be amended or a new one created. It's it intuitive? Post it publicly and ask for comment being aware that some will just oppose any change and squash bikeshedding by reminding people of the scope of the proposal. There will likely be multiple rounds of revisions. A core tenet of UI design is acknowledging that pulling a big chunk of design out of your ass without consulting users is an insta fail.
Taste comes into play more with branding and identity, though fundamentally you're still solving problems with interrogatable reasoning... They're just communicating to who should be interested in your software and how they should feel about using it. This is a different design discipline, and while some interface designers have experience in both, don't assume it.
Definitely don't assume someone with a pretty design portfolio can design your interface... Their portfolio should include studies of ways they made software interfaces more effectively solve their users problems.
You have the same problem when trying to show an early mockup to a paying client, they keep picking at things that aren't going to be that way in the final, so you wind up rarely involving them until you have a really solid draft ready. It's a tradeoff you actively make because you're getting paid to make those micro-decisions for them.
It's unfortunate because I feel FOSS could work wonderfully with design, so much of what makes design great also makes FOSS amazing, but the bridge just isn't there.
Rude. People can learn to do multiple things without being pigeonholed, you know?
> I see so many opportunities in FOSS lost to basic, unnecessary branding and usability oversights.
It's FOSS. Feel free to contribute.
Just a few weeks ago on here, there was a developer complaining about not getting any attention through his efforts on social media, and from what he said he did, it was easy to tell he did not know what he was doing and severely lacked the sophistication needed to succeed. Instead of paying for marketing, he decided to do it himself and was about to give up without even thinking about paying someone else to do it.
This is hubris that is commonly seen in developers.
My hours of dev contributions to FOSS projects over the decades are somewhere in the low 5 figure range. Despite having a formal art school design education, I never contribute as a designer because FOSS projects are usually openly hostile to design input, even by someone like me who can implement it themselves.
> Rude. People can learn to do multiple things without being pigeonholed, you know?
Pigeonholing by not expecting specialists to be competent outside of their specialty? I have considerable professional experience as both a designer and a developer in the past decade-and-a-half, and a couple of other completely unrelated careers in the decade before prior. You're fishing for things to be offended by, and probably misjudging the amount of design understanding required for actual competence.
Suggesting that being a software developer doesn't also qualify you to be a designer seems to have really bothered you for some reason. I don't think saying so is any more controversial than saying automotive engineers aren't automatically car interior designers or that being a civil engineer doesn't automatically make you an architect. If you feel like you're a great designer, fantastic. Enjoy your broad skillset, as I enjoy mine. If you feel like my comment somehow challenged that, weird but sorry?
You:
> Developers shouldn't expect themselves to be able to do good design work
Also you:
> Having worked as a professional software developer in a reputable development organization for over a decade with steady advancement before I decided to go to school for design is a good enough indicator for me.
Reread that sentence. It does not say developers can't do good design work and it doesn't say that designers can't write good code: it says they shouldn't expect to simply be able to do it. Nobody should expect to be able to do anything non-trivial they haven't deliberately learned how to do. Unless you have evidence that most developers have done the years of learning it takes to become a competent interface designer, that's just not a controversial statement.
If you're going to continue trawl my comment for minutia to be aggrieved by instead of making any coherent counterargument, you're on your own.
* Security model. What is stored server-side unencrypted? In what circumstances is the server-side encrypted data available on the server in plaintext?
* Defaults: "parent-safe"? What trade-offs are made with the defaults picked?
* Ability to edit (Android) app associations. Bitwarden has this, and it solved a huge problem I had with duplicates on LastPass. There's URI entries like androidapp://com.example.app that are easy to manually merge and keep together with corresponding web sites.
* Domain matching. Bitwarden can do: base, host, exact, starts with, or regex. Lastpass had an "equivalent domains" managed from obscure settings, which never really worked the way I wanted. I used to have a billion entries for things in .mydomain.com, but bitwarden fixes this and by setting that flag properly I get only relevant things for each internal app. At the same time, for .myapp.com and .myapp.local I can get the default dev login, so when I deploy a new instance/tenant for dev, it "just works".
Username generation. Can it do plus-addresses? Catch-all domains?
Excuse the self-promotion, but I take it that you're also too wary to click on this link to read my blog: https://dangerous.link/virus.exe
> You should trust that your browser is secure enough to render random webpages.
I honestly don't. Is dangerous.link/virus.exe any more dangerous than nytimes.com? Probably not. However if some 0-day, no interaction browser exploit does exist, it's easier to put the exploit on the some lookalike phishing domain rather than additionally exploit some mainstream site.
Of course I can't possibly know what URLs are "safe" to click on and which ones aren't, but I'm going to guess that URLs that look like they're intended for a phishing campaign are less likely to be safe than any other.
If your blog is go0gle-com.net, and someone emails or messages it to me, I'm not clicking on it and deleting the message.
Most often what happens is I click some sketchy looking link on my phone and it attempts to hijack the browser with popups and history modifications and whatever other shit they do to let me know my Android iPhone is infected and must be cleaned immediately.
If you read through stuff like the security updates for new iOS version it becomes clear that this does exist at all times. Usually most of them are likely not even not found by attackers before they're fixed, but you can never be sure. Every browser has innumerable undiscovered vulnerabilities that at any time could be discovered and exploited by an attacker. Discovering this is hard and they don't show up all that often, but you never know, even some random ad could pwn you.
Contrast that to a link like "password-man-comp.tool.win". Which at first glance can be confusing to most where the TLD is and where the subdomain is. Or like the above person's tool. Either go with something readable, even if long, or go with something short and clever. Combining both winds up looking suspicious to most people.
Which I guess is the funny part, the ones most harmed by a badly named website/link are genuine people wanting to provide a service to others, whereas malicious actors will likely use more effective (and less easily blocked) means of phishing.
One note:
1Password uses WebAuth for Yubikey and LastPass uses text input. This makes LastPass work across *remote terminals* where you don't have access to the physical machine. Now, there might be a vulnerability lurking in there, but I often find myself working on a remote windows machine and need to log into something.
Maybe this should be a footnote in your Yubikey row? Or its own row, if it isn't already in there and I missed.
"1 undefined" "2 undefined" "3 undefined"
The use case is "I want an easy access "todo list" of all passwords to update that are older than (x months|specific date)"
I would use this after notification of a breach or on my own schedule. Having to manually inspect each item is not acceptable.
Bonus points if I can specify a "policy" for items (using tags and groups is acceptable if they can be incorporated into the search without too much effort). Super bonus points if the tool generates notifications and todo list automatically.
Why these features are not standard boggles the mind. LastPass used to have this feature but removed it for who-know-why reasons.
- Doesn't require a subscription
- Doesn't require a web login
- Allows local vaults
any other requirements that maybe you simply assume should be available (like browser extensions)
Absolutely amateurish. I hope no one trusts LastPass ever again.. I know I won't.
My account was registered 2010 if anyone is interested.
Finally moved to Bitwarden and couldn't be happier. Still trying to decide if I want to self-host it or not, but more breaches of cloud-based password managers like this one may push me in that direction.
I realize that "security through obscurity" is not a best practice but even if I trust SaaS Bitwarden to be more hardened than I will ever be, I can't help but think that any centralized password manager will have a target on their back so much larger than mine that it may even out.
The biggest risk I see with self-hosting is accidentally borking the whole thing and locking myself out of my vault. But I'll probably gain enough confidence to mitigate that somewhat soon.
Same as well, with an intermediate move to Dashlane. I want a reliable, expensive password manager. It's not an easy problem to solve, so if someone's trying to do it cheap, they'll get it wrong. I wish Bitwarden would charge more, but they've proven more secure than LastPass and the Android client is way more reliable than Dashlane.
https://bitwarden.com/help/account-encryption-key/#rotate-yo...
What?!
Of course, if you are careful and follow all the instructions, in theory you could avoid this. But why allow such a foot-gun?
> Making changes in a session with a "stale" encryption key will cause data corruption that will make your data unrecoverable.
I love Bitwarden but this is just… borderline hilarious. Laughing nervously. God damn it, don’t write a damn “help” article about it, create a P0 bug, fix it asap and write a post-mortem.
Field report: I tried to see this UX in action and while it is indeed bad, there are some redeeming factors:
- By default, you don’t rotate encryption key when you change master password. This is opt-in. I’m not qualified to say whether this is a good default or not.
- If you do, a full modal warning pops up explaining to log out or wait an hour:
- They invalidate the sessions automatically, but this is delayed.
AIUI you have to tick the box, not read the warning, hurry to a different device and modify the vault, and have pissed off the cache invalidation gods all at the same time to reach corruption.
I swim against the prevailing current in believing that the cloud should only serve as a backup, never as the primary solution.
LogMeIn and subsequently LastPass is has been owned by the private equity firm Francisco Partners since 2020. Ire can be focused on Francisco Partners as they completely gutted LastPass and other LogMeIn products shortly after acquisition.
Both companies were owned by private equity firms.
I personally really love having an in-browser password manager. It's an incredible convenience and it lets every service have a unique and nearly impossible to crack password.
I have far too many services to remember them all, and using the same password for everything would be terrible.
But of course I see the risk of having "one password to rule them all" and putting so much faith in one service. If it fails, losing everything is possible.
I don't mind paying of course if there's a reason to, though for now the free version of Bitwarden has been fine for years.
This doesn’t mean that they are perfect. While Firefox allows you to choose a master password for your local password storage, even after improvements this is a very weak protection: https://palant.info/2018/03/10/master-password-in-firefox-or.... From what I remember, Chrome doesn’t offer any local protection whatsoever – if somebody manages to copy this data off your computer it’s gone.
More critical aspect is the sync functionality: https://palant.info/2018/03/13/can-chrome-sync-or-firefox-sy.... Following my report, Chrome Sync has been improved and now offers reasonable protection at least for passwords – assuming that you set a passphrase which isn’t the default. In principle, Firefox Sync is better because it always encrypts all data, not merely passwords. But its bruteforce protection is very weak, the bug report I link to is still unresolved. So you would need a really strong password to protect the data (ideally randomly generated).
Originally (before I started writing my own password manager) I also thought that this is a safe method of password generation. And then I realized that it isn’t. Wrote about it here: https://palant.info/2016/04/20/security-considerations-for-p...
For tech-savvy people - https://www.passwordstore.org/
The rest doesn't work unfortunately, proven over and over.
Reference impl. in C#: https://github.com/bitwarden/server
Self-host friendly impl. in Rust: https://github.com/dani-garcia/vaultwarden
p.s.: reference implementation is by far one of the better examples of how to do microservice-based C# solution of high code quality right.
The first one is obviously not designed to serve as a primary self-hosted option but rather to scale for large number of users.
a user's password list is arguably the most important thing on the device.
And I'm not sure you need a "web interface" to something that in the end is nothing more than an encrypted text file, which is why I always recommend pass[0] or using the browser's built-in pw manager for people that don't know ssh and git.
[0] passwordstore.org
> With pass, each password lives inside of a gpg encrypted file whose filename is the title of the website or resource that requires the password.
This is the exact problem that LastPass just got hit with (okay, one of multiple problems) -- the vault doesn't encrypt the URLs of the sites you visit. Pass is really elegant, but it leaks a ton of metadata in pursuit of that elegance. Tracking password changes unencrypted in Git really seems like it's just asking for trouble.
Yeah, the actual passwords are encrypted and stay encrypted, and that's great -- but we've just seen with LastPass that it kind of matters that the entire vault be encrypted. I personally think there are better ways to get a CLI interface than exposing the site list.
However, git repo != GitHub. Putting the repo on a home server in the LAN has served me well over the years
head -c 256 /dev/random| openssl sha384 -binary | base64 | sed 's/[=\/\\+]//g' | cut -b1-22
where "22" is the desired length of password.> Is that supposed to be reassuring, considering that the cloud storage in question apparently had a copy of all the LastPass data? Or is this maybe an attempt to shift the blame: “It wasn’t our servers that the data has been lifted from”?
Wow, seriously, they are really good at this. If not for this explanation, I would totally thought only testing environment got accessed.
As written in the this post, 1Password uses a randomly generated "secret key" together with the user-chosen master password. This "secret key" is not stored on 1Password's servers, instead it should be printed on a piece of paper and stored safely. While this is a good starting point, it significantly reduces usability, since you need this piece of paper when re-installing 1Password.
At heylogin, we are rethinking this cryptographic design. In our case, a random secret is generated inside the smartphone's security chip. From this secret, all keys for encryption are derived. The smartphone app and the browser extension is end-to-end encrypted and authenticated using an out-of-band QR code. This results in the following UX: To log into a website in the browser, the user needs to confirm on the phone. The app now provides the extension with temporary access to the passwords etc (a little bit more complicated to explain here).
Thus, if the same breach would happen to us, the vaults would still be secure, since the e2ee does not depend on a user chosen master password.
It's not easy to get a foot in this market, but I am confident, we can do it.
What's the story with "my phone went in the lake" using that setup?
If a phone is lost and it's TPM compromised would that put all future credentials at risk?
Most of the derived ideas strike me foolish since they compromise future and past. And they accrue state anyway once one must rotate keys.
Let me first say that we are just finishing up a version 2 of our whitepaper that can answer all questions regarding the cryptographic architecture including these scenarios. We'll announce that in the next 2-4 weeks when it's ready.
There are different scenarios here:
* If you install heylogin on a new phone, you will get asked to transfer your account to the new one. If you confirm, everything is cleared on the old phone, secrets are regenerated and date is re-encrypted.
* If you are using the team features of heylogin, your admin can disable your old phone (even if it's broken) and you can connect a new one with the help of the admin. The secrets are re-generated and data is re-encrypted. The underlying architecture is a little bit more difficult here and will be explained in the whitepaper.
* You can write down a backup code and use this for recovery (I like this method the least)
* We'll soon have a feature where you can add a security key as another method of accessing your data. This will also help in re-gaining access if the phone is lost.
* We'll also probably have a "social recovery" in the future, similar to the admin recovery flow but for private users.
Internally, we have more ideas to provide transfer & recovery flows. We'll keep on experimenting.
Since secrets are re-generated and data is re-encrypted, even if the old phone is broken, the TMP no longer holds secrets that are usable to decrypt the data.
Does this answer your question?
you can bootstrap from an existing installation too. you’re painting this to be more of a hassle than it actually is in practice.
Scary for activists anywhere.
When there is a problem, how helpful is the customer service? If not then a person stands to be locked out of critical aspects of their digital life
The Mud-puddle test is to demonstrate that only you can access your services. If you can call and go "hey can I get back into my vault" so can anyone that convincingly can make the same call on your behalf.
The bigger problem is: even if you are safe right now, your vault is out there. If at any point your master password surfaces somewhere - all your accounts are instantly compromised. So the only sensible solution IMO is to start rotating all passwords and usernames today.
If it's 5000, you've got 20 times as much to worry about than if it's 100100.
2FA won't help. That controls access, but not decryption, and they've already got the encrypted data, so they're past needing to get access.
To be safe, start resetting your most high-value passwords immediately. Bank, email accounts, etc. Ideally, reset everything.
It is currently(?) the case for Bitwarden, yes, but that's incorrect for 1Password, as they have client-only key material that is never transmitted to the cloud: https://blog.1password.com/what-the-secret-key-does/
With regard to the "claim not not store" part, they've had multiple security audits including granting the auditor access to the underlying source code, so if there was something underhanded going on, I believe it would have gotten out by now: https://support.1password.com/security-assessments/
I'm with you that it's not as nice as open source clients, but given a choice between trusting 1Password with code I cannot see and trusting Bitwarden with code that I can see, I'm sticking with 1Password
I memorized a small function that takes the product name as input and spits out a password. it achieves the goal of having a unique pw for every service without having to write anything down (in software or on paper). I had to amend it to account for some services that require you to reset your password to a new one and for sites with annoyingly specific password formats (i.e. 3 special chars).
Can someone infer the function starting from the password and the service name?
If yes, then there is a low (close to zero, unless you are specifically targeted) possibility to gain a clear password from a shitty website and calculate your other passwords.
Take protonmail - they started to use “proton.me” instead of “protonmail.com” more and more often. If your f(x) was f(“protonmail”) originally but after being away six months you try in the middle of the night while hungover and driving in snow f(“proton”) won’t get the same result?
Let's say you have an account at AcmeCo. Let's say AcmeCo has a breach and I can see your password hash. Let's say the company uses a weak password hash (e.g. MD5), or no salt and it's easy to reference a rainbow table.
From this rainbow table, I can look up your hash and see that your password is "lulzSecret2$AcmeCo".
Now let's say you're in another leak from BetaCo. Similar situation -- I see that your password is "lulzSecret2$BetaCo2". Maybe the two is because you were forced to rotate your password once.
It doesn't take a genius to guess what your algorithm is.
But we can take it another level. Maybe I'll try all the major banks and guess passwords using your algorithm ("lulzSecret2$bofa", "lulzSecret2$chase"). Most banks require 2fa, but most of the time they keep it to text-based 2fa.
If I know your phone number from one of the breaches (happens all the time), maybe I can hijack your SIM card (this also happens all the time) and boom, I'm into your bank account.
The issue is that your passwords have almost zero entropy in them. The only guard is that others don't know your secret function. Password crackers are already programmed to handle functional password composition. You might want to ask yourself why pw crackers are programmed that way.
Generally people do not have specific attackers going after them they are going after broad spectrum attackers you don't have to be faster than the bear you just have to be faster than the other person running from the bear.
And yes I'm not saying that's actually secure I'm just pointing out a consideration. Also there are different classes of passwords out there email and password for marketing site I'm never going to use again but I'm forced to sign up for versus something that actually is protecting something I care about like my credit card or worse my financials.
There are a lot of sites with dumb rules like can't be more than 8 characters (old WSDOT toll rule) or can't have symbols... So it doesn't always work.
Assume a service you use was breached, and you have to replace your password there. You can work around it by having another input to your generator. Instead of (master password, service), you now have (master password, service, version). Maybe you append the version into one of the other arguments to keep the function the same; doesn't matter: now there's a new, per-service argument you have to track and remember.
For me, lastpass always seemed like a bad idea as passwords are very important to me and giving someone else a copy of my passwords seems like a bad idea. Similarly, I don’t let any services know my bank passwords even if they super promise to protect them and not misuse them.
Another similar seeming task that I can’t delegate is to read my bank statements and keep track of my assets and performance.
This isn’t meant to shame people who are now at risk from lastpass’ failure, but to understand if HN readers have similar personal habits and rules.
At some point the closest you'll get is a self-hosted BitWarden instance, in which case you are basically running LastPass/1Password/et al. yourself anyways. Then you have to ask yourself (a) can you host it cheaper than a monthly subscription of a competing service, and (b) can you maintain that instance better _in your free time_ than some engineers that get paid to do it every day?
The answer to (a) for me is definitely not, my colo bill is much larger than a 1pass subscription, and (b) is also probably a big fat no considering there were concerns in this article I hadn't even thought of. So ultimately I'm happy paying a nominal fee for someone to keep up w/ the ever changing landscape of OS/browser integrations & minefield of security pitfalls regarding credential storage.
I wish there was some elegant way to magically kept all my devices in sync, that was portable & standardized, but the reality is modern vendors seem more interested in creating silos than standards.
---
However there are things I don't put in my 1pass, despite it having great support for them, because I consider the alternatives more convenient or secure:
(1) My PGP/SSH keys are on a YubiKey
(2) My 2FA TOTP codes are on that YubiKey or some other authenticator
(3) My 2FA backup codes are on an encrypted volume. That secret is not stored in 1pass.
(4) My critical services (DNS, e-mail) require hardware backed 2FA.
The theory being even if you steal my PW vault you can't own my DNS, without my DNS you can't own my MX, and without my MX you can't truly own my online identity.
Except you're not doing that. You're giving someone else an encrypted blob.
The screwup here is that LastPass also stored a bunch of unencrypted metadata.
Having said that, it is still useful for less important logins like this website for example, where it isn't a big deal if someone manages to use the account.
However it is a huge privacy issue if people know what accounts you have. For example, I have a hackforums account and pretended to be a normal user there while only using it to scout attack vectors to patch. But to some people, they might assume that I was partaking in actual hacking which is not the case.
At this point any financial institution has 2FA, I think. That still leaves say credit cards, but they are exposed enough that you’re not exactly making it worse even with a terrible custodian like LastPass.
Password managers should be held to a high standard but we should also never depend just on a password for protection of anything of value.
https://aws.amazon.com/blogs/security/you-can-now-assign-mul...
At least the UI tells me something about the internal.
I’ve trained 3-4 non-technical users on LastPass and none of them found it intuitive or easy.
I’ve managed it in a corporate environment for dozens of users who were younger and more tech savvy, for them it was mostly okay.
If the alternative is using the same handful of weak passwords for every site, the risk of your password manager suffering a security breach doesn't look so bad in comparison.
1Password for /years/ worked with a local vault (and no remote sign-in requirement), and had relatively simple syncing to iOS via wifi (no idea on other OSes, that's what I use).
I've shared my password vault between these two places with no issues and it didn't need a cloud account and I wasn't re-using passwords.
I convinced a family member and their response to the breach was "okay, who should I use instead? Or do I go back to using one password for everything?"
Given that the "using one password for everything" is such a terrible idea that we can discount as probably worse than storing your passwords in a cloud-based vault then you land on what your family member has given you as the other option "what should I use instead".
Ultimately if* there are no password managers available that will do syncing of locally stored vaults, then there are actually multiple options here:
1. Accept that the convenience (of device sync) here trumps the security issue that storing passwords in a cloud based vault causes.
2. Should there be no options that allow for device sync /and/ local-only vaults then there is another option which is to not do automatic syncing.
Option 2. is somewhat inconvenient (how much depends on who you are and what you do), but it is still an option.
Personally, Option 1. is a line I'm not willing to cross. I see single repositories of 10s to 100s of thousands of peoples passwords as a "password piñata", a massive target for attack and so I'd take the inconvenience over the compromise. That said I'm lucky to have a 1Password 7 still so do have local vaults and sync, but there's not a chance in hell I'm uploading this stuff to a central repo.
* Enpass might do what you want. It was a suggestion in the comment thread here.
Our options are convenience of device sync or one password.
Or some other mechanism, because I have been told in no uncertain terms that's as far as it goes.
I can't even convince this family member to rotate their passwords. What makes you think they'll be willing to put up with more inconvenience?
Again, the problem is the unsophisticated user who only has so much brain space for this shit.
I can't imagine LastPass is long for this world after this one. Most other breaches were minor compared to this mess.
Some good points in there, but limited pragmatism.
What kind of pragmatism would you prefer? LastPass messed up way more than they are willing to admit. And it’s not like nobody warned them before, quite a few of the issues which turn out to be very problematic now aren’t news – I brought them up years ago as did others. LastPass should be warning users now and suggesting mitigation steps, instead they claim that nobody has a reason to worry.
As to the “speculations”: I have sufficient experience with LastPass press releases to assume the worst whenever they omit details that they should definitely know. On a number of occasions they covered security vulnerabilities that I found, and I know how they operate.
Mind you, I would be more than happy to learn that I’m wrong. But this isn’t a situation where “hope for the best” is a viable approach.
Note: I did not claim that LastPass is storing master passwords. They claim that they built their system in a way that they cannot. And I merely point out that this isn’t true: they could have built their system in such a way, but they chose not to, despite being warned about it repeatedly.
That's an odd take. Who could it backfire on? LastPass has already fumbled their own response to this crisis. If not him, others would speak up. If he's wrong, then he loses credibility. The upside is that, if he's right, we're even more aware that LastPass is not a company worth dealing with.
I'm sorry if you find this disturbing, but I do not see why it should not be said.
The best (if not only) way to make these points is to analyze the PR statement itself. Any paraphrasing or generalization would just give LastPass an opportunity to reply with more non-sequiturs.
Dissembling circumlocution and omission is a feature of PR communication, designed to mislead anyone who is not intimately familiar with all the details. I would like to se more analysis of this sort.
> Security professionals seem to have a common trait of thinking they know better.
The author here does know better than the people running LastPass.
No one can steal something that's not written down
Just like the Navajo code talkers in WW II had a system that was memorized, so even if the Japanese captured another Navajo and tortured him (which they did), he couldn't reveal the code.
Have some hints to yourself, and store the hints. Even if the file is stolen, the hints won't help the thief. Never, never store a "master key" of what all the hints mean. If you forget one, just click the "forgot my password" link.
I'm not going to even hint at the hints :) I use.
The big advantage is, the hints are only meaningful to you.
The big disadvantage is, the hints are only meaningful to you.
I didn't write it down, so no one can steal it. Simple indeed, thanks!