Windows環境でパスワードハッシュを取得することにはどのような害がありますか？
ArsTechnicaはこの記事を最近投稿し、電力網への侵入方法について話しています。
ハッカーは米国とヨーロッパの電力網ネットワークに侵入した後、待機しています
抜粋：
公開されているPhisheryツールキットを使用して、攻撃者が制御する所定のサーバーからテンプレートをダウンロードするようにプログラムされたMicrosoft Wordドキュメントをターゲットに送信する方法が1つありました。
次に、サーバーは、ダウンロード中のコンピューターにSMB資格情報を問い合わせます。これは、多くの企業ネットワークが、確認済みユーザーへのアクセスを制限するために使用します。
多くの場合、ダウンロードするコンピューターが応答し、その過程で攻撃者にユーザー名とターゲットネットワークへの暗号化ハッシュを提供します。
しかし、ハッシュを取得することは、実際のパスワードを取得することと同じではありません。
だから私の質問は：Windows環境でパスワードハッシュを取得することにどんな害があるのですか？
それらの電子メールについての参考情報： The Phishery Toolkit
TL; DR：Windowsが非Kerberos（非Active Directory）シナリオでネットワークユーザーを認証する方法のため、パスワードハッシュはパスワードと同様に機能しますネットワークユーザーの認証用。
Long version：パスワードを使用して誰かを認証する従来の方法は2つあります。
- クライアントはパスワードをサーバーに送信します（通常、新しいテキストでは暗号化が使用されますが、平文で送信されます）。サーバーはパスワードを取得してハッシュし、保存したパスワードハッシュと比較します。ハッシュが一致する場合、クライアントは正しいパスワードを持っていると見なされ、認証済みとして扱われます。
- チャレンジ/レスポンス：サーバーはチャレンジ（ランダムなバイトシーケンス）を生成してクライアントに送信します。クライアントはチャレンジを受け取り、それをクライアントのパスワードと組み合わせ、結果をハッシュし、ハッシュをサーバーに送信します。その間、サーバーはチャレンジを実行し、それをサーバーが格納したパスワードと組み合わせて、結果をハッシュします。 2つのハッシュが一致する場合、クライアントは認証済みとして扱われます。
チャレンジ/レスポンス方式では、パスワードが実際にサーバーに送信されることはありませんが（これは良いことです）、サーバーはパスワードを知っている必要があります（これは悪いことです）。最初のアプローチは、伝統的なUnixアプローチです。 2つ目は、従来のWindowsアプローチです。
チャレンジ/レスポンスの「サーバーはパスワードを知っている必要がある」というデメリットを軽減するために、多くのチャレンジ/レスポンス実装はパスワードのハッシュを使用します。つまり、(challenge + password)のハッシュを比較する代わりに、実装は(challenge + hashed password)のハッシュを比較します。ただし、この場合、サービスにアクセスするために必要なのはハッシュされたパスワードだけです（悪意のあるクライアントが(challenge + hashed password)のハッシュを送信する可能性があるためですクリアテキストのパスワードを知っている）。したがって、チャレンジ/レスポンス方式でパスワードをハッシュすると、おそらく他のサービスを攻撃するために使用されるクリアテキストのパスワードを取得することが難しくなりますが、サービス自体のセキュリティの点で違いはありません。
さらに読むと参照：
https://www.toshellandback.com/2017/02/11/psexec/
ハッシュを取得したら、それらを解読してプレーンテキストのパスワードを明らかにするのは、長くて骨の折れる作業になる可能性があります（パスワードがワードリストやレインボーテーブルの攻撃に負けない場合）。幸いにも、Windowsは、IPアドレス（vs. hostname）でネットワークリソースにアクセスしたり、ドメインに参加していないデバイスに接続したりするなど、多くの状況で喜んでNTLMハッシュ値を受け入れます。交換されない唯一の時間ハッシュは、Kerberos専用環境でネットワークリソースを要求するときだけですが、そのようなタイプの実装はまれであり、多くの組織が実装する際に問題となる可能性があります。
- https://en.wikipedia.org/wiki/Challenge%E2%80%93response_authentication
多くの（すべてではない）チャレンジ/レスポンスアルゴリズム…クライアントとサーバーの両方に共有シークレットが必要です。パスワード自体は保存されないため、チャレンジ/レスポンスアルゴリズムでは通常、パスワード自体の代わりにパスワードのハッシュをシークレットとして使用する必要があります。この場合、侵入者はパスワードではなく実際のハッシュを使用できるため、格納されたハッシュは実際のパスワードと同じくらい機密性が高くなります。
- https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/passdb.html#id2588057
UNIXスキームは通常、ログイン時にクリアテキストのパスワードをネットワーク経由で送信します。これは悪いことです。 SMB暗号化スキームは、クリアテキストのパスワードをネットワーク経由で送信することはありませんが、16バイトのハッシュ値をディスクに保存します。これも悪いことです。なぜですか？16バイトのハッシュ値がは「同等のパスワード」です。ユーザーのパスワードをユーザーから取得することはできませんが、変更されたクライアントでサーバーにアクセスするために使用される可能性があります。これには、攻撃者に代わってかなりの技術知識が必要になりますが、完全に可能です。したがって、は、使用するすべてのpassdbバックエンド（smbpasswdファイル、LDAP）に格納されているデータを、すべてのユーザーのクリアテキストのパスワードが含まれているものとして処理する必要があります。
ハッシュを取得することは、実際のパスワードを取得することと同じではありません
ただし、一般的なユーザーにとっては、実際のパスワードを取得するのと同じくらい良い場合があります。この記事は電力会社の労働者についてです。平均的な電力会社の技術者が、職場でのログインパスワードに9ワードの完全にランダムなダイスウェアフレーズを持っていると思いますか？ 「MyDogFido！7」になる可能性が高くなります（7回のパスワード変更でそのパスワードが設定されているため）せいぜい。彼らは本当に、システムで根拠を確立するために1つのハッシュをクラックする必要があるだけです。十分な数の従業員がいる場合、すべての従業員のハッシュを取得できれば、少なくとも1人は取得できると思います。