Since launching Secrets 6 months ago we knew we had to offer some type of trial for prospective users, and understandably this was often requested. At the time our priority was to release our Minimum Viable Product (MVP).
For the past 6 months we have been squashing bugs, implementing features that didn’t make our MVP and applying polish throughout. At the same time, we’ve been studying various options to provide some sort of trials for users wanting to test Secrets before buying.
Finally, we’ve settled on a simple Freemium model. You can download both Secrets for Mac and iOS for free and use all features with up to 10 items. That’s it. To remove the 10 item limit you just need to make a one-time in-app purchase.
To mark this change in the business model we’re bumping Secrets version to 2.0.
If you’re an existing user you won’t have to purchase anything else… obviously. And by the way thank you for your business! 🙂
If you’re not an existing user, now is the time. Download Secrets for Mac and iOS today.
When developing Secrets we purposely avoided using browser extensions to do login filling on websites. The reasons are manyfold:
our users should not have have to type their passphrase anywhere except on the Secrets application (specially not in the browser);
only the Secrets application should handle your data and should always serve as gateway for it;
establishing communication between the browser extension and Secrets also presented some security concerns;
users would have to manually install the extension.
As such we used a much simpler and safer approach. We used Apple Events to communicate with both Safari and Chrome directly from Secrets, bypassing the need for a browser extension and all the issues that come with it.
So, what changed?
Just a few weeks after we launched Apple released macOS 10.11.5 and with it they disabled our integration by default. Our users had to manually enable a setting in Safari to bring back the functionality… Also, our Apple Events-based solution prevented us from filling logins on websites contained inside iframes, such as www.icloud.com.
To solve 1. and 2. we developed a very simple extension that tries to mimic our old behavior. Succinctly, the extension just announces to Secrets if there are login forms available to fill and checks if it should fill any of them. All the heavy lifting is still done on the main application just like before. This also meant that the logging in flow would stay the same for all existing users.
Finally, the extension enabled us to access the dreaded iframes we couldn’t access before. So filling in www.icloud.com works now!
So go ahead and update and let us know if you run into any issues.
One important feature that got left out of our initial release was the ability to generate one-time passwords.
A one-time password (OTP) is a password valid for a single use against some sort of authentication mechanism. Nowadays, the most common of these are time-based one-time passwords (TOTP) that are usually a string of numeric characters valid as an authentication token for a brief period of time (usually 30 seconds).
Companies such as Apple, Google, Facebook and Dropbox employ TOTPs as the second factor in the now popular two-factor authentication (2FA). This provides an extra layer of security in case your password gets compromised.
With version 1.2.0 now available on both the Mac and iOS App Stores, you can enable 2FA in the aforementioned sites and generate authentication codes using Secrets on your Mac or Secrets Touch on your iOS device. For many other services that support 2FA head to twofactorauth.org for a handy searchable database.
This new version also includes many bug fixes and enhancements, so please update even if you’re not planing on using one-time passwords.
When choosing a password manager it’s expected that one of the main concerns relates to information security. Keeping your information secure takes many forms but the most notable is how your data is stored on disk. Namely, how is it encrypted and protected.
Cryptography is hard… we know. Although the concepts behind different encryption strategies and integrity protection algorithms are easy to understand, putting it all together can easily introduce vulnerabilities. This is why we decided to use the most recent version of the open and battle proven standard called OpenPGP.
OpenPGP defines how data should be stored. It builds on top of the familiar encryption building blocks like AES and the SHA family. It’s been around for many years and has been widely used – from securing e-mail to authenticating a developer’s contributions to a source code repository. And of course, it has also seen some revisions along the way.
We understand OpenPGP is a pretty complex standard. It covers symmetric and asymmetric cryptography (supported by different algorithms), authentication and integrity protection, key storage… and having different revisions makes for an even more complex implementation. So why choose it versus some other simpler standard?
Here is the rationale behind the decision:
Although complex it is also very flexible. It will allow us to evolve Secrets with new features while still using a familiar and tested format.
It’s been tested and used by many, giving us confidence on the security it provides.
There are open third-party tools that can read it, providing an easy way for our users to verify our claims.
The remainder of this post will elaborate on that last point. Explaining how Secrets stores its data and how you can verify it for yourself. This is going to get a bit technical so if you’re not into that here’s the gist of it:
Secrets uses OpenPGP format with AES-128 for symmetric encryption, RSA for asymmetric encryption and signatures, and SHA-256 as the hashing algorithm.
Secret’s on disk file format is actually composed of many different components bundled together in what’s called a “file package”.
A file package perceived by the user as a single file but it’s actually a directory containing files and possibly other directories.
├── index ①
├── keys ②
├── master ③
└── store ④
Each item the user saves in the store file contains an identifier. The index file maps words used on those items to the respective identifiers. This is then used to perform fuzzy searching.
It’s encrypted and signed according to the OpenPGP format. The symmetric-key, also called a session key, is generated at the time of writing. This symmetric-key is used to drive an AES-128 cipher in CFB mode encrypting this file’s payload. The session key is encrypted with the RSA encryption public-key present in the master file. Finally the file is signed with the signature private-key present in the master file.
This can be verified using the pgpdump tool as follows:
The keys, also called a keyring, stores a series of OpenPGP public keys that the user has trusted. This is reserved for future features and is currently not in use.
Contains the RSA key pairs for this file package. It consists of three RSA key pairs: a 4096 bit RSA master key, and two 2048 bit sub-keys for encrypting and signing. All private keys are encrypted with an encryption key based on the master passphrase the user has chosen. An iterated and salted key derivation method is used. This method is documented in the OpenPGP specification.
This file can be verified with the pgpdump tool as follows:
This is where all user data is stored. It’s actually a TAR file composed of two files: metadata and objects. The metadata file is in plain text and contains information such as the store id and model version. The objects file is encrypted and signed in the same fashion as the index file described above.
The metadata file is an NSKeyedArchiver file and can be extracted with the PlistExplorer tool:
The objects file can be verified as with the pgpdump tool as follows:
We do our best to use proven and open standards everywhere we can. Although complex, OpenPGP is flexible enough to be used in many different scenarios and it will serve as the foundation for many new features we have planed. Stay tuned!