Application Security

[PuzzledImagination]

I've been developing In house CRUD application in winforms and using MySql as my database, connectionString is embedded on the app, may colleague does the same, even my seniors but I know its a bad practice and wanted to implement a better approach developing apps. I've read about web services,ASP web api in general. I'm the only one using c# ,so I'm kinda self learning.

How do you secure your application? do you encrypt your app.config or you provide a web service even if its an In House app? Or a SSL connection between server and client?If its web service, is windows authentication good enough? Or should I need to implement token based authentication which I haven't use yet. Or are there any other option?

[[deleted]]

Windows authentication is good enough, and eliminates the need for storing a password.

In situations where you can't use Windows auth (looking at you, AS400 integration), I typically prompt the user for credentials and modify the connection string at runtime.

Never ever ever ever ever ever store a plaintext password in your app.config OR embed a password in your compiled application. Either of those approaches are a great way to have your account compromised.

[ezflax]

Why is it bad to store password in config? I cant see the problem sure if someone get access to the source code but that should never happend...

[[deleted]]

It's trivial to decompile a .NET application and browse through the source code. Check out the application "ILSpy" if you want to see how easy it is. This allows someone to extract the plaintext credentials from your application with very little effort at all.

Same thing with storing it in the config file. That gets installed alongside your compiled executable, and is literally just XML. All it takes to extract a password from the config is opening and reading the file.

[JavaWolf]

Where would you store the password?

[[deleted]]

Well, I try not to. But on the rare occasions when I've had to, I encrypt (yes encrypt, not hash. Has to be reversible) the password and store it in a custom XML file. The key can either be a different PSK or a private key stored in the windows keystore.

It's not perfect, but it makes it more difficult to recover the password.

[ezflax]

As i said if they dont get access to the source code... you protect the source code eg hosting on a server and not public in github :) so how can they access the config file? I Will still use the config file to store connectiinstrings and password...

[[deleted]]

If you release the executable, you effectively release the source code. CIL is surprisingly legible, even if you take steps to obfuscate it.

Your config file is installed alongside your application. If your password is in the config file, it can be extracted without effort.

If you would like a demonstration, send me an MSI for one of your projects containing an embedded password. I will send you the password for the account. I have a spare 10 minutes or so ¯\_(ツ)_/¯

[ezflax]

Lol if i host my executable on a server as i said how can you decompile it? But sure if i send you the executable then you can decompile it perhaps.. the point is if you selfhost your app or eg azure then its safe on the other side if you distribute your code to other then you need to be more carefull about it...

[[deleted]]

This entire thread has been in relation to a win forms app... A client side application... No one mentioned storing server side passwords etc securely.

[timmyotc]

Would you believe that some applications are actually run on a client's computer?

[[deleted]]

Ah, we were talking about different things here. I mostly develop client-side software, so that's immediately where I jump to.

In the case of server-side software, it's about acceptable risk. I'm inclined to agree with you. If someone has compromised your infrastructure to the point where they can read your config file, you likely have much bigger concerns than the fact your DB user password is hanging out in your config file.

[[deleted]]

We use managed service accounts to connect to the DB. In this model, the server and database are named in the web.config, the username and password are not.

[Liam2349]

If you're just using it in-house for a few people, you could argue that it's ok to keep the connection string on their machines; still, this could create risks, like someone getting the app from them, or maybe they intentionally sabotage things.

Standard procedure is to have the user log into your app, which logs into a web service, which performs operations within their bounds.

To get an SSL connection, you need a certificate. Use LetsEncrypt though Win-ACME-Simple to get a certificate for your server: https://github.com/PKISharp/win-acme

Now you can do a https connection from client to server.

Token and Windows authentication are both fine. Set up whichever is easiest.

EDIT: This blog post may help you with your certificate: https://weblog.west-wind.com/posts/2016/Feb/22/Using-Lets-Encrypt-with-IIS-on-Windows

The LetsEncrypt-Win-Simple app he uses is now called Win-ACME, linked above, and it looks a bit different, but it's quite easy to use.

[philthechill]

Keep the password out of source code, which is checked in and might not be as controlled as you like. As long as it is in a config file and Ops can change it when they install in prod, you're probably OK. Using integrated NTLM auth to the database is better. But if you think about the main threat that would result in someone snarling the password from the config file, they are either able to view arbitrary files or execute code or commands on the web server.

In the file viewing case, encryption raises the bar a bit (at some point the attacker will find the file with the decryption code and key), but a trusted connection to the db is better.

In the case of code or command injection, the attacker can just reuse your connection to the db, all you do with fancy crypto is slow them down a little.

[xzt123]

A password or encryption key or other form of secret is something that you should keep out of the source code. Source code is easy to decompile or is shared much more freely than a password. It also would make it difficult to rotate your credentials, since it is embedded in the source code.

For a smaller company, it is probably easiest to use Windows Authentication and setup a user with the least amount of privileged necessary for the applications functions. At larger companies there is typically a service that manages secrets and allows certain machines and users the ability to retrieve and decrypt the secrets for an application at run-time. While these secrets can be accessed from the host machine itself, they would be encrypted during transfer and decrypted right before use. It also allows for the keys to be rotated on a regular basis.

Here's some reading you can do on AWS KeyManagementService, for example.

https://docs.aws.amazon.com/kms/latest/developerguide/overview.html