I want to use a smpt email class in a WPF C# app
My smpt server is cloud based and I of course need my user and password.
Whilst I may be ok with saving the user for smpt server I would like to avoid putting the password in the code.
Reading up it seems that I can not retrieve the password from AD of a user due to the way it is stored. Is that correct or have I missed something?
I can think to store a password in SQL with SALT but it there a better way than this for WPF C#?
Update
The links below help to secure and retrieve but I am being bit thick here I still have to put my password in the code / dll?
Is that secure?
For example
var str = "Password123"; var sc = new SecureString(); foreach(char c in str) sc.appendChar
You can certainly not retrive a password from AD.
You may store the password in an encrypted configuration file but note that there is no completely safe way to store a password in an application. Regardless of whether you hard-code it in clear text in your source code or encrypt it, it can still be retrieved by a malicious user. The most secure thing would be not to store the password in the application at all, but instead let the user type it in on request for example.
Related
I have a C# service that needs to run a process as another user (interactive mode). That user is an admin level user and I know I should NOT store the password as a string in the code.
I could use some help pointing me in the right direction as all the research I have done seems point to a ton of methods that all do not seem to fit with what I want to do.
Am I required to store a hashed PW in a config file? Can I store a hashed PW right in the code and someone pass that to a secure string? I feel a bit lost here and could use some guidance.
If I understood the problem correctly, you need the plaintext password, so you can start the external process as another user. This would rule out password hashes, since you need the plaintext password.
1) Probably the safest thing you can do, is to ask for the password whenever the service starts. The service can then hold the password in memory as long as the service is up.
This way you don't have to store the password at all on the harddisk.
The disadvantage is of course that the password must be entered when the service starts.
2) If you need to persist the password, there is no absolute safe way, but Windows offers an Api for exactly this problem, the Data Protection API (DPAPI). It solves the problem, that one cannot encrypt a password, without storing the key somewhere (which raises the question of where to store the key...).
using System.Security.Cryptography;
byte[] passwordBytes = Encoding.UTF8.GetBytes(plaintextPassword);
byte[] encryptedPassword = ProtectedData.Protect(passwordBytes, optionalEntropy, DataProtectionScope.LocalMachine);
With this code, Windows will encrypt the password using information of the running computer. Only your process running on this computer should be able to decrypt the password then.
I have an external application where the Administrator can set the details of the users, so I'm looking for a way to set the password of the users.
What I need for this is the same encryption is using .NET(In the main app I have implemented all these using WebSecurity).
Also I saw I can duplicate the same encryption using Membership Provider but I can't figure out how to implement it, because MembershipProvider.EncryptPassword is a protected method.
Any idea how can I get the same encryption??
Note: Example input output
Password: testtest
Encrypted password:
AMIbPCqv2CKPG7xl7wAbxVvWmML1r0J1aMqTXzq5KwN56pTPp5DNdVQVUNvICRVmSQ==
a way to set the password of the users
Not advisable to do so from security perspective. You should rather have a default password set on user creation and on first login force user to set a new password. This way you do not need to create a password really.
I might be overlooking your requirement but it seems you are going too far with this.
I have a ASP.Net C# application that needs to connect to an external API using WebServices every 5 minutes.
The requirements of the External Webservice are as follows:
Username and Password are required
I must transmit the username and password with each webservice request
Passwords expire every 90 days and must be changed prior to the expiration date
Passwords cannot be changed manually (by human), my application must connect to a separate Password Change Webservice to change the password.
My application must generate each new password based on a set of rules.
Passwords can never be reused.
SSL, Certificates and Firewall IP restrictions are required
I have built all of the previous, but I currently have one issue. What is the best practice for storing the current and historical passwords?
Obviously storing the plaintext password is a bad solution. I need to be able to have my webservice read the password and transmit it with each request. I also need to be able to access all of the historical passwords to make sure that my newly generated password is not a duplicate.
Ideally, I would like to store each (encrypted) password in my database and decrypt it whenever I need to call the webservice. Is there a best practice I should be following? Should I encrypt each password using Microsoft.Practices.EnterpriseLibrary.Security.Cryptography.Cryptographer.EncryptSymmetric(..)?
Note: Unfortunately, I have no access to change the way the external API functions. I must follow the rules provided.
With regard to the password history I would go down one of two routes:
As per your current plan, store passwords in file/db/config - suggest you use a hashing algorithm (as opposed to encryption) to compare the new password with stored password hashes for "equality".
Don't bother storing password history at all - let the first attempt to the password change web service just fail if it chooses too, then resend with an alternative password. This way, you are not duplicating the business rules of the password change web service (for example, lets say they change it to allow you to re-use a password after 6 months time).
With regard to storing the current password: assuming you must send the password as plaintext, then yes, you should store it in encrypted form. There are many articles out there on how to do this. Or you could even encrypt a specific section of your config file such as seen here.
The easiest way... use the ProtectedData class:
http://msdn.microsoft.com/en-us/library/system.security.cryptography.protecteddata.aspx
byte[] bytes = System.Text.Encoding.UTF8.GetBytes(password);
byte[] cypher = ProtectedData.Protect(data, null, DataProtectionScope.CurrentUser);
//... reverse
byte[] bytes = ProtectedData.Unprotect(cypher, null, DataProtectionScope.CurrentUser);
string password = System.Text.Encoding.UTF8.GetString(bytes);
The ASP.NET IIS Registration Tool (Aspnet_regiis.exe) can encrypt and decrypt sections of web.config. There is no special code required in an application, as ASP.NET 2.0 will magically decrypt sections at runtime.
http://msdn2.microsoft.com/en-us/library/zhhddkxy.aspx
I am trying to create a secure password login screen in c#.Right now i have just created the login screen and I am able to read the username and password from the database.But which i have designed does not have an encrypted password. Can any one help me out how to write a query to generate encrypted password and store the encrypted password value in a separate field.Thanks in advance.
Consider hashing the password that you currently store. SQL can hash a password as follows:
DECLARE #HashThisPassword nvarchar(4000);
SELECT #HashThisPassword = CONVERT(nvarchar(4000),'dslfdkjLK85kldhnv$n000#knf');
SELECT HashBytes('SHA1', #HashThisPassword);
... But SQL shouldn't even need to do this. You should hash the password as soon as your C# application receives it, and then only ever pass the hashed password into SQL to be saved. When checking if the user has provided the correct password for login, compare the hashes.
Your best bet is one way encryption.
What happens in this scenario is the user selects/is given a password. When that password is stored in the database it passes thorugh this one way encryption before it is stored. (You'll be doing this in your c# code)
Then when the user logs in, the entered password passes through this same one way encryption before it is compared with the password in the database.
This ensures that if a hacker gets into the database, it will be difficult to learn the password because they would have to determine the encryption type, and then devise a way to un-encrypt it which to my understanding is difficult at best, impossible at worst.
Here is a link to some code that may help. One Way Encryption
You don't want to do the encryption in sql itself, because if a hacker DOES access your database, they will be able to simply look at the procedure/function that you are using to do the encryption and they will have a much easier time.
And you don't want to store the password in the database unencrypted as well...
Your best bet is to write some code to read the password, encrypt it, and update the record, then all you have to do is continue to use the same encryption type and salt.
The c# cryptography library is very easy to use.
I have a class that stores a users user data (user ID & password) from the login window in my application. Currently I'm using SecureString to store the password, but in certain places I need the original password to verify things. (it has to be plain text at that moment)
Does anyone know a secure way to store it in memory where it can easily be re converted to plain text if it is needed?
It looks like SecureString itself isn't secure and there are tools to get the secure string. You can write your own code, to encrypt the string, break into parts and store it, but again no security is complete, if you need to use the password like say for Database login, etc. hacker can find out and break your code.
Security is not one point, so lot of things like code obfuscation, etc. goes hand into hand.
Tools like SmartAssembly can protect strings by auto encrypting, it.
The other idea would be to store the hash, instead of the password itself, and the hash is basically created using some random parameter, so that it can't be recreated, one time passwords.
Consider CryptProtectData():
http://www.pinvoke.net/default.aspx/crypt32.cryptprotectdata
It can use either the current user key or the local machine key. In a Web setting (i. e. ASP.NET), you want to use local machine. As long as you have a single Web server where encryption/decryption takes place.
you can encrypt password by MD5 and for compare you can encrypt inputed data and copmare two string