Najlepsza praktyka przechowywania i aktualizacji zewnętrznych haseł API

Question

Mam aplikację ASP.Net C#, która musi łączyć się z zewnętrznym API przy użyciu WebServices co 5 minut.

Wymagania Webservice Zewnętrznych są następujące:

• Nazwa użytkownika i hasło są wymagane
• muszę przekazać nazwę użytkownika i hasło przy każdym żądaniu Zestawienie
• Hasła wygasają co 90 dni i musi być zmienił się przed datą wygaśnięcia
• Hasła nie mogą być zmieniane ręcznie (przez człowieka), moja aplikacja musi połączyć się z oddzielną usługą zmiany hasła, aby zmienić hasło.
• Moja aplikacja musi generować każde nowe hasło w oparciu o zestaw reguł.
• Hasła nigdy nie zostaną ponownie wykorzystane.
• SSL Certyfikaty i firewall IP ograniczenia są wymagane

zbudowałem wszystkie poprzednie, ale obecnie mam jeden problem. Jaka jest najlepsza praktyka przechowywania aktualnych i historycznych haseł?

Oczywiście przechowywanie hasła w postaci zwykłego tekstu jest złym rozwiązaniem. Muszę mieć możliwość odczytywania hasła przez moją usługę internetową i przesyłania jej przy każdym żądaniu. Muszę też mieć dostęp do wszystkich historycznych haseł, aby upewnić się, że moje nowo wygenerowane hasło nie jest duplikatem.

Idealnie chciałbym przechowywać każde (zaszyfrowane) hasło w mojej bazie danych i odszyfrować je, gdy tylko będę musiał połączyć się z serwisem internetowym. Czy istnieje najlepsza praktyka, którą powinienem śledzić? Czy należy szyfrować każde hasło przy użyciu Microsoft.Practices.EnterpriseLibrary.Security.Cryptography.Cryptographer.EncryptSymmetric (..)?

Uwaga: Niestety, nie mam dostępu, aby zmienić sposób działania zewnętrznego interfejsu API. Muszę przestrzegać podanych zasad.

Answer 1

W odniesieniu do historii haseł Chciałbym pójść w dół jedną z dwóch tras:

1. Zgodnie z aktualnym planem, haseł przechowuje w pliku/db/config - Proponuję użyć algorytm mieszający (w przeciwieństwie do szyfrowania), aby porównać nowe hasło z przechowywanymi hasłami hasłowymi dla "równości".

2. Nie zawracaj sobie głowy przechowywaniem historii haseł - niech pierwsza próba zmiany usługi sieciowej po prostu się nie powiedzie, jeśli też się wybierz, a następnie wyślij ponownie z alternatywnym hasłem. W ten sposób nie powielasz reguł biznesowych usługi internetowej zmiany hasła (na przykład, powiedzmy, że zmieniają to, aby umożliwić ponowne użycie hasła po upływie 6 miesięcy).

Jeśli chodzi o przechowywanie bieżącego hasła: zakładając, że musisz wysłać hasło w postaci zwykłego tekstu, to tak, powinieneś przechowywać je w formie zaszyfrowanej.Istnieje wiele artykułów out there, jak to zrobić. Możesz nawet zaszyfrować określoną sekcję pliku konfiguracyjnego, taką jak seen here.

Answer 2

Narzędzie rejestracji ASP.NET IIS (Aspnet_regiis.exe) może szyfrować i deszyfrować sekcje pliku web.config. Nie ma specjalnego kodu wymaganego w aplikacji, ponieważ ASP.NET 2.0 będzie magicznie odszyfrowywać sekcje w środowisku wykonawczym.

http://msdn2.microsoft.com/en-us/library/zhhddkxy.aspx

Answer 3

... Najłatwiej użyć klasy ProtectedData:

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);