1password: since version 8, dead due to cloud-only-now, not standalone, its over-usage of Electron web and its many unverified modules/libraries; remote storage of password only in encrypted form. Key stays offline.
vaultwarden: yet another Electron web app and its usage of many unverified modules/libraries; remote storage of password only in encrypted form. Key stays offline.
KeepassXC, with syncthing: leading contender, best-self-hosted solution that stores password remotely only in encrypted form. but still has iOS unverifiable source code imposed by Apple. Key stays offline.
NordPass: best zero knowledge remote storage; has apps for Windows, macOS, Linux, Android, and iOS. When it comes to browser extensions, one would be hard-pressed to find a wider selection. You can install NordPass on Chrome, Firefox, Safari, Opera, Brave, Vivaldi, and Edge. Not open-source.
LassPass, hacked in 2022; remote storage of raw passwords
pwsafe, still is the safest CLI-only solution to date. The design of pwsafe (Password Safe CLI) got started by Bruce Schnier, the crypto security privacy expert. In pwsafe, unbroken TwoFish algorithm is still being used instead of currently safer Argon2i, simply because it's faster (after millions of iterations). The recommended client-wise of PasswordSafe is still Netwrix (formerly MATESO of Germany) PasswordSafe with YubiKey but stay away from its web-client variants due to ease of memory access to JavaScript variable names (by OS, browser, JS engine, and JS language)
Only downside for ANY PasswordSafe-design GUI client is trusting yet another app repository source.
- biometrics, Apple Watch unlock, and Yubikey support
- TOTP codes, attachments, and markdown notes can be stored
- supports password auditing with Have I Been Pwned
- supports importing 1PW vaults
Most importantly, Strongbox is made by a small and transparent company. Unlike Bitwarden or 1Password, they are solely focused on making high quality macOS and iOS apps.
My only resistance from going the route of strongboxsafe is the lack of app-specific PIN, opposed to OS-specific PIN that is still missing from the free version.
While a master password covers the specific database, the PIN covers the app.
This is a problem for me there:
1. No OS-specific PIN/passcode in free version
A wider acceptance should borne with this simple feature in the free version.
Also Netwrix is more enterprise-ready with their SOC 2, ISO 27001 and HIPAA ready but that is a moot point for most SMBs, SMEs, family-servers and homelabs.
I do do like the simple fact that Strongbox has it all out with their Github repository.
1. Pay and support this small developer. A password manager is a critical tool that needs to be constantly updated to support the latest OS. This isn't Adobe, it's a bootstrapped indie developer making an app for a small audience. I think the free version is already quite generous. Plus Strongbox includes a one time purchase for all platforms, no subscription unlike 1Password or Bitwarden.
2. Compile and build from source. It's an open source app, you are free to sideload the app if you want to.
An excellent case for StrongBox Safe, support the indie who did all the hardwork. This would save you, the end-user, from having to do the following:
Sideloading a self-compile app for Apple ecosphere often requires a DUNS ID by Apple App store which in essence will plunge you, the developer, into a yearly subscription.
Sure that one can do a TestApp, but that one-time DUNS ID requirement still remains.
That is not true. To sideload an app a free Apple Developer is required. A 7 day limit is placed on that app before it has to be refreshed. If you pay for Apple's Developer subscription then that limit is increased to 1 year.
Alternatively you can use Altstore [0] and avoid paying for an Apple Developer subscription.
Right. My bad: DUNS ID is only required if you want over the air (OTA) update to your Apple devices through the use of Mobile Device Management (MDM) tool. (I was looking for ease of use, easiest, that is.)
Was unclear on how to circumvent this DUNS ID for just the sideloading. of apps.
When you say refresh after 7-day, is the original installation of your downloaded developer app gets affected/disabled or that 7-day is just a time-limit on how often you can upload your development app?
The provisioning profile expires after 7 days; you can transfer your development app to your devices as often as you want. Not sure if you lose data, when the profile expires, though.
> a caveat that you would not get the full security
Paying the developer for access to the full security version, while the free one has more than security than most actually use, seems reasonable to me?
> LassPass, hacked in 2022; remote storage of raw passwords
I know that it's been one dumpster fire after the other in the past few years, but did they actually go as far? The most severe one I remember hearing of was a leak of (possibly insufficiently salted, depending on the age of the account) encrypted password vaults. Still, I'll never again consider or recommend them going forward.
> In pwsafe, unbroken TwoFish algorithm is still being used instead of currently safer Argon2i
This is actually a negative point for it, in my view. AES is just as unbroken, yet has received considerably more scrutiny over the years.
The only place were non-AES symmetric algorithms still make sense these days is platforms where hardware acceleration is not available (e.g. djb's Salsa/Chacha), and even there only for high-throughput applications, which a password safe decidedly isn't.
> The recommended client-wise of PasswordSafe is still Netwrix (formerly MATESO of Germany)
I've never heard of them. Is it open source or at least properly audited?
"AES-KDF in KeePass is only CPU hard, while Argon2 is both CPU and RAM hard. This means that AES-KDF is victim to GPUs and ASICs for fast password cracking. The memory requirements in Argon2 make GPUs and ASICs considerably more expensive to reach similar password cracking speeds."
Update: This post is half-wrong; Salsa is a streaming cipher and AES is a block cipher and one still need a PBKDF mechanism to construct a safer key.
Problem with AES and Salsa is that salting is required for smaller-sized password and are not considered a "hashing" algorithm; those two are block ciphers, as I recall.
No, MATESO is not open source but with an enterprise license, you can negotiate for the source code. And they have contracted audits against their software.
Netwrix PasswordSafe is more enterprise-ready with their SOC 2, ISO 27001 and HIPAA compliance but that is a moot point for most SMBs, SMEs, family-servers and homelabs.
AES and Twofish are both block ciphers. Neither are hasing algorithms, and you'll need a PBKDF or some other construction to derive a key for either, no?
Right. thanks for the update. My note should have been consulted as you being correct. Hate my memory nowadays. Need to consult some more notes before speaking.
That's the last thing I would worry about. I don't get why people would get annoyed at the implementation of UI if that UI is working well enough. Imagine someone says "although this password manager is very secure and has all the features I need, I don't use it because it uses web UI, even though the difference in performance would not matter at all compared to a native app".
Honestly I find this ridiculous and it is a waste of my time to write this comment. Who
You could wait until you are able to foray deep into the field of cybersecurity and vulnerability assessment and arrive to the same conclusion as I do.
Or you can Google "electron web vulnerabilities" and find out quicker.
I use iCloud Keychain for most of my passwords these days, but my critical passwords I continue to keep in PW as well.
PW also has an occasionally very useful feature that I have not seen in any other password manager: auto type. Sometimes I just need to point my cursor somewhere and have the password typed for me (e.g. into a login screen on a VNC/RDP connection).
PW uses Blowfish with 448-bit keys.
There is also "pass" (from the author of Wireguard) which is essentially a shell script wrapper around gpg and git:
Maybe I'm misunderstanding the feature, but I've been auto-filling login forms since I was using IE7 with RoboForm. Other than using Touch ID to trigger the auto-fill instead of 1 click, I don't see any improvements in iOS/macOS Safari.
You leave all your password on the iCloud, accessible by AppleID but that AppleID password is so powerful and covers many more sensitive things (AppleWallet, ApplePay, ...)
Whereas, using a separate PIN/passcode at application-level provides a separate (master) password which would be used for all your passwords (in case your AppleID password gets compromised).
I do not use touchID nor FaceID because it violates the Principle of 3 Factors of Authentication: AppleID merges two of three factors:
> using a separate PIN/passcode at application-level provides a separate (master) password which would be used for all your passwords (in case your AppleID password gets compromised).
That already happens exactly as you mentioned.
You need a secondary encryption password for encrypted iCloud data as well. Having access to your Apple account isn't enough.
Apple finally provides a modicum variant of Zero Knowledge password.
But that is only available in next iOS version 16.2. [1]
But, but ... BUT the Apple macOS/iOS issue of Three Form of Authentication being still being reduced into Two-Form with their merge (OR-logic) of what you have (FaceID/TouchID) and what you know (PIN/passcode) ... remains.
That reduction of authentication is still the greatest weakest link to individual security (whether ADP is used after v16.2 or not).
The auto-typing feature is not the same as autofill. Rather, it literally emulates typing from the keyboard and is useful in contexts where autofill is not supported. I only ever use it on desktop, and it's a feature that PasswordWallet has had for more than a decade.
I've been using "pass" for years and love it. There is also a very nice iOS app that works well and is open source.
I synchronise my devices and backup directly without a central repo.
Its only flaw is gpg's poor UX...
There is a fork of pass called "passage" that uses Age for encryption instead: https://github.com/FiloSottile/passage Unfortunately I don't believe any iOS/Android apps exist to work with it so far.
pass is fine if you like gpg (why?) and the only machines where you need those passwords are Linux/macOS/*nix computers. There are ways to access it on Windows, Android, and iOS, but they are unbearably painful.
Passwordstore (pass) databases are just a git repo which makes great audit trails, but also gives it syncing for free rather than reinventing the wheel.
It uses PGP rather than rolling its own encryption, which also makes it compatible with hardware tokens, for free.
It's not some complicated project... it's just a thousand or so line shell script.
It's fine if all platforms where you want your passwords can run bash scripts, git and gpg. Linux and macOS can do it fine. Windows might, although it gets flaky. Android and iOS can’t, at least not in any human-friendly way.
Ooooooo, if the passwordstore has a bash autocomplete in which to navigate selections of its config file subdirectories, then the solution becomes incredibly robust.
I trust 1P cloud storage more with their well thought out security concept than Dropbox or self-hosted nextcloud. The 1P security whitepaper goes into great detail why their cloud concept is not at all comparable to just hosting the vault on block storage.
There are companies who are pulling in the rein with regard to its placement of sensitive data, encrypted at rest or not. That is, going cloud-less (or more accurately, privately-owned public cloud, and more often, private cloud)
The prevailing concern isn't insecurity of using public cloud by using zero
knowledge, but the containment/confinement of potential damage when an end user lose control of their password manager app (hacked, laptop-stolen or accidentally leaked) by having this delete feature at the self-hosted server. This is something that Netwirx PasswordSafe really excels at.
SOC 2, HIPAA, ISO 27001 and various military guidelines are a few reasons why.
And yes, apps should also password-protect and event-log the URL configuration field separately from the password used in database(s) as well ... from any change, accidentally or maliciously.
That is following inline with still-so Common Criteria guideline.
The problem is there’s no way to truely publish OSS on the iOS App Store (or Play store) you submit a binary to Apple and you can publish a repo to GitHub but AFAIK there’s no way to correlate that those two things are the same.
So unless you build the app from source yourself there could be anything in the binary.
This increases verifiability. Not security. And it's not the real issue.
On Linux, many apps are open-source yet users don't compile them themselves; they trust that their distro vets packages properly before making them available in official repositories.
In this situation, the problem isn't the lack of reproducible builds, but insufficient oversight by Apple that led to an untrustworthy package being made available in their "repository" (App Store).
Security is provided by the OS. A side loaded app has no more access to the device than an AppStore app.
I really don’t understand this argument. If there are security concerns with a side loaded app then the problem is with the operating system, not the app.
>I really don’t understand this argument. If there are security concerns with a side loaded app then the problem is with the operating system, not the app.
What on Earth are you talking about? The OS can provide certain boundaries in terms of "this software can do X and only X kinds of permissions" but short of a full general AI how would you expect it to tell between two pieces of software with user file access and network access permission, both of which accept banking credentials and allow you to see and manipulate your money but one of which doesn't also direct all your money elsewhere after awhile and the other does. For example. Or two password manager apps, both of which send encrypted data to a remote location, one of which does so with zero knowledge the other that has baked in a secondary key or subtle flaw in the encryption. Or a million other things.
What you're talking about is, at best, an 80s or 90s view on security where it's purely about one "user" messing with another or gaining root or that sort of thing. But we've long since passed the point where it's possible for users to suffer enormous harm purely within a constricted limited set of non-admin permissions that they have over only their data, which are needed merely to do general productive work with it at all. That's a much harder problem, and involves trust relationships with other humans and organizations. There are technical efforts that can make pieces of it better or more recoverable, but particularly given the need to interact with existing real world stuff even what can be done on that front is further limited.
Claiming all potential malicious software is just a "problem with the operating system" is kind of wild to see someone write apparently unironically in 2023. I mean, there are entire classes of software where "malicious" is going to come down pretty purely to consent for otherwise identical function. If someone accepts an advertising supported software experience and consents to their data being used in certain ways (on another system at that), that's not malicious, whereas the same thing stealthily snuck in would be. Or if their data is then used in ways that were contrary to what the software claimed, now what? How is the OS on their client supposed to police that? That's a relative power problem as well as a vetting one.
With verifiability although, a side loaded store gives better nerd-level verification ability that the vast majority of nerds wont even bother with, while a trusted app store gives more low skill masses verification higher success rates in a practical manner. Facebook is going to be facebook on the apple app store, not fake facebook, and by breaking the app store only world, your going to get a lot of old people and other vulnerable people be scammed more on their phones.
>your going to get a lot of old people and other vulnerable people be scammed more on their phones.
This hasn't happened on Android. The fears about evil apps and developers insisting on their own app stores are fabricated FUD by Apple. The simple truth is 99.9% of regular users will never install an app outside the official store. Most will never know it is even an option.
A good middle ground would be an equivalent to F-Droid, where the developer can only submit the source code and the code is either compiled by F-Droid, or it is verified as a reproducible build.
I think a good middle-ground would be having the default store have the functionality for verifiable builds like F-Droid. Add a banner/badge that the app you're looking at is open source, a red flag if it's closed source, a link to the release page in their code repository for that specific release, so that techie-people can verify the hashsum themselves and look at the code.
Of course, there's still plenty of possible supply-chain attacks and the like. Closed source app store, git repositories taken over or sneaking in malicious commits, binary blobs required to run your device, and so on. But we should encourage any progression in security, and turn good security practices into common sense.
It's possible that Apple's new Xcode Cloud service could support this at some point, providing a continuous pipeline from source to release. Though I doubt it is a high priority for them.
I’m not arguing that you shouldn’t allow side loading.
But let’s say this is what developers start doing. We compile our own code and side load. Great for us. How many people can each individual support? Immediate family and close friends? Are most people on their own? Now say your immediate contacts are compromised. That exposes some of your details as well would it not? At least you’d be more vulnerable to social engineering.
So maybe you have to work towards a system where everyone is safe.
But that point applies to binary distribution outside an app store as well. How can you know that the binary linked from a GitHub repository is built from the same source?
That model has been proven for cryptocurrency, hasn't it? As long as you have enough validators, you don't need everyone to spend the considerable resources it takes to validate (or in this case, build from source).
Right now the Apple model is "trust that the Apple employee who glanced at this for 15 minutes spotted any problems".
Ideally the source is readable, though reality falls short of that for most projects.
For example, I didn’t realize I liked C until Redis. Now I’ve found a handful of C programs that I’d put into the “readable by non-C devs” bucket, like i3 and the suckless collection.
Most build tools also are a disaster from the perspective of giving end users agency over their software. Automake, make, etc are often cryptic magic to non-practitioners. Like C, they can be made readable but most aren’t.
KISS Linux falls into this bucket of “grokable” as well, it’s minimal and the process of going from source to distribution is easy to understand. Many stock distributions are so complicated I don’t think the average tech-savvy human has any hope of truly understanding what their system is doing in a single lifetime.
That's why I prefer distro-built packages over upstream binaries wherever possible. It greatly reduces the number of build and distribution platforms that I have to trust.
With reproducible builds (and as long as the distribution doesn't need to maintain any patches vs. upstream), this could even provide the best of both worlds: Verifiable hashes (comparable with upstream and other distributions) and a smaller set of trusted entities.
On the other hand, I'm not sure I'd necessarily trust a small open-source distribution's maintainers more than a widely used password manager's developers; I think I'd prefer my root of trust to be whatever has more users (and by proxy, hopefully scrutiny).
Or source-based distros (and equivalently source-based distros with reproducible builds & a binary cache of build artifacts with a package manager that checks the resulting hash matches the expected value).
Of course source can still be compromised, say by malicious dependencies. But it's better than source and binaries being compromisable.
It'd be cool if you could submit a specific Github commit (or similar) and then have the app store build it and distribute it. Then the user only needs to trust Apple or Google to not be malicious, which they kinda already need to do if they're using both an OS and app store from them.
But then apple couldn't gouge every app developer for an additional 2k. Right now you must buy a Mac to have the privilege of building and uploading iOS apps.
The problem is that the App Store encrypts each binary to a device-specific key for DRM purposes, and it's not possible to disable that.
Additionally, how would you even calculate a binary hash of an iOS app? The filesystem is locked down.
I suppose the OS could provide a way to list binary hashes (either after DRM decryption or for non-DRM-ed binaries, if that ever becomes an option), which would be slightly better if you trust the OS more than the app store, which I personally do (it's much riskier to compromise all devices than to target a single device with modified app binaries).
BTW, the GitHub profile of the repository owner points to a sketchy website [0] which looks somewhat plausible from the first glance, but then more like a content stub on a closer inspection.
[0] www.unicomedv.de
Update: the reason I think it is more a content stub than a real thing is because there are no trial downloads available for theirs desktop products, and that's a red flag. Some site sections like "Office 365" represent a total nonsense with buttons leading nowhere. The pricing page has gray-on-black text elements, so looks clearly deoptimized for performing any real conversions. The whole site gives a strong fly-by-night vibe.
According to Northdata[0], the Managing Director has been part of the now-defunct "Black Diamond Suxess Club GmbH", which allegedly has been running a Ponzi scheme[1].
Also, if you look up the address, it's not an office complex. It's a residential area with single-family homes.
> Also, if you look up the address, it's not an office complex. It's a residential area with single-family homes.
I don't like considering this a signal. We want indie developers to flourish (a business name is little more than paperwork that anyone can get), and it's too easy for the nefarious to buy a "virtual office" in a legit-looking office building that is little more than a PO Box.
I was coming here to say the same thing. It's really amazing that they used their own domain name to receive the payload from this malware analytics code. Possibilities are (1) all of the people associated with this company are not real people (faked LinkedIn profiles and everything), (2) they are really, really dumb, or (3) it was a roque employee/contractor who saw an opportunity to set this up and skim some cream.
> there are no trial downloads available for theirs desktop products
They have a contact form and it's quite normal here in Germany that you have to contact the business first before you can download the business software.
All in all most normal small IT companies I know in my area have a similar looking website.
Which makes it more unserious is that one of the Managing Directors has done shady business in the past.
This is one of those cases where, regrettably, decentralization and open sourceness can play out not very well, to say the least.
Someone can make an API, a library, a file format, which is bona fide good, and for good purposes. They leave the implementation for platforms they don't care about to others, because why not? And then someone makes an app which looks totally legit, is open source even. You end up thinking that the fact it's open source is by itself enough clout to trust the app.
But the thing is, there's so much code in the repositories added every day that no one will be able to give it enough eyeballs so that all the shady bollocks it does are shallow. Malware authors don't even have to particularly hide the malicious bollocks away, or compile their published app from different sources. And if you chase them down, they rebrand, do SEO, and publish two new totes legit looking apps for each one you get to take down.
Centralized services like Bitwarden (LastPass left a bitter taste in my mouth) come with their own sets of problems, but at least they have a company behind them whose site can be verified as belonging to them and pointing to the correct version of their official client app.
>This is one of those cases where, regrettably, decentralization and open sourceness can play out not very well, to say the least.
I think this is one of the cases where the problems of decentralisations are exacerbated by the problems of centralisation.
It's hard enough to vet a github repository, but at least it can be done.
After funneling the code through an intransparent, centralised review process that claims to ensure "the highest standards for privacy, security and content" you can no longer verify anything.
> It's hard enough to vet a github repository, but at least it can be done.
It will, more often than not, fall victim to the bystander syndrome. Someone else will do it, right? Right?
Well, in fact, nobody will do it. Here's why: a KeePass client is already a niche piece of software; people who are aware of it and would like to use it on their iOS devices form a small subset of all KeePass users; of those, people who have actual chops to perform a review of source code, are an even smaller subset; of those, people having enough spare time and brain cycles to be bothered is a number very close to zero, or can be counted on a drunk carpenter's fingers. Those people will maybe carve time to look once they suspect something fishy is happening.
You're stating this in absolute terms but the reality is not black and white. If it was possible to review the code that actually gets deployed, then it would depend on a project's popularity how many people would be willing to take a look at the source code. I might do it myself if I relied on it for something like a password manager.
The intransparency introduced by the app store makes it impossible for anyone to look at the code. Any publisher of malware can be 100% certain that no one will look at their code. It's sort of the inverse of the chilling effect.
And when a suspicion arises there's no way of finding out the truth about what actually happened and you have no way of knowing what to protect against.
I'd stay away from any KeePass clients with network access. I don't have a recommendation for iOS, but for Android KeePassDX [0] seems like a good option as it has no network permission to begin with.
How do you attest this without simply trusting the dev or monitoring package data transferred by the app?[1] iOS, differently from Android, doesn’t have a explicit network permission that the user can verify.
All apps have network access by default and there’s nothing you can do about it without jailbreaking.
[1] as many pointed out: open source in iOS is a moot point as there’s no way to verify the binaries.
You’re misunderstanding me. On android you can see if the app have network permission. On iOS privacy report you can see if the app accessed the network.
There’s an important distinction. On the first instance the app can’t access the outside world. On the second you will just know that it did.
[Edit]
See the author of keepassium commenting on the same issue about a month ago:
Have been using it for 3-4 years now. Its integration with the Apple ecosystem is second to none. I do use an online version that syncs with iCloud so I can access it anywhere (but with a Yubikey).
How do you suggest keeping your database in sync between your desktop and mobile device? I use Keepass2Android and I'm 100% happy with it, because it has incredibly good Dropbox sync support. I don't think throwing out every single networked feature just because of one malicious app is a reasonable or proportionate response.
Besides, I'm sure some clever attackers could think long and hard and come up with plenty of covert exfiltration channels without even needing direct network access. For example, adding a "safety redirect" every time you open your web browser, like t.co does.
I would never use Keepass client on the mobile device. I have 0 trust to what developers have published there. If I need to type a password on mobile device, I will do it manually.
If you don't declare network access in the app manifest, your app cannot make a network connection. If you declare network access, app can make a network call and user confirmation is not required. It is thus very easy to check for apps that are truly offline.
Unfortunately neither iOS nor Android allow you to totally disable internet access on a per app basis. On Android side manufacturers like Xiaomi do allow it, but nothing built in for all. There is Netguard on Android atleast. I really think it should be possible to disable internet access on a per app basis.
Ironically enough, iPhones for the Chinese market allow you to disable an app's network access completely. Non-Chinese-market ones only allow disabling mobile data but not Wi-Fi.
If they already have the feature then it makes even less sense to not give it to everyone. Like I would switch my phone OS just if there was a simple way to disable internet access totally for apps.
I wouldn’t be surprised if the only reason this exists in China is because of some legal requirement or a requirement from local carriers. I’m sure Apple and the rest of the industry would rather not offer this as it would break many data collection and “engagement” strategies (you can disable network access for single-player games and not have any ads for example).
1password: since version 8, now dead for self-hosting due to "their"-cloud-only-now, not a standalone, and its downside usage of Electron web and its many unverified modules/libraries; remote storage of password only in encrypted form. Key stays offline.
vaultwarden: yet another Electron web app and its usage of many unverified modules/libraries; remote storage of password only in encrypted form. Key stays offline.
KeepassXC, with syncthing: leading contender, best-self-hosted solution that stores password remotely only in encrypted form. but still has iOS unverifiable source code imposed by Apple. Key stays offline. For Keepass usage on iOS/macOS platforms, consider a lifetime (one-fee) StrongBoxSafe app (Keepass-compatible) instead.
NordPass: best zero knowledge remote storage; has apps for Windows, macOS, Linux, Android, and iOS. Self-hosted. When it comes to browser extensions, one would be hard-pressed to find a wider selection. You can install NordPass on Chrome, Firefox, Safari, Opera, Brave, Vivaldi, and Edge. Not an open-source.
LassPass, hacked in 2022; remote storage of raw passwords
pwsafe, still is the safest CLI-only solution to date. The design of pwsafe (Password Safe CLI) got started by Bruce Schnier, the crypto security privacy expert. In pwsafe, unbroken TwoFish algorithm is still being used instead of the currently safer Argon2i, simply because it's faster (after millions of iterations; also AES is not immune to hard-memory FPGA brute-force like Argon2, yet both remain hard-CPU). The recommended client-wise of PasswordSafe is still Netwrix (formerly MATESO of Germany) PasswordSafe with YubiKey.
Only downside for ANY PasswordSafe-design GUI client is trusting yet another app repository and the compilation of "their copy of open source".
For any password manager, stay away from its web-client variants due to ease of memory access to JavaScript variable names (by OS, browser, JS engine, and JS language)
Too bad operating systems allow full internet access for applications that shouldn’t. Hopefully this security feature will one day be implemented in popular operating systems.
Tangentially related question: What is the [recommended|best|most used] iOS KeePass client? The KeePass site recommends MiniKeePass that's been archived for a couple of years already.
In retrospect, this seems like an obvious flaw in using third party clients for password management. The fact that KeePass is OSS is great, but it leads you to have to rely on these shady pieces of software to access your vault on non-officially supported platforms like iOS.
You wouldn’t have this problem if you used e.g. 1Password or Bitwarden. They have official iOS clients made by the same entity which you’ve already trusted with your secrets.
tl;dr Having to trust a third party KeePass client isn’t very smart and forces you to trust two (2) entities instead of one with your secrets. This is such a deal breaker that it might turn one off accessing their KeePass vault on iOS at all.
Exactly, as a user you need to be aware of this addition of risk. Anonymous OSS maintainers are the issue here. When I want to use a project and want to reduce the risk here, I need to vet the maintainers in a similar way I would vet a company I want to invest in.
I don't think there is a need to have someone's reputation score to use their software.
There are plenty of pieces of open source software running on operating systems that were contributed by people who are effectively anonymous.
Also, it doesn't seem like a contributor's overall character would be a great measure of how malicious their contriubtions are, as evidenced by plenty of examples of assumed good people eventually doing bad things.
I don’t understand why people believe that open source inherently makes software secure and trustable. Yes, you have access to look through the code, but I usually don’t have the expertise to understand what I’m looking at. I wouldn’t know how to look for well hidden exploits or malicious intent. I’m still reliant on others to find these issues.
At the moment, I do rely on reputation before I trust open source software. But in the case of an app store, I can trust the reputation of the store. I can trust that the app store has to work to uphold their reputation which is their motivation for maintaining a good track record of identifying problem apps. I agree this is far from perfect, but I think it’s much safer than relying on open source.
I love the idea of open source and I hope that it will never be replaced by app stores, but I don’t feel that software is inherently more trustworthy if it’s open source.
I like to distinguish "trustworthy" from "trustable". Trustworthy software is worthy of trust: it is not malicious or unacceptably buggy. Trustable software is software which can, in theory, be verified to be trustworthy. OSS is trustable, but not necessarily trustworthy. Closed-source software might be trustworthy, but it's not trustable (since trustworthiness can't be verified).
I believe it’s not necessary to fully verify a piece of software before it can be trusted. We humans are all black boxes, no one can read our minds, but we can trust each other through our reputations. I treat software the same way; as long as software comes from a reputable developer, I’ll give it the benefit of the doubt until proven otherwise.
Verified trustworthy is too high a standard to hold to software. Take for example Log4j, an open source logging library used by many enterprise Java apps worldwide, had a huge vulnerability existing in its code base for over 7 years. Even with its widespread use and open sourced code, the exploit was not reported in a timely fashion.
Thus I’m left with reputation as the only practical means of determining trust; imperfect as it may be.
Exactly, in fact the reddit post talks about this situation -- the code that sents sensitive information is right there on GitHub but nobody saw it before OP did. And what could happen is that the developers maintains two codebases, one "clean" version on github and a "dirty" version that is almost identical except the part where it secretly sends your password, and use that version to build an iOS app. How would you ever know that?
I mean, if you use 1Password on both linux and iOS, you now trust both the mobile and desktop teams at 1password. You trust two separate supply chains, one for the iOS app dependencies, one for the linux dependencies.
If you use bitwarden, you now trust the "bitwarden/mobile" and the "bitwarden/clients" repositories.
Both of those programs _also_ have separate applications with separate code for mobile and desktop, so for those you _also_ have to audit twice the code (well, not that you can audit 1password's code).
Anyway, if you're using any of these programs on desktop, you have to trust 100% of the programs you run as the same user as your password store client to not be reading memory to nab your database, so it's not like trusting one more program is that big a deal. I'm not even sure if I'm being sarcastic or not.
> Two programs running under same user can’t by default read each other’s memory.
'gdb -p $pid' works fine for me on linux as a non-root user for another pid of the same user, and that sure lets me read all memory. I think /proc/$pid/mem works fine too, right?
'ReadProcessMemory' works fine as an unprivileged user on windows I _thought_, at least I know it did last time I used it. That was years ago.
No clue about macOS.
I assume most people on hacker news are using linux though, so that's the one that's relevant.
On Linux you can prevent being ptrace'd or having your core dumped by setting PR_SET_DUMPABLE in prctl. I've seen this used in places you'd expect like ssh-agent and GNOME's Keyring password manager.
> 'gdb -p $pid' works fine for me on linux as a non-root user for another pid of the same user
I believe this requires `kernel.yama.ptrace_scope` to be set to 0, which is not the default in most distros? Or gdb to be granted specific capability, which I don't think is done by default either.
What distribution is that on? At least Ubuntu has had ptrace capabilities restricted to superuser processes and descendants for many years now, as far as I can remember.
/proc/$pid/mem access needs ptrace permissions as well and accordingly follows the same rules.
That's just fearmongering. By that logic you can never use any closed source product. How would people trust an Outlook client won't leak your emails, or iOS/Android/Windows/MacOS isn't sharing your personal information and other communication?
One such incident doesn't eradicate Apple's argument. By that logic one bad sideloading incident would undermine the logic that sideloading can be safe.
Just my 2c. I don't trust any cloud keypasses myself, and you shouldn't either. The way I been doing this is having a regular text file with all my passwords that is then encrypted by veracrypt and encrypted file container is then hosted in a pCloud. I used to do it with DropBox until one time their new version stopped doing bit-by-bit comparison, something pCloud does.
If the intention here was really to steal passwords, it could also be deniability?
Uploading sensitive stuff to logging and/or analytics packages or third party providers is a surprisingly easy mistake to make – which in turn makes it an excellent avenue for plausible deniability.
It can be really hard to tell which one it was without inside information or a detailed investigation.
Wait. I just thought iOS App Store has manual review process with human? And it gains reputation by kill all suspicious applications before published to App Store?
Nothing in security catches "all" things. A review process with a human may be good but it's far from turning humans into infallible detectors. The reputation gained by the App Store is by catching many such apps before they are published, not every single one.
next time, actually link the app in your github post to call them out rather than making an entirely cryptic post with names that can be easily changed and swapped around.
incredible security warning "hey this app that had its name changed may have been compromised". very established message that warns the other users that could have it. go search through the comments and hope its there instead!
> To my surprise the app I was using to read my KeePass database, iOSKeePass, was missing from App Store. It was deleted and I only owned a local copy.
What exactly would they link to? A dead App Store listing?
I feel your pain! So much that I built my own Local Password Manager -> Pocket Pass Manager [You get it? Pocket ≠ Cloud eh eh eh].
When LastPass moved from a free to a paid business model (paid-or-f%$k-you with users locked-in), I decided to build a password manager for myself, friends and family. I knew that password managers like One Password used only open source libraries for encryption, which made it seem simple to create a similar app, but improving the user interface and overall experience (I'm a sucker for great UIs).
This was before all LastPass fuck-ups, I (correctly) thought vault syncing was a bad idea, thus I took the local approach.
Building a local password manager has several advantages. Firstly, it avoids the risks involved in sending passwords over the internet. Secondly, there is no need for servers, meaning there are no fixed costs, forcing me to implement a subscription model. Lastly, users can be assured their passwords are secure, as they know where their passwords are at all times; for instance, you can check the app doesn't make any internet connections, and the encrypted sqlite database can be downloaded and audited.
Admittedly, I understand that other local password managers exist, but building my own was a fun personal project, developed to my satisfaction.
[I built this thing in pure Swift exclusively for iOS, as is what I used daily at Reliby (my startup-ish), and I wanted to try a 100% SwiftUI approach]
Before getting to code, one problem needed more thought: how to access the passwords from other devices? Macs have a shared clipboard, but I used Windows half of the time, I needed to find a way without compromising the security nor the locality. Inspired by Snapdrop and VLC's local upload, I came up with the idea of making the iPhone behave as a local web server, enabling users to access their keys on other devices on the same network (local network).
The first implementation, V1, used SSL (HTTPS) to encrypt the passwords payload, but the certificate couldn't be trusted, and some web browsers didn't accept it. Hence, I had to install the certificate on my computers, which ultimately became frustrating. However, this approach proved the concept could work. I ditched LastPass in just a couple of weeks!
For the second version (current is 2.3.0), I rewrote most of the code, focusing on creating a new web server approach that runs over unencrypted HTTP. The password payload is then encrypted with 256-bit AES using another key randomly generated on the explorer (client) that is transmitted to the phone by scanning a QR code. This approach ensures that even if someone is "listening" on the local network, they cannot obtain the key. What's more, users have a physical confirmation of the computer they were sharing the key with. Even if someone accessed the user's phone server, nothing would be transmitted without scanning the code. How cool is that?
Using the Pocket Pass Manager app, which is available in the App Store, users press "Share on the phone," access "jorges-iPhone.local," scan the QR code, and passwords (and other data) appear like magic on their other device.
The app also includes a built-in authenticator, credit cards, notes, offline security analysis of passwords, CSV import, and custom backups.
There is in-app purchase ($4) for adding over 20 passwords. However, those who cannot or do not want to pay can join the beta channel, where unlimited access is granted. Feedback is appreciated, but you should do backups as the app could experience bugs.
I cannot believe that my app's UI looks better than LastPass, which has millions of expenditure.
Glad I saw this. I have this installed on my phone too, though I thankfully possibly never used it? I mostly only ever use FF password manager these days and I haven’t updated any keepass entries for 2 years.
Going to change all my keepass saved passwords regardless
1password: since version 8, dead due to cloud-only-now, not standalone, its over-usage of Electron web and its many unverified modules/libraries; remote storage of password only in encrypted form. Key stays offline.
vaultwarden: yet another Electron web app and its usage of many unverified modules/libraries; remote storage of password only in encrypted form. Key stays offline.
KeepassXC, with syncthing: leading contender, best-self-hosted solution that stores password remotely only in encrypted form. but still has iOS unverifiable source code imposed by Apple. Key stays offline.
NordPass: best zero knowledge remote storage; has apps for Windows, macOS, Linux, Android, and iOS. When it comes to browser extensions, one would be hard-pressed to find a wider selection. You can install NordPass on Chrome, Firefox, Safari, Opera, Brave, Vivaldi, and Edge. Not open-source.
LassPass, hacked in 2022; remote storage of raw passwords
pwsafe, still is the safest CLI-only solution to date. The design of pwsafe (Password Safe CLI) got started by Bruce Schnier, the crypto security privacy expert. In pwsafe, unbroken TwoFish algorithm is still being used instead of currently safer Argon2i, simply because it's faster (after millions of iterations). The recommended client-wise of PasswordSafe is still Netwrix (formerly MATESO of Germany) PasswordSafe with YubiKey but stay away from its web-client variants due to ease of memory access to JavaScript variable names (by OS, browser, JS engine, and JS language)
Only downside for ANY PasswordSafe-design GUI client is trusting yet another app repository source.