Viivo SecretSync Reviews

SecretSync / CompletelyPrivateFiles Clear Text Password

Negative Review by daid
about Viivo SecretSync and Dropbox Jan 2012

Seeing a lot of concern for the [security of Dropbox]( ), of course I made an account. In an attempt to be safe, I installed it in [a chroot jail]( ) on my Linux box.

Then I thought I should try adding [SecretSync]( ) in case Dropbox has [another fail open issue]( ), or their employees get bored and try to access my data [because it is not clear they can't]( ).

Since I'd need SecretSync installed inside my chroot jail, it means I at least need to look at what's going on so I can install it to the right location to work with Dropbox. Plus it looks like a binary blob, so I don't trust the code any more than Dropbox.

In less than a few minutes, I found security loophole gems. In their shell script, to login, they use the built-in function read to store a password as an environment variable, and then pass it as unencrypted clear text to [wget]( ).

Here is the line of code that handles the login for installation setup: wget -o tmp_log "$BASE_URL/?do=$DO&email=$EMAIL&password=$PWD" -O tmp_inst_wget

I think it might even be a joke (but the software was released on the wrong day for that, and has been public for at least 6 months), since the BASEURL is [ ]( )

It's an HTTPS to a site that says completely private files, so it must be safe, right? Nope, anyone even using a simple packet analyzer like [Wireshark]( ) can see your html request (it doesn't matter that it's going to HTTPS, because the address itself still must be sent unencrytped), clearly visible as password=YOURPASSWORD. I just tested a sample query to Google's HTTPS and captured the full address in Wireshark; HTTPS was not designed to encrypt request URLs, just the data transmission once a connection is established. Incidentally, my web browser tells me their "HTTPS" is not trusted. And the password will show up at the shell terminal, too, as wget makes the connection. Hope no one is looking over your shoulder (and you close the terminal session when you are done)! They could have at least run the command in the background!

Let's not even start with using a shell script to deal with passwords and how easily a man-in-the-middle-attack can be done. This is because shell scripts are easy to edit, unlike compiled binaries. There was nothing put in place to ensure the shell script was transmitted in-tact without alteration, for instance. That server is NOT using HTTPS, so a man-in-the-middle-attack could easily insert malicious commands into the install shell script. (Installer retrieved from [here]( ))

Needless to say I did not even install this software to test the actual quality of security it can offer, since merely looking at the setup program I found two obvious flaws in as many minutes. For any kind of service, this treatment of a password is unacceptable. But for a service which is focused on security and encryption? You apparently cannot even login to your account from Linux without sending a clear text password unencryted across the network for anyone to easily see. If the programmers and security review team are happy to let this kind of junk pass Q&A, I don't see a reason to probe any further.

Of course, many people use basic hashing checksums like SHA1 and MD5 for online passwords, which itself is quite a breach of security because of [free rainbow tables]( ), but at least an eavesdropper needs 10 TB of data to crack those opposed to at least one good eye and a pencil.

If the CompletelyPrivateFiles server accepts clear text passwords, is this how the site normally functions? I am too scared to even create an account. If you log in to this account on a public computer, can't we assume the web address is cached by the web browser, and thus the clear text password and email login can be seen by anyone who checks the browser history? Modern browsers that offer suggestions to auto-complete a URL will just show you the login and password! Maybe for their web interface they aren't using clear text, but I don't see an obvious way to signup and test it.

The alternative to using this software is to literally not do anything at all, and then your password won't be sent for all the world to see.

Conclusion: If you work in the security and encryption business, don't transmit clear text passwords.