WPF - Save user credentials at first start persistent - c#

What is my purpose?
I would like to save user credentials at the first start of my application.
What is the starting situation?
At the first start I have a configuration dialog, which allows the support-employee of my company to configure the application firstly. At these dialog he can also set sundry credentials. I need these credentials for every user, who starts the app. (it is a network-based application)
May some solutions?
I know, there are 'user settings' in WPF. But these are not persistent. That means, I lose the credentials, if the application is closed and another user is starting the app. But I need these credentials persistent. And for every user.
Of course, there are also 'application settings'. But these settings I cant set dynamically at the first start of my app. So I need to set the credentials for every customer at the development and compile one executive per customer.
Furthermore I can also save these credentials in a special database. But to create a database, only for this purpose seems a little bit to huge for me.
Would be really nice, if somebody could help me. :-)

You could store it in a local SQLite database, it takes just a few lines of code and one table but either store the hashes or make sure credentials are encrypted.
Also, user settings are persisted and as long as the other user is using his or her own Windows logon their user setting will not overwrite user settings of other users. However these are stored in a plain text config file so if storing credentials you should at least encrypt the values...

Related

Mongo DB Database Protection

So Ive created a c# WPF application and I wanted to add a way for me to control who had access to it just in case the exe for it got leaked or something. So I created a MongoDB database and made a document called Password. Upon clicking the start button in the window it checks the password you've entered to the password in the database. It works perfectly fine for my uses.
However the problem presented itself when I learned about Decompilers. From what ive read my database connection link to MongoDB could be accurately decompiled. This would give the cracker access to my database with admin permissions and and would allow them to connect to it as well. What is the best way for me to prevent this from happening, and hide my secret in a way that makes it impossible/extremely to decompile?
Configurations and secrets including passwords should be stored outside of an application's code. Instead read secrets from a config file or via a login screen.

C# desktop application - how to save default admin username and password

I've been tasked with setting up default admin credentials for a .NET desktop application. As of right now, the application uses Windows admin credentials to access the manager page and I would like to add a local default admin account.
I imagine the user will go through the following process:
(1) Clean install of application
(2) User launches application
(3) App is in "logged out" state
(4) User logs in as manager with the provided default credentials (provided in user guide)
(5) Once logged in for the first time, prompt user to update local default credentials to a more secure password
After doing some research on google and stack overflow, I read that I definitely should not hard code the user credentials in the source code. I'm thinking of storing the default username/password in the app.config file. Then, in the manager page, the user can update the current username/password to something more secure. There will only be ONE local admin account so the username/password from the app.config file will need to be updated?
In other words, the default user credentials will be stored in app config. Then, modified whenever the user updates the local credentials. Does this approach work for the situation I described above? If not, I would appreciate any ideas. I've looked into DPApi as well but would prefer a simpler approach.
If you don't want use Active directory, AZMan or other popular solutions, you can store credentials in multiple ways:
In binary file with your own coding pattern.
In embedded databases such as SQlite.
Save credentials in windows registry.
Storing sensitive data in app.config is bad way.

Where should my c# application write data so that the user can not modify or access it

I have an Application that needs to store User Info such as their Username and there score and etc...
I have selected LocalApplicationData of the Environment.SpecialFolder Enumeration.
but I can access the directory for my application manually using file explorer and can edit or delete the file that can prove as a weak spot for the application and the users may be able to mess with my application.
So, Is there any directory that I can write to using code that the user will not be able to access it.
tnx
Is there any directory that I can write to using code that the user will not be able to access it.
No. An application run by a user account has the same privileges and permissions as that user. Therefore, there is no way that the application could do something the user couldn't do on his own.
If the data you need to store is intended to be browsed or modified by the user, it should go in Environment.SpecialFolder.Personal.
Otherwise, data should be stored in either Environment.SpecialFolder.ApplicationData (if it should roam with the user account) or Environment.SpecialFolder.LocalApplicationData (if it should not roam with the user, and instead should be limited to the local machine).
Yes, the user can get into these folders and destroy the data. By doing so, they run the risk of breaking your application. You can't secure yourself from yourself.
Develop a "repair" utility that can recover from the damage by recreating the necessary files on startup of your application if necessary.
As your application is running with your users privileges, there is no place your application can access that your user would not be able to access.
Your only option is to use encryption so your user cannot tamper with the file easily once it's written. But even then... what you did with the user's privileges can be undone by the user with the same privileges. You can only make it hard enough so he or she won't bother.
You can not prevent use open the file, but have some method to check if a file is being modified by user.
You can save it at Registry, or if your data is big, you can encrypt it before save to file. When you encrypt data, user can not know which infomartion it contains, and if user open the file and modify it, the data become invalid and you can know it is modified.

Change configuration in Active Directoy with code?

I have a very strange requirement and I want to know how
feasible its.
A customer wants a web application, but in it, they want the administrator to be able of:
Create users in Active Directory
2. Be able to change users password or generate random ones and then it must be changed on AD
3. Be able to change minimum login length and maximum login length for new users in AD.
4. Be able to change password complexity in case users change their password, then the web app should show an error message.
Update 1. More questions About Nr 3. Users want to be able to define if login length is between 5 and 10 characters from the web application, is there an API for this on AD?, I am not an AD expert so I dont even know if AD has the option to configure the username length.
More questions
5. Can I with AD API, view and audit log?, when were users authenticated, was login succesfull or failed?
6. Configure the number of attempts before the account is locked? and alert and administrator when an account is locked due to # of failed attempts.
7. This one is like a stupid question, can I make a functionality for users to recover their passwords via email? (literally they asked me that), but if the account is locked they wont be able to access their email either, lol
8. Configure via API when the user must change password or when it expirtes
9.
Completely feasible
Completely feasible
Not sure what this is - can you provide an example? Still don't understand.
You can enforce complexity on password change programmatically. If you want to dynamically change the password policy, this is also possible.
You would need to consume the event log on each domain controller. You could look at something like Windows Event Forwarding to aggregate the data in one place.
Configure, yes you can do this programmatically. Alert, you'd need to build a trigger on the appropriate event ID.
Passwords are stored in an irreversible (and inaccessible) manner in AD.
Yes you can configure when they need to change it, but, you can't alter the expiration date.

Implementing a local password within an application

CONTEXT:
I have a c# .net application made for a customer. The application has no network communication. In fact, the computer it runs on wont likely have any internet or network access.
In comes our customer with a very specific and non-negotiable request:
Request a administrative password before opening up certain screens and grant certain rights. This password must be within the application. The default password (i'll probably set it to 'password') must be changeable, so it can't be hard coded. And there ought to be some way to return to the default in case they forget the password.
It seems kind of superfluous to me just to stick a encrypted password in a file, in the application folder. Anybody who deletes the file would erase the password.
Is there some widely known strategy for this?
Again the password is local and not authenticated on any network.
Maybe hide it in the registry? If the registry key isn't there, then just remake it and set it to the default password. Hardcode the default password, maybe encrypted or something so someone who scans the .exe can't finde it. Also ask your client for what the default password should be, not simply make one.
The problem is, as long as you store something locally, everyone who really wants to know it, will find a way to get it. :/
If it is on windows (is it?)
Key Storage and Retrieval
MSDN Security Briefs Article (part 1)
MSDN Security Briefs Article (part 2)

Categories

Resources