10

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.

ChrisBint
  • 12,773
  • 6
  • 40
  • 62
Jon
  • 2,129
  • 7
  • 23
  • 31
  • Stick a 5-digit counter at the end of the password, with the number months since the year 2010? – tc. Jun 28 '11 at 22:35

3 Answers3

6

With regard to the password history I would go down one of two routes:

  1. 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".

  2. 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.

Community
  • 1
  • 1
Reddog
  • 15,219
  • 3
  • 51
  • 63
1

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);
csharptest.net
  • 62,602
  • 11
  • 71
  • 89
0

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

ChrisBint
  • 12,773
  • 6
  • 40
  • 62
  • -1 dynamically modifying the web.config seems like a horrible idea – Earlz Jun 28 '11 at 22:49
  • @earlz - nothing is dynamically modified. You do this at deployment time from the command line. I'd like to suggest that you undo that downvote because it wasn't an informed vote. Thanks. – Kev Jun 28 '11 at 23:44
  • Even so, it seems like the OP required his program to be able to allow for password changes at runtime, so his program would need to modify web.config if he were to use this strategy. – StriplingWarrior Jun 29 '11 at 00:52
  • I myself appreciate that now, but the comment the mod picked up on is inaccurate. – ChrisBint Jun 29 '11 at 01:07