Catastrophic breach after catastrophic breach since 2011. Lastpass has failed their fiduciary duty as a steward of sensitive information and IMO exhibited gross negligence in not encrypting URI data, ostensibly as a trade off for consumer functionality.
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.
I think the whole LastPass fiasco just shows why everyone wants to get into the SaaS business so bad - subscription revenue is the gift that keeps on giving.
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.
If you have an business account, migration is non-trivial: It's not uncommon to have hundreds of shared folders of secrets accessible by hundreds of teams.
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.
Last time I migrated (many years ago), not all the data was in the export. And the secure notes especially were mostly missing or messed up.
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).
I haven't read the 1Password whitepaper, could you elaborate? Would be curious what 1P is doing that is substantially more secure than what LP is doing (not counting the braindead stuff like not encrypting website URLs) Having been a 1P user, my guess is that, unlike LastPass, in 1P the data used to encrypt your vault includes both a completely random key and your master password, while in LastPass it's just your master password. Is there anything else?
Yes, 1P uses a random key additionally to the master key, like you described. That's the one 1P asks you to print out and hide somewhere, and which you also need when opening a vault on a new device. I don't know what LP does, but here are some notable things I gathered from the 1P whitepaper:
- 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.
That's useless if you're migrating away because of security concerns. What you actually have to do is to go to all of the sites and change each of the passwords you have stored in LastPass.
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.
I feel this way but this is wishful thinking. It's more likely that they will transition even more into a gray privacy territory by marketing LastPass to less and less tech-savvy users, eventually bundling it for free with some spammy ad-supported service and/or preinstalled on a phone or laptop (basically, Norton and McAfee territory). The parent company is already not trustworthy, and this breach is the last nail into LastPass as a trustworthy service.
Most economic models of equilibrium explicitly state that they model outcomes “in the long run” for precisely this type of a circumstance.
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.
Duopoly. Plus cost of switching away once you sign up.
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.
All major browsers offer password management, then there's Apple Keychain, 1Password, KeePass, Bitwarden, and Lastpass. And that's just the ones I could think about while reading your comment.
Where is the the duopoly, and who's being forced out of the marketplace due to lack of government regulation of password managers?
Much of this could be addressed by antitrust enforcement as well as actually having competent lawmakers that understand the products their citizens use overwhelmingly daily. Policymakers barely understand the internet, let alone zero knowledge architecture and encryption
Sundar Pichai being asked about if someone is handpicking search results comes to mind, as an illustration
in one regard i'm with this and i do want them to have a fiduciary like responsibility
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 know password manger services are super convenient, and probably worth the cost for most, especially non technical users. But my preference has always been to manually manage my own local KeyPass database.
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
Here is my problem with KeyPass: its unclear to me how it deals with emergency family access.
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?
That sounds like a huge anti-feature to me. The few services that a next-of-kin should realistically need access to (banking and... that's pretty much it) will already have a process in place for handling this.
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.
Yes, most services have a “death process” that typically involves the next of kin sending the death certificate and some type of document confirming they are in charge of the deceased’s estate. They might then set you up with your own login, or send you paper copies of all the info you need to an email account or mailing address.
All of our family pictures and videos are in a place that only I have the password to. If anyone wants anything, they come to me. That is another password I would want passed on. I also pay all the bills. My wife would need access to all of the utility accounts, the mortgage payment account, the credit card accounts, the insurance accounts, the retirement fund accounts, etc. There is way more than just banking.
This is the reason I went with LastPass, because they have a feature designed and designated for recovery after death, with support, and 1Password would require me explaining to my family how they would use the emergency kit after I died, and they would likely 1) be pissed at being asked to understand it, and 2) not even try it after I died, and suffer all the inconvenience of not having access to my accounts.
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.
> 1) be pissed at being asked to understand it, and 2) not even try it after I died, and suffer all the inconvenience of not having access to my accounts.
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!
Excuse me if this seems impolite, but is there a reason you need his passwords? Financial institutions have a very regulated pipeline for access of deceased accounts to relatives. And for personal email and stuff, well I think that should remain private unless the deceased explicitly wanted to share.
This is a place with significant cultural differences.
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.
Transferring financial accounts I found out to be a very difficult and time consuming process. In some cases it was just flat out not possible even though I had everything I needed. I was shocked by how bad it was.
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.
Having going through this experience, there is often lots of little things. Maybe there was a shared domain registered to your email account. Closing or moving Netflix, or Disney+, or your vegetable subscription service, is much easier if you can just log in and close the account -- this can be done by writing to the companies, or if you just stop paying and responding, but everything is just easier with email access.
One of my parents neighbors died suddenly of Covid. She ran a small business as a vacation planner. Her husband did not have her email password. This was a huge pain and a source of stress when he was arranging the funeral because he was unable to inform people who expected her to be managing their upcoming vacation that she died. Sometimes timely access is valuable.
Where I live it could take months (or even years if thr heirs of a deceased doesn't agree on the terms) to have the access to the money. It would be quite illegal to knowingly use the money of a deceased person, but things happens.
Fair question, but since it's not a service, I don't see how that is KeePass' responsibility. But, It's really just a simple as making sure your dependents have a copy of your master password. If I remember correctly, the native Windows version has a step to print of a sheet to share with family members when you create a new database (I could be wrong, it's been a while). Either way it would be trivial to type up a word document to print off. If you use a key file as well, it a little more complicated. Depends on if you're assuming folks have access to your machine or not. As someone else suggested, a thumb drive could be a good solution. Whatever you choose they need to have a copy of the DB file, master pass, and key file and you're good :)
With KeePass, the trivial solution for this situation could just be a second subset database of relevant accounts on a thumb drive, with the password known to family individuals. That seems easier than relying on a cloud provider and some sort of half-baked insecure emergency access mode.
I'm not really sure how this anecdote is relevant. Are you denying that flash drives fail? Are you endorsing not having a backup plan?
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 have backups, thank you. My kdbx is in my Nextcloud, synchronised across my 4 PCs and Mac and my phone. So I have 6 copies (one on Nextcloud, and one on each device) at any time. Then I have backups on secondary storage (like external drives).
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.
Yes. I do this. I have all my financial account numbers and passwords written on a piece of paper stored in my safe deposit box. If anything happens to me (knocks wood), my family will still be ok.
What else is in your self deposit box? I thought only rich people with gold and jewels and spies with fake passports and ready currency used safe deposit boxes.
I'm middle class. We have a safe deposit box where I keep stuff that would be a pain in my ass to replace in the event of a fire/flood/etc.
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.
A local bank near us provides a free one as long as you keep $100 min balance. So ends up being very cheap offsite backup to store important documents, a backup hard drive of most precious data, etc.
When we first immigrated to Canada my family kept some of our documents such as birth records etc. It was super cheap and my family felt security was beneficial.
They are really handy for storing backup hard drives too. Short of having your own armed guards and razor wire it is good physical security for free or cheap.
Something to be aware of regarding safe deposit boxes: possession of the key does not automatically grant access to the box.
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.)
To add to this: if someone is not on that access list but is instead listed in a will, my understanding is that the will has to go through probate before access to the box is granted. It's quite likely that people would want/need access to passwords before that.
It depends on the scenario. Which is why planning eventualities is so important. If I suddenly die, then my wife has knowledge and signatures on file necessary to keep going. Also a three ring binder book to look up since that is not the time to be making decisions. If both my wife and I die together, and our minor kids are the ones remaining than immediate password access is a good deal less important compared to the keeps being fed and housed and things being worked out. Of course the will will come into impact, guardianship, life insurance, social security survivors benefits, when they will live, where they will go to school. Winding down this business I have and other matters would be secondary.
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.
> How would KeyPass deal with the same type of situation?
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).
Print password and detailed access instructions. Put instructions in safe deposit box. Allocate access to safe deposit box in your will.
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.
With KeePass you'll have to manage said emergency access. Either by sharing that master pw directly or maybe if it concerns business matters by keeping those records in an own db and employ a notary to manage such emergency access.
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.
My wife and I have the password to our vaults in each others vaults, however I am not sure what would happen if both of us die.
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.
If one uses an offline password manager then you want the stored passwords to be approximately as secure as memorized passwords.
So how do you deal with emergency family access to memorized information in the deceased person's brain? Same deal.
One option (albeit not the simplest): Shamir shares + a few trusted individuals or locations (eg. family, lawyer, safe) + "in the event of my death" instructions enclosed with your will.
I've actually ended up syncing my KeyPass db & sharing it with my team via our own gitlab instance.
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
Doesn't this create the same problem, albeit on a different pain point? Now the service/methods you use to sync and store your DBs are a problem without much benefit? I've seen people use keepass and then google drive, which just seems silly at that point if you're going to negate keepass' benefit (local management) just to attempt to gain some of the benefits of managed services like bitwarden in very clunky ways.
unlike the others where your only option is a single database, some keepass apps allows you to have multiple databases open at a time which means you can split up your sites/passwords depending on how important they are and have a different levels of security for each one.
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
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.
I've been using Dropbox, then Nextcloud to keep the database synchronized on all my devices for years and years. Absolutely no problem at all, and dead simple.
Then you're stuck with Chrome forever. Same with Firefox or Safari. I wish browser vendors would agree on one password sharing protocol that's just some end-to-end encrypted blob that you could download from any browser and unlock with your password. You login to your Firefox or Google account, add passwords, and if you want to use those from the other browser you just get some http link that points to the encrypted blob and then the other browser downloads the blob and you unlock it with a password.
You can export your passwords as a CSV file and import to other browsers (obviously if one chooses to do this, they should delete this file securely after it's been imported).
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.
Sure, but if I have a Macbook with Safari and a Linux workstation with Firefox and a Windows gaming PC with Chrome, then I have to use a 3rd party service, right? I don't mind that personally, I'm just an old man yelling "You should have better interoperability between similar competing software services!" at clouds (in the literal and figurative sense).
Google nuked an old email address of mine which was using a custom domain (free Workspace account). That email contained all my correspondence for a period of about 10 years. No way to restore it, no way to flag it to anyone at Google. I have been slowly removing Google services from my life, one of the last transitions being to Kagi.
You're telling like they didn't send tons of notifications emails before they did so, eh? And after they "nuked" (you lost your access), you still had months of time to pay and restore access.
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.
That’s always there. People rely on the google a lot. Have apps in play Store, run YT channel. And other platforms similarly have power over their user base.
I wasn't quite ready to self promote this but I will go ahead anyway, since people are probably researching alternatives now. I'm working on a comparison of different password managers.
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'm admittedly a hammer seeing everything as a nail, but as a designer, I see so many opportunities in FOSS lost to basic, unnecessary branding and usability oversights. Developers shouldn't expect themselves to be able to do good design work any more than designers should expect themselves to be able to make scalable, reliable, maintainable, production-ready code. It's a specialty for a reason! Incorporating designers into FOSS projects from the beginning seems like a no-brainer, but design is nearly universally considered a superficial matter to be considered once the real work of back-end development is done (which is generally never.) It's one of the reason that open source alternatives will remain the alternatives rather than the standards. Good design takes a lot of up-front work, and once you get ignored or bikeshedded into oblivion with one design proposal, the liklihood of doing it again is pretty much zero. Definitely my white whale, but it kills me to see so many great projects that could have so much more impact if they enfranchised specialists to design the look and feel.
One of the great difficulty of tackling that problem is often FOSS projects are averse to design decisions like that made by someone relatively fresh to the project - even if the problem is incredibly obvious to the designers and not the core development team. You would have to spend a lot of time gaining trust to then be able to present an idea like switching domains.
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.
As a professional designer who's spent more time in my life developing FOSS than designing, I generally see FOSS projects refusing to accept design input, period. I've thought a lot about why and I see two broad problems:
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.
Let me respond as a developer with admittedly no taste at all, who both committed and fixed plenty of atrocities:
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?
Standardize communication, if the team talks on discord, have a channel for design. If there are github issue labels for feature requests, have labels for various design requests. Things like this go a long way! Contrast how people feel about translation changes vs design changes. Most people don't even know if the translation is valid! They accept it however easier than design changes purely because there is so much more standardization with translation changes. Create spaces where design talks can happen without people feeling like they're stepping over others toes.
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.
How would you treat the same problem if it was security, or some really deep performance-critical vendor-specific database design issue or any other problem that wasn't practical to learn yourself before acting? Design is absolutely no more full of snake oil salesmen than web development, for example, you just intuitively know how to spot shitty cargo cult WordPress 'developers' and not shitty designers.
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.
I definitely agree with these two major pain points. It relates to some of my personal experience as well, you would have to effectively solo an entire design markup just to potentially get key FOSS members on board with design changes.
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.
Yeah... the big difference with paying clients is that they know there's a need, and they know they can't do it themselves (even if they incorrectly think they know enough to judge why.) Working with FOSS is essentially cold-calling clients having done a design proposal upfront.
Speaking as someone who was mainly a "developer" for a while, one frequent problem I see from developers is that they assume they can excel at everything because they are good at coding. Since coding is a hard task that not everyone can do well, they think this talent applies to everything else.
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.
Solid example, thanks. Worth specifically noting that we shouldn't be quick to judge, though. Every one of us has succumbed to novice cockiness at some point in our lives. People who build things, like developers, gain novice-level knowledge of everything from interface creation to domain-specific knowledge to copy writing to photo editing by osmosis. I'd be lying if I said I was any different.
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.
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. Being asked to speak at a couple of conferences about my dev work is another good sign I guess.
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?
No, it's just amusing how hypocritical you are. You can be a designer and a developer, but nobody else can?
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.
> Developers shouldn't expect themselves to be able to do good design work any more than designers should expect themselves to be able to make scalable, reliable, maintainable, production-ready code.
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.
Clicking on a 'phishing' link can't hurt, and it's not like this person's website is ever going to be presented to you in a sensitive context (e.g. "download/install software from this site"). You should trust that your browser is secure enough to render random webpages.
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
Any URL on the web could host a browser exploit that requires no interaction beyond visiting, but if I had to guess which one were most likely to, I'd put phishing links up there.
> 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.
>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.
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.
Exactly, which is why I don’t assume my browser is secure. I could get pwned by an ad on a trustworthy site, but there’s not much I can do about that so I take that risk. Visiting sketchy URLs is a risk I can choose not to take.
Your link is actually a great example. It's readable, you know what each part of the link is for (unless you're tech illiterate in which case just the readable quality is enough). And so by clicking it, I know I'll probably head to some page called Dangerous to see virus.exe.
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.
It’s hardly working at all under Wayland. Copying to clipboard has been broken for at least 18 months. AgileBits doesn’t seem to care. [0]
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.
Thanks for providing the detailed comparison among the many password managers. I think it's more accurate to describe 1Password's CLI as "yes" rather than "yes?poor" and submitted a PR for consideration: https://github.com/Soft-wa-re/password-manager-comparer/pull...
one thing I wish Bitwarden did is conditional username for URI
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.
I see a few things that might be worth adding, as some were explicitly why I switched from LastPass a few years ago:
* 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?
This is a cool page. One thing that is important for me that is lacking here is emergency access (e.g. https://www.lastpass.com/features/emergency-access). It would be great to see side-by-side comparisons of that.
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".
Which apps handle this better? I'm not supremely concerned about my password being pulled from memory, from an attack surface perspective, but I am curious which apps address this best and how.
Not saying it's the best out there (and the UI is a little clunky as it often flashes a pin input screen that gets skipped over when using your fingerprint), but I like how Keypass2Android can be configured to do it. When you select "Enable Biometric Unlock for Quick Unlock" (and don't disable the PIN feature) you can use your fingerprint as long as the app is still in memory, without it storing your master password.
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.
One of the major features I'm looking for is the ability to easily list passwords by age.
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.
KeepassXC does this, probably other keepass clients too. There are columns for creation, modification, expiration, and last-access, all of which can be sorted on. Each entry can have an expiration date/age.
Simple. Portable. Works across platforms. Local. If that is a selling point for you, password safe just works. I apologize if it sounds like an ad, but I am a very happy user.
Sweet. I've been looking for this. I decided to ditch my home-grown solution and switch to a real manager this week.
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.
Thanks for posting this. I was about to post an "Ask HN" to see what password managers people here are using, but this seems very helpful to compare the various services.
After doing some more research, I've pretty much come to the conclusion I should be using KeePass (or KeePassXC) but I wasn't really sure how I should go about syncing. I will definitely look into Syncthing, thanks!
It depends on how one views "free tier," since if one doesn't pay when requested (whether from the end of a trial, just normal expiry, or if there's a separation event from the "free family for business") the vault remains yours and active, but goes read only.
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
Thank you for this confirmation. I already suspected that LastPass failed upgrading people’s security settings for each change of defaults they made. But so far I’ve only seen one person who found an account with one iteration (that was their very first default). Now you gave me two more.
Incredibly pathetic. I am so disappointed in LastPass. I was willing to forgive their subpar UX because hey, at least my passwords were safe. I've moved over to Bitwarden and am happy for now, but man what a shitshow.
I love BitWarden, but coincidentally yesterday I saw a problem pop up on Reddit that was terrifying: There is a known issue where changing your master password can cause you to lose all your data:
> When you rotate an encryption key, you must immediately log out of any logged-in sessions on Bitwarden client applications (Desktop App, Browser Extension, Mobile App, etc). […]
> 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.
Agreed. It should at least log you out of all sessions without you having to do it yourself. This is good to know if I ever want to rotate my encryption key. Knowing this, I may even log out of all sessions even if I was rotating my master key.
Same, I held onto Lastpass much longer than I would have put up with any less-essential SaaS product.
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.
At least Bitwarden encrypts the whole vault as a blob. I don't bother self-hosting because I figure I know less about hosting a Bitwarden vault than they do so it's not much more secure. If I had a local server on my LAN I might consider it, because then at least I have a few firewalls between me and the internet. I've been a happy paying Bitwarden user for several years now, since just before the first "minor" Lastpass breach.
Yeah, I’m definitely not trained in security like the password manager engineers are. But I keep wondering if being distributed offsets that risk. That is, I can spin up Bitwarden in my Unraid machine in like five minutes and behind a reverse proxy, nobody even knows it’s there to attack. Maybe I have some security vulnerability, but it seems significantly less likely to be tested than a centralized commercial service. Curious if others have thoughts. I’d happily pay Bitwarden for whatever.
Yea this is exactly where I am. I have an Unraid box at home, currently mostly using it as a NAS, Plex server and for some home automations.
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.
I'm one of those software devs who don't do my own stuff, I happily pay services for good products, but I know it would be "better" security (probably) to have my own server in-home and all that. I don't just choose anything, but I don't want to deal with servers or technology debugging outside of my day job. I used to run my own servers and just got tired of having to maintain them; and even "fully automated" systems need maintenance.
> disappointed in LastPass ... moved over to Bitwarden
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.
A lot of people argue that a cloud provider has more expertise in a given domain than a customer for whom IT isn't a core competency. I reject this argument. What we have here is the classic principal-agent problem in economics. Your data is (or should be) sacred to you. LastPass's regard for your data is only proportional to the profit they think they can extract from you. Beyond that, they only answer to Citrix's shareholders. (Citrix, or Shitrix as I call them, is ultimately the parent company.)
I swim against the prevailing current in believing that the cloud should only serve as a backup, never as the primary solution.
Cirtrix hasn't ever been the parent company to LastPass. LogMeIn bought Citrix's GoTo product division, and also bought LastPass, so that's the extent of their relationship.
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.
I would love to have a service that cataloged all private equity takeovers so that I could migrate away from them. Every time they milk the brand and slowly atrophy.
I'm really curious what people in the know have to say about PM's in general and what the good options are.
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.
Browsers’ built-in password managers certainly have above average quality, at least when used as a purely local solution. A while ago I listed typical issues of the browser integration in password managers, browser vendors have it all covered. Except for #5 where they opted for convenience: https://palant.info/2018/08/29/password-managers-please-make...
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).
I have a small script that does hash(key + masterPasswd). key is usually just the site's domain name. I have the script and a few of the important passwords (eg my email) written down on paper in case my drive dies. It works fine for me.
It isn’t. You certainly used MD5, SHA1, SHA256 or SHA512 as hash, with SHA256 being the most likely one. All of these are very easy to bruteforce – if someone has one of your passwords, bruteforcing your master password won’t take all too long.
Self-hosted instance of Bitwarden works pretty well, and you can make it accessible behind a VPN to your local network only (plus there are multiple implementations of its back-end). Less-automated solutions make impractical concessions in usability.
Oh, I'm sure Vaultwarden is much more resource-friendly, but even then:
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.
For whatever it's worth, I think people should be a little careful about using Pass. From their website:
> 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.
>> The cloud storage service accessed by the threat actor is physically separate from our production environment.
> 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.
I think we can do better in protecting vaults against offline brute force attacks.
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.
> 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.
you can bootstrap from an existing installation too. you’re painting this to be more of a hassle than it actually is in practice.
maybe… I sort of agree it's not a huge hassle when recovering from another still functional 1Password installation. I still think that the initial flow of asking the user to print something that looks complicated is something that turns away users who are less IT-savvy.
You are asking the right & also complicated questions :)
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.
I would legit pay money for Google to pull that piece of junk from the Play Store, because it's damn malpractice at this point, given there are so many other options that don't straight-up swallow the TOTP keys
You can back the secrets up to a text file, print them out, etc. too. They're short Base32 strings and TOTP is a standardized protocol with an RFC (6238) and everything.
Except it is cumbersome to doo on Google Authenticator. You must press export to get shown a giant QR code. You can't screenshot it. Must photo with different phone and print on a piece of paper for offline storage.
Thankfully their UX is awful, which prompted me to switch to 1Password. It feels like they're milking a cash cow rather than trying to improve the product.
"We learn here that LastPass was storing your IP addresses. And since they don’t state how many they were storing, we have to assume: all of them. And if you are an active LastPass user, that data should be good enough to create a complete movement profile. Which is now in the hands of an unknown threat actor."
While having a Customer Service Rep tell you you're shit out of luck if you can't remember your master password may suck, it's pretty much the only way to actually be some semblance of safe.
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.
Assuming I'm a LastPass user and I have a sufficiently long master password with hardware based 2FA do I have anything to worry about? The one weak link is mobile authentication which bypasses 2FA. I honestly forget how that's configured.
A long password doesn't mean much by itself. If it has been previously leaked in a different breach, reused, is relatively easily brute-forced - then yes, you need to worry about that.
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.
I initially assumed I would be safe because of 2FA. Sadly it looks like this is not the case, the second factor is used to access the encrypted data, not decrypt the data. As the attacker already has the encrypted data, they have bypassed the stage where 2FA is providing protection.
This appears to also be the case for 1password and bitwarden, so not specifically a lastpass failure.
> This appears to also be the case for 1password and bitwarden, so not specifically a lastpass failure.
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/
Yes, a secret key like this could have made this breach much less concerning. Assuming you trust the company to not also lose this data (that they generate and claim to not store). What I was really hoping to find was a paid, cross platform, cloud sync'ed solution that can be setup to require your password and physical key to decrypt. i.e. have 2FA protection from a data breach like this.
There's nothing that I'm aware of preventing one from putting the secret key material on a hardware wallet of your comfort level and having it type in the encoded value when signing onto a new device (the way the Yubikey pretends to be a keyboard when plugged in); obviously(?) 1Password is not incentivized to own such a complex workflow but there's nothing that I can see stopping you from doing it. FWIW they also support 2FA on login, which is different from the secret key to unlock the vault, so ... 3FA?
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
Can someone point out a big flaw in my password management system? I have always felt kinda dumb for not using a PW manager but my system has worked for the last ~10+ years and I have never had any issues.
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).
Not necessarily a huge flaw and indeed it’s a method I used for a long time too - but what it doesn’t really help with is when there’s a breach and one of your passwords is in a leak. What do you do: make (and remember) an exception and the second choice function? Or change all your passwords so an amended function still holds true for all sites? With a password manager you just change the breached one and that’s it.
I used to do a similar thing, then I realized it was a potential problem.
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.
Assume the function is a cryptographically appropriate hash function, you can reduce the risk of suggested attack to almost nil, considering the number of inputs you'd need for such attack
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.
> Can someone point out a big flaw in my password management system?
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.
Yes but is someone specifically looking at your passwords across all the accounts I'm trying to crack them or are they just taking the easy road and trying those same passwords and every other site. One requires a lot more effort than the other while still being relatively easy.
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.
What about when a product changes names, between your logins?
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?
> function that takes the product name as input and spits out a password
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.
Can't reuse a previous password is a great signal of what your password actually is.
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.
This is pretty cool, and could even make a great "no storage" type product here. Hmm 1 problem could be forced password changes? I've noticed some sites at times require password changes.
It would be interesting to hear people’s life philosophy in this area.
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.
It's a tradeoff based on convenience. I use Linux, Windows, Android, and iOS on a daily basis; using some combination of SyncThing, OneDrive, Google Workspaces, and iCloud. Getting an offline-first PW manager to work correctly and consistently across those devices, operating systems, and services is no easy feat. Doubly so if you actually want proper integration with the OS & browser keychain.
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.
I would never put financial passwords in a cloud based password manager. Even if they do everything perfectly encryption-wise, no one can guarantee an attacker wouldn't alter the client-side code to leak your master password.
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.
> I would never put financial passwords in a cloud based password manager.
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.
And of course they have a new version where they are constantly asking you to store credit cards and addresses, unless you dig deep into the settings to disable those constant prompts.
Maybe before I die multiple YubiKey support can be considered a standard. Even AWS doesn’t support it which is just unfathomable. They support one, so you can’t have a backup, so they may as well not have the feature.
Question that may have been answered but I'm coming up short with searches. What about LastPass Authenticator TOTP seeds. Were those compromised as well?
I'm not sure about the insight. But i hate the UI, UX of Lastpass. Why it's so hard to change for simplicty and ease of use ? Is it dark pattern, is it technically impossible due to technical architectural complexity, or tech debt,.. ?
At least the UI tells me something about the internal.
The login text input button overlay is often obscured by other elements with click triggers, in some cases making it unusable. Many sites don’t populate with the input button so you have to get the password using context menus.
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.
Because there needs to be a baseline level of convenience in order to get less-technical people to even consider using a password manager at all.
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.
There is a pretty large gap between "cloud based password storage" and "using the same password for each site".
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.
That's literally the option though if you've managed to convince someone to use a password manager.
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?"
"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.
The gpost contributed to the discussion i am having with my kids, namely: avoid cloud-based pw storage. They're beginning to understand why, finally.
We also discussed 'feeling better than others for arbitrary reasons '.
I spent the holidays moving to a different provider (1password). 1password's security posture is superior in almost every way and it allows me to avoid having to worry about syncing keepass, etc to my phone and 10 different computers. I still have hundreds of passwords to change at this point.
I can't imagine LastPass is long for this world after this one. Most other breaches were minor compared to this mess.
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.
This is a compelling article, I feel more motivated now to reconsider my options. FWIW, my $0.02 feedback on pragmatism: as a user, it would be nice to have more what-to-do-about-it for non-security-experts. Also I didn’t love the parts of the article where you speculated about LastPass’ motivations and process (even if they turn out to be true!) The opening paragraph is making assumptions about the timing, which could backfire pretty badly if you’re wrong. You also speculated about the web site storing master passwords, justified by saying “they absolutely could, and you wouldn’t even notice.” They could do a lot of things, including selling passwords to the highest bidder. From my non-expert point of view, it’d be more helpful & pragmatic to stick to known facts and not whip additional fear into what is most definitely a bad situation.
Thing is: this is the third article on the topic I wrote in the past few days. Covering your options wasn’t the goal here, it’s in the first article: https://palant.info/2022/12/23/lastpass-has-been-breached-wh.... Particularly the “executive summary” at the start.
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.
The statement you objected to was used to demonstrate that a specific claim by LastPass ("As a reminder, the master password is never known to LastPass and is not stored or maintained by LastPass") offers no guarantees that your master password is known only to you. This, in turn, leads to the conclusion that, even if you followed all of LastPass's guidance on master password security, the prudent thing would be to take some action - something that LastPass explicitly denied later in the statement.
I'm sorry if you find this disturbing, but I do not see why it should not be said.
> which could backfire pretty badly if you're wrong
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 completely disagree. The article makes an extremely strong case that the press release was designed to mislead people into downplaying both the severity of the situation, and the depth of incompetence at LastPass (both of which are matters of considerable importance for all current and prospective LastPass customers.) Attempting to mislead people is considerably more serious than mere incompetence.
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.
I disagree, this article did not come off this way to me, as all the comments were brief and backed up with supporting materials. In addition, the usage of words that would convey feelings the author had about the company were nonexistent — they described the actions taken (or not taken) by the company and left the reader to come to their own conclusions.
Agreed. The tone was objective and factual. It's too bad the owners of LastPass failed to heed the criticisms that preceded this incident. FYI for anyone carping about LP's legal liability here: read the disclaimers (and indemnification agreement) in their TOS (personal or business). It's a real howl, and pretty much software industry standard.
A (perhaps) unconventional approach to password management, which I recommend to anyone. If you enjoy complexity, this is too simple for you.
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.
This used to be my main approach, but now I only use it for some key sites and rely on a password manager for the other 90%. Why the change? Watching the mental deterioration of aging on friends and family, and noting the beginnings of such things in myself. My mind is so much slower than it used to be, including recall. It's not only aging. A friend had a concussion from a lousy picture frame falling off the wall. It wasn't even that big or heavy. 3 years later still slowly rebuilding mental and language function.
I forgot the other part of my reasoning: my hints only work for me. If I am incapacitated in a way that affects my password recall the hints won't mean shit to my family.
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.