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.
Related
I have a asp.net web application.
I want; users can digitally sign PDF documents with certificates installed in the client machine. Users have a PIN. They must upload file and enter their unique PIN. If certificate is installed and true signed the document and stored at server.
I dont know any plugin for this. I m not sure about my explanation and i hope you have some ideas about that.
[Disclosure: I work for CoSign]
Yes, we have customers doing what you ask for, with the process mediated by the developers web app (written in ASP.net or other languages). See our CoSign Signature Web Agent sdk.
I'm working on an asp.net website that needs to store user passwords for another website so that I can retrieve data periodically without requiring the user to keep logging in. I can't imagine how one-way hashes would work in this case since the user isn't going to be re-keying the password every time. I'm assuming I need to encrypt the passwords to store in a SQL Server database and decrypt them when needed. But that's where things get tough for me. The basic infrastructure is a C#/Asp.Net MVC3 website running on load-balanced Azure compute instances and storing data in SQL Azure. I'm not a crypto guy, and I don't want to make a rookie mistake. There seems to be a lot of information out there, but nothing seems clear to me. Even though the data I'm connecting to isn't sensitive, I want to treat my users' information with the same care I want my personal data treated. Any advice on how to proceed would be appreciated.
EDIT:
I certainly understand that storing passwords is not a best practice, but in some cases it is simply unavoidable. I have come across this project, but have not tried it yet: http://securentity.codeplex.com/. It uses a digital certificate on the web server.
Users of the 3rd party site are able to set their data as "public", in which case I wouldn't need to store their password. So I may give users the option of doing that instead.
You should have a look at OAuth and Single Sign-On.
In simple terms: Only an authentication token is sent between the different systems.
You (the site) should never have knowledge about the users passwords. At most you should know the hash of the passwords to your site.
Read the two topics above and you will know how to properly secure your and the "neighbour" site.
Edit
In Short:
The other site (site B) implements OAuth server processes. Your site (site A) implements OAuth client authentication. When requesting user information from site B you redirect the user to site B authentication to allow site A to read information from site B regarding the user. Site B creates a token that site A can use to access the information. This token can be time limited (or not).
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'm looking at starting a new web app which needs to be secure (if for no other reason than that we'll need PCI (Payment Card Industry) accreditation at some point).
From previous experience working with PCI (on a domain), the preferred method is to use integrated windows authentication which is then passed all the way through the app to the database using kerberos (so the NT user has permissions in the DB). This allows for better auditing as well as object-level permissions (ie an end user can't read the credit card table).
There are advantages in that even if someone compromises the webserver, they won't be able to glean any/much additional information from the database. Also, the webserver isn't storing any database credentials (beyond perhaps a simple anonymous user with very few permissions for simple website config)
So, now I'm looking at the new web app which will be on the public internet. One suggestion is to have a Active Directory server and create windows accounts on the AD for each user of the site. These users will then be placed into the appropriate NT groups to decide which DB permissions they should have (and which pages they can access).
ASP.Net already provides the AD membership provider and role provider so this should be fairly simple to implement.
There are a number of questions around this - Scalability, reliability, etc... and I was wondering if there is anyone out there with experience of this approach or, even better, some good reasons why to do it / not to do it.
Any input appreciated
Having used ADAM in a project, I found it to be bear. Documentation for developers can be sparse, it has quirks that differentiate it from full AD and, most importantly, I could not get a straight answer from MS as to whether it will be fully supported in the future. The impression I got was that ADAM was the bastard child and that the new Federated services (ADFS) was where they wanted people to go. Just moving the ADAM store from one member server to another was a pain. Now that said, my issues with ADAM had to do with development against and maintenance of the store, It definitely has the ability to scale and it was reliable. That said there are times when you need to delve into 80th level spells of LDAP/Directory magic to figure what it is or is not doing.
For a public facing site, AD/ADAM might be overkill IMO. You could use alternate MembershipProviders like the SqlMembership provider to get the good level of security with respect to credentials. If you wanted to go further, you could use database encryption (SQL Server at least has this ability built-in) to encrypt information that falls into the PII (Personally Identifiable Information) arena and of course encrypt the backups. The advantage that a database backed authentication store has is that you have all the tools that your database product provides to scale out, do backups, control access and so on.
EDIT: Let me add, that with .NET you can setup your site so that it runs under a Windows user and connects to the database using Windows Authentication (assuming the db supports it). Thus, no credentials need to be stored in a config file. However, if you had to store credentials for whatever reason, you can then use DPAPI to encrypt the credentials in the config file.
ADDITION In response the question about securing encryption keys you have a couple of choices. The first is to simply hash the credit card numbers. That greatly simplifies any problems with access to the data however, it means that the customer would have to re-enter their card number for each purchase. If you want to remember the customer's card number, then you move into a new realm of maintenance of the decryption keys. In this scenario, you absolutely should use Windows Authentication to the database and look into SQL Server 2008's Extensible Key Management feature which lets you hook-in a third-party key management program into SQL's encryption functionality. In this way, only the website user would have access to the keys used for decryption. There are other solutions to ensure that the website cannot be compromised. The greater worry is that someone gets a copy of the database undetected. Here's a link on using SQL Server to be PCI compliant:
Deploying SQL Server 2008 Based on Payment Card Industry Data Security Standards (PCI DSS) Version 1.2.
couple ideas
Run AD/AM - Active Directory Application Mode.
It scales well. It's the same core code as AD. Similar management capabilities. Solid reliability. Works with the ASPNET AD Membership Provider.
And it's included in Windows.
Also consider exploring a federated identity system, via ADFS 2.
unlike AD/AM, this approach is fairly leading-edge. The final version of the ADFS v2 server is not yet available from Microsoft, but it is at "release candidate" stage. If you have the stomach to be an early adopter, ADFS2 holds the possibility to employ a federated identity approach. That means you could accept identity tokens from a variety of existing sources: a google sign-in, a yahoo sign-in, any OpenId source, and use that as the identity on your site. Users would not have to "register" and authenticate to you. Instead, your site would honor the identity and authentication provided by some trusted third party, and perform authorization based on that identity.
This is not a direct answer but having a AD user account means you need a windows CAL for that user. Another way would be to issue client certificates to user and map client certs to AD users in IIS.
You might also consider AzMan with SQL store available from Windows 2008 onwards or the open source netsqlazman.
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();
}