Security & Permissions

[matteodem]

This project looks really interesting, but I've been asking myself following things that I didn't see explained in the docs.

• When I create a database with name global would other people that have access to IPFS also see the same data as I do in that global database?
• How do I protect my data being overridden in a key store? If the database would be shared over IPFS then it would be hard to prevent that I imagine.

Hope there's someone who can answer these questions, or forward me to answers to similar questions.

[riteable]

I was wondering about the second point too. How do you protect data from being changed by anyone and everyone?

[niksmac]

I suppose you have to use some consensus based database like Tendermint to achieve this.

[icyc9]

There is no mechanism to enforce data structure, unlike smart contracts. Imagine the implementation of a feed using orbit. The attack vector appears quite large, given sovereign control to every user. There is no agreement or data model enforcing the structure of input data. As there is no validation mechanism, a feed can suffer spam and entries of invalid data.

In a system of this design, trust is all we have.

@haadcode If I'm missing something or incorrect, feel free to expand.

[niksmac]

What @Robertchristopher said is correct. And I dont think we need something to enforce the data structure.
If you are looking at the consensus mechanism, orbit-db is not something you want to try, at least now.

[icyc9]

I'm trying to understand common environments in which implementations utilizing OrbitDB are appropriate. Entering the world of Orbit unveils many new paradigms and design patterns.

Common technologies and applications typically require access control mechanisms. At this state in Orbit, any application would require complete trust and ensured authenticity amongst all. Unfortunately, as a humanity, I don't believe we've reached that evolutionary state as of 2017.

I've noticed Akasha's use of OrbitDB (described here). Modeling a decentralized social media over the Orbit technology inherently engineers an unstable system with a large attack vector. Malicious users are lines of javascript away from compromising any feed system embedded into the network (spam, invalid data writes, ...). No security mechanism is enforcing regulation and consensus legislations, leaving merely trust.

Even looking at the Orbit chat application, there are some clear vulnerabilities as no defense mechanism is protecting the system from spam floods.

I'm not suggesting Orbit to implement a consensus mechanism, as that is not the intention of the technology.

@niksmac @haadcode I assume Orbit is not designed for building secure systems? As of now, it appears to be a proof of concept. There haven't been any large systems deployed on it, other than Akasha, which I assume was able to circumvent these issues?

[haadcode]

Thank you for all the questions and discussion in this thread! It's great to see other people jump to explain orbit-db. Thank you ❤️

I've been off of orbit-db for some time now but getting back to it as we speak. I'll answer all the questions here soon.

Since this and similar questions pop up frequently, we need to have a place where people can read about orbit-db in more detail. So, I'm taking that as my first task and write a document that describes orbit-db's design, architecture and functionality so that people can refer to it as their first guide to orbit-db. I have a pretty good idea what it should contain, but if anyone has input as to what should be explained, please do let me know, it would be highly appreciated!

But to answer briefly to the original questions. And please excuse my brevity, I don't mean to come across harsh with the answers here :)

When I create a database with name global would other people that have access to IPFS also see the same data as I do in that global database?

Yes. Currently the database names are global and every peer has "read and write access" to every database.

How do I protect my data being overridden in a key store? If the database would be shared over IPFS then it would be hard to prevent that I imagine.

tl;dr currently you can't. This is a feature that has been long due and requested by many, so I'm putting it on very high prio to implement.

Once implemented:
Every database will be per public signing key meaning that there's a way to define which peers can write to which database based on signing keys. This will also ensure that the data is authentic.

This will indeed "enforce a data structure" but not on the data level (ie. what you store in the database) but on the operations log level (ie. from which the state of the database is derived from). It means that the data authentication/verification happens on the protocol level, not on the view level. There's no need for consensus to achieve this. That said, consensus mechanisms would have suitable use cases in orbit-db to manage or incentivize the access control or availability.

There's a secondary layer to this which is the pubsub. Each orbit-db database name currently maps 1-to-1 to an IPFS pubsub topic. There's currently no access control in pubsub, but there have been talks about implementing it some day. With the new functionality to orbit-db described here, we will still have a large spam vector in pubsub that will eventually need to be protected.

I've noticed Akasha's use of OrbitDB

I believe Akasha ended up NOT using orbit-db (in their current version at least).

I assume Orbit is not designed for building secure systems?

It is designed to implement secure systems. The implementation is just not there yet today. We're working on it and once the data authentication has been implemented, it should address most of your current security concerns.

I hope this answers the most pressing questions. Please do ask for clarifications and more details if need be!

[haadcode]

Write-permissions were implemented and released in v0.18.0. Take a look and see if what's there helps with your use cases. You can read more about Access Control from the new getting started guide.

Would be happy to answer further questions and get feedback on how to improve it!

[Bajix]

I bet the ACL would be a lot more powerful if it adopted multi-signature threshold encryption in a scheme identical to what's being implemented in EOS. We could use a side-channel to coordinate adding signatures from multiple parties, and then validate the signature of a set of keys rather than a single key.

Also is there anything that prevents using nested databases? For example, a top layer orbit-db database that uses multi-sig and then has a key-value store that points to other DBs, each with their own permissions. That way the top level DB can update ACL on second-level DB's, and users could figure out the new DB address. The DB content would remain the same despite ACL changing, so there would be no migration process

[aphelionz]

Happy to report that dynamic ACL work is in release candidate now for 0.20.0. You can npm -i -S orbit-db@rc2 and give it a spin.

If you have more questions about security and permissions, I'd recommend checking out the new OrbitDB Field Manual. Feel free to open issues and PRs there if things don't make sense.