Heartbleed Security Statement for SQLCipher

2014-04-10 11:16:21 -0400

Like most service and software providers, we've been working hard at Zetetic to assess the impact for our customers resulting from this week's OpenSSL security disclosure, commonly known as the OpenSSL Heartbleed bug. More specifically referred to as CVE-2014-0160, this issue has undermined the security of many internet platforms by allowing attackers to read arbitrary memory from services using the popular OpenSSL library to provide secure communications over the web. This attack can allow extraction of private keys, session data, and user information from affected websites.

We are pleased to report that SQLCipher is not directly impacted by the Heartbleed bug and subsequent disclosure. Many SQLCipher platforms, including SQLCipher for Mac OS X, Android, Xamarin.Android, ADO.NET, and Windows C++ do make extensive use of OpenSSL. However, they only utilize the low level "libcrypto" interfaces to access encryption algorithms. Specifically, SQLCipher's OpenSSL provider uses the EVP interfaces, random number generator, and PKCS5_PBKDF2_HMAC_SHA1. There is no use of OpenSSL's SSL functions, and thus nothing that would expose SQLCipher to direct attack via Heartbleed.

As a result, applications that currently rely on SQLCipher for local data security need not be concerned with Heartbleed exposure as a result of the SQLCipher library. Of course, application and service providers should be sure to carefully audit their software and infrastructure to ensure that there aren't other components or services that rely on affected versions of OpenSSL.

Finally, even though Heartbleed does not impact SQLCipher, we will include the latest OpenSSL 1.0.1g in upcoming releases of SQLCipher Commercial Edition for those customers using our commercially supported libraries to ensure dependency on the latest stable version.

We take security seriously and we are happy to communicate with customers about the details of this issue, so please don't hesitate to contact us if you have any questions.

STRIP for iPhone and iPad 2.2.2 Released

2014-03-31 12:27:49 -0400

We released a point update for STRIP for iPhone and STRIP for iPad today alongside today's update to STRIP for OS X. The new versions contain various bug fixes and a handy new improvement: a cancel button on the Sync view. STRIP for iPhone and STRIP for iPad are available now in the iTunes App Store (if you don't see 2.2.2 yet try again in a few minutes, the App Store doesn't always get the update out quickly after we Release.)


  • New Button to Cancel sync in progress
  • Fixes direct IP / Hostname view for WiFi Sync
  • Fixes masking switch on Note labels
  • Fixes login interface on device rotation
  • Fixes crash on resume when menu showing on iPad

If you're enjoying the changes we've been making or if you'd like to see more, please consider reviewing STRIP in the iTunes App Store and letting us know. If you have any issues whatsoever or if you'd prefer to get in touch with us directly please write us at support@zetetic.net. Thanks!

STRIP for OS X 2.2.0 Released

2014-03-31 11:55:49 -0400

Today we released STRIP for OS X 2.2.0, a major improvement over 2.1.0 in terms of stability, resource utilization and convenience. If you take a look at the image above you'll see some new additions to the interface—toolbar buttons! The icons for these were lovingly designed by Jory Raphael at SensibleWorld.com, and we'll be seeing more artwork from Jory in STRIP soon.

OS X 10.9 Mavericks Required

This version of STRIP requires a minimum OS X version of 10.9 Mavericks, do not install it without first upgrading OS X. STRIP for OS X 2.2.0 is sync-compatible with the previous version 2.1.0 allowing some time to upgrade, but with all the fixes in this update we're hoping you'll make the leap with us sooner than later.


Download STRIP for OS X from the Mac App Store. If you purchased the independent build of STRIP for OS X from Zetetic, simply launch the app and select "Check for Updates" from the STRIP menu in the menu bar if you are not prompted to update.

What's New

Toolbar: We probably should have added these buttons a lot sooner, but hopefully this is a reasonable initial set with obvious functionality. One of the buttons however, with the flashlight icon, does something new. This button (and the associated keyboard combo shift+command+M) allows you to quickly show and hide all masked fields on the entry view and we find ourselves using this all the time now.

Entry view: There's so much we have planned here but for now a minor update to the display of field labels and values along with a slew of fixes for the actions presented in the context menu when you right-click on a field (in view and edit modes).

Import: If you've ever tried to import a lot of records into STRIP for OS X via CSV (like say 500), it was very slow, consumed a ton of memory and was prone to crashing. All fixed up! Although, there is a hard limit of 998 records in one import at the moment. We'll be looking to fix that in future updates.

Memory use: Such memory leaks, many fixes. We'll be paying a lot more attention to this from here on out, making heavy use of profiling tools to manage resource utilization and ensure STRIP is a good citizen on the OS.

Sync: Some bug fixes here as well, along with a fully functional Cancel button. Sometimes there are errors on sync or the network connection is interrupted—you need to be able to cancel the operation and STRIP should handle errors gracefully.

Guts: We found some ugly bugs in how STRIP handled data persistence and put a lot of effort into fixing that up. We're constantly trying to improve and here's one area where we couldn't ignore code written three years ago. There will be no bit-rot in STRIP!

As always, if you have any questions or issues please contact us at support@zetetic.net. If you like this update to STRIP and want to see more please consider leaving a rating or a review in the Mac App Store, tell us what you'd like to see next.


  • Adds new timer to erase field values copied to clipboard after 2 minutes
  • Now uses internal, private pasteboard for copying category and entry records
  • Adds preference to sort labels alphabetically (defaults to enabled)
  • Adds new toolbar buttons
  • Adds Start Sync button to toolbar
  • Adds Password Generator button to toolbar
  • Restores global availability of Password Generator (shift+command+P)
  • Adds new show/hide all masked fields feature to toolbar and View menu (shift+command+M)
  • Adds right-click and keyboard command to launch selected field (command+return)
  • Adds shift+command+J for masking and revealing the selected field
  • Adds 4 and 8 hour intervals to preferences for Auto-lock
  • Includes minor improvements to entry view display
  • Fixes crash during import
  • Fixes poor/slow performance during import
  • Fixes memory leaks during import
  • Fixes memory leaks in main window interface
  • Fixes Auto-lock engaging during import for lengthy imports and shorter lock intervals
  • Fixes sync failure regression on passwords with a single-quote character
  • Fixes window restore location after Auto-lock
  • Fixes preventing access to Preferences window while locked
  • Fixes right-click commands on fields improperly mapped to selected row instead of click target
  • Fixes sorting of new and edited category and entry records to maintain alphabetic sort
  • Fixes any missing or duplicate replica IDs on sync
  • Fixes dysfunctional cancel button on sync progress sheet

Could SQLCipher Improve WhatsApp Security?

2014-03-19 14:54:54 -0400

WhatsApp, a popular cross platform messaging application, has been in the news recently, not only for the high-profile acquisition from Facebook, but also due to security concerns. A recently published article disclosed the WhatsApp database is exposed to third-party access and is not properly secured.

The Issues

The published analysis showed that WhatsApp can store both plain-text and encrypted databases on the SD card, where they could be accessed by malicious 3rd party applications. The only protection for the database is a simple AES cipher with an easily derived key, which leads to real security issues.

Because the database is encrypted as a whole, it’s very likely that at some point during application usage, the entire database itself must exist somewhere in a plain text form in order for the SQLite library to use it. This could pose a risk if the raw data became available to an attacker.

However, the most significant issue is that WhatsApp uses easily discoverable keys on the the encrypted database. Originally a static key was used to perform the encryption on all Android installations, though WhatsApp has now been updated to use a derived key based on the name of the email account on the device. In either case, this renders the encryption key available to applications running on the device, allowing exploits.

A Note on Key Management

Key management is a difficult issue, requiring careful consideration during application design. Storing the key directly within the application, or derived solely based on data on the device, is a poor practice. Decompiling a binary to access the key or determine the process used to create it is a rather straight forward process. Once the key has been identified, the data is at risk.

We strongly recommend that applications ensure that key data is provided by the user (e.g. a user supplied password). It’s fine to combine that with with device data to generate a password, but that is an additional precaution. It’s equally important to pass the key material through a key derivation function with a salt in to generate the actual key for encryption. This helps protect against dictionary and brute force attacks.

How SQLCipher Could Help

In the case of WhatsApp, SQLCipher can help address some of the factors above by providing a more secure environment for application data. Coupled with a user-supplied password or pin, SQLCipher’s built in security controls would automatically provide key derivation and encryption using a unique per-database salt. This would ensure that even if two databases are created with the same password they will not have the same encryption key. Furthermore, using SQLCipher, data is only decrypted as needed, decreasing the risk of plain-text data exposure. Finally, using SQLCipher would provide additional security features to ensure the integrity of the data, preventing tampering and closing off other potential attack vectors.

Many companies both small and large depend on SQLCipher to protect their data across a variety of platforms. Because WhatsApp is already using SQLite to store data, converting to use SQLCipher in its place would require minimal modifications, something WhatsApp might consider.

Tempo Maintenance, Tuesday February 27th at 9:00 PM EST

2014-02-26 17:52:55 -0500

This Thursday night, February 27th at 9pm EST, Tempo and other web systems will be temporarily unavailable while we perform critical patch updates to ensure the stability of our services.

This maintenance outage will also affect the Tempo API, the the Connect website, and the site for Codebook.

Down time could last up to 1 hour, however we believe it will be completed much more quickly. If you need to get in touch with us for any reason, please don’t hesitate.