Develop Reference

Retrieving credentials / passwords from AD

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.

Retrieve current user name and password from OAuth

In a C# MVC app that is using the OAuth login method, how do you retrieve the decrypted password for the current logged in user?
I know
User.Identity.GetUserName()
Gets the user name but, in the table AspNetUseres is a PasswordHash column with the hashed password and I want to be able to retrieve that and decrypt it if needed in the app. I can retrieve the hashed string fine but unsure how to convert it into text...

You can't. The whole point of hashing is to obscure data in such a way so you can verify it, but can't see the actual value.
To be able to encrypt / decrypt values, you would need to set up password encryption, not hashing.
But you shouldn't be decrypting user passwords anyway. If you want to mention why you need the password, perhaps someone here could suggest an alternative way of getting what you want.

how can my application remember username and password after the user logs in?

When the user check "remember me" i want to save the username and password.
The user should be able to login directly the next time.
What is the best way to do this?
I tried isolated storage but maybe the code i wrote is incorrect.
I hope someone can help me.

There is a great how-to on how to Encrypt Data in a Windows Phone Application - it may be worth comparing that code with yours

The best and secure way to do this.. Is storing unique ID which are relevant only to the servers that you are talking to as cookies.
Algo:
Get the username and password from the user
Check for authenticity of the user.
If authenticated, then generate an unique ID relevant to this user and store it on server.
Pass on this unique ID to client side and store this in a cookie. Set the max-age
Next time when the user come to your site. Check for the unique ID on the server and also check its age as well as when it was issued
If all's well , then give access to user

SQL query to create a encrypted password

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.

How to Manage Key in a Symmetric Algorithm

I am doing an AES encryption in my C# code, using a key which is generated using PasswordDerivedKey function by passing a password and a salt of 12 byte. I have implemented the logic in my application code and the "password" is the username of the logged in user and the salt is a static byte aray.
What is the best way of storing the password and the salt, as someone can easliy determine the salt (by reflecting my code) and the username of a person.
What are the alternatives I can adopt to store the password and the salt in a secure way. I dont think storing them in my application code is the best way of doing it.
Edit: By password, i meant the passkey used in the PBKDF function (to derive an encryption key) and its not the password provided by the user. I am using Windows Authentication

Why would you need to store password if it is merely an encrypted version of the windows username?
Anytime you need to encrypt/decrypt you know name of user thus can generate key dynamically.
Salt should never be considered a secure asset. No need to hide it. You should always assume attacker knows the salt. Salt is simply a mechanism to defeat rainbow tables and other fast lookups.
Is there something I am not seeing?
On Edit
The issue is misstated in the question. The issue isn't what/how should be stored. That answer is simple. Never store any of the cryptographic data (except salt).
The current implementation creates an encryption key from the username of logged in user. The problem is that is insecure as determining username is rather easy. To get around this one would need to either:
a) accept the implementation is insecure to someone willing to decompile app.
b) ... not a good idea ... hash can change based on groups/roles
c) use a unique secret password for each user.
c is the only secure implementation however it requires prompting the user for a passphrase when encrypting or decrypting.

Against whom must be the data be secure? If the currently logged in user is allowed access to the data, but other Windows Authentication users are not allowed access, what you really want is for the data to be encrypted for the particular logged in user. If you have access rights to configure the PC, you might be able to create an Encrypted folder with permissions only for the desired user. This is not 100% secure (you can still intercept the data at various places if you have root access), but your only other reasonable alternative is to add another password.
Alternately, you can simply accept that the protection is weak and provide minimal obfuscation. It depends on the value of the data and the capabilities of your possible attackers. If your attackers have sufficient privileges to Reflect over your assembly on the actual machine, then it's highly likely that they're also Administrator, which means you're pretty much screwed no matter what you do. There are tools that can connect to a running process and monitor its memory, which means they could simply wait until you've decrypted the data and read it from memory.

Best way to keep the salt is to generate it on runtime and keep it per session along with other user stuff such as username and password:
use signs in and provide username/password
hash with stored salt and check against password hash
create new salt and store it along with the hash
Symmetric encryption (or even asymmetric) is not at all recommended for passwords. You not to hash it which is just one-way.

I added this as an second answer because it is a different solution. I just thought of it tonight because I am working with this class (trying to reverse engineer kindle encryption).
You may want to look into the Protected Data Class
http://msdn.microsoft.com/en-us/library/2c64xe0y(v=VS.90).aspx
This is a class that allows you to store data in the windows cryptographic store.
By using the Protect and Unprotect function you can pass data into and pull data from the cryptographic store.
If you didn't want to force the user to create (and remember) an encryption key you could.
1) Check to see if current user has encryption key in the store.
1a) If not then create a random encryption key
2) Use key to encrypt file and store
3) To decrypt retrieve key from store.
4) Another user may be able to access the file but will be unable to get a copy of the key from the store.
A couple caveats. Only the windows user who stored the key can retreive the key. However this can be bypassed depending on environment. If the user has no windows password (or weak windows password) anyone w/ access to machine can run as the user and windows will gladly hand over the key. In a domain environment anyone (admin) who can impersonate the user and modify password can access they key. If user's windows profile is trashed so is the only copy of your encryption key.