Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am developing an application which will require an entry for a functional "service account" from active directory to be used via impersonation to perform certain functions of the application that require elevation. It would basically give users of the application abilities restricted by app functionality without having to give their account rights. In the past I've used an SHA1 encrypted hash and stored the encrypted password in the web.config. This is probably no where near as secure as other methods out there. The primary goal here is to be able to store the user id and password for the service account in the app without storing it in clear text anywhere. Any recommendations on this?
ASP.NET Core's configuration setup allows multiple different sources for config: JSON, environment variables, etc. For storing secret information, some are better suited than others, so here's your main options:
User Secrets: this is a no-brainer for development. Any type of account information, API keys, etc. should be stored in user secrets in development. The chief problem is that this is only for development. As a result, you still need to find a solution for production.
Environment variables: While not encrypted, environment variables at least keep these settings confined to a particular server (where you might already be storing credentials for a service account like this anyways) and out of your source control. Still, some users may prefer a bit more security.
Azure Key Vault: Currently, this is the only distributed configuration option provided by ASP.NET Core that supports encryption. It's of course not free, but it's not that expensive, either. If you are already running in Azure, this is a no-brainer, but it's still a good option even if you're not.
Anything else you want to use: One of the nice things about ASP.NET Core is that everything is modular and swappable. You can use built-in configuration providers, those provided by third-parties, or even custom ones you create yourself. That latter fact, in particular, opens a world of possibilities to you, as if you simply take the time to write your own provider, you can actually continue to use something like a Web.config as you're used or integrate some other solution you want to use.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
Suppose I have an API endpoint such as Facebook Graph API, which I design an application running on my PC to periodically connect to the API and retrieve my posts, comments, etc. On each Timer_Tick, the program reconnects to the API and brings the top 10 data items from the API, and persists these data into databases.
Now, suppose that this application is built by 3rd party, and I just downloaded from the internet as binary file not opensource.
How can I know if the application is leaking my Facebook data to third party without my knowledge?
Is there a mechanism to monitor such leaking if found? (from programmatic perspective)
This is a matter of security and for being sure you almost must think about any vulnerability here and try to make sure there is no way to reveal data by the known vulnerabilities but you cannot be sure about unknown ones.
If this is the matter of the trust and you are dealing with sensitive data i strongly recommend you to avoid using 3rd party tools unless they are provided or certified by the API provider. here are some techniques witch will help you understand about what is going on in the backyard but they will definitely not guaranty the safety :
1- First of all make sure the application is really a binary code (i know you mentioned it as a binary), it's because some executable files are just scripts or semi-scripts but look a like a binary files. for instance in the some cases if the source of the executable application is written with C#, Python, Java, there are tools out there that will help you DeComplie the application and find out what's going inside. this solution of course can be considerably tough if for example the code is obfuscated or there is complex models or OO programming models involved.
2- Use network monitoring tools like WireShark or any other tool to capture all traffic of HTTP/HTTPS requests while using the 3rd party application. because the API is just the same as HTTP requests used by applications to exchange data you can use these tools to monitor what's going on in your computer. normally this application must only connect to the Facebook servers and URLs needed to use the web API, if there is any other request sent or received from a server other than the Facebook there is chance of data leak here. if these requests are not encrypted by SSL/TLS you would be able to see the data being exchanged or if they are encrypted through SSL/TLS there are tools that provide man in the middle attack solution to see these traffics but if they are encrypted in the application layer you won't be able to see what data are being transmitted so it might involve suspicion about data even higher chance of data leak. don't forget that this monitoring must be extended for the entire using cycle of the application.
Also limiting the application to talk only to the server in witch you are calling the API with OS Firewall will be step forward to decrease the chance of data leak here.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Preface: I'm new to developing for secure commercial applications, and I understand that I may be too sensitive.
I'm working with a supervisor as a freelancer on a project that uses very truncated version of Forms Authentication and an SHA1 hash sans salt. The project uses no other security, and I've been explicitly ordered not to use any built in security that would ordinarily come with an MVC application, along with a few of the rendering/scripting libraries and the built in methods for role authentication or data annotation.
To the best of my knowledge, the application will not be interacting with legacy code, and the choice to use these methods does not lie in backwards compatibility with any already existing code bases.
The project uses a home brew method for encryption, roles, and security that uses a version of SHA1 and overrides or does not make use of many of the Forms Authentication methods.
Data stored by the application will include financial and personal records for a variety of entities and individuals ranging from small businesses to government entities.
I have mentioned several times that I am uncomfortable with the fact that the application does not use most MVC security tools, urged my boss to let me use more security, and have documented my issues with the project.
I have also spent hours reading on Asp.Net Identity and other tools in preparation for customizing them according to the project requirements while maintaining things I consider necessary, but was refused permission to do so.
Despite my worries, I want to finish the project if at all possible, preferably in a way that does not expose the users too badly or myself to legal ramifications for the kind of data that could be exposed here.
Given the following conditions, I would like to know if there are any specific ways to increase the security of this project:
Can't use OWIN/OAuth or Asp.Net Identity.
Initial authentication must be performed against the same table where sensitive user and financial information is stored in plain text. All subsequent authentication and roles management is performed against the home brew code, which stores session variables.
No salt may be used with passwords.
Password length is the only requirement for creating passwords, and the required length is very short.
Can't track or limit how many times a user can try to access or log into the system.
Can't use two-factor authentication.
Can't set the authentication ticket or security cookie to expire promptly.
Can't use data annotations for roles, authorization, and to some degree for validation on incoming data (some things have been nixed, others not).
Can't use anyone else's tools for security.
Can't create or limit roles using any of the built in classes/must use home brew method for limiting roles only.
Can't use the User.Identity object or methods.
In general, because of the nature of the data being stored, I am worried that the home brew security, coupled with the absence of current security tools, has created a situation in which it is extraordinarily difficult for sensitive information not to be exposed.
My communication with my supervisor is very poor. I'm hoping that any responses will give me more/better ways to communicate the vulnerabilities I'm seeing. No doubt I'm being annoying to my boss at this point, likely a contributing factor in our communication break down, but I'm very, very worried about all this.
And again, I am prepared to hear I'm being over-sensitive or that I am in the wrong. I am keenly aware that as a new developer, I have yet to develop a full understanding of the field. The vast majority of my experience has been academic, and I know that the classroom is not necessarily a good model for the actual practice of software development.
I'm also prepared to hear I should just finish the project and leave my boss alone.
But to the best of my knowledge, whatever that can be said to be, what I'm creating will be trivially easy to break, and I feel obliged to try and do something to make it a little harder for all the reasons above.
From what you've written here this sounds like the kind of project you would not want to be involved in. The constraints you listed sound like they are building a web app from the 90s. It sounds like they have covered all the bases as far as things you don't want to to if you plan to make you application secure go.
The only thing I can think of to say is that you should make sure they use https. Also, Captchas haven't been listed here explicitly, but they probably fall under 3rd party tools.
You should probably revise the homebrew codebase to see if you can strengthen it?
And you should probably have a long hard think about whether this job is worth the trouble or not...
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am about to start development of application in C# and .NET. The application is going to be big in terms of how user will configure it to display on the screen.
I need some way to store configuration data and I have only explored 2 options yet and it is XML files and INI files , which one of these is better? Is there any other new way to store data that works great with .NET Framework?
This is a really broad question, but basically the way I see it there are a few prime places to store application data. Exactly what and how you store is going to depend on the type of data. The following is my personal short list:
Registry - The windows registry can be used to store single key/value pairs or small amounts of read only data. You really can only write these settings when your application is installed unless you are running in administrator mode (which isn't a good idea).
App Config - Similar to the registry this allows storage of application data that is generally best written during installation or during configuration but not much after that. The nice thing about this is the system administrator can often find these files and they are xml which means they are easier to edit (and read) than other files.
Isolated Storage - If you are storing application, user or machine specific information and you don't mind writing your own file readers and writers (or you are interested in delving into xml storage) this is an excellent option for you. It allows user specific settings and it doesn't require the user to have special privileges on the computer.
Local Database - If you want values that you can look up easily, read and write often and are stored simply a local database can be excellent. You might consider looking into SQLLite or a similar tool for this.
Network Database - This is pretty much as advanced as it gets. If you want user information to be automatically processed regardless of where the user opens your application and you want to be able to share settings between computers this is probably your best option. You can use MySQL for free or SQLExpress if you aren't storing GB of settings. It does require a significant amount of setup but it might be the best option anyways if you require this level of capabilities.
Hopefully this gets you started. Best of luck!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
What I need to do is meet my competition and 'update' my winforms application so that it is fully accessible via an online service.
I'm not sure whether to recode my winforms app so that it uses WCF/Odata to access the database or whether the whole app will need re-writing as a webforms app and moving the database to the hosted website. The later option will likely be the more difficult of the two options given my coding experience. At present, the database resides on the end-users PC and the winforms app provides 100% of the end-users access. There is also a web interface that provides the end-user's clients access to reservations, their own user details etc. The web interface is self-hosted on the end-users PC.
With regards to serving up the data to the end-user, will there be an appreciable time difference between my proposed winforms app retrieving and consuming the data from a remote hosted database VERSUS a fully hosted webforms/database app? Can this difference be quantified before I take the plunge?
Web versus Desktop is a huge topic.
My two cents:
Web:
1 - Pros:
Accesible from all kinds of devices (PC, Mac, Smartphone, Tablet).
No installation required.
Only server deployment / update is required.
2 - Cons:
Stateless (this means no client side cache, for example)
Less control over the client computer's features (File System and the like).
Browser hell (UI looks/behaves different on every browser)
harder to code due to crappy javascript everywhere
Web-based vulnerabilities (such as XSS and the like)
.Net Windows Desktop:
1 - Pros:
Stateful (you can cache lots of data in the client).
More control over the client computer's features.
Looks the same on every machine.
easier to code due to stateful nature and no javascript (hooray).
2 - Cons:
Only works in Windows. No smartphone, no Mac, no tablet.
client installation required (which might include a .Net Framework installation).
Server + client updates required (easier with ClickOnce).
That said, winforms is a really old technology no one cares about anymore, and which does not support anything. Web applications can be made to look and feel beautifully with some CSS. winforms looks ugly no matter how hard you try to improve it.
If you go the Windows Desktop route, you'd rather upgrade your application to WPF.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Recently, a project came my way with requirements to ...
1. Build a C# console app that continuously checks website availability.
2. Save website status somewhere so that different platforms can access the status.
The console app is completed but I'm wrestling with where I should save the status. I'm thinking a SQL record.
How would you handle where you save the status so that it's extensible, flexible and available for x number of frameworks or platforms?
UPDATE: Looks like I go with DB storage with a RESTful service. I also save the status to an xml file as a fallback to service being down.
The availability of the web-sites could be POSTed to a second web service which returned a JSON/Xml result on the availability of said website(s). This pretty much means any platform/language that is capable of making a web-service call can check the availability of the web site(s).
Admittedly, this does give a single point of failure (the status web service), but inevitably you'll end up with that kind of thing anyway unless you want to start having fail-over web services, etc.
You could save it as XML, which is platform independent. And then to share it, you could use a web server and publish it there. It seems ironic to share website availability on an other website but just as websites, other type of servers/services can have downtime also.
You could create a webservice, and you probably will need to open less unusual ports on firewall to connect to a HTTP server than to connect a SQL Server database. You can also extend that service layer to add business rules more easily than at database level.
I guess webservice is the best option. Just expose a restful api to get a simple Json response with the server status. Fast and resources cheap.
Don't re-invent the wheel. Sign up for Pingdom, Montastic, AlertBot, or one of the plethora of other pre-existing services that will do this for you.
But, if you really must, a database table would be fine.