Question on Disclaimers and the Reality of security on current alpha and testnets

Test networks are test networks, and so are accompanied by very appropriate disclaimers disavowing any assurances of stability, security, privacy, anonymity, etc. I understand that and will generally treat the network accordingly.

But it brings up a few questions regarding whether the technology is of necessity demonstrating inherent properties of design security, and the degree to which it is not, by virtue of having the vaults all hosted by a single entity (MaidSafe), any “viewports” built in currently to aid development, etc.

I’m sure someone with the right skills and knowledge could determine much of this by looking at Github, but that’s not me.

I don’t see how we could be implementing self auth and self encryption without that high level security already in place. Perhaps security of IPs could be compromised due to all nodes belonging to one entity, but not sure about that or other angles.

3 Likes

Mainly this is down to the fact we have not done a security audit ourselves over the completed code base, so we err on side of it’s not secure. There are a great many things are, like encrypted data, session data, logins etc. but they are not secured against group attacks. This means the network could be DOS’d or at least groups could (in the wild). It would not allow decrypt of any data, just prevent access or even delete.

So with node age, data chains etc. the last parts fall into place before we can clamp down on security parts. For instance we reduced consensus, ignore groups consensus on a few messages etc. all for testing sake right now. Even node relocation is currently not secured (accumulated, by that I mean agreed by whole group).

So the security if you like of certain parts we have switched off/turned down or not yet implemented. Sounds scary, but it’s not :smiley: it’s just the rush to get it all working as a unit then we tweak these parameters and do our audits. Possibly we will also pay for audits externally if possible, although we need to evaluate that as we move on. They help but I have seen many such audits recently miss a lot, but they should certainly add something, done correctly.

I hope that makes sense, just the workload right now means we cannot say secure in terms of data resilience or even group consensus being fully in place. It is secure in terms of data being encrypted etc. The network does not know how to decrypt any of that.

Hope that helps a little, a bit like a car being safe to drive, we just have not fitted the seat belts or air bags yet (or have some of them turned off in Alpha1 and possibly 2).

7 Likes

Thanks David. That is more or less what I was thinking.

At the minimum, we can communicate securely across the network.

I was thinking that with MaidSafe running all the vaults, it would be theoretically possible to establish IP addresses of clients, but not what they were communicating. And it would be really difficult to figure out with whom, though maybe not impossible. Not that MaidSafe would be trying at this moment, except as part of analyzing attack vectors.

Just looking for the bottom level at which different pieces can be thought of as rock solid defaults right now.

2 Likes

For what it’s worth, I believe it’s very important to have some sort of external, trusted, high quality audit. It’s for security reasons, obviously, because you’re in a bubble whether you like it or not, but also to show to everybody that Maidsafe is not afraid and even encourages criticism.

2 Likes

Yes this would be the case, we could log IP addresses etc. so it’s currently a weakness and like a centralised server in that respect. What it sees beyond IP would be message types (at the moment) although not easy it is possible. So some metadata and IP addresses.

1 Like

I agree and it will require pretty strict guidelines as to what is audited and how really. One issue we have is the size of the system. For this reason it may require several audits of individual libraries (poor person in routing) and then some kind of all the pieces together audit.

I feel it’s just too easy for a project to get some kind of audit and then declare we are Ok etc. I know you are not talking about that but it does happen and can be misleading. So the plan of auditing I feel will be important and will take time and money an awful lot of money. So this is where bounties come in, do we do both? Would be nice if we could. Bounties would be aided with even better documentation and tests, like fuzzing testing, side channel tests etc. So we need to add that in as well.

This will be a a large lump of work and tasks that will very unlikely be able to be given in one contract.

TL;DR I 100% agree though with your statement.

4 Likes

Yeah, definately, it’s not like shopping in a supermarket. With bounties do you mean bug bounties? Might also be good as a long-term encouragement.

/edit and could also be supportet by the community with donations, for example.

2 Likes

Yes both bug bounties and security bounties with varying levels of payment. I tend to feel these are very encouraging if you come across decent “whitehat” devs. Security audits are really hard and AFAIK seem to be relatively way more believed than they should be, just look at the audits so far on systems that get hacked with alarming consequences, so they help for sure, but just how much is unknown. A bit like taking on a marketing company or similar, hard to know how good it was. If it turns up some stuff then yes we can see value, but are we then secure? I doubt it, but some people will think we are, due to an audit.

I have had very brief talks with Zooko (zcash) about jointly getting libsodium audited, for instance, as a joint venture and would love to see much much more of this going on.

6 Likes