Czy można obliczyć skrót hasła używany przez usługę Active Directory?

Question

Obecnie przechowujemy użytkowników naszej aplikacji internetowej w naszej bazie danych wraz z hashe/solami ich haseł. Hashy są obliczane, gdy użytkownik jest tworzony i ustawia swoje hasło i przechowywane w tabeli użytkownika w bazie danych.

Jakiś czas po utworzeniu konta użytkownika możemy chcieć utworzyć konto systemu Windows w naszej domenie i chcieć ustawić hasło użytkownika domeny, aby było takie samo, jak hasło używane do logowania do aplikacji internetowej. Ponieważ nie zapisujemy wersji hasła w postaci zwykłego tekstu, nie mamy sposobu, aby wysłać ją do AD, gdy ją stworzyliśmy.

Jednym ze sposobów, w jaki myślałem o obejściu tego problemu, byłoby obliczenie wszystkich skrótów haseł używanych przez AD, gdy użytkownik po raz pierwszy ustawi hasło, a następnie jakoś ustawi rekordy w AD później, gdy utworzymy użytkownika.

1. Jak utworzyć hasze (myślę, że są to MD4, MD5 i DES), używając .Net?
2. Czy można pominąć tworzenie hasła w UserPrincpal.SetPassword i wykonać inne połączenie w celu bezpośredniego ustawienia skrótów przechowywanych przez AD?

Wygląda na to, że powinien istnieć sposób, aby to zrobić, ponieważ MS ma narzędzia do synchronizacji haseł od AD do użytkowników Azure.

Answer 1

Starając się zachować hasło AD zsynchronizowane z hasłem DB jest to zły pomysł z dwóch powodów:

• Jest to słabość zabezpieczeń (komentarze już wskazywał na to, wspominając sól)
• To jest utrzymanie problem. Zmiana hasła zainicjowana przez komputer z systemem Windows pozostawi hasło DB bez zmian.

zamiast tworzenia okna konta z tym samym hasłem, zmieniać uwierzytelnienia aplikacji internetowej do korzystania zarówno uwierzytelnianie AD i Windows Forms uwierzytelniania. W ten sposób ich poświadczenia AD (jeśli je mają) zastąpią monit o podanie nazwy użytkownika/hasła.

Answer 2

Unikając posiadania a) zaszyfrowanego hasła, do którego można uzyskać powrót tekstu jawnego, b) słabego skrótu, są to złe pomysły na wypadek naruszenia bezpieczeństwa bazy danych przez wewnętrznego/zewnętrznego napastnika.

Można rozważyć inne podejście: * utworzyć konto AD dla użytkownika z długim, losowym, nieznanym hasłem. Umieść znacznik czasu "ADPasswordLastSet = null" na koncie. * następnym razem, gdy użytkownik zaloguje się do twojej aplikacji internetowej, po uwierzytelnieniu ich, masz hasło w jasnym, więc ustaw hasło użytkownika AD do tego samego. Nie zapomnij zaktualizować flagi ADPasswordLastSet.

Dlatego nie musisz nigdzie wpisywać hasła, jeśli możesz ustawić je synchronicznie.

Jedna rzecz do zapamiętania: zasady złożoności haseł - chcesz się upewnić, że zasady obecne w interfejsie, z którym współpracuje użytkownik, mają bardziej rygorystyczne zasady.