This is a quick post about STRIP, our password manager, and how you can use it to make life a little easier. Say you have a Foo Web Services account and you run virtual machine instances there—you'd typically store three pieces of information in STRIP so that you can log into the console and access your instances:

• username
• password
• web browser console login URL

Thus when you need to log in, you can just pull up STRIP, start typing the record name, quickly copy the password and then double click on the URL to launch it in your browser to get going:

Okay, nothing new there, right? But maybe the reason you're logging in to the Foo Web Services console is because you need to get the DNS names for your virtual machine instances so you can log in to one or more of those servers via SSH. Now it's a nuisance, now you have to copy each URL out of the web interface and into your Terminal.

But STRIP can take care of this for you, cutting out the step to your web console, by using URL fields. Let's create a new label just to make clear what's going on here by going to the File menu and selecting Customize Labels, which produces a sheet showing all your labels in STRIP:

Create a new label, name it SSH for now, and set the Mode to "url," then click Done to dismiss the Customize Labels sheet.

In our Foo Web Services record we'll add a new field for each of our virtual machine instances, setting the label to SSH for each. If we use the SSH URL connection string format in the field itself, ssh://user:password@hostname:port, we'll be able to double-click these fields to launch SSH connections in Terminal (or the preferred SSH app/client on your computer/device). In the following screen, I've added two such SSH urls:

• ssh://frank@ec2-not-a-real-node1.compute-0.fws.example.com
• ssh://frank@ec2-not-a-real-node2.compute-0.fws.example.com

Now when I double-click these fields on the record in STRIP my operating system offers to launch to launch Terminal for me (with a warning, I should add):

After I click Allow, a new Terminal window launches and fires up an SSH connection so I can do whatever I normally do to verify my identity (password login, public key, etc). 

This also works on iOS or Android if you have an SSH client installed. Simply tap on the URL fields in STRIP for iOS or Android to get the option to launch the URL in your preferred SSH app:

(Yes, that's a sneak preview of the iOS 7 interface, don't hold us to it, work in progess!)

When I tap on Launch SSH, iOS opens up an app on my device that's registered for handling ssh: connections, in this case it's good old TouchTerm:

As you can see, TouchTerm attempts to open the connection with the details supplied in the URL string (and in the case of example.com, gives up for good reason).

Creating labels with a mode of url is a powerful way to make it easy for you top pop into STRIP and fire up a connection to a system that requires credentials you've stored in STRIP.

Off-topic: have a favorite SSH client for iOS or Android that we should check out? Feel free to leave comments! 

We've become aware of a compatibility issue with STRIP running on iOS 7 that is affecting users who switch between the numeric and text keyboards during login. The problem occurs when toggling between the "abc" and "123" modes while the Mask on. When switching between keyboard modes with the application switch, the contents of the password entry box is cleared. If you don't realize that the password box has been cleared, this have the appearance of being unable to log in following on iOS 7.

For example, with a mixed password of "6789abcd", one might start off in the numeric entry mode to enter the first part of the password. However, under iOS 7, if one were to tap the "abc" toggle to switch into the standard keyboard mode to enter the remainder of the password, the contents of the password field would be cleared, removing the 6789 from the password text field. A user who didn't notice this could continue entering text, but only "abcd" would be passed into STRIP, resulting in an incorrect password error.

The good news is that there are two simple workarounds for this issue that will allow you to log into STRIP:

1. Our recommended approach is to use only the "abc" mode to log in for the time being. To do this, switch the mode to "abc", then tap the "123" button in the bottom left corner of the iOS keyboard to bring up the numeric keyboard. The numbers will be arranged across the top of the keyboard. Enter any digits, then tap the "ABC" button on the bottom left of the keyboard to toggle back to text.
2. If you are in a secure location where other people can't observe your screen, toggle the "Keep password hidden" switch to "off". While the Mask switch is off the keyboard toggle will operate normally.

We are treating this as a high priority issue and will make sure there is a fix for this issue in the next release of STRIP. Please contact us at support@zetetic.net if you have any questions or other issues.

Update: We've become aware of a minor issue with iOS 7 that may cause difficulty loggin in if you use the application "abc / 123" keyboard switch. Please read this follow-up post for information on this issue and simple fixes.

Here at Zetetic we're always on alert when a new iOS version is released, and iOS 7 is upon us. We've seen our password manager STRIP through four previous major upgrades to iOS (from iPhoneOS 2 to iOS 6) and we've learned a few things over that time. If you are preparing to upgrade to iOS 7 and are wondering if STRIP is ready and what you need to do, this post is for you.

Ready to Rock

We've been testing STRIP 2.0.3 (the current version in the iTunes App Store) on iOS 7 for some time now, and we're pleased to report that the app works just fine as it is. It looks and works just the same as before. We've worked hard to see if there are any bugs lurking, and there very well may be some, but so far so good, STRIP is ready. The next major version of STRIP (2.1.0) has also been extensively tested on iOS 7 and we hope to submit that for release soon, as it contains significant improvements for protecting your data along with various minor features and adjustments. Stay tuned for that in the coming weeks.

Take a Backup Before You Upgrade

Major upgrades to iOS involve backing up your data, installing the new version of iOS, and then restoring your data. If the restore does not complete, you could be left with missing data (music, apps, etc) after the upgrade. Usually repeating the restore part of the process takes care of that, but we advise that you to take your own backup of your device's and STRIP's data before beginning the iOS upgrade process.

If you use STRIP's sync functionality to replicate your data to Dropbox, Google Drive, or a desktop over WiFi, you already have another snapshot of your data you can use to restore STRIP in the event that the iOS upgrade wipes out your data. If you haven't synced STRIP to one of these targets, or it's been a while, do a fresh sync before starting the iOS upgrade so the data in your backup is up-to-date.

You can also backup your entire device to iTunes or iCloud for restore after the iOS upgrade. We strongly encourage you to do this as well. Apple provides updated, step-by-step instructions on backing up and restoring via iTunes and iCloud.

One thing we'd like to point out is that a Restore post-upgrade is part of the iOS upgrade process. Your music, data, and third-party apps are restored (somewhat slowly) after the upgrade and after the device becomes available. If you are upgrading via iTunes, be sure to watch the iTunes display and do not disconnect your device from your computer until the restore completes fully.

Send Us Your Feedback

After you upgrade to iOS 7, please give STRIP a shot and let us know how it goes. If you have any problems at all, please reach out to us directly at support@zetetic.net, we'll be standing by. Feel free to leave comments on this post, let us know how the app is running on iOS 7 and if you have any ideas for improvements.

We are happy to announce the SQLCipher 3.0.0 beta release. Included with this release are the following:

• New default KDF iteration count is 64000, up from 4000
• New PRAGMA cipher_migrate
• New sqlite3_key_v2 and sqlite3_rekey_v2 functions
• New ATTACH behavior
• Extended Raw Key / Salt feature
• Based on latest SQLite 3.8.0.1

KDF Changes

With this release the default iteration count used for PBKDF2 is 64000, up from the previous default of 4000 - an increase of 16 times our previous cycle count. The intent of this change is to provide an increased level of security and protection from brute force attacks by extending the work factor needed to derive a database key.

PRAGMA cipher_migrate

The KDF default iteration change establishes a new standard database setting, and thus existing databases must be migrated to the new version. To ease the process, we've introduced a new PRAGMA that will aid in the conversion process from an old SQLCipher database, given that default configurations were previously used during creation.

Below shows an example of migrating a 2x SQLCipher database to the new 3.0.0 format. SQLCipher will upgrade the database in place:

> ./sqlcipher 2xdatabase.db
> PRAGMA key = 'YourKeyGoesHere';
> PRAGMA cipher_migrate;

The cipher_migrate PRAGMA can migrate both standard SQLCipher 1.x and 2.x databases. Note that if non-default settings, such as a different cipher or kdf_iter were used in the original database, a manual migration would be required with the use of sqlcipher_export.

SQLite API Additions

In SQLite 3.8.0 sqlite3_key_v2 and sqlite3_rekey_v2 were added; specifically they introduce the alias name of the database during key and rekey operations. This further becomes available when accessing key and rekey commands via PRAGMA. To show an example scenario we will explicitly key the attached database using a separate PRAGMA command:

> ./sqlcipher database.db
> ATTACH DATABASE ‘new.db’ as new;
> PRAGMA new.key = ‘foobar’;

Attach Changes

This release also changes the behavior of the ATTACH command. In previous versions, you could attach a database using same password as the main database by leaving the optional KEY parameter off of the ATTACH statement. For instance, the following statement would attach a database using the same password as the main database, but derived using the attached databases salt.

ATTACH ‘new.db’ AS new;

In the new version, ATTACH will not re-derive a key unless it is explicitly provided via the KEY parameter, like so:

ATTACH ‘new.db’ AS new KEY ‘password’;

In practice, this means that calling applications will need to provide the key on the ATTACH parameter, via sqlite3_key_v2, or PRAGMA <db>.key, in order to set passphrase, or the salt and derived encryption key from the main database will be used instead.

The change to ATTACH is supported by a new feature for providing raw key material. In the new version, it is now possible to provide both a raw encryption key and a raw salt header value in the key using BLOB notation:

If the raw key data is formatted as x'hex' and there are exactly enough hex chars to fill the key (i.e., 64 hex chars for a 256 bit key) then the key data will be used directly. If the raw key data is formatted as x'hex' and there are exactly enough hex chars to fill the key and the salt (i.e 92 hex chars for a 256 bit key and 16 byte salt) then it will be unpacked as the key followed by the salt.

This allows a caller to specify a matching raw key and salt combination that can later be derived from a passphrase.

Together, these change allows SQLCipher to securely wipe the source passphrase from memory after key derivation.

SQLite Changes

Along with all the changes to SQLCipher, the source is now based off the latest SQLite 3.8.0.1 source. This release includes support for the new next generation query planner, partial indexes as well as an addition of the notindexed option within FTS4.

The source for SQLCipher 3.0.0 can be found here, we have included SQLCipher for Android binaries here. Please take a look and let us know if you have any feedback, it is always welcome!

Google has recently confirmed that there is a serious issue with improper seeding of the pseudo-random number generator (PRNG) found on some versions of the Android platform. As a result, we've released a new version of SQLCipher for Android which addresses potential risks introduced by this vulnerability. SQLCipher for Android 2.2.2 binaries can be found here.

The issue itself centers around improper default initialization of the OpenSSL PRNG; specifically, it appears from the fix that /dev/urandom was not included in the seeding process to the entropy pool. This increases the likelihood that low-entropy data could be provided when requesting random data from calls to OpenSSL’s RAND_bytes.

Previously, SQLCipher for Android was dynamically linking the system provided version of the OpenSSL library on the device. This means that SQLCipher was using the version of OpenSSL on affected platforms. This reduced complexity and allowed for a smaller binary payload when integrating the library into an application. Unfortunately, it also means that older versions of SQLCipher used the affected versions of OpenSSL on those Android versions.

To address this issue, SQLCipher for Android will no longer rely on Android’s system-provided OpenSSL library. Instead, new binaries statically link the 1.0.1e tag of OpenSSL, currently the latest release. We have verified locally that OpenSSL 1.0.1e includes data from /dev/urandom in the entropy pool during initialization. This change has the added benefit of normalizing behavior, as there are outdated distributions of OpenSSL embedded in certain Android platforms. We estimate that the statically linked library will add 1.0 MB to most ARM-only applications, although it could be as high as an additional 2.3 MB if other architectures are supported (e.g., x86).

SQLCipher relies on random data for two purposes: initial generation of the random database salt, and generation of per-page initialization vectors (IVs) for AES-256-CBC encryption. Happily, neither usage will result in catastrophic failure, as was the case with Bitcoin wallet applications, where poor randomness led to the generation of weak asymmetric keys. That said, it is likely that existing databases created on older Android platforms will have low-entropy salts and IVs. Theoretically this weakness in the underlying PRNG could facilitate optimized attacks in certain circumstances.

As a result, we strongly recommend that you upgrade to the latest SQLCipher for Android binaries as soon as possible. Out of an abundance of caution, we’d also recommend that those concerned with the security of existing databases generated on affected Android platforms perform a database export via the sqlcipher_export convenience function to re-encrypt the database. This process will generate a new random database salt and initialization vectors for all pages in the database.

If you have any questions, please feel free to ask. Thanks!