When I read their most recent email updating about the situation today or yesterday, I did get a definite chill down my spine. I've not used LP for a year or so, but my data (much of it now old) is still stored there, mainly left as a backup as I'd heard some people had some weird issues migrating to other password managers.
I had made a mental note some months back when this first happened I should really go through everything important in my vault and update all passwords to sleep more peacefully at night. I had also made a mental note at the time that if this situation were going erupt into something much worse, it would almost certainly be over the Christmas period when many people are not at work or their computers and it would be the perfect moment for causing maximum chaos and destruction. Looks like I now really need to prioritise that tomorrow. Really not what I wanted to be doing on Christmas Eve...
I'm not too worried because anything important that I have in LP is protected by 2fa. It's notable that the author says his accounts are protected by 2fa, but I don't understand how LP being hacked would allow an attacker to defeat that.
he said his seed phrases were in lastpass. There is no 2fa protection for private keys if the assets are in his crypto wallet and he's custodying them.
I can see it both ways. It is putting all your eggs in one basket. The flip side is your vault is supposed to be protected enough that shouldn't be an issue.
Another comment rightfully points out that the vault itself is only protected by a password. I don't think that's protected enough if it's on cloud storage.
He said there wasn't much value in the wallets. Doesn't strike me as crazy to keep a small amount in something convenient. You see a similar convenience/security trade off made by big players, with immediate transactional needs satisfied by online/hot wallets and reserves held in offline/cold wallets.
Just for your consideration, I'd bet good money that the 2FA only protects against login credential stuffing, but the vault data is only protected by your master password and can be attacked offline and indefinitely
I mean the individual accounts are protected by 2fa. I have an account or two where I know the password has been leaked but they're so unimportant that I can't be bothered to change the passwords. They still can't get in without my approval.
LastPass allows you to delete your account without entering your master password. If their infa is compromised, you don't want to enter your master password to lastpast again it case the hacker planted something in lastpass' client code to snoop entered master password.
For anybody else left wondering, Bitwarden does encrypt (nearly) everything in your vault:
> At Bitwarden we take this trusted relationship with our users seriously. We also built our solution to be safe and secure with end-to-end encryption for all Vault data, including website URLs, so that your sensitive data is “zero trust” secure [1]
I haven't used LastPass in years, but the recent news made me wonder how Bitwarden was handling URLs.
Items contain overviews and details which are encrypted separately
by the vault key. We encrypt these separate so that we can quickly decrypt the information needed to list, sort, and find items without having
to first decrypt everything in the vault.
Item overviews include the item fields needed to list items and to quickly match items to websites, such as Title, URLs, password strength indicator, and tags.
Additionally, 1Password makes the extra effort to never even send the URLs of your accounts to their servers. Even with their Watchtower service, which notifies you of breached accounts and websites that support 2-factor authentication, your passwords and website URLs are never sent to 1Password servers.
I had been a very happy customer for years before they started moving to that policy. It's what finally made me set up a vaultwarden instance and migrate all my stuff over.
I didn't like the move to a subscription model, but I'd have sucked that up if I could've continued to bring my own sync.
For those of us that have been using it for long enough, we can still use the "classic" version stuck at v7, but it means being able to self host. no monthly SaaS fees.
From what I can tell, v7 is Intel-only. That means when Apple sunsets Rosetta 2, it’s not going to work anymore. I’ll need to switch to something else before then, but hate Electron, and all the other options seem to use it (and now 1Password does, too).
That's a good catch. I'm still on a MacTel MBP, so this is not something I had ever considered. That's going to be just one more reason I'll keep the current laptop powered up on a shelf in the closet if/when I upgrade to a newer computer.
I feel like there should be a law of the internet for this. The more a company asserts that their data is secure and encrypted and you should trust them, the more likely it is to leak and be proven to be massively vulnerable.
It’s fine to store your passwords online for convenience, but as a user, it’s important to accept that it’s no longer your private password and will, at some point, leak.
They’re not worthy of having any law named for them, even a negative one. Really wish there was a Software Hall of Shame where they can go rest in infamy.
It all depends on how the data are encrypted. With a sensible design capturing the encrypted storage will only reveal the number of encrypted records, rough estimates on their size, and time stamps.
Ideally it would be an opaque blob with no information about the number of records or their size, just the total size and maybe a last modified or accessed time.
Password managers typically offer to store images like document scans. Without per record encryption one needs to send the whole encrypted blob on each modification.
Not necessarily. You can have a write-ahead log which also consists of opaque blobs and which other devices can pull and reconcile on their own. At some point, a whole reconciled version is uploaded.
> The more a company asserts that their data is secure and encrypted and you should trust them, the more likely it is to leak and be proven to be massively vulnerable.
That's a consequence of the Murphy's law [1].
Very well written. You phrased it perfectly for it to have its place at [2] which is full of this kind of stuff. It's almost like this sentence claims itself the right to appear there. If you read French you might enjoy this website. If not, you might still enjoy the different phrasings of Murphy's law in different languages here [3].
I definitely feel the opposing law works. When I see a project with a massive disclaimer about "this crypto is not audited, I'm a noob never deploy this anywhere" I'm likely to see better crypto than most of the commercial products I work with, including ones with sales people that talk about unbreakable crypto.
That's a silly term for that. Commercial businesses have the same access to NIST that the military does. Their guidance is even free!
Military grade when we're talking about a screw is a little different. It means that the screw is made and QC'd to a very specific spec/standard.
My next question might be, "Where can I find you on the FedRamp approved list?". To which, I'm sure they'd respond that anything outside the algorithm is not military grade, which is what most attackers will exploit in the end.
> When I see a project with a massive disclaimer about "this crypto is not audited, I'm a noob never deploy this anywhere" I'm likely to see better crypto than most of the commercial products I work with, including ones with sales people that talk about unbreakable crypto.
I'm working on an opensource project for Linux users that needs crypto. Needless to say, I'm not an expert in that domain. I was planning to ask experts for help in reviewing the crypto. Your statement makes me slightly nervous. What is the standard procedure to ensure crypto safety in a software project?
Use available and widely used libraries for the low level crypto parts (e.g. don't code RSA or key generation on your own). Apart from that, get audits if you have the means but I guess using libraries like openssl should be enough for most open source projects.
Understand (before you start writing code) the basic security properties that you want to deliver through use of cryptography. This is usually where most implementers fall over (including the big commercial products).
To give a couple of specific (but non-exhaustive) examples, generally framed in terms of password managers:
- A password manager should protect the identity of the sites the user has saved, the content of the username and password field, and any associated notes. (That's fairly straightforward, most people are likely to agree on this). But what about integrity? Should you use an authenticated cipher mode like GCM? What will you do if the authentication tag fails verification?
- The password should be encrypted such that if a password is re-used across websites, it is not discernable from the ciphertext that this is the case. (Fewer people will think about this, but some will... Using AES in ECB mode isn't enough to prevent this! Lastpass appear to have done this in the early days).
- The key used to encrypt each ciphertext should probably be unique, to reduce any potential impacts of weaknesses in ciphers or cipher modes. Each cipher should use a unique per-instance instantiation as well (i.e. IV, GCM tag, etc.) How do you store and derive these passwords though? That will take you into key derivation functions, and password-based ones, like scrypt/bcrypt/argon2. These can derive a crypto key from a user password. You can then use that key as input to a KDF (with a per-entry salt) to derive the actual AES key used for each entry.
- If you're designing a wire protocol, what properties do you seek? Replay resistance? How do you prevent session resumption type attacks? (don't design a new wire protocol, use something robust like modern TLS!)
98+% of the time, at least in my experience, people who mess up crypto don't understand what goal they are seeking to achieve by using the cryptography, and haven't threat modelled it. Usually this is because regular devs are being asked by "BigCorp" to add "AES 256 crypto" to meet a client tick-box requirement. I would say if you understand how people are likely to seek to break/compromise what you are building, you can then start to design a solution. Expect to read 10x more articles than you expect, and before you start writing any code though.
And don't focus too much on getting an expert to review the code only - you ideally want to get some input reviewing the concept, architecture, understanding of the threat model, and the security properties you want to deliver. I've blown huge holes in crypto systems before, as people did things "nearly" right, but didn't understand the wider application, so were exposing/leaking the key elsewhere etc.
How hard is it to store encrypted data that needs a locally held master key to decrypt? Pick any industry... You'd have to be willfully ignorant or outright corrupt to fail your core business promise, wouldn't you?
The average user that LastPass caters to thinks that a "backup" is the reason they were late for work in the morning. LastPass doesn't want to be in a position where they're telling their users, "Sorry you're SOL," if their device breaks and they don't have a second copy of their locally-stored encryption key.
[edit] I guess that's true. I'm not sure who their users are, but obviously not people overly concerned about security. [/edit]
Just because I think it's funny - every time I visit my dad (who's in his 80s) he regales me with his startup ideas. "Why don't you build something that I can put on my glasses so when I lose them I can find them? Whoever invents that would be a billionaire." I say, "Yeah dad, they have that."
"Why don't they make it so I don't have to remember passwords for all these different websites? I could just have one password and it would remember it for everything."
I think I've explained at least a dozen times why I think third party trust is a bad idea; I've had to really refine it down to the level of explaining this to a six year old.
But the salient point here is that even my dad never signed up for LastPass. So who the fuck is signing up for LastPass?
>It’s fine to store your passwords online for convenience, but as a user, it’s important to accept that it’s no longer your private password and will, at some point, leak.
ehh. I store my passwords online but its on a file I encrypted offline with strong password (over 20+ characters) and key. I use keepass which is a locally encrypted and stored password manger, and I store the DB on Dropbox and download it to any of my computers/devices were it is decrypted locally when needed. I don't trust password wallet services ass they all seem to want to do the enryption server side with a reset-able password which really means they have the master password not you, but my set up seems secure enough to me.
I have a similar setup, except I use Syncthing. Works fine with Keepass2Android/KeepassXC on both Windows and Linux machines.
Occasionally I might need to do some manual steps (a week ago windows stopped running Syncthing and that caused some conflicts down the road), but most of the time it just works.
> I don't trust password wallet services ass they all seem to want to do the enryption server side with a reset-able password which really means they have the master password not you
None of the popular password managers work this way.
> Recovery Groups
One of the most powerful capabilities that a team administrator has is
the power to assign members to the team’s Recovery Group. In most
configurations the assignment is automatic and Owners, Organizers, and Administrators will automatically be made members of the Recovery Group. In 1Password Families there is no ability to separate the roles of Owner, Administrator, and Recovery Group member; they are all wrapped up as “Organizer.” With 1Password Teams Administrators are given more control, but not all of the underlying flexibility may be exposed to the user.17 17We discovered during our beta testing that it was difficult to make the distinction between Owners, Administrators, vault Managers, and Recovery Group members clear enough for those distinctions to be sufficiently useful. This document describes recovery in terms of the Recovery Group even when the group is not exposed to the Team administrator in those terms.
> Implicit sharing
When a vault is created, a copy of the vault key is encrypted with the
public key of the Recovery Group. The members of the Recovery Group
are able to decrypt the private key of the Recovery Group. Thus from an
exclusively cryptographic point of view the members of the Recovery
Group have access to all of the vaults. Recovery Group members never have the ability to learn anyone’s account password, Secret Key, Account Unlock Key (AUK), or SRP-𝑥. Recovery is recovery of the vault keys; it is not recovery of account passwords nor Secret Keys.
Exactly: 1Password doesn’t have the keys. Recovery works because the vaults are encrypted with the keys of everyone in the recovery group. No “server side” encryption instead of end-to-end.
Bitwarden, Keeper ($ but trusted at megacorps), and good ol' PasswordSafe are the safest solutions.
I run BW with Yubikey 2FA and a local hosted sync server.
KeePassX/C perhaps. Vault for secrets management.
Never touched LastPass, 1Password or any of these other mickey-mouse commercial apps that invariably claim "military-grade encryption" or "unhackable" when their fundamental constructions are crap.
Except or unless your google account gets locked. Any number of reasons and posts HN horror stories exist about other users getting locked out of their lives because of a user account or lack of access thereof
That’s a risk. I pay for my account to try and mitigate this risk so I’m the actual customer, not advertisers.
Google workspaces has a support assisted recovery option. I host dns separately from google as their admin level recovery may require some dns signaling.
Other steps include a yubikey etc . I’ve actually had the experience of losing all my Authenticator codes on an iPhone upgrade which at the time was how I did 2fa - so had to go through recovery for many providers. My top takeaway - if I was paying for service it was possible if sometimes a bit time consuming. If I wasn’t it was hit or miss.
Other tip? Google Authenticator may not backup to iCloud!! I had 20 codes in it including some really hard to fix ones.
I see a lot of people mentioning bitwarden around here; is their actually a technical reason to believe they are better than Lastpass or any of their competition (have they like open sourced all their stuff?).
There’s very little room for failure and learning in the online password safe field, so I generally assume these companies are in one of two states:
> is their actually a technical reason to believe they are better than Lastpass or any of their competition (have they like open sourced all their stuff?).
I choose to use their clients unmodified, along with an instance of the server formerly known as "bitwarden_rs" running in my basement as the sync backend.
https://github.com/dani-garcia/vaultwarden
I still pay them annually for their "freemium" features even though I prefer not to let them host my data.
Do you expose your server to the internet or is it ok to sync devices only when you’re at home? Is every device a replica, if you lose your server can you redeploy it from the data on your device?
Not the parent, but I have been hosting a Vaultwarden instance on the public internet for about two years now.
After learning about certificate transparency logs, I moved the app from a raw subdomain behind a secret URL path. Think “hello.domain.com/correcthorsebatterystaple”.
Is it security by obscurity? You bet. Does it work? Yes. I regularly evaluate the JSON logs emitted by Caddy in a pandas script and so far, no foreign party has even hit that endpoint.
It’s like an extra username of sorts you’d have to know. I’ve always been unsure of where to draw the line when it comes to obscurity. People online are viciously against it, but isn’t a password also just obscurity, if you squint your eyes real good? It’s all secrets users would need to know.
All that being said, I’m thinking of hosting it at-home-only as well. Would be a huge win in security and barely any loss in convenience.
I’d say the things hitting your endpoint are going to be entirely automated scanners that are looking for unauthenticated resources or low hanging common passwords. If you have even a moderately strong password, it’s just noise. I’d be wary about drawing any significant conclusions from logs, because the sophistication of attackers you’ve excluded are quite low.
I’d say defense-in-depth is more about nesting strong cryptographic primitives, than simply adding layers. What you’re trading off for is complexity and convenience vs security. In the URL case, a password is more secure (and treated as such) and lots of care is usually taken to make sure the hashing scheme is timing resistant etc. I don’t know if Caddy makes equivalent guarantees, but I’d be very surprised if path matching was not just a string match/regex/trie. In terms of time to crack, just prepending these characters to the password would give you more protection, because that then has to go through a resource intensive hashing process.
An example of defense-in-depth would be to host at home only. Here, it’s because you’re nesting actual isolation (which is a good security primitive by itself), with a strong password. This gives you protection even if your threat model is “caddy is borked and is letting anyone do anything”.
Now in reality, you can do just about anything and it’ll work (because in the grand scheme, you’re probably not a high value enough target for any high cost attacks). If you secretly happen to be, then you can afford an actual security audit, rather than relying on random info from HN :)
> I’d say defense-in-depth is more about nesting strong cryptographic primitives, than simply adding layers.
I like this insight, thank you.
One rebuttal I have: appending those characters to the password would make it a stronger password, but it wouldn’t add another, wholly different, mode to authentication. It would be the same thing, just harder (and I don’t need a longer password as it stands). What if this mode is flawed in itself? That’s when a wholly different one is desirable.
In that spirit, I had also thought about just slamming http basic auth in front of everything. Even if that basic auth uses weak credentials, it adds to security in a multiplicative/exponential way (multiple passwords/systems), over just a linear one (single but long password). I suppose that’s also what you mean by layering.
Linear/multiplicative stuff is actually quite helpful for discussing the path thing.
Adding a “password” path is actually only increasing your security by a constant factor per character because of the risk of timing attacks (unless you are sure that the path matching algorithm is secure against it now and in the future). Ideally a 2nd layer would guard against it in a multiplicative way (an entirely different with system).
Cryptographically, adding characters to the password rather than to the path is better (because it increases the search space exponentially) than adding characters to the path, which can be brute forced separately per character.
But this assumes a very perfect view of software, where there are no bugs. Once you add a risk model for bugs, then there might be small values of path length where the additional constant factor is better than the multiplicative one that you get from adding characters to your password. So your rebuttal holds, depending on the exact bug risk model you have.
I think nowadays, tailscale/wireguard is really convenient and pretty secure as a 2nd layer. I was averse to self hosting my password manager in the past due to not being comfortable having the consistent time to secure more critical applications, but I might actually move to a world where I host more critical things myself behind a VPN.
I had a at-home-only version once. Then I failed to unlock my vault on my iPhone (FaceID issue or something) and it refused to allow me to enter the master key without first passing the 2FA check with the server (did it delete the local vault or something?!). I had to go home to fix it.
I’d recommend ensuring you have some sort of VPN solution so that you can access your vault away from home, too.
Personally, I just decided to use the 1st party server. I realized that reliable access to my vault is a service I really don’t want to be without due to technical issues in my setup.
I currently have my server at home connected via wireguard to a VPS. On that VPS, I run Caddy and have it reverse proxy back to my server over wireguard.
If I were building it out today I might just use tailscale and be done with it.
I'm not sure about whether every device is a replica of the server. I believe that's the case (given how they behave when the server is offline) but that doesn't figure into my recovery plan.
But in the case of the mobile apps, downloaded from their respective platform's app store, how can you guarantee the code you see on github is the exact same code you're running on your device?
Admittedly this supply-chain-verification is an issue for all mobile app store apps but seems particularly important with something like a password manager.
In a perfect scenario you would be able to use a reproducible build [0], for Android you can actually get Bitwarden from F-Droid [1] which uses those reproducible builds.
For Google play store, there was also that developers needed to sign their apps before releasing to stores, so you knew that it came from developer, but Google removed that when they introduced app bundles. There is still a way to verify if the build is the same as developer provided, but automatic protections that were there are now gone [2]
Looking at that, it doesn't seem like you can actually get Bitwarden from F-Droid? That looks like instructions to set up a third-party repository (hosted by Bitwarden)?
The page didn't mention anything about reproducible builds. (Doesn't mean they aren't using it though, but that would be internal.)
I may be wrong, the idea is interesting but looks more like a password generator and a terrible password manager to me.
You still need to store somewhere informations like url, username, counter, etc. right ?
Can you change the master password without changing all your accounts password ?
If one happens to find your master password, he's basically able to get/generate all your passwords just like a normal pw manager with no 2FA, correct ?
You have it right. This master password derived passwords idea is nothing new. Few people actually use it because it's not actually a great idea for the reasons you listed.
Doesn't necessarily mean it's safe. Say there's passwords accidentally appearing in logs as part of a traceback - even if the passwords are kept encrypted, just having access to the logs is enough. Even if everything is encrypted client-side, it could appear as part of a client crash dump being sent by telemetry. Leaked plaintext databases aren't the only possibility.
Bitwarden caches Web urls as well on its browser extensions.
Sometimes it knows that you have saved login for the specific web page before you have logged in. Certainly LastPass had urls unencrypted for this specific reason - to show users that you have saved login for this page, would you like to login?
It is the endless usablity vs. security battle. Of course, there are better ways to implement this than LastPass has done.
I would hope not... that term should be reserved to indicate that the data is encrypted on one of your devices and is merely passed encrypted through their servers to your other devices.
LastPass-the-company doesn't need to die over this incident, but I can't help but wonder if a kind of corporate panic will stop them from doing what they need to survive it.
I agree: LastPass has been hot garbage for many years but it still has a significant presence, some guy’s low-value crypto wallets would not be the first we hear about a compromise of LastPass vaults. There are entire companies using LastPass for critical systems.
I absolutely believe it’s possible that LastPass has been compromised more than they’ve let on and I won’t be surprised if we eventually find out vaults are vulnerable, but I don’t believe this is how it would play out.
Sunday the 18th is conveniently around the time of the latest announcement, but not the time of the actual hack. Feels like someone is over fitting.
But if you had a ton of credentials from people, scanning for crypto credentials and trying to use those may be easier/faster/safer to turn into money than system credentials to some random company network.
If the hack of LastPass happened yesterday, sure, but it happened months ago. There are a variety of different attacks that could be executed in that time, and the sooner the attacks are executed, the better — because less time for credentials to be rotated.
I find it implausible that the first hint of vault compromise comes 4 months after the hack and is against a low value cryptocurrency wallet. Especially considering that when LastPass first had issues, there were dozens of people reporting personal experiences of it here on HN — if LastPass vaults are compromised, the internet would be flooded with reports.
I largely agree with you, however it may also be the case that the attackers have been working on cracking vaults quietly since the hack and the announcement made them go after everything they had cracked so far instead of continuing to work quietly. They might have decided the crackable vaults don’t rotate credentials within them often, but it becomes much more likely after the announcement.
They weren't really credentials, but keys. Pop those into any compatible wallet and you control the money now.
If someone had put the key in the URL field (because there is no corresponding URL because it's not a credential), and the URL field was unencrypted, that could account for it.
You would hope, but I've been working in customer/technical support in the crypto industry since early 2017. People are not remotely as careful as you would expect (and hope for) them to be.
This attitude is why a poor person will effectively be put in debtors prison and no one bats an eye. It requires "someone important" before people think maybe it actually happens.
That and you get to centrally admin this for others (employees, family members), fine grained access controls for business use, you don't have to host and secure anything yourself (e.g. Bitwarden), pretty good UX on all your devices. I had to use a shared KeepassX file in git for a project and it was a frequent source of problems.
I used KeePass + Dropbox/Syncthing for years, but eventually gave up. At some point I saved my KeePass db with a newer version (of the software and the DB format), and later found out that the newer software version will not run on an older version of MacOS that I still use on one machine.
I mean, I could maybe update the OS on that machine (not sure--it's over 10 years old) but at that point it was less work and less risk to switch to BitWarden. And the user experience is much better as well.
I have >200 unique randomly generated passwords in my Keepass file for various accounts (granted, a lot of them are throwaway accounts). No way I could ever remember those passwords, so any attempt at using that approach would necessitate less secure passwords.
People keep asking: if you have family and you need partial sharing and full sharing as well as write capabilities on multiple devices at same time without messing up, keepass is insufficient.
If this is true there really is such low hope for cryptocurrency. If you can’t store your keys in a service like LP hardened via physical 2FAA. What’s left? Air gapped setups?
I think lastpass is reputed to be bad compared to competitors like 1password. If you can’t secure your bike with a flimsy Kevlar belt, what’s left? A team of two armed guards?
Passwordless might be the way to go. We (as a society) have been trying to do 2FA now wherever we can. 2FA can involve an authenticator app but it is easier with a physical key. That physical key by itself can obsolete the password for many uses.
The more numerous the places where we can abandon passwords, the fewer the secrets that we need to keep.
This is the answer. The only advantage of passwords is that they’re cheap and universally compatible. PKI based solutions are more secure and more convenient. They cost a few dollars and there are too many standard, though.
Ultimately, I expect the biggest barrier to be mental. People have had mantra about passwords banged into their heads for decades that they have become synonymous with a secure system and people are suspicious when their device just lets them in with little to no friction.
I don't know why, but I'm still a bit afraid of using security key everywhere.
I have an irrational fear of losing/breaking my security key. Even though I know my phone is fine and always with me (as a comparison).
I just set up a whole backup solution for my many self hosted applications, all encrypted with the keys safely in my password manager. Even uploaded to S3, because I figured if I'm paying for it, I could ID-and-support ticket my way to my data even if I lost my AWS credentials.
I don't know how to integrate a security key into this scheme. What to do if it actually gets lost ?
Will I have to use emergency codes for all the accounts ?
Can I make a backup of it somewhere ?
Would that defeat the purpose ?
I'll buy one someday, when I'll have all this figured out.
I think that worry makes sense. It is a good idea to keep a backup. For example, you could get two YubiKeys, use one as your primary, and put the other in a safe place as your backup.
It is a little bit of a hassle. But changing 200 passwords because LastPass was breached is also a hassle.
One option is to have two identical security keys. In general, you can't easily read the secrets from an existing key, but you can overwrite/initialize them to get two with identical data.
The problem with that is that it requires to have all these security keys available in order to enrol them, which is not possible if you want to store one of them in a different secure location. If you have two keys in your pocket, that's not much of a backup; having two identical keys means that you can enrol the one in your pocket and if it gets lost, the copy from your safe works.
Do encryption on offline computer with trusted open source encryption solutions. Why do you think bitcoin experts have always said to do everything offline?
this sort of thing is why I append the name of the website + a unique identifier + password, so that I don't have to bother changing my password during such nonsense, ugh.
it's deterministic, but obviously I can't tell you the secret ;)
that being said there are a lot of things you could use. you could use information in the whois, you could use the birthdate of the founder of the site, etc.
personally I believe people should use the same password for all sites and then something similar to what I described. though I use a password manager, I do always feel nervous about the implementation leaking out details
Eventually, some website you use is going to get hacked. They’ll have stored passwords as plaintext. From there, anyone who wants to hack any of your accounts knows your password format. It’s going to be obvious to them that they just need to replace the domain.
how would they figure out the unique identifier? couldn't you say the same thing about using an arbitrarily unique password and then a password manager. if your password manager is hacked then they'd get the encrypted passwords for all sites you use along with all the personal information.
of course, you'll say, don't use a crappy password manager. and that's correct. same reason I use a separate format for sketchy sites.
for what it's worth my format isn't really as described, but it is similarly deterministic, but not visually so. the cipher is basic enough to do in your head but complicated enough that you wouldn't know from a glance
a real password example for your scrunity:
m0m2a2yiplagsosowgolredd1o2t3c!o!m2
steps:
m a i l g o o g l e d o t c o m
strategy
zip
secret
mypassword123!!
offset (publicly determinable)
0
unique: 2022
m0m2a2yiplagsosowgolredd1o2t3c!o!m2
i use a password manager so the long text generally is irrelevant. the main reason I do this is because I don't feel comfortable needing my password manager. I like being able to figure out my actual password completely independent of a phone or internet or app.
the strategy depends on how sensitive the app is (strategies include: zip, append, vowel-zip, no-vowel-zip, num-zip, all the same but with a reverse-offset). unique is usually something like when I joined, or something determinable from the site and my head.
all of this seems much more complicated than it is. once you understand you could calculate the password in your head in a couple seconds.
By your example, your passwords are a set of fixed or knowable data, plus a unique identifier that in your examples is three characters long. Therefore knowing one of your passwords gives all except three characters of every other password, thus making your effective password length three characters (substitute the actual length of your unique identifier if it's more than three).
Sure, that's slightly better, but you're putting in quite a lot of effort for minimal reward - there still isn't much entropy here compared to the size of the password, and you're relying on security through obscurity (that no-one will work out your method). Password crackers on modern GPUs can chew through many millions of guesses per second so having such a significant leg up would likely make your strategy trivial to break.
Also plenty of perfectly respectable sites have been compromised in the past so your estimation about how safe the site is unfortunately doesn't help much.
I really think you'd be better off using long randomly-generated strings and keeping multiple backups of your password database. There are lots of options that don't put you in the hands of a third party. All (?) sites offer password reset facilities in case of emergency, and you could memorise your email account password so that you can always at least get into that.
the main goal for myself is to be able to have complicated passwords and remember them without a computer. the problem with all password managers is ultimately it must be possible to get them in plain text by design, so if someone gets that they get all of your passwords.
It does reduce the search space for a brute force attempt. Depending on how short your identifier is. Also if two sites passwords are leaked it could make someone’s job a lot easier.
This means that if a breach reveals more than one of your passwords, the pattern is easily recognized and you just made ALL your passwords extremely weak. Not a great idea.
Doesn't that make your passwords predictable? If you use the same secret for every domain and now if an attacker figures out your one secret then they would be able to find out all your passwords.
A master password is at least generating random passwords though and encrypting the passwords themselves. Let's say your master password gets compromised, but not the password database itself... then attackers would still have no way to access your other passwords. With the method being described, simply obtaining the "secret" makes other passwords known without even needing access to the password database itself.
Reminder that in 2015 LastPass was acquired by LogMeIn, who then in 2021 announced it was spinning off back into its own thing, though whether that has happened yet is unclear.
If you look into what LogMeIn (now renamed to “GoTo”) makes… this doesn’t make me feel good about GoToMeetings, GoToMyPC, or join.me.
That's an interesting take, because for many of us, prior knowledge about the insecurity of GoTo products (not so branded then) were evidence that the security of LastPass was at risk.
I saw a class action filed. If the class is admitted I may opt out, I want compensation for each of the many hours I now have to spend rotating my hundreds of passwords. This is totally unacceptable.
You want compensation for rotating your passwords even though there is no evidence other than this random twitter thread that any of them are comprised?
You wouldn't normally be compensated for your own time lost in a matter that didn't actually cost you money eg actual time not hypothetical time lost from work.
If this was true, i feel like it would be a little strange for the attacker to use it to steal a small amount of crypto. Once its revealed how bad this is, there would probably be a small window before people change their passwords, i would assume attackers would either go for a big score before revealing this capability, or they would try to hit everything very quickly. Just hitting a tiny amount of crypto seems odd.
Seems very likely, it's now known (maybe always was) that metadata fields aren't encrypted. If Twitter poster added those keys to a 'metadata field's then they were clear text.
I've been using LastPass for years. Looks like I'm going to have to export everything from my LP vault and import it into Bitwarden. Any downsides to Bitwarden that anyone knows of? I'm asking more about convenience, i.e. how well the browser extensions and Android app work and less about security.
Switched from LastPass to Bitwarden some time ago. The only issue I had thus far was exporting the contents out of LastPass. Some of the special characters in some passwords did not export properly. I had to add those items by hand.
As for Bitwarden, I like the UI (iPad, Mac, iPhone) but routinely forget how to generate a new password - the function is buried inside one of the menu options. Other than that, I really like it. And, there is option to host your own vault.
Thanks very much. I wanted to hear from others who've made the same switch, so this is really helpful. LP has been pretty seamless for across devices so I wanted to know what to expect with BW.
Quick tip: if you have Bitwarden's browser extension installed, you can use Cmd + Shift + 9 (I'm assuming it's Ctrl + Shift + 9 for Windows) to load your clipboard with a randomly generated password: h4!E49vFcGEE%c#$HZ%z*3^5B
I use LastPass at work and Bitwarden (technically Vaultwarden but same clients) at home.
I find that Bitwarden's UI is much less quirky, for lack of a better term. LastPass finds ways to consistently annoy me.
The commonly clicked secrets move to the top, I can see more than two items in the list, it doesn't forget me periodically, and when prompted for credentials I can't cancel it and get in anyway.
You can add multiple sites to the secret, not in some hidden menu in Bitwarden. That's handy for things like AD/LDAP credentials.
I moved to bitwarden and was happy at first, but after a while the app UIs were really annoying. They save/update password functions kept messing up and I would lose the password.
I eventually decided that the UI was too clunky to move my whole family onto and opted for 1password. Very happy with that choice.
If you want to improve your security, don't export from LastPass. Instead, authenticate into each service with the creds in LastPass, change your password in the service, then save the new password into Bitwarden.
In general, one should avoid exporting/importing credentials. Instead reset them and save the new creds into the new place.
Having all your keys/passwords on a 3rd party server is something that I've never been willing to accept from a security standpoint. That's what always kept me from using a `hosted` solution. I do get the allure from a multi-user management aspect though.
I loved a similar setup when 1Password used to make that easy. I am very grumpy about them bait and switching me to a cloud/subscription model. (But not quite grumpy enough to have done anything about it yet.)
Version 7 is still available on their website to download (if you have a key for it). Oddly enough they still do update it. It's what I use and likely will use until it no-longer works or there is some issue with it.
Is the added security just that Dropbox is a lower value target (possible) and that attackers won't think to look for password databases in Dropbox accounts if they do compromise Dropbox (less likely)? Or is there something more to it?
EDIT: Given the replies below, I should be clear that I'm not interested in comparing to LastPass, I'm comparing to Bitwarden. LastPass had an obviously bad security model that failed to encrypt everything, but Bitwarden does not have that flaw.
You do not store the password on a password manager either. LastPass swears up and down that they never see your master password, all encryption happens client side. I can see good reasons not to trust LastPass at their word, but Bitwarden?
No. When you login to LastPass, your password can be taken if LastPass is compromised. You have to trust that LastPass will not do it. If you login to Dropbox, the master password to your keepass database cannot be stolen. You don’t need to trust Dropbox.
In theory, the master password is never supposed to leave your device even with the cloud-based password managers. So, yes, you're trusting that their clients do what they say they do, and I suppose an attacker could hijack the client and offload your password.
That said, the same risk applies to any client you use. Someone could have compromised the latest update of KeePassX as readily as they can compromise LastPass's client. If you don't have automatic updates then that's helpful, but I'm not sure it's producing enough security to be worth the extra hassle.
Having to do it while updating narrows the window of opportunity for sure, but I don't think KeePassX is a more secure target than Dropbox or Bitwarden.
They don't have to get bad code into an MR (though that's one option), they could compromise the website and have it distribute a different binary. If you build it from source you're safe against that, but are you really building it from source?
Also, remember that the same logic applies to Bitwarden: they need the master password and therefore must compromise the client during the window where you update it.
Drop box is just the sync mechanism, with keepass' encryption (and their own care to keep the keys safe and not carried on the same medium) being all the protection.
Dropbox is not added security in this setup, it is a natural factor if what is being transferred [the keepass file(s)] is sufficiently secure in itself.
No possibility for a MITM attack (except, I suppose, with a keylogger, but then you've got bigger problems), and absolutely NOTHING outside of encryption, whereas whoever has this leak now knows what users have accounts on what websites, which is a veritable treasure trove.
That plus security through obscurity: no one is presuming you're going to come out of a Dropbox hack with millions of password vaults. Even finding them would be... nightmarish. (Though I suppose you could somehow hack a Dropbox file index database?) The value of a target like LastPass is absolutely insanely high: it's a concentrated honeypot of encrypted vaults.
Plus, the Android app makes using a Dropbox synced folder location fairly trivial, so that works pretty well. And you can set your own number of password rotations, which, while annoying when it takes my phone 5-10 seconds to unlock, realllllllly helps ensure no one else is going to crack this vault if they ever got it.
> No possibility for a MITM attack ... and absolutely NOTHING outside of encryption
LastPass is a disaster, but in theory these benefits are true of Bitwarden as well. They say they encrypt the entire vault, no exceptions, and do the encryption entirely on device.
I can see the honeypot argument, but Dropbox is also a big honeypot for different reasons (tons and tons of plain text information that could be very valuable in the right hands). And I don't think finding the vaults would be as hard as you think it would, because searching for encrypted files should be relatively easy, and any encrypted file is probably worth attempting to crack.
I'm not trying to argue for cloud password managers, I'm totally open to being persuaded and would immediately switch if I were, but I'm really failing to see where the added security is versus Bitwarden. Bitwarden is open source just like KeePassX, so if it did not implement the security model that claims to I think someone would have blown a whistle by now.
The database is encrypted when at rest; i.e., no plaintext is stored on Dropbox. Assuming your master password is decent, you could plaster the database on a billboard and it would be safe. LastPass, on the other hand, encrypts some information (the actual passwords). The URLs and other sensitive information is stored in plaintext in the cloud. [Final edit. I swear.] As you note, as long as the entire blob is encrypted it doesn't really matter how it's replicated; BitWarden's one-stop-shopping can certainly be more convienent.
But that is the same claim that Bitwarden and 1Password make. Both insist that they don't ever see your master password, which means that your vault security depends entirely on it being good enough. And both encrypt everything.
Assuming that I trust Bitwarden not to lie about their security model, what do I gain by piecing together multiple tools to accomplish the same thing?
(Sorry, I turned around and made an edit, but not before you replied.) KeePass encrypts the entire database, all fields, as one giant blob. LastPass stores URLs and other fields as plaintext; these too can contain critically sensitive information. [Edit: (See I flagged it)] As far as know it wasn't LastPass's client that was compromised--it was their servers/data store.
Their software does see your master password. It may process it locally, it may not. If it's run in web client inside browser, that may change at any second. This may happen due to attack, their mistake, their dependency vulnerability or plain lie on their part. Fundamentally you need to trust them.
In case of keepass and independent sync(doesn't have to be Dropbox), software that sees master password doesn't need access to the internet. Can be even airgapped if you are extra paranoid.
So to sum it up: keepass + sync is better, because there's no single party that is even able to screw up you to the point of leaking your passwords. "Impossible to fail" is better than "they are doing their best, pinkie promise".
Also - why pay recurring fee for yet another cloud storage, when I just need plain encryption software.
> Their software does see your master password. It may process it locally, it may not. If it's run in web client inside browser, that may change at any second. This may happen due to attack, their mistake, their dependency vulnerability or plain lie on their part. Fundamentally you need to trust them.
All of this applies to KeePass, minus the browser extension bit (which is trivial to avoid by not using the browser extension). The only difference is that you can theoretically firewall KeePass from the network, which I'll grant you would make a difference, but the fact that you reserve that for the extra paranoid suggests most don't do that.
> because there's no single party that is even able to screw up you to the point of leaking your passwords
Again, only true if you block network access. If not, you have as many points of failure as with Bitwarden, because only the client needs to be compromised to get both vault and password.
> Also - why pay recurring fee for yet another cloud storage, when I just need plain encryption software.
Bitwarden free is plenty for me right now, so this doesn't play into my calculus.
Personally, I'm not interested in making the switch if I'll have to fiddle with firewalls on all my devices in order for it to be more secure for my current solution. It's not that this conversation is made me think less of KeyPass, it's that I'm yet to see a convincing argument that Bitwarden is worse than what I would end up with in practice by switching.
Still - cloud password managers are built to upload your data to the network and it's much easier to smuggle something, when keepass apart from maybe update check doesn't have any network activity. Someone would spot it pretty fast and that would be instant death for the project. On cloud solutions it may take years to be found, as demonstrated here: https://arstechnica.com/information-technology/2022/06/mega-...
That being said - bitwarden is pretty transparent in what they do, compared to the competition and I'm seriously considering giving it a try (but with self hosted backend).
Doesn't KeePass use a single database file with no conflict resolution?
I looked at using them but ultimately decided against them, a conflict overwriting a password scares me more than even just using chrome sync and calling it a day.
It does seem to be solvable though. I could see myself using SyncThing+ KeePass if I ever became unsatisfied with BitWarden and I found an app without too many sync issues.
Write yourself a graph of your core account recoveries, don't put those on. Just put your leaf accounts on (those that recover from the core accounts).
FWIW. After using it at my previous workplace, I got a 1Password family account.
It’s got my (not particularly technical) wife using unique strong passwords for all her online accounts and made family password sharing easy. I think the convenience of the cloud is key to this.
I get that there’s a security risk that 1Password gets compromised and the app is infected with malware or there ends up being a vulnerability on their encryption scheme but it still feels like a net improvement to my overall online security.
Also MFA can help mitigate the risks of the passwords being compromised.
But you do not have the keys and passwords on that server. Only their encrypted forms. And the master password never leaves your machine(s), the sensitive bits are only decrypted locally.
This is reasonably safe, as long as you're careful with your master password, no different form GPG.
I'd still rather not let anyone have the encrypted versions of my keys/passwords. If the software is compromised then it's reasonable to consider the encrypted data can be brute forced with some time.
I'm not here to argue the merits of encryption. I understand it very well. I'm only considering my own levels of comfort and need to trust a 3rd party as well as pay a recurring fee to store my keys/passwords.
Encryption that can't be brute-forced within centuries, even with a quantum computer, exists for some time, and is not really expensive to apply, especially on such small scales as a password database.
I kind of agree with you, but on the other hand, they are storing everything you give them using strong cryptography. If you fundamentally don't trust cryptography then none of those passwords you are worried about are worth protecting in the first place. So I'm not sure it's logically consistent to say that such a service should / should never exist on that basis.
Where I do think it resonates is fundamentally it's just a bad idea to centralize things like this. It may be a necessary to construct a commercial business around this, but centralising massive amounts of trust across unrelated entities into ANY party is just a fundamental compromise that shouldn't have to be made. We would all be better off with genuine decentralised infrastructure to make all this work.
What does irritate me is that all these companies are full of "zero trust" marketing spiel but their products always actually end up coming back to placing 100% trust in them in the end.
It's not the cryptography that I don't trust. It's the e2e implementation. I mean we wouldn't be having this conversation if it was just about the cryptography. Also, subscription fees are a turn off.
This is quite interesting. A couple of weeks ago, I received an extortion phishing email, but it was directed to a secondary email address that hasn’t been previously compromised. It made it past Gmail’s spam and phishing filters into my inbox.
Maybe a coincidence, but I guess every weird thing that happens is going to raise alarm bells.
I was suspicious of the LastPass concept (storing passwords in a cloud app) when a former employer introduced it some years ago, but they had a strong IT and security culture so I trusted them to make the right choices and adopted it for my personal use.
A few months ago I hsd an issue with my LastPass 2FA device and a policy set by my former employer blocked me from resetting it for my personal account. It was resolved by LastPass, but that was the first strike, and I had spent most of the night extracting my personal account passwords manually from the mobile app, which remained logged in. That was strike 1. This is strike 2.
I’d love to hear the story about bypassing/resetting that 2FA setting? Sounds suspiciously like something that could be social engineered around by a sufficiently skilled attacker?
I am very much of the opinion that if I fuck up my side of 2FA protection, the resources/accounts they’re protecting should be lost forever. (Or at the very least, a co-account holder might be able to reset some things, like my AWS IAM creds or GSuite admin account). If I can ring up and whine at enough support people to get them to hand over my account, so can a sufficiently persistent skilled social engineer…
Any two factor that doesn’t require your firstborn or travelling in person to some frightening building to remove is basically a form of security theater. Most can be removed by support pretty easily just by asking.
Why would support be in the business of removing it just because someone asks? If I needed it removed I could take a call at my official phone number and photograph my actual ID.
My cell provider requires a photo ID in person or a long pin not stored in the same place as other passwords in order to assign my number to a new phone and 2FA to access account.
This raises the bar from knowing my password to knowing my password, knowing my ID, producing a fake facsimile of my ID, stealing my pin from its encrypted container on my desktop, taking over my phone number, then taking over my account.
I don't have a pile of crypto to steal ergo this would be a LOT of work to send spam as me until my email gets flagged. It would be like a heist movie only with the target being the $40 in my wallet. mission impossible themesong begins playing
Basically support just needs to exercise reasonable caution when removing or changing it.
On a balance of risks, your your former employer may have made the right call. The issue is, do you use something that isn't perfect but everybody can use, or do have a substantial portion of tech illiterate people not use anything, which would be an even greater risk.
I think the policy is fine, but since I left my former employer more than a year ago, the policy should have been lifted on my personal account automatically (assuming that my former employer deactivated the work account, which I expect that they did).
Same thing for me with sudden spam emails. But the receive address did not have the customization for me to track it, instead my first name. Not sure if lastpass related but maybe.
BTW one client of mine runs a heavy security operation and they use KeePass.
And so does sending your passwords to a phone or a home/work pc via chats or email, or using a single password everywhere, or maybe a couple of them with trivial variations. Cloud password managers wouldn’t even exist if people didn’t do much more stupid things to enter their passwords on a different device than the cloud could ever think of.
>And so does sending your passwords to a phone or a home/work pc via chats or email, or using a single password everywhere, or maybe a couple of them with trivial variations. Cloud password managers wouldn’t even exist if people didn’t do much more stupid things to enter their passwords on a different device than the cloud could ever think of.
"You should do something stupid because most people do things that are even more stupid" is not a good argument in my opinion. I've been in the computer/tech space for 30+ years without every sharing a password or doing something stupid with my passwords, and it hasn't ever been any sort of burden. Why is it so controversial among the HN crowd to simply be minimally intelligent and careful with your sensitive information?
May I ask how you accomplish this without any sort of burden? Because from my perspective, managing strong unique passwords for hundreds of accounts across desktop, mobile, servers, and other devices is a major pain and I’m tired of dealing with it.
It’s human nature to take shortcuts and develop bad habits when you’re dealing with a flawed system and poor tools that puts the burden on the end user to manage everything. And if I’m struggling with four decades of experience, how is the average non tech user expected to do it properly?
>managing strong unique passwords for hundreds of accounts across desktop, mobile, servers,
I have a couple of dozen unique passwords. The ones I use most frequently are easily remember with pass phrases and all are written down on a couple of sheets of paper.
>and other devices is a major pain and I’m tired of dealing with it.
You are free to sacrifice security for convenience, but don't cry about it when your security is compromised because you consider maintaining your security too much of a hassle.
>It’s human nature to take shortcuts and develop bad habits when you’re dealing with a flawed system and poor tools that puts the burden on the end user to manage this.
I would argue that outsourcing your "security" to a third party is a shortcut and a bad habit that compromises your security. If you can't be bothered to worry about your own security because you find it too much of a hassle, then you have nobody to blame but yourself when your security is compromised.
>And if I’m struggling with four decades of experience, how is the average non tech user expected to do it?
Most non-tech users don't have hundreds of accounts to manage. I would hope and expect that even non-tech users have the ability to use a paper and pencil, and write down their passwords. At what point are responsible, sentient adults expected to take responsibility for themselves and their own security?
>May I ask how you accomplish this without any sort of burden?
Being an adult who is responsible for yourself is a necessary burden. This is also true for your own security.
And when I say that I will stop using 1password when the local vault no longer works, people look at me like I'm paranoid and crazy.
I've looked at the white paper https://1passwordstatic.com/files/security/1password-white-p..., I think 1password has a decent security posture for their cloud offering but then there's always the risk of a breach where the attacker controls the site and can intercept your master password through it. Same as what happened with British Airways or Lavabit.
There is always the risk of an attacker infiltrating the company to write vulnerabilities or a government forcing the cloud provider to write malicious code in order to degrade security. That's what the U.S. government almost succeeded at forcing Apple to do in the wake of the San Bernardino case.
A local vault is better than a cloud vault, but if that local vault software is written by a commercial company there's still that risk.
My understanding is the app decrypts the vault locally. I guess they could put out a malicious update but then you’d be impacted whether there was a cloud-free option or not.
Yes, but I think it would be harder to push a malicious update especially since currently 1password doesn't send information on the license when checking for updates. So a malicious update wouldn't be targeted as easily as logging in a web app.
Additionally exfiltrating the data would be harder for a locally stored vault..
Or controls one of the many apps. Every time I install the Firefox extension I wonder if I’m really able to be sure that I haven’t been directed to a compromised version or lookalike.
Please stop commenting whether you are a LastPass user or not. Some of your profiles on HN have an email address and in general all your comments are public so can be mined, plus "rich techies" could be prime targets for more direct and elaborate phishing campaigns.
For all you know, they are bots or shills to encourage actual users to comment.
Remember this?
<Cthon98> hey, if you type in your pw, it will show as stars
<Cthon98> ********* see!
<AzureDiamond> hunter2
<AzureDiamond> doesnt look like stars to me
<Cthon98> <AzureDiamond> *******
<Cthon98> thats what I see
<AzureDiamond> oh, really?
<Cthon98> Absolutely
<AzureDiamond> you can go hunter2 my hunter2-ing hunter2
<AzureDiamond> haha, does that look funny to you?
<Cthon98> lol, yes. See, when YOU type hunter2, it shows to us as *******
<AzureDiamond> thats neat, I didnt know IRC did that
<Cthon98> yep, no matter how many times you type hunter2, it will show to us as *******
<AzureDiamond> awesome!
<AzureDiamond> wait, how do you know my pw?
<Cthon98> er, I just copy pasted YOUR ******'s and it appears to YOU as hunter2 cause its your pw
<AzureDiamond> oh, ok.
Aren't we assuming at this point that the attackers have the complete customer list? I imagine that it would be way easier for them to have a script query that list directly and search for names and emails to find high value targets, rather than reading through HN hoping for a hit.
This is news to me. Was the customer list also stolen? Specifically, customer records linked to individual vaults?
My concern with anyone identifying themselves as being affected by this breach is that a 3rd party would be able to collect a lot of information about the user for a very targeted social engineering attack. Conversations here often disclose personal information such as approximate age, location, past experiences, hobbies, etc. It's a gold mine for social engineering.
> To date, we have determined that ... the threat actor copied information from backup that contained basic customer account information and related metadata including company names, end-user names, billing addresses, email addresses, telephone numbers, and the IP addresses from which customers were accessing the LastPass service. The threat actor was also able to copy a backup of customer vault data ... both unencrypted data, such as website URLs ...
Given how incompetent they've been, it would be safe to assume that the vault data is linked to customer account information. And because website URLs are included in the package, there is already tons of information for spear phishing, and any LastPass user here is probably already doxxed to the bad actor.
In general, you're right, but I really think that in this case the ship has sailed. The attacker has more information than they could possibly sort through by hand, they're not going to resort to reading forum posts.
I've been using KeePass for years and have recently switched to Strongbox which is an incredible app/ui to interact with Keepass databases for macOS and iOS.
The database is kept in sync with either Dropbox or iCloud.
I just wish Firefox would integrate Apple’s Keychain. I don’t know if it is even possible or not. But it is such a pain because I really am tired of all these password managers and also security breaches from multiple silos. Medibank has leaked all my data and now I have lastpass to deal with too.
This is why Microsoft's requirement to drink a verification can was so genius. Imagine being a hacker and have to drink multiple verification cans to be able to proceed throughout multiple transactions. "Hacker dies from overdose due to ingestion of too much Doritos and Mountain Dew"
Wait, so you're telling me that Cloudflare interstitial is running some PoW check on my client? I always thought that was just a way to let the user know they're being rate limited on Cloudflare's end.
Effectively yes. Not mining bitcoin, but modern bot detection works by asking your browser to do various tasks and comparing the results to a known good sample.
It could be a complex math problem, or another common trick is to purposely trigger bugs like a javascript engine not rounding numbers correctly in edge cases.
While this could be what happened, I suspect otherwise.
For many years, those of us in the cryptocurrency fields have said never enter your keys on a computer. Generate them offline on a hardware device and let that be it. The person making this claim clearly had to enter unencrypted keys into a computer to put them into his laspass vault. There are a number of malware variants that specifically target keys and search things like input fields in web forms and clipboards for those keys.
435 comments
[ 2.7 ms ] story [ 249 ms ] threadSee 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)
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 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.
https://support.1password.com/watchtower-privacy/
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
[2] https://courtois.cc/murphy/murphy.html
[3] https://courtois.cc/murphy/murphy_original.html
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.
https://www.lesspass.com/
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
https://www.ibm.com/topics/end-to-end-encryption
> 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.
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.
(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.
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.
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.
https://www.lesspass.com/
If you look into what LogMeIn (now renamed to “GoTo”) makes… this doesn’t make me feel good about GoToMeetings, GoToMyPC, or join.me.
https://twitter.com/SwiftOnSecurity/status/16060717986671738...
LastPass has a LOT to answer for.
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.
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.
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.
"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.
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..
Remember this?
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.
The database is kept in sync with either Dropbox or iCloud.
At this point I just don't want my data in the big, juicy hacking target.
https://imgur.com/dgGvgKF
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.
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.