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 GROUPUID: 1F66429EC892BBDB FIELD1: <blob> FIELD2: <blob> FIELD3: FIELD4: FIELD5: FIELD6: FIELD7: FIELD8: FIELD9: <blob> FIELD10: <blob> NOTE: HASATTACHMENT: 0 HASCUSTOMFIELD: 0 VIEWCOUNT: 6 *************************** 2. row *************************** [snip] 10 rows in set (0.03 sec)
Oh dear. Oh dear oh dear.
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?
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.Comments (12)