Можете ли вы рассчитать хэш пароля, используемого Active Directory?

В настоящее время мы храним пользователей нашего веб-приложения в нашей базе данных вместе с хэшами/солями их паролей. Хэши рассчитываются, когда пользователь создан, и устанавливает свой пароль и сохраняется в таблице пользователя в базе данных.

Через некоторое время после создания учетной записи пользователя мы можем создать учетную запись Windows в нашем домене и хотим иметь возможность устанавливать пароль пользователя домена, чтобы он был таким же, как тот, который пользователь использует для входа в систему веб-приложение. Поскольку мы не сохраняем текстовую версию пароля, у нас нет способа отправить ее AD, когда мы ее создали.

Один из способов, которым я думал обойти эту проблему, - это рассчитать все разные хэши паролей, которые AD использует, когда пользователь сначала устанавливает свой пароль, а затем каким-то образом устанавливает записи в AD позже, когда мы создаем пользователя.

Как бы вы создали хэши (я думаю, что они MD4, MD5 и DES), используя .Net?
Можете ли вы обойти создание пароля на UserPrincpal.SetPassword и сделать другой вызов, чтобы напрямую установить хеши, хранящиеся в AD?

Кажется, должен быть способ сделать это, поскольку у MS есть инструменты для синхронизации паролей от AD до пользователей Azure.

Ответ 1

Попытка сохранить пароль AD, синхронизированный с паролем БД, является плохой идеей по двум причинам:

Это слабость безопасности (комментарии уже указывали на это, упоминая соль).
Это проблема обслуживания. Изменение пароля, инициированное ПК с Windows, не изменит пароль БД.

Вместо создания учетной записи Windows с тем же паролем измените аутентификацию вашего веб-приложения, чтобы использовать аутентификацию AD и проверку подлинности Windows Forms. Таким образом, их учетные данные AD (если они есть) заменят приглашение имени пользователя/пароля.

Ответ 2

Избегая удержания a) зашифрованного пароля, вы можете получить чистый текст, b) слабый хеш - обе плохие идеи, если БД скомпрометировано внутренним/внешним злоумышленником.

Вы могли бы рассмотреть другой подход: * создать учетную запись AD для пользователя с длинным, случайным и неизвестным паролем. Поместите в учетную запись отметку "ADPasswordLastSet = null". * в следующий раз, когда пользователь будет входить в ваше веб-приложение, после его аутентификации у вас будет пароль в ящике, поэтому установите для него пароль пользователя AD. Не забудьте обновить флаг ADPasswordLastSet.

Поэтому вам не нужно писать пароль нигде, если вы можете установить его синхронно.

Одна вещь, которую нужно помнить: политики сложности пароля - вы хотите убедиться, что политика, присутствующая в пользовательском интерфейсе, с которой пользователь взаимодействует, имеет более строгую политику.