1Password Refugee’s Guide to KeePass

Introduction

Passwords are the gateway to our digital identities. I have been relying on 1Password to manage my passwords in local vaults for a few years. But as you may know from the recent news, the company is moving in a controversal direction, which I do not support. You can find more discussion on this topic in the links ¹, ². As a 1Password refugee, I have been on the quest of finding a reliable and trustworthy alternative since then.

I will talk about the reasoning behind my choice, the migration process, choices of client apps on both desktop and mobile, and the setup of one-time passwords.

As a disclaimer, I am in no way affiliated with any software or developer mentioned in this article.

KeePass

I have examined many alternative systems, including BitWarden, Secrets, and Enpass. But in the end I settled on KeePass, which is a free and open source password manager operating on its open standard database format, kdbx. The are several reasons for this choice.

• Firstly, I will not be locked-in by the original software itself. There exist many excellent clients across all platforms that read and write the same database format. If one of them is going in a direction I dislike, I can always switch apps while keeping the same database.
• Secondly, the open source nature means the code and standard can be freely reviewed. There have been many independent audits for KeePass, making it more trustworthy than a typical proprietary software.
• Lastly, the database is a single encrypted document ending in .kdbx, which can be stored anywhere. I can choose to sync it via any standard cloud storage, without needing to subscribe to any additional services, nor setting up my own server.

Migration

The migration process from 1Password to KeePass is not exactly straightforward. It has to be done on a desktop computer, as 1Password only exports data from their desktop clients. It also seems that 1Password does not want you to export your data too easily. Their support article guides to export to 1pif format or plain text csv format, both of which are less than ideal. The 1pif format is not documented well ³, while the csv requires extensive manual calibration to properly transfer all data. So the best solution is to import from the 1Password local vault format opvault directly.

This requires an extra step for 1Password account users, because their data is not stored in opvault. To obtain the local opvault database, one needs to create a local vault and copy all items in the 1Password account to the new local vault. This requires enabling “Allow creation of vaults outside of 1Password accounts” in the 1Password settings, and sync it to a local folder to expose the database.

Once the opvault database is prepared and located, the conversion to kdbx format of KeePass can be done the most easily by using the KeePassXC client, which is a modernised port of the original KeePass. The import option “1Password Vault” in KeePassXC directly opens the opvault database and converts it to kdbx. Although KeePass can also import it with the help of the OneVault plug-in.

Now all data should have been migrated from 1Password to the kdbx database. You can choose to store it anywhere, or sync it with any cloud storage. But as a pre-caution, you should still keep the 1Password database in the rare case of data loss during conversion.

Clients

Desktop

The best desktop client is probably KeePassXC, which runs natively across Windows, macOS, and Linux. It supports time-based one-time password (TOTP), and integrates with browsers (Chromium, Firefox) out of the box. The original KeePass client only runs natively on Windows, requiring extra setup to run on macOS and Linux. But it is more extensible with plug-ins. For most use cases, I would recommend KeePassXC over KeePass.

iOS/iPadOS

There are two actively maintained KeePass apps on iOS, namely KeePassium by Andrei Popleteev, and Strongbox by Mark McGuill. Both are commercial apps in the App store, but with a dual GPL license as open source projects. They both offer a generous free version, and a more convenient premium version that can be accessed with either a subscription or a one-off license. KeePassium also offers a so-called “perpetual fallback license” for annual subscribers, which means those who subscribe for more a year get to keep access to all previous premium features, forever. Roughly speaking, KeePassium is more minimalist and polished; while Strongbox has more features and options, e.g., checking compromised passwords with “haveibeenpwned.com” (HIBP), fetching favicons automatically.

One major difference is that KeePassium is a completely offline app without any networking code ⁴, while Strongbox directly connects to the internet to integrate with Dropbox, Google Drive, and haveibeenpwned. These convinient features in Strongbox do come with some risks. It is more secure if the app that can read my secret cannot communicate with the internet. While I use and like both of them, I prefer KeePassium slightly for the above reasons.

Android

Although I am not an avid user of Android anymore, a quick search shows that there is no shortage of good KeePass apps on Android, like KeePassDX.

One-Time Password

One-time password requires a bit more attention in KeePass. The standard practice is to create two additional attributes: “TOTP Seed”, and “TOTP Settings”. The “TOTP Seed” field holds the secret key, while the “TOTP Settings” field usually holds “30;6” which means “generating 6 digits every 30 seconds”.

As a bonus, this can also be used to generate TOTP for Steam, by filling in the Steam Authenticator key in “TOTP Seed”, and “30;S” in “TOTP Settings”. It is a little tricky to get the secret key. But with some patience and caution, this can be obtained following ⁵ using the Steam Desktop Autheticator, which is an open source port of the Steam Mobile Authenticator running on Windows. When the encryption passphrase is set to empty, the secret key can be found in the .maFile as the string following otpauth://totp/Steam:<username>?secret= before the next & symbol.

Conclusion

It is sad to see 1Password to become increasingly more money-driven and customer-hostile. But fortunately, there are excellent open source alternatives like KeePass and BitWarden. So far I have been very satisfied with my adoption of KeePass.

In terms of features, KeePass has both advantages and disadvantages compared to 1Password. For example, KeePass supports additional security with key file, and hardware authentication like YubiKey. There is also attachment support on the mobile KeePass apps. But the lack of group sharing features in KeePass might be a dealbreaker for some, in which case BitWarden should be considered instead.

As a lesson learnt, I shall always try to keep important long-term data in some open standard format.

---

1. https://talk.macpowerusers.com/t/1password-8-will-be-electron-subscription-only-and-no-longer-support-local-vaults/24661 ↩︎
2. https://news.ycombinator.com/item?id=28145247 ↩︎
3. https://github.com/juanii/OneVault#pros ↩︎
4. Strongbox has released a networking-free version, Strongbox Zero, since this article was published. ↩︎
5. https://github.com/SteamTimeIdler/stidler/wiki/Getting-your-%27shared_secret%27-code-for-use-with-Auto-Restarter-on-Mobile-Authentication ↩︎

Build a Firewall to Protect our Privacy on iOS/iPadOS

Updated on 29 Aug 2021

Introduction

In the recent years, privacy invasion has become one of the most heated topics in the digital era. The online advertisers are trying their very best to gather our private information, build our profiles, and track us across the internet for targeted ad delivery.

With the introduction of App Tracking Transparency in iOS/iPadOS 14.5, we have gained the ability to reject the collection of our IDFAs, which are the device identifiers for advertisers. This is a big step forward to protect our privacy.

However, this identifier is far from the only information collected by the advertisers. I know everyone is slamming on Facebook on this. But it is well deserved so let’s join the crowd. Here is the list of data collected by Facebook as shown on the Privacy Label in the App Store:

• Purchases
• Financial Info
• Contact Info
• Contacts
• User Content
• Search History
• Browsing History
• Identifiers
• Usage Data
• Diagnostics
• Other Data

The more concerning issue is that not only the Facebook app itself collects these data, a massive amount of other apps also collect them by implementing the Facebook Platform SDK. The only piece of information we can deny access to on iOS is just one of the identifiers, namely the IDFA.

Traditionally, firewalls are one of the weapons we have to fend ourselves against non-consensual tracking, by denying internet connection to a list of servers belonging to the trackers. However, iOS does not have a built-in firewall. So we need to use some third-party solutions. The app of focus today is Surge [1], which is marketed as an advanced networking toolbox.

I’ll outline how to set up the app as a system wide local firewall in the next section, followed by a brief guide on how to enable DNS over HTTPS.

Firewall

In this section, we’ll set up Surge to block all traffic to a list of IP addresses of known trackers. We’ll use the Steven Black’s Unified Hosts as an example list. But it can be customised to include any address. We’ll walk this whole process once so you understand what is going on.

First, we need to obtain the hosts and convert in into the required format. After downloading it, open it in a regular-expression-capable text editor, say Textastic. We only need the list of IP addresses that we want to block. So we remove the 0.0.0.0 at the beginning of each line, as well as the section of local hosts. This can be done in a single step by using the following regular expression


^(?!#|0\.0\.0\.0\s(?!0\.0\.0\.0)).*|^0\.0\.0\.0\s


to replace the matches with an empty string. Then we save the file as hosts.txt. If this is not something you are comfortable with, I also have the resulting hosts.txt available on GitHub. I’ll try to update it regularly but obviously it won’t be as up-to-date as the original.

The next step is to load this list into the configuration of Surge. First copy the hosts.txt into the profile folder Surge, which is located in “Under My iPhone/iPad” by default. If you have set “Profile Sync” with iCloud Drive in Surge, then obviously this folder is located under “iCloud Drive”. Now we have the block list in place. We just need to add a single line in the configuration file, which can be accessed by tapping the profile name on the top-left in Surge followed by “Edit in Text Mode”. Here we paste the rule


DOMAIN-SET,hosts.txt,REJECT


immediately before the line FINAL,DIRECT. This line basically tells Surge that hosts.txt is a set of domains to reject their connections.

In case you don’t want to go through this process, you can directly add the following rule to the configuration profile instead


DOMAIN-SET,https://raw.githubusercontent.com/Taxyovio/Surge-Firewall/main/hosts.txt,REJECT


which will be kept up to date automatically by Surge. You can also skip editing the profile altogether by directly “Download Profile from URL” in Surge from github.com/Taxyovio/Surge-Firewall/raw/main/Firewall.conf.

In addition to blocking specific domains, Surge can also block traffic from certain apps by matching user agents. For example, the rule


USER-AGENT,Instagram*,REJECT


will reject all traffic from Instagram [2]

Finally we want to start up this firewall. First select “Rule-Based Proxy” in the “Outbound Mode” so Surge will process the rule we just added. Next tap on “SETUP” and follow the instructions to set up a local VPN. Now the firewall should be working to reject connections to those trackers and advertisers. A quick test is to visit “amazon.com” and see that fls-na.amazon.com is rejected under “Recent Requests”. In addition to trackers, the firewall will also block most ads served in apps.

We can set up Surge to automatically start after device reboots. This setting can be accessed in Surge under “More – Always On – Turn on Surge Automatically”. You can also hide the “VPN” label on the status bar by turning on “Hide VPN Icon”, although this may cause errors when there’s a shortage of RAM.

DNS over HTTPS

Besides rejecting connections to certain domains, Surge has a lot of advanced features to offer, which are far beyond the scope of this article. But one of them I would like to include is the capability to run DNS over HTTPS (DoH), which is an encrypted protocol to resolve Domain Name System. It adds another layer of security and privacy for web browsing, by preventing DNS queries being eavesdropped or manipulated.

This can be configured by tapping the “DNS Servers” button on the “DNS” card in Surge. You just need to fill in the DoH URL in the “DNS-OVER-HTTPS” section, say https://1.1.1.1/dns-query provided by Cloudflare or https://dns.quad9.net/dns-query by Quad9.

MitM

Surge also has the capability to descrypt and intercept https traffic, by doing a so-called “man-in-the-middle” (MitM), on your own network, from your own device. This can be used to block persistent in-app ads, which usually cannot be blocked without a jailbreak.

For example, the following steps enable ad-blocking for YouTube videos:

• Enable “MitM” in Surge and follow the instructions to install a certificate. (Do not share the certificate with anyone, unless you know what you are doing.)
• Add youtube.com and googlevideo.com under the “Hostname” section in the “MitM” card. Surge only performs “MitM” attacks on the hostnames listed here.
• Download YouTube.sgmodule and YouTube.js from my repository to the Surge configuration folder.
• Tap on “Modules” on the “Module” card and add YouTube.sgmodule as “New Local Module”. A module is basically an isolated configuration in addition to the main conf file, which can be easily turned on and off.
• Turn on “Scripting” in Surge, which enables the YouTube.js file as subsection of the module. This step can be skipped. But I find the blockign more reliable when it is on.

Conclusion

Setting up Firewall and DoH drastically improves the security and privacy of surfing the modern web with an iOS device. I am aware that there exist partial alternatives like AdGuard Pro and 1Blocker, which are primarily Safari Content Blockers. There’re also some VPN services bundling a firewall into their app, like Lockdown. But Surge is the best, dedicated tool for this task in terms of both flexibility and performance. The pricing is quite steep on the first sight. But considering its feature set and one-off license nature, it is well worth the cost.

---

1. This article is written in the context of Surge 4.7.0.  ↩
2. For more rule types, please consult the user manual.  ↩

Short Review of Privacy Policies of Spark Mail

I really wanted to use the iOS email client by Readdle. But recently I became more privacy aware. So I did some research on their Privacy Policy, which is quite concerning. The relevant parts are quoted here in the following three paragraphs.

(1) Spark Application (the “App”) and Spark for Teams Service (the “Service”) are brought to you by Readdle, Inc. (the “Data Controller” of your personal data). Consequently, “We”, “Us” and “Ours” refers to the Data Controller.

(2) OAuth login or mail server credentials: Spark requires your credentials to log into your mail system in order to receive, search, compose and send email messages and other communication. Without such access, our Product won’t be able to provide you with the necessary communication experience. In order for you to take full advantage of additional App and Service features, such as “send later”, “sync between devices” and where allowed by Apple – “push notifications” we use Spark Services. Without using these services, none of the features mentioned above will function.

(3) Email content while using Spark Services: We allow you and your colleagues to create teams within the Service. It allows you to have a secure space where you share information such as email conversations, shared email drafts, have private discussions, or create links to specific emails. This information is stored on our secure servers in order to make Services available to you, so you can collaborate with your teammates around email.

The technical terms are defined in (1). The ‘bad guy’ here is the so-called Spark Services, which is not even explicitly defined anywhere. We can see that the email content while using Spark Services is stored on their server from (3). From the first sight, we might mistake Spark Services with Team Services due to the wording in (3). However, Spark Services are always used regardless if we use the team features, as indicated in (2).

To summarise these concerning paragraphs, our email account credentials and email contents are always stored on their server for some features to function, even if we do not opt into these features, such as Team Services and Push Notifications.

In the official blog post by their co-founder Alex Tyagulsky, they promised to give users the option to not storing account credentials on their servers, as quoted below:

Some people raised a question about why do we store access tokens even if you have decided not to use Push Notifications. It’s a valid question and, in the next update of Spark, we will change this behaviour. Spark will not send your account information to our servers if you decide to not use Push Notifications when adding your account for the first time. Please note that this will disable other server side features as well. Also, if you enabled Push Notification on first launch, we will transfer the information needed to access your account to our server. To delete it, you can either disable “Allow Notifications” switch in Spark Settings or delete Spark from your iPhone.

However, since they introduced Team Services in Spark 2.0, there has been no such option anywhere. Spark just silently upload all credentials to their servers without any ‘explicit consent’ and without opting into Team Services. The real update in 2.0 was to enforce the data exploitation. This issue was also discussed in a blog post last year.

In my opinion, if not for privacy concerns, Spark is probably one of the best third-party email clients on iOS, along with Canary and Airmail. But both of Canary and Airmail offer fetch notifications to not store credentials on servers. Spark should also offer similar option as a premium feature. Users should have the choice to pay with “private data” or just money.