I need a little guidance on how to implement signing of documents in a web based document distribution system we are developing.
At its simplest, user A will be logging into the website and create a Data Package. Word/Pdfs can be added to the package. User A will sign this document(s) using a digital certificate. User A might assign this to other users for reviewing the documents. They may sign the documents as well.
Now I know how to digitally sign data with C#. What I don't know is how to generate a certificate when each user logs into the website. The site is secured with DigiCert certificate.
What approach should I take to generate a digital certificate for each user? Once I have a .pfx file I believe I can store it in the database and use that.. Any guidance on this matter will be greatly appreciated!
thanks
I take to generate a digital certificate for each user? Once I have a .pfx file I believe I can store it in the database and use that..
This is what I call "naive approach" (read simplistic). You consider to store (maybe even generate) keypairs for the users in a web application. The biggest isssue with this approach is that someone with low-level access to the system (admins) or if database is leakt could gain access to the user's private key. To have a secure solution (considering signing), the private key may not leave its user
Doing everything in a web environment, you may consider using SubtleCrypto or other client site libraries, however at this point of time I see no reasonable way to manage the keys for pure web apps. Maybe you can store the user's keys and certificate in a localStorage, but it leaves some space for mallignant scripts to leak the keys.
Many real life secure solutions are working with secure modules (e. g. crypo cards), unfortunatelly the web libraries have no access to the modules (usually exposed as pkcs11 interface). As a solution usually the signing piece runs as custom code on user's computer. Before it was ActiveX, Applet,.. now it is often a "driver" exposed as a web server bound to "localhost" so the signig service can be used as web api from web applications.
I am currently working on a project in which I am rewriting an old (late 1990s) web application in ASP.NET. Part of this application is a user authentication system, which is used to access a couple of pages on the site. The user credentials (username, password, etc.) are stored in a database table.
This is all pretty standard, but while working with this database I found, to my horror, that this data is stored in plaintext.
I am wondering what the best way would be to improve the security of this insecure system. Is there an easy method of taking the plaintext data, encrypting (or hashing) it, and reinserting it? Can I use .NET Forms Authentication to facilitate any of this, and is it a good option for user authentication in the new app?
Thanks!
If you are on a Windows network, I'd use Windows Auth, which uses Active Directory. That would allow your Systems Admin group/person to administer who has access to the application.
Forms Auth is a good idea if Windows Auth won't work for you.
If they won't give you the time to implement either of the auth frameworks, I'd definitely encrypt the passwords on the database. Write a Console app and encrypt the passwords using information found here: Encrypt and decrypt a string
Then you'd need to modify your existing app to check encrypted passwords instead of plaintext ones.
How can I safely store cookies between my program's sessions? Should I use encryption or is there another, simpler way? If I will use encryption, what is safer: store encrypted cookies in files or in registry (with QSettings)?
I use Qt.
It isn't really needed to encrypt cookies when you save it to hard drive (if you aren't trying to defend against people who can read the user's hard disk).
So I am using connection strings in my web.config using SQL authentication.
Of course people say this could be a vulnerability as you are storing password in plaintext.
However, from what I know, IIS never serves web.config, and web.config should only have read access to administrators and IIS anyway. So if the hacker has gained access to the webserver, then it won't matter what encryption I use because the private key will be on the webserver.
Wouldn't encrypting connection string be classified as security through obfuscation?
Is it worth encrypting web.config connection string and storing the private key on the webserver?
Further, of course if I don't use SSL, I am transmitting connection string over HTTP in plaintext. If I use SSL then this problem should be mitigated as well.
I wouldn't say that storing a plaintext password in Web.config is a security vulnerability, in and of itself. But encrypting the password is a useful defense-in-depth measure, not just security through obscurity:
What if IIS is misconfigured to serve Web.config?
What if a security vulnerability is discovered in ASP.NET (like the padding oracle vulnerability) that allows anyone to download Web.config?
There are varying degrees of access to the Web server, from full administrative privileges to server-side code injection. If an attacker can only manage to do the latter, he might be able to read Web.config but might not be able to access the machine keys, especially if your application is running under partial trust.
In the end, it's up to you to decide if the risk of storing plaintext passwords in Web.config is acceptable. Of course, if Windows authentication is an option, then you may want to consider using that instead of SQL authentication.
UPDATE: When talking about security, it's a good idea to identify the assets and the threats. In this case, the asset is sensitive data in the database (if the data is unimportant, then why bother protecting it with a password?), and the threat is the possibility of an attacker somehow gaining access to Web.config and thus the database as well. A possible mitigation is to encrypt the database password in Web.config.
How much of a risk is it? Do we really have to plan for such an astronomically rare occurrence?
This mitigation has already proved its worth once: when the ASP.NET padding oracle vulnerability was discovered. Anyone who stored a plaintext password in Web.config was at risk; anyone who encrypted the password wasn't. How certain are you that another similar vulnerability in ASP.NET won't be discovered in the next few years?
Should we also encrypt source code and decrypt on run-time? Seems excessive to me.
So what if an attacker does get access to your source code? What's the asset you're protecting, and what's the threat you're concerned about? I think that in many cases, source code is much less valuable than data. (I'm thinking here about off-the-shelf commercial and open-source software which anyone can obtain.) And if your source code is valuable, maybe obfuscation is something to think about.
I feel if they already have even limited access to your box, then your host has failed or you've installed vulnerable services already.
What about security vulnerabilities in ASP.NET or your code? They do pop up from time to time.
My concern is standard practices. Is it a standard?
Microsoft has recommended encrypting connection strings.
What you should do is evaluate the risk that storing a plaintext password poses:
How likely is it that an attacker will be able to discover and exploit a security vulnerability that exposes Web.config? Based on past history, I'd say the likelihood is low (but not "astronomically" low).
How valuable or sensitive is your data? If all you're storing is pictures of your cat, then maybe it doesn't matter much whether an attacker gets your database password. But if you're storing personally identifiable information, then from a legal standpoint, I'd say you should take all possible measures to secure your application, including encrypting your connection strings.
Consider that, if Production passwords are present in the web.config file, then any developer with access to that file has access to the Production database. This is especially a problem when the username in the connection string has read/write access to the database. It then becomes possible for developers to "fix" things with no record that the "fix" ever occurred.
I think this is not from "outside" protection, but for "inside".
Sometimes, SQL administrator/user and OS administrator are different people. But OS administrator has access to all files, so he could easily read the SQL credentials in web.config file. But those credentials can be encrypted in a way, that even OS administrator has no way to decrypt.
And it is hardly "security through obscurity", because encrypted connection string canno't be decrypted without correct user certificate and usualy only IIS "user" has that one.
I used to read some articles on IHackStuff online blog. This guy explained some ways to get to really interesting info using Google search engine typing things on the search box like:
filetype:config web.config -CVS
This came out with multiple results related to cached web.config files on production servers, all the info of those files were available to public eye. Considering this possibility I would still recomend to encrypt web.config database access info whenever such info is valuable enough.
You're right to say that web.config won't be served by ASP.NET to a browser. But developers are cautious, so when they release a new version, sometimes they copy a known good web.config to something like web.config.old or web.config.bak. And because developers are lazy, after the release they forget to delete the old web.config, or keep it hanging round for a few days in case they need to rollback the release.
Now, .old and .bak files will be served to a browser, which means it's easy to write a script or a tool that scans for these files and downloads them to an attacker who can then go through them at their leisure to look for connection strings with usernames and passwords, and suddenly credit card numbers from your database are circulating the Internet...
If you don't want to get into command-lines and RSA keys (and frankly, why would you?), take a look at this tool for encrypting your web.config.
I'm looking for an on-the-fly disk encryption software that provides real-time disk encryption only for one authenticated process. I mean one process can access encrypted folder and at the same time others can't access. is there any one?
this is a difficult problem. You want one single authenticated process to access to be able to access the encrypted disk. How do you authenticate the process? It seems that you do not trust the other processes. You will need something like a secure boot to really authenticate the process.
Another solution would be to solve this with file access rights. You use any disk encryption tool to mount an encrypted image. The single process can then be launched in the context of a privileged user (not root, create one that has rights to access the folder).