I have been killing myself over this for a couple weeks now and cannot find a viable solution. Here's my scenario:
I have a DTSX package that imports user data from an external database. It then creates user accounts and profiles in the local database. Users can also be created via a custom ASP.NET Membership Provider. The provider must be able to authenticate both types of users.
This was all fine and dandy during development because passwords were stored as clear text. However, now that we're ready for release the passwords format of the provider must be set to encrypted and so the users created via the DTSX must be created with an encrypted password. (I'd prefer the passwords were hashed but the client's requirements are that passwords be recoverable). The real problem seems to be creating an encrypted password within the DTSX that will be decryptable by the ASP.NET Membership Provider.
My original solution was to have the DTSX call a CLR stored procedure that had access to the same encryption logic as the provider. I got it working but our client wouldn't enable CLR integration. So that's out the window. Now I'm investigating alternatives. One alternative is to simply use the built-in encryption methods of T-SQL. But how do I share the keys used for the encryption/decryption?
My question is, is it possible to generate a password in T-SQL, say using EncryptByKey, that will also be decryptable by my provider? This means that the key in SQL must match the key in my machineKey configuration. I have no idea if this is possible.
Any insight/help is tremendously appreciated.
why don't you use a script task inside your dtsx to encrypt the user password?
Related
For example, I'd like to run Identity Server as an API which other resources authorise against. I'd also like to have a separate Web Application to handle Login/Registration/ForgottenPassword pages which uses said Identity Server API. I'm used to running both within the same application.
I appreciate this is a very light description for the question. I'm fairly certain I read somewhere that IdentityServer4 can be run as just a service/API.
Yes you can. You have to use the endpoints. Have a look at all of them. I think that the one that suits best your requirements is the Token endpoint. There, by specifying some params (including username and password), you can practically login and receive the tokens.
Btw - Identity Server doesn't support OOTB any forgotten password or registration support. This should be custom. And also I guess that you are not using InMemory users, so basically it is up to you how to design this, but yes - it will be separate from Identity Server.
I have a problem where I can't seem to find any solution.
I have a web application which uses webdav so I can connect to it via windows explorer and edit files. This works.
Now I want to use authentication with this folder. I already did this via a servlet filter with BASIC Authentication and DIGEST Authentication which both work fine, when the password is at some point available in cleartext.
The problem is that my passwords are stored in a hashed format in my sql database.
With BASIC Authentication i can compare the user pass with the database because it is transmitted in cleartext. I don't want that.
When I use DIGEST Authentification the pasword is transmitted in encrypted format and the password is needed in cleartext from the database to calculate the response. Since the password is already hashed there is no way to calculate a valid response.
I also checked Negotiate/Spnego/ntlm authorization but as far as I understand these are for windows users only and don't have anything to do with my sql database.
The database is either mysql, mssql or postgre.
Are there any other authentication mechanisms that work with windows explorer, where I can make it at least a little bit harder to decrypt the password so it won't be sent in cleartext?
Sounds like what you want is Forms Authentication: http://msdn.microsoft.com/en-us/library/7t6b43z4.ASPX
I am building a multi-tier application that will have multiple smaller apps apart from the main app to achieve certain goals.
Example:
I have a login class on my main app, asking for username and password. This class then does all the work, and then returns the login, with credentials, if any, or failed login state.
I want to re-use this code in my smaller client side app. Its precisely the same code, and outcome as in the main app. Therefore I want to re-use it, multiple times if necessary.
First Concern: If I use .net remoting, what security is applied? Would I have to encrypt my username and password initially, then send it through the remoting framework, and on the other side, decrypt it. And then back to the client again? I am worried about something sniffing out my username and password, and even if encrypted, can some clever hacker not just call my remote DLL with the encrypted "sniffed" credentials, as my remote DLL is expecting the encrypted format?
I am essentially trying to not make any DB connections from my smaller client app. Am I better off just putting the code in a local DLL (to the client app) and update the client app when my main DLL changes. If so, what security does MS SQL provide me for transmitting a SQL query containing the username and password to my remote SQL server?
I would appreciate any and all ideas regarding best practices and industry standards. I have always developed for an application server or desktop, so I never had to consider the security issues when sending data remotely.
Thanks in advance
I have since determined that remote access to a DB is just plain too slow to be usable. I am restucturing my solution to include a tcp middle teir, that sits next to the local db. This way I can have my business lgoic in the middle teir, and send appropriate updates to my conencted client.
I am starting a service for students at my school which requires them giving me their user account information for our school's web system so that I can automate some annoying tasks for them. I will be logging them in using CURL but I am having trouble figuring out how to store their passwords in a secure method. With most web services, passwords are encrypted then stored and when logging in, we only compare the encrypted passwords. This is much different though. Since I will be sending their passwords via HTTP requests, it's required I am able to decrypt their passwords back into original text. How would you recommend I go about storing and retrieving them?
That might not be the answer you are looking at, but if you are going to store user's credentials for a third party service, there is no way to secure the storage with software only. As you mentioned it yourself, your app needs to be able to retrieve from that store the original credentials, in order to impersonate the user. And if your app can do it, so can any other code running on that box.
Thus, the only real solution is to ensure that only your software is running on the box. That assumes physical security as well, limited access to the machine, full audit and lowering the attack surface as much as possible, by turning off all unnecessary services.
On a separate note, if the school services support access delegation (through OAuth for example), you should consider going that route, and get out of the credentials storing business.
I'm having to store a user account locally on a machine, what would be the best method to store this? (Needs to be reversable encryption rather than hash)
I'm accessing a UNC share as mentioned here:
Accessing UNC Share from outside domain for file transfer
Using this suggested method:
http://www.codeproject.com/KB/IP/ConnectUNCPathCredentials.aspx
This will be an automated process so no option of human entered credentials.
I'm currently encrypting the details and storing them in the registry using TripleDES:
http://www.devarticles.com/c/a/VB.Net/String-Encryption-With-Visual-Basic-.NET/4/
With the key and initialization vector hard coded within the application.
Can anyone suggest a better method or changes to the above to secure the credentials as much as possible?
You never ever need to store user credentials. If your process needs to access a network share then it should be run under proper credentials, using runas or service account properties. If the network credential is not in a the local/current domain it should use runas /netonly. And that's all there is to it, no excuses, no exceptions.
As a side note, Windows applications store secrets locally using DPAPI, exposed in .Net as ProtectedData class. The link has fully functional examples of encrypting data with DPAPI in .Net. However, the point remains that storing user credentials in applications, even under DPAPI, is fundamentally broken.