Security in Newebe
robinbb
potential to become. In its current form, Newebe is unattractive to me
because of its lack of (1) focus on security, and (2) ability to
authenticate users.
I am a software developer (http://robinbb.com), and I could help
improve things. I would like to ask here: does anyone already have
specific plans to augment Newebe with security or authentication
features?
Pierre
> Hello, I am new to Newebe and very interested in what it has the
> potential to become. In its current form, Newebe is unattractive to me
> because of its lack of (1) focus on security, and (2) ability to
> authenticate users.
Hello,
first of all, thanks for your interest in Newebe and for your commentaries.
> I am a software developer (http://robinbb.com), and I could help
> improve things. I would like to ask here: does anyone already have
> specific plans to augment Newebe with security or authentication
> features?
Security is, of course, a primary problem to address. Our first step
would probably be to allow to use https to access newebe pages (user
request).
As many side projects, newebe started as a proof of concept, and, due to
our lack of knowledge in the area of security, we are not sure how to
start to integrate it to the plans. So, if you have any skills to share
about it, they will be more than welcome.
I'm sure, Frank, the developer, will shortly give you a more complete
answer about it.
Pierre.
Gelnior
I'm glad you get interested in Newebe and I thank you for your email.
As Pierre said, my knowledges about security are quite poor so any
help about the subject could be useful.
To start I can give you some informations.
What exists now :
* Newebe is based on Tornado, so it herits from its security features.
http://www.tornadoweb.org/
* Password of Newebe owner is encrypted inside database.
* To keep user session alive, an encrypted cookie is stored inside
browser (Tornado secure cookie).
* Each node has a key that is sent to his contact when contact is
added. So when a contact send a document to a node, this checks that
the key of the sender is one of its trusted contact.
NB : As you can see, Newebe is far to be safe.
What we could explore and do :
* Friend of a Friend + SSL: I am not sure that it is the answer to the
problem but It could inspired us. I met a security specialist in an
Hackerspace that suggests me to use contacts to make a double
authentication. When Node A sends a document to Node B, once Node A is
authenticated to Node B, Node B asks to Node A to authenticate to Node
C, which is a common friend. I think FOAF is close to this idea.
http://www.w3.org/wiki/Foaf%2Bssl
* HTTPS : actually with Tornado you can activate HTTPS with two lines
of code, but it will require that each of your contact stores your
certificate. It's probably not so hard to implement but actually
nothing is done.
* Database : Newebe use CouchDB, but right now we don't recommend any
configuration for the DB. But I'm sure that some parameters could be
set to have a more secured one. CouchDB has propably features for
encryption or any other things I don't suspect.
* Refactoring: Newebe needs to have a better seperation between its
communications and the logic of the application. Once I would have
done that it will be easier to augment its security. I could focus on
that if you decide to help us.
Frank
Aurélien Tabard
it's great to see someone interested in pushing security within Newebe.
Frank provided a nice overview, so I'm just going to point out that
there has been quite some research within the distributed sensor network
community covering security.
I'm not sure whether how relevant it is to the basic security problems
at hand today, but a quick google scholar search provides some
interesting academic papers:
http://scholar.google.com/scholar?q=distributed+network+security
scholar.google.com/scholar?hl=en&q=f2f+security
Best wishes,
Aurélien
Robin Bate Boerop
> As Pierre said, my knowledges about security are quite poor so any
> help about the subject could be useful.
Okay, I'll give some suggestions.
> To start I can give you some informations.
>
> What exists now :
> * Newebe is based on Tornado, so it herits from its security features.
> http://www.tornadoweb.org/
Okay. I'm not familiar with Tornado, and my Python is weak, but I'll
look into its code/docs as needed. I don't have lots of time to commit
to Newebe, but I'd like to offer advice that is easy for me to offer
without too much effort on my part.
> * Password of Newebe owner is encrypted inside database.
Not that that matters much, since the password is passed over an
unencrypted connection to Newebe! :)
> * To keep user session alive, an encrypted cookie is stored inside
> browser (Tornado secure cookie).
Okay, but understand that the encryption of that cookie is not helping
things since the connection to the server is not encrypted. An
attacker has access to the cookie, as well as the password that was
originally used to obtain the cookie. If anything, the fact that the
cookie is passed to the server with every connection makes it *easier*
for an attacker to obtain access.
> * Each node has a key that is sent to his contact when contact is
> added. So when a contact send a document to a node, this checks that
> the key of the sender is one of its trusted contact.
Yes, but again, it is sent in the clear, so the key is leaked, and an
attacker has access to this.
> NB : As you can see, Newebe is far to be safe.
Yup. Above, I'm making clear where some of the insecurities are. I
know that you know. But, for the sake of the wider discussion, I'm
making plain some of the issues.
> What we could explore and do :
>
> * Friend of a Friend + SSL: I am not sure that it is the answer to the
> problem but It could inspired us. I met a security specialist in an
> Hackerspace that suggests me to use contacts to make a double
> authentication. When Node A sends a document to Node B, once Node A is
> authenticated to Node B, Node B asks to Node A to authenticate to Node
> C, which is a common friend. I think FOAF is close to this idea.
> http://www.w3.org/wiki/Foaf%2Bssl
I'll comment on FOAF+SSL below.
> * HTTPS : actually with Tornado you can activate HTTPS with two lines
> of code, but it will require that each of your contact stores your
> certificate. It's probably not so hard to implement but actually
> nothing is done.
I think that the SSL abilities of Tornado should be activated
immediately, in Newebe. The issue that you point out, about storing
certificates, is not strictly necessary. Since Newebe is very insecure
now, it would be an improvement to use SSL to communicate (everywhere:
client-server and server-server). You could simply *always* trust
whatever SSL certificate is presented to you. This means that you
might be tricked into communicating with the wrong party, but this is
still more secure that what we have now.
This will mean that each server must have an SSL cert. You can use
ssh-keygen to generate one, or allow people to use one that they
already have. This could be configured in settings.py.
Later, you can devise a mechanism to allow the user to configure the
certs that they trust. This is where FOAF comes in.
> * Database : Newebe use CouchDB, but right now we don't recommend any
> configuration for the DB. But I'm sure that some parameters could be
> set to have a more secured one. CouchDB has propably features for
> encryption or any other things I don't suspect.
In my case, my CouchDB comes configured to respond only to requests
from the host on which it resides. That provides some sort of
security. Later, it would be useful to configure Newebe to use SSL to
connect to CouchDB (especially one on a different host). This is lower
priority that activating SSL in Newebe, as explained above, IMO.
> * Refactoring: Newebe needs to have a better seperation between its
> communications and the logic of the application. Once I would have
> done that it will be easier to augment its security. I could focus on
> that if you decide to help us.
Well separated concerns in code is a good thing. However, security is
one of those things that is "built in" to code, and pervades it.
Separating security with app logic might be impossible in many cases.
Still, if some refactoring needs to be done in order to make some
security changes, it would be good to do that. Notice that I am not
volunteering, mind you. :)
Now, back to FOAF. It was created to solve the problem of distributed
trust. Once SSL is working in Newebe (without certificate
verification), then someone should evaluate the various methods that
we might use to create trust in Newebe. FOAF+SSL is one such method,
and probably a good one to adopt. There are others.
Here is my recommended course of action for the near future:
* If no cert is specified in settings.py, Newebe can make one with
ssh-keygen and store it in the DB or in a file.
* Change the code so that all connections made by Newebe are HTTPS
connections which do not verify the certs.
* ... Except for the connection to the CouchDB, which need not be
encrypted, yet.
* FOAF has certain requirements of the cert, but we should ignore
these for now, and fix those issues later.
Frank
for reference when I will do developments about security. I think I will
try to enable HTTPS connections soon. This work is not trivial because
it probably requires some Tornado tweaking, that's why I can't do it
immediately.
Frank
Robin Bate Boerop
> Thank you Robin for these advice. I put this conversation in the wiki for
> reference when I will do developments about security. I think I will try to
> enable HTTPS connections soon. This work is not trivial because it probably
> requires some Tornado tweaking, that's why I can't do it immediately.
Of course. Thanks for the reply.