Client side encryption

[bebehei]

"Stored privately and encrypted at rest."

This lets me conclude: encrypted => bashhub down

I have to assume, you want to make bashhub a reliable service, so it has to be always up.

This lets me also conclude: bashhub up is a tautology =>bashhub down won't ever be fulfilled. So encrypted cannot ever be fulfilled, because encrypted => bashhub down has to be valid.

This is simple logic: The data won't ever be in an encrypted state.

For a real formal approach. Sry, I'm too lazy spending effort in this.

[kootenpv]

I don't understand your logic :( Could you perhaps rephrase it, I'm very curious!

[bebehei]

Taken from the FAQ:

Where are my commands going?
They're stored in Bashhub's database. All commands are private. Bashhub's command database is encrypted at rest using storage level encryption. Commands are encrypted in transit using HTTPS. For more details checkout the basic security and privacy practices.

That says:

1. In general you have to trust @rcaloras for hosting the service. He can read every command, what you've typed and synced via bashhub. That's your decision, but I don't doubt his service.
2. Any person, who has got enough access to the server running it live, has got full access to all commands. This includes possible hackers. The service claims to be private, but - like in every software - there may be flaws in the authsystem giving hackers enough access to the application reading out the storage.
   • General flaws, like that the server software is not released open source
3. Anyone who gets knowledge of the storage password, has got access to all commands.

But that's not about the reason, why I opened the issue. It's about the logic, if you actually can say, that your commands are encrypted.

Bashhub is an online service. You want to have it up, with highest uptime possible.
So, If your storage is encrypted at rest, you have to shutdown bashhub, to have it actually encrypted. There is no other way, but only then it would be fine.

But as the server admin, it's your interest to have the system up as long as possible. And as the storage is only encrypted when bashhub is down, your interest, that the commands are actually encrypted, is close to zero.

The best option would be of course: Encrypt the saved commands on the client and store only the encrypted data on the server.

[rcaloras]

@bebehei Thanks for elaborating. There are a few users who have worked in client side encryption. I know @andrew-morris had previously pulled together a successful implementation on one of his systems. The major downside to this is that it breaks text search for the commands.

I'm going to change this issue to be focused on providing a suggested way to implement client side encryption.

[dimo414]

So, If your storage is encrypted at rest, you have to shutdown bashhub, to have it actually encrypted.

@bebehei I don't think that reasoning is correct. It simply means that the contents aren't encrypted while in memory; when written to disk the commands are encrypted. It sounds like Bashhub is simply relying on the underlying cloud service's secure storage rather than encrypting the contents themselves. It isn't necessary to take a running service down in order to write data to disk.

[bebehei]

I don't think that reasoning is correct. It simply means that the contents aren't encrypted while in memory; when written to disk the commands are encrypted. It sounds like Bashhub is simply relying on the underlying cloud service's secure storage rather than encrypting the contents themselves.

Yes, the contents are encrypted on disk. But as long, these are unencrypted in memory, no attacker would care, which state the disk has: The information is already unencrypted in memory.

I don't think of the attack vector, that someone (e.g. NSA) walks into the datacenter and steals your disks. I think of the attacker, who breaks into your running service. And at bashhub, basic security principles are not taken care of (open-sourcing the server or having a code audit.)

Of course, there has to be at first an attacker, who wants to do malicious things with your service and a hackable service. But we've seen that even the biggest fail (Yahoo, Facebook,...). And bashhub as a hacked target is interesting, as we've got enough private data. Only thinking of the commands, where (accidentally) forgot to properly space-out their MySQL passwords, is enough interest to search for some 0days.

I see, there is huge potential to get hacked. It is just one single server with >1.5 Million recorded commands.

I don't think that reasoning is correct. It simply means that the contents aren't encrypted while in memory; when written to disk the commands are encrypted.

I see, you understood, that bashhub has got its contents unencrypted in memory while it is online.

In general, if you want to encrypt something and put next to the encrypted data either the cleartext data or the private key, you actually have nothing encrypted. So, while bashhub is online, it has its data in an unencrypted state.

Additionally, bashhub has got a bias: It's an online service and one big point of an online service: You want to have it online as long as possible. In previous paragraph, I already pointed out, that online implies that the data is unencrypted in memory. Logically, now I'm able to exchange the word online with unencrypted.

You want to have it online as long as possible.

You want to have it unencrypted as long as possible.

Ugh.

[kootenpv]

Perhaps the solution could be to by default not store sensitive information? I've done some checks on that for git repos https://github.com/kootenpv/gittyleaks

It would be very nice to run a check before saving to the server. Perhaps some stuff would only be stored locally then. It could be a temporary solution?

[evanstucker-hates-2fa]

I'd like to second this issue. This service looks almost exactly like what I've been looking for - the feature set it great! - except I need to have it stored in my cloud, not your cloud. If I'm using this for work and I accidentally put a password on the command line, I can't have that going to a third-party. If I were able to host a bashhub server at work and the password never made it off-premises, I could use this product.

Can you open source the server side and allow client configuration to point to a private server?

[evanstucker-hates-2fa]

I'm gonna go ahead and make this a separate issue, because client-side encryption doesn't solve my problem.

[waldyrious]

@rcaloras this is just off the top of my head, so it may be a naive (or already explored and discarded) idea: couldn't search work if the client encrypts not (just) the entire command, but also an array of encrypted parts? Then search could work the same was as password matching: the search terms would also be encrypted and matched against the individual tokens. Is this viable or would such an approach be prohibitively slow?

A first basic implementation could simply split commands on whitespace, punctuation, etc. (or regex word boundaries, \b), but later down the road more advanced matching methods could be added, e.g to support partial matches via syllable segmentation/tokenization, or small typos in either the command or the search terms.

In fact, these approaches could be complimentary: a very fast first round matching only the top-level multi-word commands, followed by a round matching against the individual words (which is where I expect the most useful results to come from), and then additional rounds for syllables, typos, and even character-by-character search. This information could be stored as a tree structure for each command, and maybe a threshold of, say, 3 results at earlier levels could stop the search and provide the user with the option to manually go deeper (to save up on server resources in case the desired command is found quickly).

Of course, at this point things start becoming quite complex, so again, I would suggest starting with the word-separated search, since I suspect that'll provide a nice sweet spot of implementation complexity / practical usefulness.