The situation at LastPass may be worse than they are letting on
twitter.com
twitter.com
> At Bitwarden we take this trusted relationship with our users seriously. We also built our solution to be safe and secure with end-to-end encryption for all Vault data, including website URLs, so that your sensitive data is “zero trust” secure [1]
I haven't used LastPass in years, but the recent news made me wonder how Bitwarden was handling URLs.
[1] https://bitwarden.com/resources/zero-knowledge-encryption-wh...
https://1passwordstatic.com/files/security/1password-white-p...
It’s quite good.
Items contain overviews and details which are encrypted separately by the vault key. We encrypt these separate so that we can quickly decrypt the information needed to list, sort, and find items without having to first decrypt everything in the vault.
Item overviews include the item fields needed to list items and to quickly match items to websites, such as Title, URLs, password strength indicator, and tags.
Not a single other tool is better than it. /HappyCustomer.
I didn't like the move to a subscription model, but I'd have sucked that up if I could've continued to bring my own sync.
For those of us that have been using it for long enough, we can still use the "classic" version stuck at v7, but it means being able to self host. no monthly SaaS fees.
"file /Applications/1Password\ 7.app/Contents/MacOS/1Password\ 7" says "Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64 - Mach-O 64-bit executable x86_64] [arm64]"
Activity Monitor says that all 1Password things are of Kind "Apple" (not "Intel").
It’s fine to store your passwords online for convenience, but as a user, it’s important to accept that it’s no longer your private password and will, at some point, leak.
That's a consequence of the Murphy's law [1].
Very well written. You phrased it perfectly for it to have its place at [2] which is full of this kind of stuff. It's almost like this sentence claims itself the right to appear there. If you read French you might enjoy this website. If not, you might still enjoy the different phrasings of Murphy's law in different languages here [3].
[1] https://en.wikipedia.org/wiki/Murphy's_law
Military grade when we're talking about a screw is a little different. It means that the screw is made and QC'd to a very specific spec/standard.
My next question might be, "Where can I find you on the FedRamp approved list?". To which, I'm sure they'd respond that anything outside the algorithm is not military grade, which is what most attackers will exploit in the end.
FIPS certified systems can actually be less secure (by design) than non-certified ones
I'm working on an opensource project for Linux users that needs crypto. Needless to say, I'm not an expert in that domain. I was planning to ask experts for help in reviewing the crypto. Your statement makes me slightly nervous. What is the standard procedure to ensure crypto safety in a software project?
Yes. That's the plan. I'm using Rust's crypto libraries. All the code in the application are basically just calls to those libs.
> Apart from that, get audits if you have the means
Unfortunately no. But I got the plan from a crypto forum. I will be seeking their validation when it's done.
To give a couple of specific (but non-exhaustive) examples, generally framed in terms of password managers:
- A password manager should protect the identity of the sites the user has saved, the content of the username and password field, and any associated notes. (That's fairly straightforward, most people are likely to agree on this). But what about integrity? Should you use an authenticated cipher mode like GCM? What will you do if the authentication tag fails verification?
- The password should be encrypted such that if a password is re-used across websites, it is not discernable from the ciphertext that this is the case. (Fewer people will think about this, but some will... Using AES in ECB mode isn't enough to prevent this! Lastpass appear to have done this in the early days).
- The key used to encrypt each ciphertext should probably be unique, to reduce any potential impacts of weaknesses in ciphers or cipher modes. Each cipher should use a unique per-instance instantiation as well (i.e. IV, GCM tag, etc.) How do you store and derive these passwords though? That will take you into key derivation functions, and password-based ones, like scrypt/bcrypt/argon2. These can derive a crypto key from a user password. You can then use that key as input to a KDF (with a per-entry salt) to derive the actual AES key used for each entry.
- If you're designing a wire protocol, what properties do you seek? Replay resistance? How do you prevent session resumption type attacks? (don't design a new wire protocol, use something robust like modern TLS!)
98+% of the time, at least in my experience, people who mess up crypto don't understand what goal they are seeking to achieve by using the cryptography, and haven't threat modelled it. Usually this is because regular devs are being asked by "BigCorp" to add "AES 256 crypto" to meet a client tick-box requirement. I would say if you understand how people are likely to seek to break/compromise what you are building, you can then start to design a solution. Expect to read 10x more articles than you expect, and before you start writing any code though.
And don't focus too much on getting an expert to review the code only - you ideally want to get some input reviewing the concept, architecture, understanding of the threat model, and the security properties you want to deliver. I've blown huge holes in crypto systems before, as people did things "nearly" right, but didn't understand the wider application, so were exposing/leaking the key elsewhere etc.
Just because I think it's funny - every time I visit my dad (who's in his 80s) he regales me with his startup ideas. "Why don't you build something that I can put on my glasses so when I lose them I can find them? Whoever invents that would be a billionaire." I say, "Yeah dad, they have that."
"Why don't they make it so I don't have to remember passwords for all these different websites? I could just have one password and it would remember it for everything."
I think I've explained at least a dozen times why I think third party trust is a bad idea; I've had to really refine it down to the level of explaining this to a six year old.
But the salient point here is that even my dad never signed up for LastPass. So who the fuck is signing up for LastPass?
Also techies have been telling non-techies "use a password manager!" for years, and people fail to evaluate one solution or the other.
My brother in law (a non technical person) was telling my wife last year how good LastPass was for him!
ehh. I store my passwords online but its on a file I encrypted offline with strong password (over 20+ characters) and key. I use keepass which is a locally encrypted and stored password manger, and I store the DB on Dropbox and download it to any of my computers/devices were it is decrypted locally when needed. I don't trust password wallet services ass they all seem to want to do the enryption server side with a reset-able password which really means they have the master password not you, but my set up seems secure enough to me.
If you have specific questions, feel free to ask.
None of the popular password managers work this way.
so does the family pack
Have a look at [0] - recovery works without 1Password having the master password.
[0] https://1passwordstatic.com/files/security/1password-white-p...
> Recovery Groups One of the most powerful capabilities that a team administrator has is the power to assign members to the team’s Recovery Group. In most configurations the assignment is automatic and Owners, Organizers, and Administrators will automatically be made members of the Recovery Group. In 1Password Families there is no ability to separate the roles of Owner, Administrator, and Recovery Group member; they are all wrapped up as “Organizer.” With 1Password Teams Administrators are given more control, but not all of the underlying flexibility may be exposed to the user.17 17We discovered during our beta testing that it was difficult to make the distinction between Owners, Administrators, vault Managers, and Recovery Group members clear enough for those distinctions to be sufficiently useful. This document describes recovery in terms of the Recovery Group even when the group is not exposed to the Team administrator in those terms.
> Implicit sharing When a vault is created, a copy of the vault key is encrypted with the public key of the Recovery Group. The members of the Recovery Group are able to decrypt the private key of the Recovery Group. Thus from an exclusively cryptographic point of view the members of the Recovery Group have access to all of the vaults. Recovery Group members never have the ability to learn anyone’s account password, Secret Key, Account Unlock Key (AUK), or SRP-𝑥. Recovery is recovery of the vault keys; it is not recovery of account passwords nor Secret Keys.
Security is the area where fast and fuzzy heuristics get you into problems.
Examine each option critically and reach independent conclusions.
I run BW with Yubikey 2FA and a local hosted sync server.
KeePassX/C perhaps. Vault for secrets management.
Never touched LastPass, 1Password or any of these other mickey-mouse commercial apps that invariably claim "military-grade encryption" or "unhackable" when their fundamental constructions are crap.
Google workspaces has a support assisted recovery option. I host dns separately from google as their admin level recovery may require some dns signaling.
Other steps include a yubikey etc . I’ve actually had the experience of losing all my Authenticator codes on an iPhone upgrade which at the time was how I did 2fa - so had to go through recovery for many providers. My top takeaway - if I was paying for service it was possible if sometimes a bit time consuming. If I wasn’t it was hit or miss.
Other tip? Google Authenticator may not backup to iCloud!! I had 20 codes in it including some really hard to fix ones.
There’s very little room for failure and learning in the online password safe field, so I generally assume these companies are in one of two states:
* has unknown bugs waiting to be revealed
* out of business
As far as I know it's fully E2E encrypted, and has never had a data breach.
The only thing I don't like is the lack of SMS based 2FA, although I appreciate their commitment to maximum security by not allowing it .
You can see their server and client code here: https://github.com/bitwarden
I choose to use their clients unmodified, along with an instance of the server formerly known as "bitwarden_rs" running in my basement as the sync backend. https://github.com/dani-garcia/vaultwarden
I still pay them annually for their "freemium" features even though I prefer not to let them host my data.
After learning about certificate transparency logs, I moved the app from a raw subdomain behind a secret URL path. Think “hello.domain.com/correcthorsebatterystaple”.
Is it security by obscurity? You bet. Does it work? Yes. I regularly evaluate the JSON logs emitted by Caddy in a pandas script and so far, no foreign party has even hit that endpoint.
It’s like an extra username of sorts you’d have to know. I’ve always been unsure of where to draw the line when it comes to obscurity. People online are viciously against it, but isn’t a password also just obscurity, if you squint your eyes real good? It’s all secrets users would need to know.
All that being said, I’m thinking of hosting it at-home-only as well. Would be a huge win in security and barely any loss in convenience.
I’d say defense-in-depth is more about nesting strong cryptographic primitives, than simply adding layers. What you’re trading off for is complexity and convenience vs security. In the URL case, a password is more secure (and treated as such) and lots of care is usually taken to make sure the hashing scheme is timing resistant etc. I don’t know if Caddy makes equivalent guarantees, but I’d be very surprised if path matching was not just a string match/regex/trie. In terms of time to crack, just prepending these characters to the password would give you more protection, because that then has to go through a resource intensive hashing process.
An example of defense-in-depth would be to host at home only. Here, it’s because you’re nesting actual isolation (which is a good security primitive by itself), with a strong password. This gives you protection even if your threat model is “caddy is borked and is letting anyone do anything”.
Now in reality, you can do just about anything and it’ll work (because in the grand scheme, you’re probably not a high value enough target for any high cost attacks). If you secretly happen to be, then you can afford an actual security audit, rather than relying on random info from HN :)
I like this insight, thank you.
One rebuttal I have: appending those characters to the password would make it a stronger password, but it wouldn’t add another, wholly different, mode to authentication. It would be the same thing, just harder (and I don’t need a longer password as it stands). What if this mode is flawed in itself? That’s when a wholly different one is desirable.
In that spirit, I had also thought about just slamming http basic auth in front of everything. Even if that basic auth uses weak credentials, it adds to security in a multiplicative/exponential way (multiple passwords/systems), over just a linear one (single but long password). I suppose that’s also what you mean by layering.
Adding a “password” path is actually only increasing your security by a constant factor per character because of the risk of timing attacks (unless you are sure that the path matching algorithm is secure against it now and in the future). Ideally a 2nd layer would guard against it in a multiplicative way (an entirely different with system).
Cryptographically, adding characters to the password rather than to the path is better (because it increases the search space exponentially) than adding characters to the path, which can be brute forced separately per character.
But this assumes a very perfect view of software, where there are no bugs. Once you add a risk model for bugs, then there might be small values of path length where the additional constant factor is better than the multiplicative one that you get from adding characters to your password. So your rebuttal holds, depending on the exact bug risk model you have.
I think nowadays, tailscale/wireguard is really convenient and pretty secure as a 2nd layer. I was averse to self hosting my password manager in the past due to not being comfortable having the consistent time to secure more critical applications, but I might actually move to a world where I host more critical things myself behind a VPN.
I’d recommend ensuring you have some sort of VPN solution so that you can access your vault away from home, too.
Personally, I just decided to use the 1st party server. I realized that reliable access to my vault is a service I really don’t want to be without due to technical issues in my setup.
If I were building it out today I might just use tailscale and be done with it.
I'm not sure about whether every device is a replica of the server. I believe that's the case (given how they behave when the server is offline) but that doesn't figure into my recovery plan.
But in the case of the mobile apps, downloaded from their respective platform's app store, how can you guarantee the code you see on github is the exact same code you're running on your device?
Admittedly this supply-chain-verification is an issue for all mobile app store apps but seems particularly important with something like a password manager.
For Google play store, there was also that developers needed to sign their apps before releasing to stores, so you knew that it came from developer, but Google removed that when they introduced app bundles. There is still a way to verify if the build is the same as developer provided, but automatic protections that were there are now gone [2]
[0] https://en.wikipedia.org/wiki/Reproducible_builds [1] https://mobileapp.bitwarden.com/fdroid/ [2] https://arstechnica.com/gadgets/2021/07/google-play-dumps-ap...
The page didn't mention anything about reproducible builds. (Doesn't mean they aren't using it though, but that would be internal.)
I haven't been willing to take it that far yet, though that appeals to me.
You still need to store somewhere informations like url, username, counter, etc. right ? Can you change the master password without changing all your accounts password ? If one happens to find your master password, he's basically able to get/generate all your passwords just like a normal pw manager with no 2FA, correct ?
end-to-end encryption means something like https, it's a communication quality between trusted parties
> Password managers [...] In this case, however, the user is on both endpoints and is the only person with a key.
But “wary of” and “weary of” both work. :-)
English is my third or fourth language, so I guess I’m less sensitive to mistakes like that.
Without context, I just don't understand why this anecdotal thread should be considered credible.
Disclaimer: I use FOSS password managers for everything possible but have to use LastPass for some non-personal stuff and I very much dislike it
This is your regular reminder that all crypto is scam , this is a simple mathematical fact.
Is a meme
Not everything posted on HN has to be verified true. The decision calculus here seems strongly in favor of signal boosting it, so that people who need to can take defensive action, even if it turns out to be wrong.
"I suspected someone used a 0day on me" is not exactly inspiring confidence
"Initially I imagined I was targeted by a 0day or rootkit"
which actually does not make sense, because it implies he thinks those two things are fungible. He's obviously not a security expert, but he's also obviously not totally technically incompetent.
Way to make yourself feel important. It's not that you made some terrible choices yourself, like using a known-insecure password manager SaaS, or putting real money into crypto. Nono, somebody pulled a 0day on me, what can ya do? Shrugs
Also the people talking about “burning zero days”… every time you use an exploit (ignoring the exact meaning of 0 days) it doesn’t become burned by the first person. The hacker could use it on hundreds of people before it’s discovered and patched by whatever software it targets. That could take months.
The big difference between the two examples is this: LastPass is known to have bugs. Huge amounts of data were stolen from them and we just found out that it was a lot more than we thought.
For all we know, they were storing passwords in the clear somewhere.
Trivia note: the first compiled language I used was PL/I, and the compiler was notoriously buggy and would crash on well-formed programs. Our teacher told us to put do-nothing statements in when this happened (`PUT SKIP(0);` if I recall correctly), and with some trial and error, those would fix it.
Yes. After their last major breach I exported all my data and deleted all my credentials and account with LastPass. Seeing the details of this breach, I'm super happy I did.
The thing that's bad, is that apparently their developers have access to (backups off) production data. That implies that their security infrastructure is not different from regular startups at all so all of their marketing is just bullshit. They didn't sacrifice developer productivity for security on this point, so they can't be trusted to have sacrificed anything for security at any point.
No it isn’t.
> What would you have the people who are using LastPass do, stop using it?
Yes.
> Because some crypto dude…
No?
https://www.cnet.com/tech/services-and-software/lastpass-say...
https://www.forbes.com/sites/daveywinder/2019/09/16/google-w...
https://www.cpomagazine.com/cyber-security/lastpass-2019-pas...
That together with others here claiming they have a LOT, makes me think they might have hot, cold, soft and hardware wallets.
That's subjective and has no value in determining whether the post is true.
"Not everything posted on HN has to be verified true. The decision calculus here seems strongly in favor of signal boosting it, so that people who need to can take defensive action, even if it turns out to be wrong."
What? Proven true, no, any sort of evidence, yes. As for taking actions, there's a cost.
From one of the tweets:
> I did not download anything. My machines are clean, and I have physical 2fa on everything. None of the links or contracts I interacted with were malicious. Nobody else had physical access to my PC.
Yeah sure. Sounds like my aunt when she messed up her PC and loudly claims "but I didn't do anything!" Surefire sign that she did. Turns out it's true, every time.
One entity has something to lose, the other doesn't?
1. You don't know if this person has nothing to lose
2. Even if they have nothing to lose that doesn't mean they are being honest.
I have no idea what this has to do with this discussion, and this just comes off as an ad hominem attack. Flat earthers claim that there's an economic interest in lying to them? And you think that claim is particularly genuine or even similar to this argument?
> You don't know if this person has nothing to lose
It is possible that they have some competing business and are trying to damage LastPass, but there's absolutely no evidence of that, nor any suggestion other than to double-check your credentials and your expected security if you are a LastPass customer. So, if they do have an interest, they're doing a particularly bad job of acting within it.
> Even if they have nothing to lose that doesn't mean they are being honest.
And we're not going to reach 100% certainty of any fact through discussion on a message board. It is interesting that some people spend a lot of effort trying to ensure this obscurity gets injected into the conversation, and it suggests that their own motivations should be questioned.
All in all, on the balance of apparent probabilities, there's more reason to trust this person than not. You can attempt to assail that logic if you like, but I would appreciate it if you stuck to the facts of the argument instead of kicking up dirt.
So feel free to go ahead and jump to conclusions :)
See what is unencrypted in your LastPass vault - https://news.ycombinator.com/item?id=34105368 - Dec 2022 (9 comments)
LastPass breach is worse than you think because URLs were unencrypted - https://news.ycombinator.com/item?id=34102982 - Dec 2022 (81 comments)
LastPass users: Your info and vault data is now in hackers’ hands - https://news.ycombinator.com/item?id=34100087 - Dec 2022 (19 comments)
LastPass says hackers stole customers' password vaults - https://news.ycombinator.com/item?id=34099647 - Dec 2022 (15 comments)
LastPass user vaults stolen in recent hack - https://news.ycombinator.com/item?id=34097142 - Dec 2022 (276 comments)
Lastpass Security Incident - https://news.ycombinator.com/item?id=33806803 - Nov 2022 (560 comments)
LastPass confirms hackers had access to internal systems for several days - https://news.ycombinator.com/item?id=32912350 - Sept 2022 (21 comments)
LastPass says hackers had internal access for four days - https://news.ycombinator.com/item?id=32871051 - Sept 2022 (7 comments)
Last Pass Hacked - https://news.ycombinator.com/item?id=32612645 - Aug 2022 (35 comments)
LastPass: Notice of Security Incident - https://news.ycombinator.com/item?id=32598587 - Aug 2022 (130 comments)
It could be a complex math problem, or another common trick is to purposely trigger bugs like a javascript engine not rounding numbers correctly in edge cases.
I absolutely believe it’s possible that LastPass has been compromised more than they’ve let on and I won’t be surprised if we eventually find out vaults are vulnerable, but I don’t believe this is how it would play out.
Sunday the 18th is conveniently around the time of the latest announcement, but not the time of the actual hack. Feels like someone is over fitting.
I find it implausible that the first hint of vault compromise comes 4 months after the hack and is against a low value cryptocurrency wallet. Especially considering that when LastPass first had issues, there were dozens of people reporting personal experiences of it here on HN — if LastPass vaults are compromised, the internet would be flooded with reports.
Good points.
The time might have been spent analyzing the source code for vulnerabilities in the way the vaults were being protected.
If someone had put the key in the URL field (because there is no corresponding URL because it's not a credential), and the URL field was unencrypted, that could account for it.
Maybe a coincidence, but I guess every weird thing that happens is going to raise alarm bells.
I was suspicious of the LastPass concept (storing passwords in a cloud app) when a former employer introduced it some years ago, but they had a strong IT and security culture so I trusted them to make the right choices and adopted it for my personal use.
A few months ago I hsd an issue with my LastPass 2FA device and a policy set by my former employer blocked me from resetting it for my personal account. It was resolved by LastPass, but that was the first strike, and I had spent most of the night extracting my personal account passwords manually from the mobile app, which remained logged in. That was strike 1. This is strike 2.
I am very much of the opinion that if I fuck up my side of 2FA protection, the resources/accounts they’re protecting should be lost forever. (Or at the very least, a co-account holder might be able to reset some things, like my AWS IAM creds or GSuite admin account). If I can ring up and whine at enough support people to get them to hand over my account, so can a sufficiently persistent skilled social engineer…
It was a support request, and IIRC they disabled it remotely.
My cell provider requires a photo ID in person or a long pin not stored in the same place as other passwords in order to assign my number to a new phone and 2FA to access account.
This raises the bar from knowing my password to knowing my password, knowing my ID, producing a fake facsimile of my ID, stealing my pin from its encrypted container on my desktop, taking over my phone number, then taking over my account.
I don't have a pile of crypto to steal ergo this would be a LOT of work to send spam as me until my email gets flagged. It would be like a heist movie only with the target being the $40 in my wallet. mission impossible themesong begins playing
Basically support just needs to exercise reasonable caution when removing or changing it.
In my case I was off boarded by an employer, but retained access to it on my mobile device and could read all passwords.
Their initial response was that it was by design, then later tried to pay a bounty I never accepted.
BTW one client of mine runs a heavy security operation and they use KeePass.
Just like they say in crypto "not your keys, not your crypto" - it applies here too. Not your storage, not your passwords.
KeePass on an airgapped box, or an encrypted hardware password manager with no network interfaces is best, though frankly, I'd even be more comfortable writing down passwords on paper (at home) than I would be storing them on someone else's server.
I say all this as a big tech red teamer, or, someone who breaches other people's servers for a living.
And yes - there is basically no way to actually prove that your passwords on a server aren’t accessible to someone - especially if they can update software.
100% agreed. Physical access is not something than an attacker, especially one likely to be in an entirely different country or even continent, can easily achieve.
Sounds inconvenient for password retrieval when not home, how does this work in practice?
How about an airgapped phone with GrapheneOS and Keepass?
Is it inconvenient at times? Yes. But I spend so much time at my desk, that those times aren't super common.
On mobile, my personal daily driver is running GrapheneOS, but I do not keep my passwords on it.
I am unaffiliated with them, and this isn't an endorsement, but I just recently ordered a Mooltipass, which I intend to thoroughly audit. If it's security proves satisfactory to me, I may use one going forward in a limited capacity.
I've looked at the white paper https://1passwordstatic.com/files/security/1password-white-p..., I think 1password has a decent security posture for their cloud offering but then there's always the risk of a breach where the attacker controls the site and can intercept your master password through it. Same as what happened with British Airways or Lavabit.
A local vault is better than a cloud vault, but if that local vault software is written by a commercial company there's still that risk.
Depending on your device and platform there's still "that risk" even if its open source. If you're compromised, you're compromised.
My understanding is the app decrypts the vault locally. I guess they could put out a malicious update but then you’d be impacted whether there was a cloud-free option or not.
Additionally exfiltrating the data would be harder for a locally stored vault..
EDIT: Given the replies below, I should be clear that I'm not interested in comparing to LastPass, I'm comparing to Bitwarden. LastPass had an obviously bad security model that failed to encrypt everything, but Bitwarden does not have that flaw.
The part where they said they do not store either the key or password on Dropbox.
But what you said is also an additional benefit.
That said, the same risk applies to any client you use. Someone could have compromised the latest update of KeePassX as readily as they can compromise LastPass's client. If you don't have automatic updates then that's helpful, but I'm not sure it's producing enough security to be worth the extra hassle.
They don't have to get bad code into an MR (though that's one option), they could compromise the website and have it distribute a different binary. If you build it from source you're safe against that, but are you really building it from source?
Also, remember that the same logic applies to Bitwarden: they need the master password and therefore must compromise the client during the window where you update it.
Dropbox is not added security in this setup, it is a natural factor if what is being transferred [the keepass file(s)] is sufficiently secure in itself.
Another reply indicates that the main thing is that you don't have to trust the cloud service to do the encryption and zero-knowledge stuff right.
That plus security through obscurity: no one is presuming you're going to come out of a Dropbox hack with millions of password vaults. Even finding them would be... nightmarish. (Though I suppose you could somehow hack a Dropbox file index database?) The value of a target like LastPass is absolutely insanely high: it's a concentrated honeypot of encrypted vaults.
Plus, the Android app makes using a Dropbox synced folder location fairly trivial, so that works pretty well. And you can set your own number of password rotations, which, while annoying when it takes my phone 5-10 seconds to unlock, realllllllly helps ensure no one else is going to crack this vault if they ever got it.
LastPass is a disaster, but in theory these benefits are true of Bitwarden as well. They say they encrypt the entire vault, no exceptions, and do the encryption entirely on device.
I can see the honeypot argument, but Dropbox is also a big honeypot for different reasons (tons and tons of plain text information that could be very valuable in the right hands). And I don't think finding the vaults would be as hard as you think it would, because searching for encrypted files should be relatively easy, and any encrypted file is probably worth attempting to crack.
I'm not trying to argue for cloud password managers, I'm totally open to being persuaded and would immediately switch if I were, but I'm really failing to see where the added security is versus Bitwarden. Bitwarden is open source just like KeePassX, so if it did not implement the security model that claims to I think someone would have blown a whistle by now.
Assuming that I trust Bitwarden not to lie about their security model, what do I gain by piecing together multiple tools to accomplish the same thing?
In case of keepass and independent sync(doesn't have to be Dropbox), software that sees master password doesn't need access to the internet. Can be even airgapped if you are extra paranoid.
So to sum it up: keepass + sync is better, because there's no single party that is even able to screw up you to the point of leaking your passwords. "Impossible to fail" is better than "they are doing their best, pinkie promise".
Also - why pay recurring fee for yet another cloud storage, when I just need plain encryption software.
All of this applies to KeePass, minus the browser extension bit (which is trivial to avoid by not using the browser extension). The only difference is that you can theoretically firewall KeePass from the network, which I'll grant you would make a difference, but the fact that you reserve that for the extra paranoid suggests most don't do that.
> because there's no single party that is even able to screw up you to the point of leaking your passwords
Again, only true if you block network access. If not, you have as many points of failure as with Bitwarden, because only the client needs to be compromised to get both vault and password.
> Also - why pay recurring fee for yet another cloud storage, when I just need plain encryption software.
Bitwarden free is plenty for me right now, so this doesn't play into my calculus.
Personally, I'm not interested in making the switch if I'll have to fiddle with firewalls on all my devices in order for it to be more secure for my current solution. It's not that this conversation is made me think less of KeyPass, it's that I'm yet to see a convincing argument that Bitwarden is worse than what I would end up with in practice by switching.
That being said - bitwarden is pretty transparent in what they do, compared to the competition and I'm seriously considering giving it a try (but with self hosted backend).
I looked at using them but ultimately decided against them, a conflict overwriting a password scares me more than even just using chrome sync and calling it a day.
It does seem to be solvable though. I could see myself using SyncThing+ KeePass if I ever became unsatisfied with BitWarden and I found an app without too many sync issues.
It’s got my (not particularly technical) wife using unique strong passwords for all her online accounts and made family password sharing easy. I think the convenience of the cloud is key to this.
I get that there’s a security risk that 1Password gets compromised and the app is infected with malware or there ends up being a vulnerability on their encryption scheme but it still feels like a net improvement to my overall online security.
Also MFA can help mitigate the risks of the passwords being compromised.
This is what I’m at on it too. Without cloud syncing convenience wins and we end up using simple passwords over and over again.
With cloud syncing I believe we are much more secure than we would otherwise be.
Especially across multiple users.
This is reasonably safe, as long as you're careful with your master password, no different form GPG.
I'm not here to argue the merits of encryption. I understand it very well. I'm only considering my own levels of comfort and need to trust a 3rd party as well as pay a recurring fee to store my keys/passwords.
Where I do think it resonates is fundamentally it's just a bad idea to centralize things like this. It may be a necessary to construct a commercial business around this, but centralising massive amounts of trust across unrelated entities into ANY party is just a fundamental compromise that shouldn't have to be made. We would all be better off with genuine decentralised infrastructure to make all this work.
What does irritate me is that all these companies are full of "zero trust" marketing spiel but their products always actually end up coming back to placing 100% trust in them in the end.
Here's the thing: yes, my tool is probably less secure than a professional tool, by an order of magnitude. But it's also a far less attractive target for hackers. If you spend an hour to crack my tool, you get one guy's data. If you spend 1000 hours to crack LastPass, you get millions of users' data. The cost::payoff ratio for hacking LastPass is far better.
They also say not to roll your own encryption, but if you encrypt your data and then use ssl it does increase security. When there is some bug meaning your ssh key was easily guessable (happened with dsa keys) having that obfuscation will prevent bulk collection from doing things like keyword matching against your data. Doesn't work if everyone does it, but it does work.
Most of the time you gain the most not from state-level impossible to break security, because most of the time you aren't trying to defeat a room full of geniuses all working full time with you as a target.
Remember this?
<Cthon98> hey, if you type in your pw, it will show as stars
<Cthon98> ********* see!
<AzureDiamond> hunter2
<AzureDiamond> doesnt look like stars to me
<Cthon98> <AzureDiamond> *******
<Cthon98> thats what I see
<AzureDiamond> oh, really?
<Cthon98> Absolutely
<AzureDiamond> you can go hunter2 my hunter2-ing hunter2
<AzureDiamond> haha, does that look funny to you?
<Cthon98> lol, yes. See, when YOU type hunter2, it shows to us as *******
<AzureDiamond> thats neat, I didnt know IRC did that
<Cthon98> yep, no matter how many times you type hunter2, it will show to us as *******
<AzureDiamond> awesome!
<AzureDiamond> wait, how do you know my pw?
<Cthon98> er, I just copy pasted YOUR ******'s and it appears to YOU as hunter2 cause its your pw
<AzureDiamond> oh, ok.My concern with anyone identifying themselves as being affected by this breach is that a 3rd party would be able to collect a lot of information about the user for a very targeted social engineering attack. Conversations here often disclose personal information such as approximate age, location, past experiences, hobbies, etc. It's a gold mine for social engineering.
> To date, we have determined that ... the threat actor copied information from backup that contained basic customer account information and related metadata including company names, end-user names, billing addresses, email addresses, telephone numbers, and the IP addresses from which customers were accessing the LastPass service. The threat actor was also able to copy a backup of customer vault data ... both unencrypted data, such as website URLs ...
Given how incompetent they've been, it would be safe to assume that the vault data is linked to customer account information. And because website URLs are included in the package, there is already tons of information for spear phishing, and any LastPass user here is probably already doxxed to the bad actor.
In general, you're right, but I really think that in this case the ship has sailed. The attacker has more information than they could possibly sort through by hand, they're not going to resort to reading forum posts.
https://apps.apple.com/us/app/pass-password-store/id12058205...
In particular, I don't see how 2FA is possible with this, so shoulder surfing is a bigger issue.
I definitely trust Google or BitWarden more than a password I can memorize plus my own constant vigilance.
You can use anything that integrates with GPG ... eg: you can do it with a Yubikey [0]
[0] https://support.yubico.com/hc/en-us/articles/360013790259-Us...
Still, it doesn't allow SMS or email based 2FA as far as I can tell, since that involves a trusted server and doesn't mean anything in a trustless model where the server owner could just add a bypass.
Umm, why not?
First, you can use a different app (like aegis) to generate OTPs.
Second, pass has an extension (https://github.com/tadfisher/pass-otp) that can be used to generate OTPs.
Third, you can use something like oathtool to generate your otp using your totp secret
oathtool -b --totp "your-totp-secret"
With keepassxc, 1password, or even chrome's password manager, if a phisher links you to "gmail.scammersite.info", even if it looks exactly like the real gmail login page, browser-integration will not fill in the password field.
With pass, the default flow is to copy the password to your clipboard, and paste it into the password field manually. That allows the above phishing attack to succeed.
For that reason, I would not rely on password store. If you want to control your own database, use keepassxc, and sync the kdbx file with either git, dropbox, or anything else you like.
I am aware password-store technically has browser extensions, but few people use them in practice, and since password-store doesn't have an idiomatic "URI" field for a password, it doesn't actually auto-fill by default in a way that stops the above attack.
As a bonus reason, password-store also leaks filenames (entry names), while keepassxc and most other options do not leak the entry name.
As another bonus reason, using gpg is a fraught pain in the ass, and it's such a sharp and difficult to use tool that it's actually harder to securely make disaster recovery plans.
Passwords are per file. Grabbing a password by a Yubikey touch doesn’t expose other passwords. Per password sandboxing. With keepass, you open the vault most of the time to expose a less important password, and the entire vault is at risk.
Beyond Pass, you should be careful with the browser extensions (and browser in general ). There are a lot of them, never audited.
The entire vault is at risk only if the attacker has a zero-day in the browser extension, or already has local code execution.
In your threat model, which is more likely:
1. you get sent a phishing link and click on it, and then copy+paste into a password field
2. An attacker compromises your browser extension with a zero-day
3. An attacker manages to get local privileges on your computer, is competent enough to exfiltrate your keepassxc database from memory after you unlock it with your hardware token, but is not competent enough to exfiltrate your 'password-store' passwords, or browser session cookies, or whatever
https://twitter.com/SwiftOnSecurity/status/16060717986671738...
LastPass has a LOT to answer for.
If you look into what LogMeIn (now renamed to “GoTo”) makes… this doesn’t make me feel good about GoToMeetings, GoToMyPC, or join.me.
(Though I suppose changing a bunch of passwords that I had in LastPass is also kind of a pain.)
I mean, I could maybe update the OS on that machine (not sure--it's over 10 years old) but at that point it was less work and less risk to switch to BitWarden. And the user experience is much better as well.
For many years, those of us in the cryptocurrency fields have said never enter your keys on a computer. Generate them offline on a hardware device and let that be it. The person making this claim clearly had to enter unencrypted keys into a computer to put them into his laspass vault. There are a number of malware variants that specifically target keys and search things like input fields in web forms and clipboards for those keys.
And if that were the case then this is really getting into criminal negligence territory (especially the way they've been disclosing it).
I had made a mental note some months back when this first happened I should really go through everything important in my vault and update all passwords to sleep more peacefully at night. I had also made a mental note at the time that if this situation were going erupt into something much worse, it would almost certainly be over the Christmas period when many people are not at work or their computers and it would be the perfect moment for causing maximum chaos and destruction. Looks like I now really need to prioritise that tomorrow. Really not what I wanted to be doing on Christmas Eve...
I can see it both ways. It is putting all your eggs in one basket. The flip side is your vault is supposed to be protected enough that shouldn't be an issue.
At this point I just don't want my data in the big, juicy hacking target.
> I think the situation at @LastPass may be better than they are letting on. > > On Sunday the 18th, four of my wallets were completely safe. There were no losses. > > Their seeds were kept, encrypted, in my lastpass vault, behind a 16 character password using all character types.
IOW, the honesty and integrity of the user does not matter. What matters is some form of verification of the cause of a breach, because this single post presents no useful evidence for determining the cause of the breach, most especially ruling out over-the-shoulder attacks.
What has confounded me for a long time is this question: are there no breaches of security cameras? I can spend time in a Starbucks and always see someone enter a password into some device, I do not recall reading that a security camera system has been hacked, yet I would assign an incredibly high value to security cameras in places like coffee shops, airports, hotel lobbies, etc.
There are fewer ways to get the data than reasons why the data has not (yet) been used.
You can't prove there was no breach.
As I demonstrated in what might be called talking past the sale, there are other attacks that have nothing to do with the security of the technologies used.
I don't know the person who originally stated this, but as the popular refrain goes: "security is a process, not a technology."
As for Bitwarden, I like the UI (iPad, Mac, iPhone) but routinely forget how to generate a new password - the function is buried inside one of the menu options. Other than that, I really like it. And, there is option to host your own vault.
&^Q@w7rC#F!%V%swarZ4@pss#
4nKR7ReAG^ghezg%yD6CF79b!
aH8MPi5NoKv4Hzdfec7Q*c4XT
hwD!LktbF5&Wxy^wh^Uq7%&%^
CYQ9%5^vXAiz&4fPp%fWfa%rq
I find that Bitwarden's UI is much less quirky, for lack of a better term. LastPass finds ways to consistently annoy me.
The commonly clicked secrets move to the top, I can see more than two items in the list, it doesn't forget me periodically, and when prompted for credentials I can't cancel it and get in anyway.
You can add multiple sites to the secret, not in some hidden menu in Bitwarden. That's handy for things like AD/LDAP credentials.
I eventually decided that the UI was too clunky to move my whole family onto and opted for 1password. Very happy with that choice.
In general, one should avoid exporting/importing credentials. Instead reset them and save the new creds into the new place.
UI\UX is bad. I tried switching to it from 1P, but went back after four months because I'd rather pay more than suffer daily.
The more numerous the places where we can abandon passwords, the fewer the secrets that we need to keep.
Ultimately, I expect the biggest barrier to be mental. People have had mantra about passwords banged into their heads for decades that they have become synonymous with a secure system and people are suspicious when their device just lets them in with little to no friction.
I just set up a whole backup solution for my many self hosted applications, all encrypted with the keys safely in my password manager. Even uploaded to S3, because I figured if I'm paying for it, I could ID-and-support ticket my way to my data even if I lost my AWS credentials.
I don't know how to integrate a security key into this scheme. What to do if it actually gets lost ?
Will I have to use emergency codes for all the accounts ?
Can I make a backup of it somewhere ?
Would that defeat the purpose ?
I'll buy one someday, when I'll have all this figured out.
It is a little bit of a hassle. But changing 200 passwords because LastPass was breached is also a hassle.
The database is kept in sync with either Dropbox or iCloud.
As far as I can tell BitWarden and Google are the two good ones. I use BitWarden.
My reasoning is anything new and experimental is scary, I want something with tons of users that's well established. If the community isn't all over it, it's probably not reviewed enough.
Open source makes stuff a little more trustworthy, but by itself isn't enough.
I also don't want to pay a lot for it, and many are paid.
The two big FOSS ones everyone knows are KeePass and BitWarden.
Keepass uses some single file database last I checked. Terrible for sync as the sync engine won't be able to automatically merge conflicts and you might get hassles.
That just leaves BitWarden, or just using Chrome because it's there, it's easy, and Google seems to be good at protecting you from everyone but them.
A 16 characters password from all character types can’t be broken.
How could hackers break the vault, with end to end encryption and such password?
I suppose the point was more that faced with many users' LastPass vaults there are more likely and less likely keys -- but they'll still have to try the keys.
In my experience "I didn't click on any suspicious link" and similar user denials are exactly why you don't ask them that during incident response, instead you get them to give you all their browsing/download history/content so you can verify that.
It could be cookie theft (physical 2fa can't stop that) or consent phishing if they use oauth for their main lastpass login. As soon as this was noticed, disk/memory images should be taken of all devices with lastpass ideally so they can be investigated. I don't know if the victim here uses laspass on their phone for example or by new apps they include new browser extensions or updates to existing apps (supply chain compromise).
Many users don't use "good" passwords, so you use a high number of iterations on the KDF, to make it harder to brute-force an account's password.
Lastpass initially used 5000 rounds of KDF for old accounts. That's not a lot, especially today. They increased it over time to 100,100 iterations (which is better).
The data stored in a password vault is encrypted by a per-entry key, derived from this user password. If a user's password is weak, predictable, re-used, etc, then attackers now have an opportunity to decrypt the contents of their vault. Up until now, attackers generally have been assumed to not have access to user vaults, as that requires authentication (maybe including MFA).
No local software has been compromised, but getting a hold of the server-side backups makes it possible to try to brute force user's passwords in a way that was prevented by server-side rate limiting and MFA.
There is also some side information leakage from the server-side copies of users' vaults, like the URLs of websites in a given vault not being encrypted, and vaults being tied to user identities and contact info.
This tweet thread suggests/implies that at least one user has had a password compromised from information held in an encrypted vault. There's no evidence yet of a compromise of the locally installed software, but it emphasises the importance of changing passwords, moving to new wallets if seeds were exposed to Lastpass etc.
Edit:
https://web.archive.org/web/20120320015133/https://helpdesk.... confirms that the default was indeed 500.
According to https://www.infosecblog.org/2012/06/lastpass-and-pbkdf2/, there are even some old accounts with a single round of sha256 (!)
Wonder if Lastpass encrypted everything with the password-derived key directly, necessitating a full re-keying.
It's not nearly as convenient as LastPass, but likely more secure. It uses TwoFish with a 256 bit key length, which was one of the finalists for the AES standard.
With _random_ passwords which most LastPass users probably generated, the attacker has no way of knowing if a key resulted in a successful decryption unless they login to a particular site.
If the URLs were part of the encrypted payload though, a quick string check for “http” or “www” would tell them if a key was correct or not during their brute-force attempts. Maybe a silver lining?
"The cloud" is just someone else's computer.
Sharing your password with anyone always makes you less secure.
"You should do something stupid because most people do things that are even more stupid" is not a good argument in my opinion. I've been in the computer/tech space for 30+ years without every sharing a password or doing something stupid with my passwords, and it hasn't ever been any sort of burden. Why is it so controversial among the HN crowd to simply be minimally intelligent and careful with your sensitive information?
It’s human nature to take shortcuts and develop bad habits when you’re dealing with a flawed system and poor tools that puts the burden on the end user to manage everything. And if I’m struggling with four decades of experience, how is the average non tech user expected to do it properly?
I have a couple of dozen unique passwords. The ones I use most frequently are easily remember with pass phrases and all are written down on a couple of sheets of paper.
>and other devices is a major pain and I’m tired of dealing with it.
You are free to sacrifice security for convenience, but don't cry about it when your security is compromised because you consider maintaining your security too much of a hassle.
>It’s human nature to take shortcuts and develop bad habits when you’re dealing with a flawed system and poor tools that puts the burden on the end user to manage this.
I would argue that outsourcing your "security" to a third party is a shortcut and a bad habit that compromises your security. If you can't be bothered to worry about your own security because you find it too much of a hassle, then you have nobody to blame but yourself when your security is compromised.
>And if I’m struggling with four decades of experience, how is the average non tech user expected to do it?
Most non-tech users don't have hundreds of accounts to manage. I would hope and expect that even non-tech users have the ability to use a paper and pencil, and write down their passwords. At what point are responsible, sentient adults expected to take responsibility for themselves and their own security?
>May I ask how you accomplish this without any sort of burden?
Being an adult who is responsible for yourself is a necessary burden. This is also true for your own security.
Self hosted, at home, or I don't trust it. It's really that simple.
Please reaffirm my choice to pick you as our company password manager years ago before I research the ambiguity of centralized password management and make my own decision.
Too many people who should know better on this site itself kept recommending things like Lastpass... Incredible.
1. password was somehow left in plain text
2. there was a problem with the encryption implementation by LastPass. likely this is the reason.
this is why you always encrypt crypto stuff with offline computer using well-vetted tools like VeraCrypt or openssl, and not rely on cloud storage encryption. Only you can do your encryption. relying on others doomed to fail eventually.
facebook.com$293MyPasswordYouKnowIt!!123
password to gmail would be
mail.google.com$113MyPasswordYouKnowIt!!123
only annoying thing is that the passwords are long. I guess it's secure, though.
edit: see child post for clarification. I do something above for spammy sites, but for something like gmail I probably wouldn't do that.
that being said there are a lot of things you could use. you could use information in the whois, you could use the birthdate of the founder of the site, etc.
personally I believe people should use the same password for all sites and then something similar to what I described. though I use a password manager, I do always feel nervous about the implementation leaking out details
Eventually, some website you use is going to get hacked. They’ll have stored passwords as plaintext. From there, anyone who wants to hack any of your accounts knows your password format. It’s going to be obvious to them that they just need to replace the domain.
of course, you'll say, don't use a crappy password manager. and that's correct. same reason I use a separate format for sketchy sites.
for what it's worth my format isn't really as described, but it is similarly deterministic, but not visually so. the cipher is basic enough to do in your head but complicated enough that you wouldn't know from a glance
a real password example for your scrunity:
m0m2a2yiplagsosowgolredd1o2t3c!o!m2
steps:
m a i l g o o g l e d o t c o m
strategy
zip
secret
mypassword123!!
offset (publicly determinable)
0
unique: 2022
m0m2a2yiplagsosowgolredd1o2t3c!o!m2
i use a password manager so the long text generally is irrelevant. the main reason I do this is because I don't feel comfortable needing my password manager. I like being able to figure out my actual password completely independent of a phone or internet or app.
the strategy depends on how sensitive the app is (strategies include: zip, append, vowel-zip, no-vowel-zip, num-zip, all the same but with a reverse-offset). unique is usually something like when I joined, or something determinable from the site and my head.
all of this seems much more complicated than it is. once you understand you could calculate the password in your head in a couple seconds.
edit: oh, I did say append so I see why you'd think that. that's my bad. what I meant was include
Also plenty of perfectly respectable sites have been compromised in the past so your estimation about how safe the site is unfortunately doesn't help much.
I really think you'd be better off using long randomly-generated strings and keeping multiple backups of your password database. There are lots of options that don't put you in the hands of a third party. All (?) sites offer password reset facilities in case of emergency, and you could memorise your email account password so that you can always at least get into that.
Press [X] to doubt.