Encrypting files & usernames/passwords - What are the normal practises?
-
Hi, I'm building an app in C#. I won't bore you with the details, but basically I have two security questions. Any help would be much appreciated! 1. I will be saving files on a external server. I would like to encrypt the files before sending them. Different 'users' will be using this app. What are the best practices regarding C# to encrypt files? Public/Private key encryption? Where would I store the keys...in the registry? I'm well versed with regards the cryptography in theory, but do not have much experience in practise. What API's....where? Etc, etc...Any ideas?.. 2. The application be will be using a third-party service, which requires a username/password. I suppose this username and password will be kept on a database somewhere, and the app will retrieve it. What are normal practises for this kind of thing? Store it on a database on server, and have the application request it? Should it be plain-text or encrypted? If so, how so? Remember, the idea is that users of the app can use this service, but should never know the username/password. There's just a huge amount around on encryption, etc - but no real 'this is the right right way' methods. Any help appreciated. By the way, this is for a fictitious company, so don't worry - this won't be a security risk! Regards, Cormac Redmond
-
Hi, I'm building an app in C#. I won't bore you with the details, but basically I have two security questions. Any help would be much appreciated! 1. I will be saving files on a external server. I would like to encrypt the files before sending them. Different 'users' will be using this app. What are the best practices regarding C# to encrypt files? Public/Private key encryption? Where would I store the keys...in the registry? I'm well versed with regards the cryptography in theory, but do not have much experience in practise. What API's....where? Etc, etc...Any ideas?.. 2. The application be will be using a third-party service, which requires a username/password. I suppose this username and password will be kept on a database somewhere, and the app will retrieve it. What are normal practises for this kind of thing? Store it on a database on server, and have the application request it? Should it be plain-text or encrypted? If so, how so? Remember, the idea is that users of the app can use this service, but should never know the username/password. There's just a huge amount around on encryption, etc - but no real 'this is the right right way' methods. Any help appreciated. By the way, this is for a fictitious company, so don't worry - this won't be a security risk! Regards, Cormac Redmond
For encrypting files, well, if you're sending them to the server, are you doing this using .NET remoting? If so, there are some documented ways of encrypting .NET remoting streams. Alternately, you can use the System.Security.Cryptography.CryptoStream to encrypt the stream before streaming it to the server. For #2, it's common to keep user names in plain text in the database. However, passwords do not need to be kept in plain text on the server. For this, you should simply encrypt hash the plain text using MD5 (again, look in System.Security.Cryptography) or some other hashing algorithm to hash the password, then save the hashed password to the database. When a user logs in, hash the password he typed, and compare it against the encrypted version in the database. If they match, the passwords match.
Last modified: 1hr 7mins after originally posted -- hash instead of encrypt, thank you dan
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Guess who's having a birthday? (It's not Jesus) The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
-
For encrypting files, well, if you're sending them to the server, are you doing this using .NET remoting? If so, there are some documented ways of encrypting .NET remoting streams. Alternately, you can use the System.Security.Cryptography.CryptoStream to encrypt the stream before streaming it to the server. For #2, it's common to keep user names in plain text in the database. However, passwords do not need to be kept in plain text on the server. For this, you should simply encrypt hash the plain text using MD5 (again, look in System.Security.Cryptography) or some other hashing algorithm to hash the password, then save the hashed password to the database. When a user logs in, hash the password he typed, and compare it against the encrypted version in the database. If they match, the passwords match.
Last modified: 1hr 7mins after originally posted -- hash instead of encrypt, thank you dan
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Guess who's having a birthday? (It's not Jesus) The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
Judah Himango wrote:
For #2, it's common to keep user names in plain text in the database. However, passwords do not need to be kept in plain text on the server. For this, you should simply encrypt the plain text using MD5 (again, look in System.Security.Cryptography) or another encryption algorithms to encrypt the password, then save the encrypted password to the database. When a user logs in, encrypt the password he typed, and compare it against the encrypted version in the database. If they match, the passwords match.
That should be hash the password with MD5. Don't want to confuse the OP any more than he already is. Also advances in cryptographic attacks have gotten to the point where 128bit hashes are becoming questionable for the longterm, if possible something longer should be used instead.
-- Rules of thumb should not be taken for the whole hand.
-
Judah Himango wrote:
For #2, it's common to keep user names in plain text in the database. However, passwords do not need to be kept in plain text on the server. For this, you should simply encrypt the plain text using MD5 (again, look in System.Security.Cryptography) or another encryption algorithms to encrypt the password, then save the encrypted password to the database. When a user logs in, encrypt the password he typed, and compare it against the encrypted version in the database. If they match, the passwords match.
That should be hash the password with MD5. Don't want to confuse the OP any more than he already is. Also advances in cryptographic attacks have gotten to the point where 128bit hashes are becoming questionable for the longterm, if possible something longer should be used instead.
-- Rules of thumb should not be taken for the whole hand.
Yes, MD5 hash, rather. Yes, a better option might be SHA.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Guess who's having a birthday? (It's not Jesus) The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
-
Judah Himango wrote:
For #2, it's common to keep user names in plain text in the database. However, passwords do not need to be kept in plain text on the server. For this, you should simply encrypt the plain text using MD5 (again, look in System.Security.Cryptography) or another encryption algorithms to encrypt the password, then save the encrypted password to the database. When a user logs in, encrypt the password he typed, and compare it against the encrypted version in the database. If they match, the passwords match.
That should be hash the password with MD5. Don't want to confuse the OP any more than he already is. Also advances in cryptographic attacks have gotten to the point where 128bit hashes are becoming questionable for the longterm, if possible something longer should be used instead.
-- Rules of thumb should not be taken for the whole hand.
Thanks for the replies. Using System.Security.Cryptography, etc - How would I go about decrypting the files on say, another machine? My real problem here is with keys; where to store them, how to keep them secure, etc. Basically, I'm building a backup application, where there can be many users. It will use Amazons S3 service for storage. I want those files encrypted however before being sent to S3. The user should be able to access (download and decrypt) the files from any location. Hence we need a central server to: 1. Supply the app with the login/pass for S3, and 2. A list of what files on S3 belong to what users. S3 isn't simply a file system, so it's not as easy as just storing files, hence the need for 2. So I know about the namespaces to use, but not how to store keys, and access keys, etc etc. Can you shed more light? Regards, Cormac Redmond Cormac
-
Yes, MD5 hash, rather. Yes, a better option might be SHA.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Guess who's having a birthday? (It's not Jesus) The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
By hash, you mean use the users username+password as a key for the encryption? I was thinking that - seems like the logical choice.
-
By hash, you mean use the users username+password as a key for the encryption? I was thinking that - seems like the logical choice.
No, actually what you do is hash your password. To use MD5 hashing, you could do it like this:
using System.Security.Cryptography;
using System.Text;...
string password = "super secret password";
byte[] passwordBytes = UnicodeEncoding.UTF8.GetBytes(password);
MD5 md5 = MD5CryptoServiceProvider.Create();
byte[] hashedPassword = md5.ComputeHash(passwordBytes); // <-- this is what you store in the database.As you can see, this doesn't rely on any sort of key; in fact, you never need to store the user's real plain text password anywhere, just the MD5 (or other hashing algorithm) hash of that person's password. When the user goes to log in, hash his inputted password, and check it against the hashed passwords in the database. If they're equal, that means the user has specified a correct password. This way is great for security -- even if someone got into your database or intercepted the password being sent to the server, it doesn't matter, because it's just the MD5 hash of the password, not the actual plain text password. Make sense?
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Guess who's having a birthday? (It's not Jesus) The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
-
Thanks for the replies. Using System.Security.Cryptography, etc - How would I go about decrypting the files on say, another machine? My real problem here is with keys; where to store them, how to keep them secure, etc. Basically, I'm building a backup application, where there can be many users. It will use Amazons S3 service for storage. I want those files encrypted however before being sent to S3. The user should be able to access (download and decrypt) the files from any location. Hence we need a central server to: 1. Supply the app with the login/pass for S3, and 2. A list of what files on S3 belong to what users. S3 isn't simply a file system, so it's not as easy as just storing files, hence the need for 2. So I know about the namespaces to use, but not how to store keys, and access keys, etc etc. Can you shed more light? Regards, Cormac Redmond Cormac
Ok, the MD5 option (or any other hashing algorithm option) works only for scenarios where you never need to decrypt the object. For example, this is a good option for passwords. See my other reply to you for more info about this. However, for decryption, you're probably going to need a key to encrypt and decrypt. For this, there are several articles on code project covering this. Basically, you'd need to look at some of the transform classes in System.Security.Cryptography, such as RijndaelManaged. MSDN has this sample[^] on how to use CryptoStream to encrypt and decrypt a file using a key. As far as where to store the key, I have no idea really. :) I don't think there's any standard place to store the key. Maybe someone else can better answer the "where to store the key" question.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Guess who's having a birthday? (It's not Jesus) The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
-
Ok, the MD5 option (or any other hashing algorithm option) works only for scenarios where you never need to decrypt the object. For example, this is a good option for passwords. See my other reply to you for more info about this. However, for decryption, you're probably going to need a key to encrypt and decrypt. For this, there are several articles on code project covering this. Basically, you'd need to look at some of the transform classes in System.Security.Cryptography, such as RijndaelManaged. MSDN has this sample[^] on how to use CryptoStream to encrypt and decrypt a file using a key. As far as where to store the key, I have no idea really. :) I don't think there's any standard place to store the key. Maybe someone else can better answer the "where to store the key" question.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Guess who's having a birthday? (It's not Jesus) The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
Ok, cheers for that! I'll have a read of those articles! Regards, Cormac
-
No, actually what you do is hash your password. To use MD5 hashing, you could do it like this:
using System.Security.Cryptography;
using System.Text;...
string password = "super secret password";
byte[] passwordBytes = UnicodeEncoding.UTF8.GetBytes(password);
MD5 md5 = MD5CryptoServiceProvider.Create();
byte[] hashedPassword = md5.ComputeHash(passwordBytes); // <-- this is what you store in the database.As you can see, this doesn't rely on any sort of key; in fact, you never need to store the user's real plain text password anywhere, just the MD5 (or other hashing algorithm) hash of that person's password. When the user goes to log in, hash his inputted password, and check it against the hashed passwords in the database. If they're equal, that means the user has specified a correct password. This way is great for security -- even if someone got into your database or intercepted the password being sent to the server, it doesn't matter, because it's just the MD5 hash of the password, not the actual plain text password. Make sense?
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Guess who's having a birthday? (It's not Jesus) The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
Ah, good. All making sense now. Cheers, Cormac