November 19, 2015 at 08:34Secure social networks - myth or reality?
In this article I want to tell how I came up with the idea of a web service for secure social networks. How it was implemented and on what technologies. I will share technological solutions to problems during the development of the service.
The idea of this project came to me after getting acquainted with the current state of affairs in the field of encryption. I ran into two problems.
On the one hand, this is the complete insecurity of users from information leaks from social networks, instant messengers, etc. For example, Skype or Telegram stores all correspondence on its servers and, at the request of the government, provides any data from these correspondence. I also recall the recent hacking of a dating site for adultery Ashley Madison, where the user data sailed away.
On the other hand, everyone knows that the higher the level of protection, the less pleasant it is to use such a product. For example, to sign and encrypt emails using PGP, requires special software and skill. Using Telegram, you must install their messenger and shine your SIM card and, moreover, secret chat mode, with only one user, there is no group mode. Also, changing the device, you no longer look at what you chatted about earlier in secret chat.
A rather interesting solution is offered by Bitmessage. As stated on Wikipedia, “sacrificing some convenience for the sake of security and decentralization” is, in my opinion, a key drawback of this solution.
On the Internet, I met a service that allows you to encrypt text notes and store them in the clouds. Access was through a normal browser and you had to know the password from your notes. The trick was that the service itself guaranteed that it could not spy what was in your notes, since the encryption took place in your browser using your password. And on the server everything is transmitted already in encrypted form. The symmetric encryption algorithm was used. In other words, if someone gets access to your notes, then there is no sense in this, since they are encrypted.
I took these two concepts into service. We store user data already encrypted on our servers. The process of encryption and decryption is on the user's browser side by its password. My task was complicated by the fact that I need to transfer a message from one user to another. They will not encrypt with the same password. For this, I used an asymmetric encryption algorithm. To do this, each user must have a public and private key.
When one user sends a message to another, he must take the public key of the second user and encrypt the message with him. The second user receiving the message uses his private key to decrypt. This is where the symmetric password encryption approach came in handy. You can distribute public keys to them openly, but forcing a user to drag on a USB flash drive or store his private key on a screw is not convenient. To do this, I made sure that the public and private keys are generated in the user's browser and transferred to the server. Public in the clear, and private in the password that the user sets.
Further, I needed to somehow understand that the message sent or the requested list of messages really comes from such and such a user. To do this, all requests from the user are signed with his private key, and my public key is stored on my servers in the clear form with the help of which I check this request or message whether it is true from this user or not.
When the question arose about the choice of technologies, I thought for a long time whether to do everything quickly and on old proven things. Or he can try what is new and what the future stands for. As a result, I wrote the server side in Scala running the Play Framework based on the Cassandra database. The client part on CoffeeScript running AngularJS. Design taken from Bootstrap. Encryption was done using the Forge library in JavaScript. Unfortunately, HTML5 has no built-in encryption mechanisms.
Architecturally, it looks like a JavaScript client that goes on Rest to the server. WebSocket is also used to receive notifications of new messages from the server. Each WebSocket connection generates an Actor, which subscribes to the Akka event bus, and if the event is associated with its user, it sends it to the browser.
I would also like to note the experience of using the Cassandra database. This is somewhat unusual. When you work with a regular database, you throw tables, fields and start any queries on them. If it slows down, then you add indexes. Cassandra has the opposite. Each table is essentially one main query that quickly goes for the given keys in the table. Those if you decided to somehow tear data from it differently with different sampling conditions, then you will have to make another table and other keys to it and essentially duplicate the data. This approach makes it difficult for quick development, as it immediately forces you to think through everything optimally. But you won’t roll out the bragging thing for production :) You
can familiarize yourself with the project source codes here: github.com/evgenyigumnov/protectednet I made the Open Source project and the service itself free.
The idea of this project came to me after getting acquainted with the current state of affairs in the field of encryption. I ran into two problems.
On the one hand, this is the complete insecurity of users from information leaks from social networks, instant messengers, etc. For example, Skype or Telegram stores all correspondence on its servers and, at the request of the government, provides any data from these correspondence. I also recall the recent hacking of a dating site for adultery Ashley Madison, where the user data sailed away.
On the other hand, everyone knows that the higher the level of protection, the less pleasant it is to use such a product. For example, to sign and encrypt emails using PGP, requires special software and skill. Using Telegram, you must install their messenger and shine your SIM card and, moreover, secret chat mode, with only one user, there is no group mode. Also, changing the device, you no longer look at what you chatted about earlier in secret chat.
A rather interesting solution is offered by Bitmessage. As stated on Wikipedia, “sacrificing some convenience for the sake of security and decentralization” is, in my opinion, a key drawback of this solution.
On the Internet, I met a service that allows you to encrypt text notes and store them in the clouds. Access was through a normal browser and you had to know the password from your notes. The trick was that the service itself guaranteed that it could not spy what was in your notes, since the encryption took place in your browser using your password. And on the server everything is transmitted already in encrypted form. The symmetric encryption algorithm was used. In other words, if someone gets access to your notes, then there is no sense in this, since they are encrypted.
I took these two concepts into service. We store user data already encrypted on our servers. The process of encryption and decryption is on the user's browser side by its password. My task was complicated by the fact that I need to transfer a message from one user to another. They will not encrypt with the same password. For this, I used an asymmetric encryption algorithm. To do this, each user must have a public and private key.
When one user sends a message to another, he must take the public key of the second user and encrypt the message with him. The second user receiving the message uses his private key to decrypt. This is where the symmetric password encryption approach came in handy. You can distribute public keys to them openly, but forcing a user to drag on a USB flash drive or store his private key on a screw is not convenient. To do this, I made sure that the public and private keys are generated in the user's browser and transferred to the server. Public in the clear, and private in the password that the user sets.
Further, I needed to somehow understand that the message sent or the requested list of messages really comes from such and such a user. To do this, all requests from the user are signed with his private key, and my public key is stored on my servers in the clear form with the help of which I check this request or message whether it is true from this user or not.
When the question arose about the choice of technologies, I thought for a long time whether to do everything quickly and on old proven things. Or he can try what is new and what the future stands for. As a result, I wrote the server side in Scala running the Play Framework based on the Cassandra database. The client part on CoffeeScript running AngularJS. Design taken from Bootstrap. Encryption was done using the Forge library in JavaScript. Unfortunately, HTML5 has no built-in encryption mechanisms.
Architecturally, it looks like a JavaScript client that goes on Rest to the server. WebSocket is also used to receive notifications of new messages from the server. Each WebSocket connection generates an Actor, which subscribes to the Akka event bus, and if the event is associated with its user, it sends it to the browser.
I would also like to note the experience of using the Cassandra database. This is somewhat unusual. When you work with a regular database, you throw tables, fields and start any queries on them. If it slows down, then you add indexes. Cassandra has the opposite. Each table is essentially one main query that quickly goes for the given keys in the table. Those if you decided to somehow tear data from it differently with different sampling conditions, then you will have to make another table and other keys to it and essentially duplicate the data. This approach makes it difficult for quick development, as it immediately forces you to think through everything optimally. But you won’t roll out the bragging thing for production :) You
can familiarize yourself with the project source codes here: github.com/evgenyigumnov/protectednet I made the Open Source project and the service itself free.