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).
Related
I am a windows service that downloads and saves oAuth tokens and I need to store them encrypted on the local hard drive until they expire and reuse them later. The problem being a service is that I cannot ask the user for a password. Is there a safe or suggested method to secure files when storing them and prevent other processes decrypting it? My language of choice is python and it would be relatively easy for someone to find out the encryption algorithm.
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.
My team have been asked to 'enhance' a web app to permit the following. Is this considered a security risk in a web app? I'm not sure about this.
"Be able to access directories, for exporting and importing [data into the database] , outside of the virtual directory"
In other words the requester wishes to be able to navigate to a data file anywhere outside the application's IIS virtual directory, presumably when importing (or exporting) data.
I think this means on the web server, but it may mean local files on the client machine (to be clarified). But either way the question stands.
If you are talking about going outside the boundaries of the web application, that means a risk. Once you allow a particular user to go beyond your web application, then there is no more control in what that user could do with the webserver.
Have a look at path traversal attacks:
https://www.owasp.org/index.php/Path_Traversal
Also, here is a list of things to consider in order to avoid this:
https://www.owasp.org/index.php/File_System#Path_traversal
Any questions, just let me know.
Regards,
Fabio
#fcerullo
The question does not stand 'either way'. They are different questions. If it is about being able to select a file from the local computer to send to the remote server then that is pretty routine. e.g. one does it all the time while attaching a file to an email. The user is the one who initiates the file choice AND it is their file to send to the web app. No security hole here.
IF you have a need to allow clients to be able to browse the server computer for all sorts of files, then that itself is NOT a security hole. That is what you wanted, you got it. It is a security hole ONLY when you did not mean that the client should be able to grab hold of files off any whichever directory on the server. This whole scenario is classified as security issue because more often than not you do NOT want clients to have access to all inclusive files on the server. Typically the client needs to be able to access only certain files. Restricting you to virtual directory is one way of doing it. e.g. would you want your clients to be able to grab hold of the actual DB files with records of all users of your web site and then load that DB file in their own DB?
If you need to go beyond that, you need to implement mechanisms in place that allow access to only certain files. Remember your web server is running in the context of some user on the server OS. When the client request comes to the server, it that that web server user under which the command executes. So you cannot achieve security by simply putting in permissions for that web server user.
What is the risk of not using a trusted connection?
For example here is a scenario: I have created a very simple application which only has 4-5 lines of codes which uses an SQL connection with my connection string within web.config, and sends a select command to my database, and display results in an interface.
What are the security weakness here?
Edit:
I know trusted connection is related to authentication, what I wonder is I don't know how can the system be hacked if I don't use it ? (I will use my application at my company's servers and the application is a public application, so every company member can use it, so why do I need a trusted connection if it is a local company application ?)
To look at it the other way around, the main benefit of trusted connections is that you do not have to manage passwords in your application. If your application needs a password to connect to SQL Server, then where do you put the password (or connection string) so that the application user (or other developers, or sysadmins, or external consultants, etc.) cannot read it but you can still change it easily when required?
Passwords in files or the registry can often be read by users because when they run the application it has to retrieve the password, therefore the user needs access. Or a sysadmin or consultant has access to the filesystem where an application config file is. Obfuscating the password with some form of encryption is possible, but then you have to secure and manage the decryption key. Hard-coding the password in the application makes it difficult to change and also makes it highly likely that the password will be visible in the source control system, which is typically a relatively insecure system (in practice, if not by design). You can create a web service that the application gets the password from on startup but then you have to authenticate access to the service somehow.
Using trusted authentication avoids all of this completely by making the operating system responsible for authentication and unless you are a world-class security programmer, the odds are good that Windows provides a more reliable mechanism than you can create yourself.
I will use my application at my company's servers and the application
is a public application, so every company member can use it, so why do
I need a trusted connection if it is a local company application ?
Security risks in non trusted connection lies how you store SQL server passwords and use them in application. if you store passwords in config file or hard code in program, any other developer who has access on your code can view it and on the worst can change database in such a way that may break application or steal sensitive information. it will be a privacy breach as well and your company may be sued for this ( you can't just imagine what can happen).
#Pondlife has also elaborated very well.
AFAIK, the only extra layer of security a trusted connection gives is authentication. If you use a trusted connection then Windows will authenticate your connection in Active Directory.
A quick google yields this link:
What is a Trusted Connection?
I was wondering if anyone had successfully used DPAPI with a user store in a web farm enviroment?
Because our application is a recently converted from 1.1 to 2.0 ASP.NET app, we're using a custom wrapper which directly calls the CryptUnprotect methods. But this should be the same as the ProtectedData method available in the 2.0 framework.
Because we are operating in a web farm environment, we can't guarantee that the machine that did the encryption is going to be the one decrypting it. (Also because machine failures shouldn't destroy our encrypted data).
So what we have is a serviced component that runs in a service under a particular user account on each one of our web boxes. This user is a set up to have a roaming profile, as per the recomendation.
The problem we have is that info encrypted on one machine can not be decrypted on another, this fails with the win32 error:
'Key not valid for use in specified state'.
I suspect that this is because I've made a mistake by having the encryption service running as the user on multiple machines, hence keeping the user logged in on more than one machine at the same time.
If this is the problem, how are other using DPAPI with the User Store in a web farm environment?
In a web farm environment, rather than using DPAPI to encrypt/decrypt your data directly, you would instead use it to encrypt the key that you later use to decrypt your protected data.
You would "install" the key onto each server as part of the deployment process. The installation script would need to run under the AppPool's identity, and could store the encrypted key either in an app.config file or in the registry.
The encrypted data itself could be stored in a central repository / database, so that it can be accessed by all servers in the farm. To decrypt the data, the web app would retrieve the encrypted key from where it was installed, use DPAPI to decrypt it, then use the result to decrypt data that comes from the central repository.
The downside is that the cleartext key might exist on the local disk for a short time during the initial install process, where it might be exposed to operations staff. You could add an extra layer of encryption, such as with the web.config machineKey, if that's a concern.
The Microsoft poster is wrong.
http://support.microsoft.com/default.aspx?scid=kb;en-us;309408#6
"For DPAPI to work correctly when it uses roaming profiles, the domain user must only be logged on to a single computer in the domain. If the user wants to log on to a different computer that is in the domain, the user must log off the first computer before the user logs on to the second computer. If the user is logged on to multiple computers at the same time, it is likely that DPAPI will not be able to decrypt existing encrypted data correctly."
It appears that DPAPI will not work in a farm setting. I think this is a rather large oversight on Microsoft's part and makes DPAPI almost useless for most enterprise applications.
I just saw this. There is a way you can make this work, and that is to make sure the machines in the farm are in a domain, and use a domain account to encrypt and decrypt the data (ie; run the application under the domain account)
You cannot use DPAPI in the manner you want with local accounts because the key material is not exchanged between servers.
hope that helps!
Twelve years later . . . you can try using CNG DPAPI, which was meant to work in cloud environments that may or may not be load-balanced. From that link (in case it gets taken down):
Microsoft introduced the data protection application programming
interface (DPAPI) in Windows 2000. The API consists of two functions,
CryptProtectData and CryptUnprotectData. DPAPI is part of CryptoAPI
and was intended for developers who knew very little about using
cryptography. The two functions could be used to encrypt and decrypt
static data on a single computer.
Cloud computing, however, often requires that content encrypted on one
computer be decrypted on another. Therefore, beginning with Windows 8,
Microsoft extended the idea of using a relatively straightforward API
to encompass cloud scenarios. This new API, called DPAPI-NG, enables
you to securely share secrets (keys, passwords, key material) and
messages by protecting them to a set of principals that can be used to
unprotect them on different computers after proper authentication and
authorization.
In .NET Core this looks like
public void ConfigureServices(IServiceCollection services)
{
services.AddDataProtection()
.ProtectKeysWithDpapiNG();
}