Burn after reading
Last semester, as a homework for the course of information security in the Technopark Mail.Ru, we were offered to write a one-time reference service. Similar services already exist, but this idea seemed interesting to me both from the point of view of practical application and from the point of view of technical implementation. I completed the task, and, having slightly modified the system, laid out in open access. About what tasks I had to solve and what problems to face, I will tell in this short article.
So, secureshare.pw is a one-time reference service, i.e. A means to securely transfer sensitive data to another person. The bottom line is that the user's secret data is stored in the server database, and the user is given a one-time link by which these same data are available. The link is valid only for one (the default) view, immediately after it the data is destroyed. You can not be afraid that the link will remain in the history of messages of your IM server, in the list of sent letters, in server access logs, on screenshots of monitors. By the time the attacker gets to this link, it will be meaningless.
The basic functionality of the system is very simple. All you need is to save the data from the form to the database and provide the user with a link that uniquely identifies this data. For example, add the primary key to the get parameter. After displaying the data, perform an elementary DELETE request, and you're done. After the first approach, the system worked exactly like that.
')
But somehow it's not serious, is it?
Well, let's think about what's wrong here. The first thing that catches the eye is the primary key right in the get parameters of the request. That is, if you sort through all the numbers in turn, you can gather up a lot of other people's secrets. The solution is quite obvious - to use something large and selectable instead of a number. Let's say sha1-hash (collisions were found in md5 and it is no longer recommended to use it). Great, add a new field to the database, create a UNIQUE index on it and generate it randomly for each new user secret. Already better.
The data in the database is stored in the open form. Not good somehow, it's a secret. If the base leaks, all our secrets will be available to the attacker. What to do? Do not store data in the plain text! Let's encrypt them. Choose a strong symmetric block encryption algorithm, and when displaying data, we will decrypt the data on the fly, since the volume of messages is usually small. Now, if the base leaks, the attacker will have to still sweat to get the necessary data. Not bad. But there is a serious "but." Often, after all, the hacker either has no access to the system at all, or has full access. Including the source code of our service, which performs decryption, including the encryption keys, and then all the data from it will be in full view - you can decrypt them "with one hand." It turns out that there is no special meaning in encryption. What to do?
Each user message is encrypted with a randomly generated key. After encryption, the key is divided into two halves, one of which is stored in the database along with the encrypted data, and the other half is embedded in the link that is given to the client. As a result, it turns out that it will be possible to decrypt the data only having both halves of the key. Thus, the base can generally be laid out in open access and fully disclose the entire algorithm of the system - without the second half of the key, which is in the link at the client, the data in the database is just a bunch of garbage. Fine!
It seems that everything is not bad. We invent a name, register a suitable domain. They became secureshare.pw.
Last detail: worthless serious things on the open HTTP-protocol to drive. Need HTTPS. The first step is simple - we do not allow using HTTP and forcibly redirecting from port 80 to port 443, having previously configured HTTPS on the server. Works. But in the corner there is a bright red inscription indicating that the authenticity of the domain is not confirmed, and Chrome gives out a fearsome red (in the new version - yellow) screen with a warning.
Not good. Our identity must be confirmed by one of the root certification authorities. A couple of queries in a search engine - and we find a lot of offers from various companies. I chose GoDaddy - not too complicated procedure and adequate money. Suitable for a startup ;-)
As a final stroke, add a couple of nice features - the number of impressions before the link is removed from the database (default = 1), the date upon which the link will self-destruct (kronscript every day), even if it was not viewed (default is week), and also confirmation of viewing (protection against unintentional viewing and destruction of data).
Done! We have at our disposal a reliable service capable of transmitting the newly generated passwords, passport data and other confidential information to your friends and colleagues.
Your questions and suggestions, as usual, well. Thanks for attention!
The article was written in the framework of the contest of articles by the Technopark Mail.Ru project students.
What are we talking about
So, secureshare.pw is a one-time reference service, i.e. A means to securely transfer sensitive data to another person. The bottom line is that the user's secret data is stored in the server database, and the user is given a one-time link by which these same data are available. The link is valid only for one (the default) view, immediately after it the data is destroyed. You can not be afraid that the link will remain in the history of messages of your IM server, in the list of sent letters, in server access logs, on screenshots of monitors. By the time the attacker gets to this link, it will be meaningless.
First approach
The basic functionality of the system is very simple. All you need is to save the data from the form to the database and provide the user with a link that uniquely identifies this data. For example, add the primary key to the get parameter. After displaying the data, perform an elementary DELETE request, and you're done. After the first approach, the system worked exactly like that.
')
But somehow it's not serious, is it?
Second approach
Well, let's think about what's wrong here. The first thing that catches the eye is the primary key right in the get parameters of the request. That is, if you sort through all the numbers in turn, you can gather up a lot of other people's secrets. The solution is quite obvious - to use something large and selectable instead of a number. Let's say sha1-hash (collisions were found in md5 and it is no longer recommended to use it). Great, add a new field to the database, create a UNIQUE index on it and generate it randomly for each new user secret. Already better.
Third approach
The data in the database is stored in the open form. Not good somehow, it's a secret. If the base leaks, all our secrets will be available to the attacker. What to do? Do not store data in the plain text! Let's encrypt them. Choose a strong symmetric block encryption algorithm, and when displaying data, we will decrypt the data on the fly, since the volume of messages is usually small. Now, if the base leaks, the attacker will have to still sweat to get the necessary data. Not bad. But there is a serious "but." Often, after all, the hacker either has no access to the system at all, or has full access. Including the source code of our service, which performs decryption, including the encryption keys, and then all the data from it will be in full view - you can decrypt them "with one hand." It turns out that there is no special meaning in encryption. What to do?
Fourth approach
Each user message is encrypted with a randomly generated key. After encryption, the key is divided into two halves, one of which is stored in the database along with the encrypted data, and the other half is embedded in the link that is given to the client. As a result, it turns out that it will be possible to decrypt the data only having both halves of the key. Thus, the base can generally be laid out in open access and fully disclose the entire algorithm of the system - without the second half of the key, which is in the link at the client, the data in the database is just a bunch of garbage. Fine!
Fifth and final approach
It seems that everything is not bad. We invent a name, register a suitable domain. They became secureshare.pw.
Last detail: worthless serious things on the open HTTP-protocol to drive. Need HTTPS. The first step is simple - we do not allow using HTTP and forcibly redirecting from port 80 to port 443, having previously configured HTTPS on the server. Works. But in the corner there is a bright red inscription indicating that the authenticity of the domain is not confirmed, and Chrome gives out a fearsome red (in the new version - yellow) screen with a warning.
Not good. Our identity must be confirmed by one of the root certification authorities. A couple of queries in a search engine - and we find a lot of offers from various companies. I chose GoDaddy - not too complicated procedure and adequate money. Suitable for a startup ;-)
As a final stroke, add a couple of nice features - the number of impressions before the link is removed from the database (default = 1), the date upon which the link will self-destruct (kronscript every day), even if it was not viewed (default is week), and also confirmation of viewing (protection against unintentional viewing and destruction of data).
Done! We have at our disposal a reliable service capable of transmitting the newly generated passwords, passport data and other confidential information to your friends and colleagues.
Your questions and suggestions, as usual, well. Thanks for attention!
The article was written in the framework of the contest of articles by the Technopark Mail.Ru project students.
Source: https://habr.com/ru/post/209924/
All Articles