

Diaspora Security - will this work? - kuahyeow
http://github.com/diaspora/diaspora/wiki/Security-Architecture-Proposal

======
rakkhi
Diagram Why have a secure client and web browser? Why wouldn't both interfaces
only be via the web and secured with TLS? Doesn't the local "secure" client
provide a backdoor and increase attack surface? I could understand an out or
band channel eg a management interface or SMS for two factor authentication
and out of band messaging. I'm not sure that in social networking adding
client into the permissions for Data, Posts and Comments make much sense

What interface is the seeds outside the pod communicating on? Should in not be
via the web or secure interface? Or is this another API for seeds in different
pods to communicate?

Why is there a database per pod?

Think the goal of encrypting only sensitive data and depending on the users
risk appetite makes sense but it is not compatible with your low complexity
goal. Also it is harder to explain to users and when security is left unto
users in practice the lowest or default security option generally gets chosen.
So this may work if encrypted and no access is the default

Minor point - why invent aspect when group works?

The security model looks like standard mandatory access control. I'm not sure
this works well in social networking. A better model maybe discretionary
access control with inheritance of permissions and management by Aspect,
Audience and User. Permissions should be able to be granted or revoked at the
Data, Post and Comment level

"Dual authentication is required. Users authenticate via a login name and
password." If by duel authentication you mean two factor, this does not
achieve that.

"Audience Seeds must request the Post and any encryption key from the Owner
Seed." This sounds like manual key exchange, a better approach maybe any posts
to an Audience is encrypted to the public keys of all members, so when the
notification is received posts can be automatically decrypted by the private
key of each Audience member

"However, this has the ramification that any change in Audience of a Post
would also change the Audience of any Comments by other Users. This would
suggest that Audience changes should not be allowed, but a easy method for
enforcing this is not evident" You could let each Owner who comments change
the access level of their comment. If this is set to a higher level than the
post the comment is not visible to the additional audience

I would also be interested in the high level requirements that drove this
architecture eg for a secure distributed social network some basic
requirements I would have thought are: [+] least privilege access to data
posts and comments based on explicitly authorized access for the audience set
by the data owner. [+] the most restrictive permissions set by a owner, aspect
or audience of the data to apply [+] secure in transit all data [+] secure in
storage and backup unless owner sets as insecure [+] access to all data shall
be authenticated and authorised and limited to least privilege on each access
request for data (a vulnerability in the first release where simply by
changing user ID other users content could be accessed [+] authentication and
authorisation shall be based on open standards and federated eg open ID and
oAuth [+] Multi factor authentication shall e supported [+] Sharing of of Data
and access to functions with authenticated users, aspects and audiences shall
be simple [+] Access granted to Audiences and Aspects shall be inherited by
users belonging to those [+] Ideally the creation of Aspects and Audiences
shall be self forming based e.g. on algorithmic analysis of common interests
and existing connections

~~~
kuahyeow
I think a pod is a host, like wordpress.com is a host of WP blogs, hence a
database per pod. A seed is an individual user account. The way I understand
it, each seed can be encrypted so that even the pod owner can just look in the
database.

The really interesting bit comes from key and information exchange between
seeds. I agree it's going to be hard to explain all this succinctly to users.
Theoretically, the goal is secure and decentralized social networking. One use
case would say, a friend on another host can see your photos, but no one else
on that other host. Can this ever be done in a foolproof and secure way? I can
think of a lot of different things that can fail - malicious impostors, users
setting the loosest security, revocation, but it might be good enough for a
vast majority of users.

------
tedunangst
If it works as I think is described in the high security model, you will have
to upload a copy of your update for every single friend. And when you add a
new friend, you will either have to reupload all the old posts or your new
friend will be presented with a blank profile.

And if it doesn't work like that, there's not much difference between low and
high security that I can see.

~~~
bonzoesc
You can reduce this workload by using an asymmetric algorithm like RSA to
store an intermediate key.

Post = P Symmetric encryption of X with key Y = E(X, Y)

Posts are stored as E(P, K_master) Authorizations to posts are stored as
E(K_master, K_reader)

You can trust your friends (that don't own quantum computers) with your RSA
public key, allowing them to E(K_master, K_you) data that can only be
decrypted with your private key.

It is weak to a known plaintext attack (in which a user Eve with both K_master
and E(K_master, K_alice) could attack Alice's private key), and of course weak
to an authorized user sharing the master key. It's also weak to copy and
paste, just like every other private social network.

~~~
tedunangst
I assumed you would at least want to block people leaking the master key, even
if you can't stop copy paste.

~~~
bonzoesc
Since it's only for that particular item, it doesn't offer any reason to leak
it and not just the item content.

------
elbenshira
All this high-level stuff is great and all, but honestly, after that developer
"preview" release, I am extremely nervous about putting _any_ personal info on
a seed (or whatever they call it).

I feel that they've lost a lot of trust, and they will need to do something
more than a super high-level wiki page on github to win this trust back.

~~~
n8agrin
Don't spread FUD. These guys are at least trying to do something in a market
where almost everyone else has assumed Facebook has won. And they built and
shipped something. I can't even remember the last time I could claim that
100%. Finalize your opinion when their final release is available.

~~~
mayank
I'm curious -- what is your faith in them based on? I feel sorry for the
amount of expectations they were shouldering, but are you being supportive
because you truly believe in their (unproven) technical abilities, because you
hate Facebook so much, or are you just being nice because startup criticism
can be really soul-killing? If a large corporation had released alpha code
like that, would you trust the corporation with your data, even down the line?
As much as it may be a nice Don Quixote story, results and credibility are the
only things that matter here. The four of them are probably wonderful people,
but that means squat when it boils down to code.

~~~
n8agrin
Faith? Support? I certainly don't have faith in them any more than I have
faith in you. I know neither you nor them. How could I have "faith" in an
unknown? However, I believe that most of the time people attempt to be good.
And given that they are willing to let us see their code (unlike many other
institutions) I would argue they are living up to my belief at least for now.
So they released an alpha that had security issues? The model of open source
validated itself; they received critical feedback and will hopefully act on
it. If they do not act on it, so be it, I will not trust them with my
information. But I don't believe in cynicism especially cynicism aimed at a
self-advertised alpha project.

Does that mean I support them? Very well then, I support them! Go hunt some
giants! Change the world! Go make things better while your critics sit on
their hands and tell you can't, too afraid to build things themselves!

~~~
mkjones
Being good and being able to write secure software are very different,
somewhat orthogonal, qualities.

------
nl
It seems kind of hand-wavy in parts. Looking at the Seed-to-Seed
communications this part doesn't seem too well thought through: _Note -
Audience authentication may be required to reduce the load of serving requests
from non Audience Seeds._

What does the audience authenticate to? The origin or the serving seed?

How is revocation handled?

When person A comments on person B's item, who gets to decide who sees that
comment?

