The curious cases (2 Part Series)
Recently we hired an external freelancer to our team to help with a backend server project done in .Net Core and PostgreSQL database server. Our solution consists of many projects including an MQTT protocol based server, a threaded TCP server, a calculation/processing engine and a public rest API.
After just two weeks this person suddenly changed his attitude and said he's too unhappy with the security and performance issues in the project so that he has already decided to leave. In person, we never managed to get from him a list of issues he was referring to. We unfortunately had to threaten him not paying for his works unless he provides some evidence to his claims. We were too afraid that our project suffers from some overlooked problems we missed and if he has the expertise and experience to advice us we simply wanted to know.
After few days an e-mail arrived thanking us for cooperation and a brief list of what the person found so unacceptably bothering about the security and performance in our project. Here's an unedited excerpt from the e-mail:
First of all, you shouldn’t be worry about the security. I just told you generally.
But I strongly recommend you to follow these changes on the code and DB to have a better quality. (this is just a help)
- I guess that we transfer data from GUI to the API server probably with HTTPS , but this is not enough. Because a person can easily get a SSL certificate with DNS spoofing and listen to the packages. So the first thing is , We are sending our password for login or any other transaction as a plain text and then we will only encrypt it on DB. We must also encrypt the passwords on the client-side with another salt or another type of encryption when we want to send a request like LOGIN function. (recommend different salt for different customers)
- 3 char password for users are really short. Because with authentication attempts attacks , a person can find a password after a short while , at least 7 or 8 chars recommended
- And also we should prevent authentication attempts, for example after 10 time attempt of one user, we block that user.
- There is something also that maybe is not very important, but just for you to know, there is something called Man-in-middle Attack or spoofing , for preventing any issue in this case, it’s better to validate any request to server. For example in project/Add we just check if the body.Device is not null then we do our process , But imagine that if body.Device is really not null, and the data on the package was not a correct data. This type of data can harm the DB data or add some invalid values. For this item , because you normally know your customers, it’s not an important issue. But it’s still important.
- In Database I found many non-indexes fields like Group in Table ProjectDevices. (can be better in performance)
- About the tokens in API header I recommend you to Encrypt it while sending.
- And also because of better security I recommend to have a node to node client certificate (x509. Certificate authentication)
I have decided to personally go through the list and examine, investigate and eventually fix the problems in each point. After reading it through though - I realized this person just lacks the knowledge and the threats he describes are not real.
I decided to write a detailed explanation to each point in individual articles so you may find some of these useful when working on your project that you understand the topics and you're not missing anything regarding security and performance.