SplashID Sucks

August 22nd, 2010

After an evaluation of SplashID (made by SplashData) as a new password manager for my workplace I've come to the conclusion it's snake oil rather than secure. And not just snake oil, but poorly designed snake oil. Here's why.

The architecture of SplashID is simple. The backend is a plain MySQL database. The user interface is SplashID's app, available on Windows and Mac. When you start your client and log in, it communicates directly in MySQL-speak to the database backend. The connection to MySQL is SSLified (yay!), although bizzarely SplashData call this encryption "IPSec". Not having an actual server process between the clients and database is an unusual design, but it's possible to build something secure this way so we press on.

In SplashID's world, each user's access credentials are made up of three parts. Since each user has a MySQL account, the first two are a username and password. The third part is a "master password". What's a master password? I'm glad you asked. You see, every cell of data in the SplashID database is encrypted with the same key. (Encrypted with AES-256 and Blowfish. Why use two ciphers? Why not!) The encryption key is, of course, the "master password". Because all data is encrypted with this key, every user has to have access to it. Most programs do this by storing the "master password" in the database, one copy per user, encrypted with that user's password. Unlike these programs, SplashID just makes every user remember piece of secret information. Why SplashID does this is another mystery, and a strike against them for poor UI design.

Let's investigate this "every user is a MySQL user" concept. I've created a limited user for myself in SplashID with no access to any passwords. The Splash client app obviously lets me see nothing, but how about a generic MySQL client?

Inappropriate syntax highlighting turn on!

$ mysql -u user1 -p -h splashtest
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 92 to server version: 5.1.47-community
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql> show databases;
| Database           |
| information_schema |
| mysql              |
| splashiddb         |
3 rows in set (0.02 sec)
mysql> use splashiddb;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> show tables;
| Tables_in_splashiddb  |
| apppreftable          |
| attachmenttable       |
| columninfotable       |
| customicontable       |
| customtypetable       |
| databaseinfotable     |
| eventloggertable      |
| groupsubgrouptable    |
| grouptable            |
| mostviewedtable       |
| recentlyaddedtable    |
| recentlymodifiedtable |
| recentlyviewedtable   |
| recordtable           |
| typetable             |
| usergrouptable        |
| usertable             |
17 rows in set (0.02 sec)

It looks like there's only one table that all passwords are stored in. MySQL doesn't offer per-row access controls, but surely I can't view every password in the database with my limited user???

mysql> select * from recordtable\G
*************************** 1. row ***************************
RECORDID: 1F6642A0C892BC76
TYPEUID: 0000000000000013
FIELD1: <blob>
FIELD2: <blob>
FIELD9: <blob> 
FIELD10: <blob>
*************************** 2. row ***************************
10 rows in set (0.03 sec)

Oh dear. Oh dear oh dear.

mysql> Bye

So there you go. Every user in SplashID, no matter how limited, can view every password in the database, all encrypted with a key they know. Another strike against SplashID. They need a miracle now.

And hark! Here comes the explanation from SplashData. I emailed them specifically regarding my findings, wanting to make sure this wasn't some huge mistake. I asked:

...every cell is encrypted using the same process, right? From that it follows that if a user can decrypt one cell, they can decrypt every cell. The only protection is that your encryption routine is not published. Or am I missing something?

The reply:

That’s right Alex.

That’s why I mentioned-
> Actually, they don't use the same key. AES key is a hash function of the
> Blowfish key. I'm sorry I cannot give you more details on the algorithms we use.

So, if the user knows the Blowfish key, it is not enough. They still need to decrypt using SplashID Enterprise application.

Even though every user can download the entire encrypted database, even though the master password decryption routine is stored in the client side application, it's all fine because nobody has ever reverse engineered an application to extract a single hash function before! In the end, the previous security missteps hardly matter compared to this blunder. All it will take is one enterprising security researcher or blackhat to figure it out and put their findings on the web, and suddenly every password in every SplashID install is wide open for the taking by its users.

We won't be using SplashID at my workplace, and my advice to you, dear reader, is to avoid them too.

12 Responses to “SplashID Sucks”

  1. Amer Kawar on August 22, 2010 11:04 am

    I learnt one thing from this post: My grandma knows more about security than SplashID's team.

    Thanks for taking the time to make a lot of people feel smart!

  2. Julian on August 22, 2010 12:13 pm

    I wonder if this only applies to the enterprise product - as presumably some of the smaller scale things aren't backed with MySQL and might not have the same design. They only have a single password, for starters, not this odd master key arrangement.

  3. barack on August 22, 2010 2:10 pm

    I kind of like it.

  4. Randy on August 22, 2010 2:42 pm

    You may be able to have SplashID show you passwords that aren't yours by modifying the database.

    Can you change the GroupUID to yours? Can you modify one of yours to have others password information in it? Can you create a new entry with their password that you have access to?

  5. Steve on August 22, 2010 8:29 pm

    If its only about storing some passwords you could use cloudsafe.com


  6. anonymous on August 23, 2010 9:28 am

    Take a look at http://clipperz.com/ -- They use MySQL, but decryption is all done on the client in *JavaScript*. You can even dump the (encrypted) data into a HTML page and use the app locally. Very neat.

    (My only beef is that if you set up a private server, you can't prevent random people from putting rows in your database. Shesh!)

  7. Alex Jurkiewicz on August 23, 2010 6:01 pm

    Those are good ideas Randy. I didn't think of them at the time and our test install is long gone sadly. Perhaps someone who wants to be the author of a CVE should look into this? :)

  8. Sherry Markwart on January 20, 2011 11:52 am

    I just want to be able to sync it with my android without having to uninstall, reinstall, blah blah blah every time I need to reset my devise. I am looking for something else.

  9. Alex Jurkiewicz on January 20, 2011 11:56 am

    I have a Dropbox account with a Keepass password database synced in it. Dropbox and Keepass both have android apps so it's pretty simple to get an up-to-date copy onto my phone for use.

  10. Dan Connor on January 5, 2012 11:05 pm

    This writeup was hilarious. Another example of "enterprise" software dropping the ball in a big way.

  11. Mount Knowledge » SplashID for iOS by @SplashData stores master password inside database: #security #fail on March 18, 2012 9:18 am

    [...] seems that SplashData made a similar faux pas with SplashID Enterprise Safe. This makes me fear the worst for the other members of the SplashID [...]

  12. Sherry Markwart on May 9, 2012 4:38 pm

    Since my negative comment in January 2011, I must say that splash has really improved. Thanks to all who worked so hard to get thing up and running smoothly. I can now recommend splash id without reservation!

Comments are closed.