Suspicious iOS KeePass Client
old.reddit.com
old.reddit.com
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.
- fully native apps
- open source
- fully offline option (Strongbox Zero)
- one time purchase
- solid browser extensions for Chrome and Firefox
- native keychain autofill for Safari and Orion
- compatible with other KeePass apps on other platforms
- multiple sync options iCloud, G Drive, Dropbox, OneDrive, SFTP, WebDav, Syncthing
- support for offline vaults
- 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.
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.
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.
Alternatively you can use Altstore [0] and avoid paying for an Apple Developer subscription.
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?
> still missing from the free version
The obvious solution is to pay. Any reason you are opposed to this?
But for others, it should be a caveat that you would not get the full security provided by Strongbox Zero or Strongbox Pro.
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?
In short, make the leap before you really safely try it out?
I can only see a monthly or yearly subscription option?
Strongbox Pro - upfront one time purchase https://apps.apple.com/us/app/strongbox-pro-lifetime/id14818...
Strongbox - same as Strongbox Pro offers free trial and subscription https://apps.apple.com/us/app/strongbox-password-manager/id8...
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?
https://www.reddit.com/r/KeePass/comments/k511o6/comment/ged...
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.
Salsa is a stream cipher.
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
Or you can Google "electron web vulnerabilities" and find out quicker.
https://www.passwordwallet.com/
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:
While password auto-type is also found in Android, its security model is not quite a firm Bell-LaPadula yet like those implemented in Apple iOS/MacOS.
Exposing API to monitoring keystrokes remains problematic for any OSes.
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.
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:
1. "what you know (memory rote)" with
2. "what you have (biometric)".
https://www.cs.cornell.edu/courses/cs513/2005fa/NNLauthPeopl...
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.
https://support.apple.com/en-ph/HT202303#:~:text=Apple%20wil...
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).
https://support.apple.com/en-ph/HT202303#:~:text=Apple%20wil...
Your selection of password manager is going to be invariably dictated by how many different platforms you need to sync up your password manager with.
And those maintainers of their own password manager are in an arms race.
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.
I haven't seen a website this aggresive if you dare to open it in uBo in quite some time. Scroll down one screen and it constantly reloads.
I'll stay with 1p.
What do you mean by this? That Electron itself uses unverified modules/libraries, or that 1Password is? And do you have any citations for this?
1Password stop doing that and makes you use only their own cloud infrastructure.
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.
That is following inline with still-so Common Criteria guideline.
edit: It was recently renamed from bitwarden_rs which I was familiar with.
But I suspect you would be a contractor and probably would not be able to.
:-)
So Chrome, Firefox, Safari, Chrome, Chrome, Chrome, and Chrome?
AFAICT, There is nothing Chrome about Edge.
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).
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.
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.
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.
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.
Or you can build from source and confirm on your own.
Is the expectation that only a few users (watchdogs) do this and everyone else benefits from the extra validation?
Right now the Apple model is "trust that the Apple employee who glanced at this for 15 minutes spotted any problems".
I don’t think any distribution mechanism will solve the “how can I trust these bytes I got from the internet” problem.
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.
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).
Of course source can still be compromised, say by malicious dependencies. But it's better than source and binaries being compromisable.
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).
[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.
Also, if you look up the address, it's not an office complex. It's a residential area with single-family homes.
[0]: https://www.northdata.com/M%C3%BCller,+Montgomery,+K%C3%B6ln...
[1]: https://www.bekm.us/black-diamond-suxess-club-gmbh-mario-ore...
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.
And I bet there are no Wozniaks in that garage.
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.
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.
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 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.
Here’s the AppStore link: https://apps.apple.com/us/app/keepassmini/id6446373282
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.
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:
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
There is another option - buy an iPhone in China:
iOS: Disable WiFi (not just cellular) for specific apps without jailbreaking https://tinyapps.org/blog/202209100700_ios-disable-wifi-per-...
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).
https://play.google.com/store/apps/details?id=keepass2androi...
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.
It's still not 100% secure, but you would need both a compromised Keepass app and a compromised Dropbox app.
Almost all apps make outside connections and it would make no sense to prompt the user for that.
password managers, self-hosted (revision 2)
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)
I currently sync my vault via WebDAV and they even support storing the local keyfile.
It's also open-source under AGPL, though iOS doesn't have anything like F-Droid to verify builds.
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.
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.
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.
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.
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.
'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.
I'd wager a beer that MacOS is the dominant OS. Followed by Windows. Followed by Linux.
Ctrl-f for 'PR_SET_DUMPABLE' in the manpages:
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.
/proc/$pid/mem access needs ptrace permissions as well and accordingly follows the same rules.
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.
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!
What exactly would they link to? A dead App Store listing?
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.
Here are the links if you want to try it out, I hope you like it. - AppStore: https://apps.apple.com/us/app/pocket-pass-manager/id15638393... - TestFlight (beta/free): https://testflight.apple.com/join/NeYmSS4B
Feedback is much appreciated.
Going to change all my keepass saved passwords regardless