-
Notifications
You must be signed in to change notification settings - Fork 19
Security
My security skills are very poor. I will work on it later but if any specialist can help, feel free to send me your advice !
Newebe owner password is encrypted with SHA-224.
When an user logs in, the given password is converted with SHA-224 then compared to stored one.
Don't write your own password checks. Try to use something that's built into a framework like, for example, Django.
Dictionary problem : that you are just hashing a password to store it. If someone gets the local DB, they can quickly try a dictionary of common passwords and see which ones match. Read this: http://codahale.com/how-to-safely-store-a-password/
Tornado stores a secured cookie to keep the connection alive. This rely on a key set in the settings file.
Database could be encrypted and setup to be more secure.
idea => description : http://www.w3.org/wiki/Foaf%2Bssl
Newbe is setup to handle only HTTPS request. At installation a certificate and a key are built then they are used to handle encrypted connection.
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. 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.
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.
http://bytes.com/topic/python/answers/585011-aes256-pycrypto