Roboform Security Revisited: Lies, Deception & Misnomers.

You may recall, I recently published an article entitled "How secure is Roboform: The 5 Minute Challenge".

Well, 6 months have passed and although there's been no official public response from Siber Systems, they have made a number of comments to journalists and customers by email/Facebook and support tickets; during which I've been labelled as "misinformed", "unpleasant" and "sarcastic".

There were no bugs in the first place. Roboform on Facebook

Hmm. They edited the post.

Stick to factual articles. Roboform on Facebook

In both replies, you'll note a link to the HackerNews article which tried to debunk my claims. Fortunately, The HackerNews pulled the article and replaced it with this; something which Scott Helme pointed out.

Security is our number one priority and we are working to ensure that no vulnerability exists, as it has still yet to be confirmed Roboform on Facebook

So they couldn't replicate it, assumed it was inaccurate and publicly berated the researcher that reported it! Charmin'!

A week later, Chris Gomez raised the issue again.

Although they still couldn't replicate it, they did at least release a patch.

Since then, it's been radio silence. The "Roboform Everywhere" portal was still insecure, but that clearly wasn't going to change any time soon.

Poking the bear

A couple of days ago, a concerned Roboform user sent this:

Sigh. Let's start over.

RoboForm does not pass Master Password over any network
RoboForm does not transmit any decrypted contents of the user data files (passcards/identities/safenotes) over any network.
Olivia @ Roboform Support

I agree. If you use the Roboform desktop application, the master password & passcard data do not travel across the network. That said, I never claimed they were. The article clearly states "Roboform Everywhere Portal" as opposed to the Roboform desktop application.

These services are using SSL connection (https) for communication between the client (browser) and the server.
When the user submits the Master Password to decrypt a file, the Master Password is submitted to RoboForm Everywhere server, the server performs the decryption, and the decryped data is transmitted back to the client.
Even if the user selects to cache the Master Password, the Master Password still is not stored on server.
Olivia @ Roboform Support

That's somewhat true.


Yes, they use SSL. Unfortunately, it's SSLv3 and susceptable to the POODLE exploit, which is insecure. They also use RC4, which is considered weak. There's no forward secrecy, HSTS, pinning, elliptic curve crypto or indeed anything considered "military grade", to use their phrase.

You'd have to be insane to willingly send your master password over a "secure" channel such as this... but what if it's not encrypted at all?

For at least a week in August 2014, Roboform's Everywhere Portal sent data to/from their servers over HTTP!

No encryption, no hashing... nothing! Just a few minutes before their reply though, the server miraculously started enforcing SSL (albeit insecure/weak).

Did they own up, admit their mistake and allow users to change their passwords? Nope... they quietly patched it and presumably hoped nobody had noticed.

Sending vs Storing the Master Password

Assuming you've read the first article, you'll note I said

Your master password is sent to Siber Systems Me - here

I specifically used the word "sent" because it was completely at odds with Vadim's (CEO) statement.

As I've previously shown, it's not only sent to Siber Systems (which they now admit), but there's no hashing involved whatsoever. On both counts, that's a lie.

Their paraphrased rebuttal of "ok, but we don't store it" is pretty weak, not to mention inaccurate.

What's the difference?


If you're sending the master password over any network, you have to trust it's being handled with care, every step of the way. We already know the transport layer is horrendous... and that's what we can see; who knows what's going on behind the scenes.

Even with the best of intentions though, it's never as safe as simply not sending it in the first place.

Even if the user selects to cache the Master Password, the Master Password still is not stored on server. Instead, two strings are derived from it; the first string is stored on the server, the other in a browser cookie.
Olivia @ Roboform Support

To derive two keys from the master password, the server must have the master password to begin with. At the very least, this is stored in server memory until the key derivation process is complete.

Let's assume they discard the key immediately after key derivation. The only way to recover it is to combine the 1st derived key (already on the server) with the 2nd key (stored in the user's browser as a cookie).

As each requests comes in, those keys are once again combined to encrypt/decrypt your passwords.

Why do they claim they don't store it, if they do?

I can only assume they mean it's not stored after your session ends.

That doesn't alter the fact that at some point, your master password and/or the keys derived from it reside on the server.

Discarding them at the end of the session doesn't negate the fact they're accessible to the server, during the session.

You see, Paul Moore "discovered" the #2 (which has never been a secret), and somehow wants to apply it to #1 Olivia @ Roboform Support

That's disingenuous too.

I have never confused the two variants... but when they say "Roboform never sends your master password", users are likely to see "Roboform" as an umbrella term describing any product which bears the name. Even if they spot the difference and research it further (as I did), they're likely to find Vadim's quote and assume "the master password is NEVER sent to the server".

It may not be a secret, but it's far from clear either.

Another message in the article is that #2 is not secure enough because of decryption on the server. I would say it is still secure because of SSL connection
Olivia @ Roboform Support

HTTP, SSLv3 and RC4. Need I go on?

"Multi-Factor Authentication"

In September 2014, Siber Systems announced what they call "Multi-Factor Authentication".

As we know, 2FA in a PW manager is not possible, but they've given it a shot...

An OTP by email?! THAT'S NOT 2FA!

There are 3 factors.

1) Knowledge (something you know - passwords, PINs etc)
2) Possession (something you have - a smart card, yubikey etc)
3) Inherence (something you inherently are - fingerprint, iris/retina etc)

Your password combined with a PIN number sent by email are multiple steps of a single factor, or 2SV. Don't take my word for it... even NIST agrees (section 6.1.4).

I emailed Natalie Pinto @ Siber Systems to ask for their comment.

Anyway, let me provide a few more details that may help.
The OTP is only used once to register the device. We don't require that the user enter the OTP each time they access their Everywhere account. We drop a software token on the device based on the successful recognition of the OTP. So, the software token is "something you have.
We plan to add SMS as a delivery method for user's OTPs.
I looked at Wikipedia and saw that Soft tokens can be used as a multifactor option.
Natalie Pinto @ Roboform Support

An OTP via SMS isn't 2FA either.


Don't get me wrong, I wasn't expecting to be on Siber's Christmas card list, but I think the way they've handled these issues is disgraceful.

When it comes to choosing a password manager, trust is everything. Although Roboform (the desktop/mobile app) is undoubtedly more secure now, I wouldn't trust it with any personal information, let alone the keys to my digital life.

That's it folks.