Your code has lots of security and performance issues, he said...

Introduction

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)

1. 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)
2. 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
3. And also we should prevent authentication attempts, for example after 10 time attempt of one user, we block that user.
4. 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.
5. In Database I found many non-indexes fields like Group in Table ProjectDevices. (can be better in performance)
6. About the tokens in API header I recommend you to Encrypt it while sending.
7. 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.

Stay tuned.

Comments

[J Beetz]

Hi Slavius,

At the risk of seeming confrontational (i'm trying not to be). I'm curious to understand your reasoning to discount the concerns raised in points 2 & 3.

Short passwords with little to no complexity are useless.
check this link to see how quickly a short password can be guessed.

Allowing continued login attempts simply ties up resources and allows the attacker to eventually guess their way in. So, at the least your service will run slower than it should and at the worst the attacker can eventually get in. Rate limiting logins can go along way to securing resources by deterring brute force and rainbow dictionary attacks.

Of course context is key for this type of concern. Is the API accessible via public ip address? If not, it's probably ok to not worry so much about rate limiting, but password complexity is a must regardless (in my opinion).

As for Item 1, I too have thought that HTTPS alone is not enough to secure certain types of data in transit. Although the profession at large doesn't comment on it, i wonder if there's something to that question. This SO Question seems to negate the concern.

I'm looking forward to reading your findings in future posts.
Respectfully,

[Slavius]

Hi,

thanks for your feedback. We'll get to the password part soon when I finish my next post. ;) Spoiler alerts - it was a misunderstanding what the password length check in that context means and what is it used for.

Stay tuned!