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...
Related
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.
We currently use WIF to secure our application and back end services. I'm trying to determine if we really have a need for WIF in our solution, or if its just an extra layer that consumes resources without providing any benefit.
Our current application is split up into 2 separate web applications, a Client and Admin and several WCF services. Identity is not shared between the two applications(You have different credentials for admin and client). Identity is only ever shared between the client and the WCF services. This occurs between machines, but never across networks or enterprise boundaries.
We use a third party to perform authentication, however the 3rd party is not used as an Identity Provider. That function is performed inside the application itself.
We currently have no future plans to share identity between other applications or services, or to use a 3rd party Identity Provider, etc.
Given the way our application is setup, do we really gain much from using WIF as an additional means of securing our back end services? If WIF was removed what are we losing?
If you remove WIF, you'll have to replace it with something. Unless you decide that you don't need user authentication and authorization at all. Remember that in addition to authentication, WIF gives you the claims-based authorization model.
Another benefit of WIF is that it's becoming a well-known standard way of securing applications, meaning that when you bring on new developers in the future, they'll likely be familiar with your security model. That's a big benefit. Compare that to a custom security model that you'd have to train the new developers on.
Also, WIF is a proven technology with well-known security benefits. If you implement WIF as recommended, your applications are secured. That's not necessarily true of other models, especially a custom-designed security model.
Also, you say that you currently have no future plans to use the more advanced features of WIF. There's a big difference between not currently having plans and never ever going to do it. With your current WIF implementation, you have the flexibility to add those things if plans change in the future. If you replace WIF with something else, you're giving up that flexibility. Or at least making it much more difficult.
Were it my project, the first questions I would ask are:
Does the existing WIF security model work? If no, then fix or replace. If yes, then ...
Is it causing any trouble (materially affect memory usage, application response, or developer productivity)? If not, then leave it alone. If yes, then ...
Are the benefits of replacing it worth the cost and the risk of breaking something or failing to implement some other feature?
If you have something that works and doesn't impede your ability to improve your application, then any time you spend working on that piece is at the cost of some other feature.
I recently launched my desktop application and it got cracked after a few days. I posted a question on stack overflow and people said that i cannot stop that. In the start of the software i cannot allow this to happen and i want a solution. So, following is what i am thinking.
Currently, I have desktop application that communicates with the web server to verify the user. Once the user is verified it saves the values in Registry. The hacker has bypassed the communication code and added fake values in registry and he can use my software now.
Now, i am planning to take some of my code from MAIN features of the software to a WEB SERVICE hosted somewhere else on a web server. Whenever the software needs to run that feature the software will give a call to the WEB SERVICE with the values in REGISTRY. I will verify those values and return the results. But if the values will not match my database then i will reject the call.
So, my questions is:
1- Do you think this solution is feasible ?
2- According to my thinking, it will make the software useless to the hacker. What do you think ?
3- Any flaws in this solution ?
You don't have to get cracked. Jeez, everybody thinks there's no solutions available to prevent piracy, but there are. Disclaimer: I work for a company (Wibu Systems) that prevents software piracy and provides license management solutions.
Here's the thing: this (like all security issues) is a highly specialized area of focus and the crackers are smarter at this than you are. They are already familiar with the different home-grown solutions people roll themselves and can crack those quickly.
Commercial solutions (ours is CodeMeter; in all fairness other companies make good solutions too like SafeNet and KeyLoc) rely on strong encryption with multiple layers of protection against key discovery. These companies have spent years developing, improving, and testing their solutions; it's unlikely you will be able to come close to the robustness and quality of such a solution on your own. I can almost guarantee you that any solution you create on your own will get cracked very quickly, unless your product is uninteresting to the crackers.
I'm not trying to create an ad here; I just want to set the record straight. Companies that traditionally got cracked constantly who switched to CodeMeter stopped getting cracked. Check out Propellerhead's Record product for a good example.
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 9 years ago.
Improve this question
I want to create a small helpdesk ticket control system at work, that would allow users to enter a help request ticket; these tickets would then be assigned to a technician to work on, and the technician would mark it as "FINISHED" after the job is done. The requesting user would then be able to confirm and "CLOSE" the ticket, so that a Help Desk supervisor can keep track of response times and other stats based on the ticket details. Nothing too complicated, using .NET and SQL Server.
I am not sure if I should develop this as a Web application or a Windows application. This application would be used in the plant floor, so it would have to be easily available in the LAN. But we currently host a list of Windows applications via Citrix, so deployment would not really be an issue here. I don't really have experience creating winapps from scratch (though I've modified quite a few), but it feels like a web application would not look as "solid".
What advice can readers provide that could guide me into deciding the better architecture for this purpose?
EDIT
Thank you all for your thoughts! Given that this is a very simple application, I could go either way. I decided to go with a Web application, as our local Citrix setup still has some quirks that need to be fixed.
If you develop a web app you can pop it on your local intranet and your users can use either their browser within Citrix, or via the browser on their terminal.
However, if you've got the infrastructure in place, then perhaps a Windows application would be easier to develop and deploy. The only limitation with a windows application would be that if you were to move away from a Citrix environment, or were to expand to wanting to use the system externally to the plant floor, then it's harder to deploy and maintain your installations.
You can use Web Deployment with Windows applications which is quite nice as it updates itself whenever you publish a new version, however it is a bit of a faf for the users and you've no guarantees that the user will allow the update to occur. So if you had a critical update, the users could, in effect, choose to ignore it.
That's where the web application gets its bonus points. One installation and one point of access. If you update it, then all users are instantly on the latest version.
Personally, I'd go with the web application for future proofing and ease of acccess. It's slightly more work than a windows application, but the payoff usually exceeds the extra time required for the web application.
Before writing this system, I would highly recommend searching www.codeplex.com and making sure that adapting another work isn't a better choice. You may find something that is already written and meets your needs while allowing you to dig around, learn and be ready to modify when they want some new feature not already present. (I believe all projects grow if the users believe in the developer.)
If you are going to write your own and can do it in the time you have, I would highly recommend that you either go with MVC if web based, or WPF (using MVVM) if you want a desktop client. There is a definitive learning curve to either MVC or WPF with MVVM. But I believe the payoff will come. I have found changes much easier when there is a clear line between business logic and visual behavior.
Personally, in this situation I would go for a windows application - as it doesn't sound as though you've any compelling reason to invoke the complexity of web-ness (perhaps it's just me that thinks web => additional complexity). I'm sure you could create a neat little windows app. in half the time it would take to create a clunky web version of the same thing!
As a sidenote:
I really like the way Eclipse Mylyn integrates with XML-RPC. Check this architecture out for inspiration:
http://www.eclipse.org/mylyn/
If you went for a similar strategy you might start off with a simple front end (Maybe as a C# with a native GUI and augment with a web-based integration with your intranet at a later point whichever is the fastest for you to do).
In esscente a 3-tier approach where you have:
The database.
The application layer wich implements an XML communication protocol (XML-RPC is quite simple).
A front end where information fields and workflow steps are 'introspected' rather than hardcoded in the client.
Just a though, hope it helps.
Write a winform app, and distribute it over ClickOnce. It's the best way to go, IMO.
Don't rush to make this decision. In the end, the Web vs Win question is about user accessibility. Much of the processing logic for your business need is independent of the interface. Spend your up front time building the right data model and identifying the necessary processing/services that you need. A well designed DB and service layer will work with both Web and Win apps. This will also give you the best flexibility as your "product" inevitably grows. You may very well want a web interface for managers needing reporting functionality and a WinForms application if you need more advanced user processing abilities for your users. And that is when your initial design work will payoff.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I've been looking for a simple key/license system for our users. Its partly to stop piracy (avoid users from sharing the application around) and the other half to track the number of 'licensed users' we have. I have already read a few good suggestions on SO but I'm curious as to how people have implemented the 30 day evaluation criteria.
Do you generate a key that stores the date somewhere and do a comparison each time or is it a little more complicated - deleting the file/removing the registry shouldn't deactivate.
Are there any example implementations out there that can give me a head start? The irony is that our PM doesn't want to license a third-party system to do it for us.
This is for a Windows Forms application.
Have you checked out the Rhino-Licensing project by Ayende Rahien. You can also see his blog post about licensing a commercial product which led him to develop this solution.
There are two separate challenges: i. How do you prevent a copied app from running. ii. How to prevent users from ripping out/bypassing your prevention scheme. The first one is usually done by taking a hard to copy signature of the user's system (e.g. Hard Drive ID + Processor ID + RAM, etc) and using it as the seed/key AND activating it on-line by calling "home".
The Second issue is harder to do in .Net since the source code can be in someway extracted and recompiled to exclude your protection system. The key here is to make it cheaper to buy the license than to remove the protection at the user's end. You may find that for most products, the suggestion to use a customized engine to encrypt your product libraries that also contain your copy-protect and decrypt it at initial run-time, might be enough.
I am not sure you can actually protect a .NET - There may be commercial solutions that do the trick. The reason is .NET code can be seen through Lutz Roeder (Thanks Jasonh for the heads up) Red Gate's Reflector (It was formerly by the named guy above). The best way to deal with it is to look for code obfuscation which makes reflecting more trickier, I can point you to one place I know of that does this for free - Phoenix - NtCore.Com.
The more esoteric solution would be to create a .NET hosting environment in C++, load the binary image (which could be encrypted) and the hosting environment than undecrypt it in memory - have heard of that theory but not sure how that would be done in practice. Please do not use your own protection scheme as there could be a weakness.
Someone once said - "Security through obscurity"....
Hope this helps,
Best regards,
Tom.
I worked on a project that handled this by putting some critical functionality (for example data storage, reporting, or payments) on an external server we ran, and requiring the user to log in to this server to get the functionality.
Customers can make backups, share, or run the application locally, but to access this critical function they have to type a password in to our application and connect to our server. Customers knew the password allowed changing their data, so they would not want to share the password with other people.
This was handy because we do not care how many copes of the application are out in the wild, we only track server connections. We included machine-identifying data like MAC address in the connection data, so we can track which machines are connecting.
I'm not just saying this because my company sells the OffByZero Cobalt software licensing solution for .NET: your PM should know that software licensing is very hard to get right, and if you roll your own, you'll be supporting it for the foreseeable future.
Take a look at the article Developing for Software Protection and Licensing; it explains how to choose a solution, why you should obfuscate your application and gives a number of tips for structuring your code to be harder to crack.
In particular it makes the point that the vast majority of companies should outsource their software licensing, as it makes no sense to spend developer time on building and maintaining a complex system that isn't your core business.
What is more important to your company: adding an important new feature to your product, or tracking down a peculiar permission behaviour on an ancient version of Windows that's clobbering your licensing system?