Security issue on read.cash (post-mortem)

Yesterday, we were alerted about a security issue affecting CashID login (via Badger Wallet). Under some conditions, a user was able to log in into other random user's account.

The issue has since been fixed.

The issue was with our CashID implementation. Before you start the process of identifying a user with CashID, you create a "nonce" - basically, a random string. During the process, CashID client returns that this nonce should be associated with some particular cash address. We were caching this information for 10 minutes. After that, usually within a few seconds, the user clicks the "Sign" button and the software sends this signature along with the nonce back to the server.

The problem was that, if a user took more than 10 minutes to click the "Sign" button in Badger Wallet, the information about the cash address belonging to this nonce was gone from our cache.

After we've got back the string with a signature, we've reached back to the cache to find out which cash address should we authenticate in and got back "blank" ("null", in computer terms).

We didn't check that "blank" is not a valid cash address. We then queried the database to give us a user that has "blank" as his CashID address. Database happily obliged to provide one random user that didn't have any CashID cash address. We proceeded to log that user in.

Who was affected

As far as our investigation shows user @aschatria had some information changed, which has since been restored, and lost about $0.07 worth of upvotes.

As soon as @Ocro (bug reporter) was logged in to @aschatria account, he followed the site instructions to generate a new wallet. After the wallet was generated - its cash address was recorded as the "upvote address" for @aschatria's account, so he got a few upvotes that were destined to @aschatria, which @Ocro (as a test, after consulting with us) proceeded to move to own wallet.

What did we do

We've added the check that cash address that we're trying to log in is not blank.

We've looked through the registration/login code a few more times to ensure there were no more obvious bugs.

We've sent $5 to @Ocro for reporting the bug.

We've sent $1 to @aschatria to compensate for the lost $0.07.

If that doesn't sound like big amounts, please understand that read.cash is not a profitable enterprise yet.

Responsible Disclosure

If you have a security issue to disclose - please send us an email to hello@read.cash (it's in the footer of every page), you can optionally protect the message with PGP encryption using our public key (also in the footer).

Please do not post any security-related information publicly (including to Reddit or via an article on read.cash) - you're inviting bad actors to wreck havoc by exploiting the security issue before it has been fixed.

Then, please, give us at least a few days to respond. We're not a huge corporation, we don't have 24/7 agents ready to respond to any request in minutes. We're just a few developers trying our best to respond in time.

Is everything safe now?

We still advise everybody not to keep more than $5-10 in their online accounts. During the development of read.cash our priority was (and still is) "user experience", sometimes at the expense of potential security.

We could, of course, force you to enter a password for each upvote or require you to install Badger Wallet AND click "Sign" for each upvote, it increases the security greatly, but also severely degrades the user experience and introduces unnecessary obstacles in the registration process.

There are a lot of preventive measures to avoid anyone getting access to your private key (which is stored in your browser), but we can't achieve 100% protection. It's not possible to do while keeping the user experience smooth.