Thoughts on RoboForm Password?

[mynameGeoff]

Hi again!

 

I wanted to lean on the community and get your thoughts on RoboForm; they're a password manager similar to Bitwarden and 1Password:
https://www.roboform.com/

 

Reading reviews online looks fine. They're just not as well-known as the companies previously mentioned. Just looking for info on if they're a creditable enough company to explore sponsorship with and if anyone has any experience using their service.

 

Appreciate your guys' help

[RokinAmerica]

I have been using it since Covid and I started WFH. Very pleased with it and easy to use.

 

If you have any questions more specific let me know.

[Jaxrebel]

Not been using them for years using bitwarden myself but they where solid when i used them and not heard anything obivous bad about them.

not sure if the cost is for any device.

 

 

[Arika]

i'm sure they're fine, but i dont see why anyone would choose them over bitwarden given the super restrictive free tier.

[98323xr45]

Reading their whitepaper, they only use 100,000 iterations for their key-derivation function (PBKDF2-HMAC-SHA256) by default. OWASP recommend at least 600,000 iterations for this hash function. This is especially relevant here, as the KDF is used to derive the encryption key for all passwords. If RoboForm was breached, and a user had a relatively weak password, this would make a brute-force attack to recover the encryption key (and therefore all passwords) feasible. Other major password managers use a minimum of 600,000 iterations: Bitwarden announced this here, LastPass here, 1Password here. I would strongly encourage LTT to discuss this with RoboForm, and encourage them to increase the minimum iterations of their KDF, before accepting sponsorship.

 

Personally, I would also prefer that Argon2id was selected as the KDF for any new password manager, but PBKDF2 is acceptable. I would also prefer that at least their client code was open sourced, but that may be too much to ask.

 

Edit: Also, their description of their cryptographic protocol for data sharing places a great deal of trust in the RoboForm server, since the client blindly trusts that public keys provided by the RoboForm server actually belong to intended recipients. Some out-of-band key sharing method between participants (or at least the option for this) would be far preferable to me.

Edited June 15, 2023 by 98323xr45
Mention data-sharing protocol

[mynameGeoff]

8 hours ago, 98323xr45 said:

Reading their whitepaper, they only use 100,000 iterations for their key-derivation function (PBKDF2-HMAC-SHA256) by default. OWASP recommend at least 600,000 iterations for this hash function. This is especially relevant here, as the KDF is used to derive the encryption key for all passwords. If RoboForm was breached, and a user had a relatively weak password, this would make a brute-force attack to recover the encryption key (and therefore all passwords) feasible. Other major password managers use a minimum of 600,000 iterations: Bitwarden announced this here, LastPass here, 1Password here. I would strongly encourage LTT to discuss this with RoboForm, and encourage them to increase the minimum iterations of their KDF, before accepting sponsorship.

 

Personally, I would also prefer that Argon2id was selected as the KDF for any new password manager, but PBKDF2 is acceptable. I would also prefer that at least their client code was open sourced, but that may be too much to ask.

 

Edit: Also, their description of their cryptographic protocol for data sharing places a great deal of trust in the RoboForm server, since the client blindly trusts that public keys provided by the RoboForm server actually belong to intended recipients. Some out-of-band key sharing method between participants (or at least the option for this) would be far preferable to me.

Appreciate your feedback and insight here, I'll send your response over to the brand and see if it's something that can be implemented in the future. As an outsider looking in, I'm sure it'll take some time to implement, but it would definitely be something worth looking into for them.

 

I'll keep the thread open for a bit longer to ensure everyone gets a chance for input but based on responses, we'll give them a shot and see if they perform well.

[aklferris]

On 6/13/2023 at 3:51 PM, mynameGeoff said:

Hi again!

 

I wanted to lean on the community and get your thoughts on RoboForm; they're a password manager similar to Bitwarden and 1Password:
https://www.roboform.com/

 

Reading reviews online looks fine. They're just not as well-known as the companies previously mentioned. Just looking for info on if they're a creditable enough company to explore sponsorship with and if anyone has any experience using their service.

 

Appreciate your guys' help

I'd stay away... you guys respect Paul Moore, the security researcher who found the Eufy/Anker lies, and whose research was discused on WAN show...  here is is write up on Roboform:

https://paul.reviews/how-secure-is-roboform-the-5-minute-challenge/

 

Now, that was in 2014... so idk what they have changed.  I'd make sure not only the issues covered have changed, but also the culture that led to these issues.  Also, for what it's worth, I used the product for years not knowing about the issues... and have since moved to BW.

[aklferris]

Also, looks like until recently (this year) the default PBKDF2 iterations was 4096, when 300,000+ is recommended.  I'd say their security culture is the issue... good luck getting them to change. 

 

Edit: ok. so OWASP recommends not 300k, but 600,000 iterations MINIMUM for PBKDF2... and at the beginning of the year Roboform was setting people's iterations to less than 5,000... and now?  they are setting peoples default iterations to... wait for it... 100,000... 1/6th the minimum recommended. Does that sound like the type of product you want people to use for security? 

https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#pbkdf2

 

I'm not a security expert, but I can read and I'd stay far far away.

 

 

 

[aklferris]

IDK if you guys have ppl on your team that are well-versed in security apps, but I'd like to see you guys have knowledgeable people review what I shared before making a decision.

[aklferris]

man, I feel like I'm spamming... sorry to post so much... I just want to say one last thing here... I just found your forums after hearing about them many times on LTT youtube... and I want to say I'm glad to see you guys taking sponsorer deals so seriously.  Thanks for being proactive as well as being open to any complaints people have.  Keep up the good work!

[BuhDan]

I'm gunna have a poke at this and see if I can find out some more info.

I'm not entirely convinced one way or the other, but I'm not hearing anything overwhelmingly positive.
Might be best to take a cautious approach. Their paper is recent, but the damming report is from 2014.
My main concern is how/where they handle decryption, which from the 2014 article seems... unconvincing.

I don't think I have quite the level of knowledge required to make a final call on this, so I'll escalate.

[98323xr45]

17 hours ago, BuhDan said:

I'm gunna have a poke at this and see if I can find out some more info.

I'm not entirely convinced one way or the other, but I'm not hearing anything overwhelmingly positive.
Might be best to take a cautious approach. Their paper is recent, but the damming report is from 2014.
My main concern is how/where they handle decryption, which from the 2014 article seems... unconvincing.

I don't think I have quite the level of knowledge required to make a final call on this, so I'll escalate.

Important to remember that in 2014, decrypting in-browser was a lot more complicated than it is today. Since we have access to WebAssembly + the Web Crypto API in most browsers now, it's not as difficult to implement secure client-side encryption/decryption entirely in the browser (Although it is still complicated! Cryptography is very hard to get right, you will shoot yourself in the foot if you don't know what you're doing!). In 2014, it was another matter entirely. This isn't an excuse for their previous security posture of course, but it is just a lot easier to do things correctly these days.

[aklferris]

On 6/17/2023 at 11:18 AM, 98323xr45 said:

Important to remember that in 2014, decrypting in-browser was a lot more complicated than it is today. Since we have access to WebAssembly + the Web Crypto API in most browsers now, it's not as difficult to implement secure client-side encryption/decryption entirely in the browser (Although it is still complicated! Cryptography is very hard to get right, you will shoot yourself in the foot if you don't know what you're doing!). In 2014, it was another matter entirely. This isn't an excuse for their previous security posture of course, but it is just a lot easier to do things correctly these days.

sure, but look how they are handling iterations in 2023...  I'd say they are putting their customers at risk... these iteration recommendations are (in part) based on what a single modern consumer graphics card is capable of in the wrong hands.  And Roboform doesn't seem to care.  check out the link I shared.

[aklferris]

On 6/16/2023 at 6:09 PM, BuhDan said:

I don't think I have quite the level of knowledge required to make a final call on this, so I'll escalate.

just curious what came out of this?

[mynameGeoff]

On 6/23/2023 at 2:56 AM, aklferris said:

just curious what came out of this?

Hey, sorry for the delay. I was out to VidCon last week for business and had limited access to my email.

 

After chatting with @BuhDan and others internally outside the biz team, we'll put a pause on this one until we can get more info on if and when RoboForm will start implementing better security measures before we can partner together on sponsorship. We'll continue to monitor things as they progress.

 

Thanks again for keeping us and our partners accountable, all of us on the biz team appreciate it