Security ja JP
ASF は現在、ECryptoMethod の定義として、以下の暗号化方式をサポートしています：
| 値 | 名前 |
|---|---|
| 0 | プレーンテキスト |
| 1 | AES |
| 2 | ProtectedDataFortCurrentUser |
| 3 | EnvironmentVariable |
| 4 | ファイル |
それらの正確な説明と比較は以下で入手できます。
暗号化されたパスワードを生成するには、たとえば SteamPassword で使用する場合、選択した適切な暗号化方式と元の平文パスワードを指定して、encrypt コマンド を実行してください。 その後、取得した暗号化済み文字列をボット設定プロパティの SteamPassword として設定し、最後に PasswordFormat を選択した暗号化方式に一致するものへ変更してください。 encrypt コマンドを必要としないフォーマットがあります。例えば、 EnvironmentVariable または Fileのように、適切なパスを指定します。
これは、 0 の ECryptoMethod として定義されたパスワードを格納する最もシンプルで安全でない方法です。 ASFは、文字列がプレーンテキストであることを期待しています - パスワードは直接形式です。 これは最も使いやすく、すべてのセットアップと100%互換性があります。 秘密を保管する標準的な方法です安全に保管するには まったく安全ではありません
現在の基準で安全と見なされる AES 方式でのパスワード保存は、ECryptoMethod の 1 として定義されています。 ASF は、この文字列が base64 エンコード された文字列シーケンスであり、変換後に AES で暗号化されたバイト配列になるものとして扱います。その後、含まれている 初期化ベクトル と ASF 暗号化キーを使用して復号される必要があります。
上記の方法は、攻撃者が復号とパスワードの暗号化に使用されているASF暗号化キーを知らない限り、セキュリティを保証します。 ASF では、--cryptkey コマンドライン引数 を通じてキーを指定できます。最大限のセキュリティを確保するため、この方法を使用することをおすすめします。 これを省略した場合、ASF はアプリケーションにハードコードされた、既知の独自キーを使用します。つまり、誰でも ASF の暗号化をリバースして、復号されたパスワードを取得できるということです。 それはまだいくらかの努力を必要とし、それほど簡単ではないが、可能です。 そのため、ほとんどの場合、秘密に保たれている AES 暗号化を --cryptkey で行う必要があります。 ASF で使用される AES 方式は、十分満足できるはずのセキュリティを提供し、PlainText の単純さと ProtectedDataForCurrentUser の複雑さのバランスを取ったものです。ただし、カスタム --cryptkey と併用することを強くおすすめします。
適切に使用されている場合 (長い、カスタム --cryptkey), 安全なストレージのための非常に高いセキュリティを保証します。
現在の基準で安全と見なされる DPAPI 方式でのパスワード保存は、ECryptoMethod の 2 として定義されています。 この方式の最大の利点は、同時に最大の欠点でもあります。暗号化キーを使用する代わりに（AES のように）、現在ログインしているユーザーのログイン資格情報を使用してデータが暗号化されます。つまり、データを復号できるのは、暗号化されたマシン上でのみ、さらに暗号化を実行したユーザーによってのみです。
これにより、この方式で暗号化された SteamPassword を含む Bot.json 全体を誰かに送ったとしても、その人はあなたの PC に直接アクセスできない限り、パスワードを復号できません。 これは優れたセキュリティ対策ですが、同時に互換性が最も低いという大きな欠点もあります。この方式で暗号化されたパスワードは、他のユーザーや他のマシンとは互換性がありません。たとえば OS を再インストールした場合は、自分自身であっても互換性がなくなります。 自分以外のマシンから設定にアクセスする必要がない場合は、これは推奨される方法です。 クロスマシンの互換性も必要としません
このオプションは、現時点で Windows OS を実行しているマシンでのみ使用できます。
3 の ECryptoMethod として定義されたメモリベースのストレージ。 ASFは、パスワードフィールドに指定された名前を持つ環境変数からパスワードを読み込みます(例: SteamPassword)。 例えば、 SteamPassword を ASF_PASSWORD_MYACCOUNT と PasswordFormat を 3 に設定すると、ASF は ${ASF_PASSWORD_MYACCOUNT} 環境変数を評価し、アカウントパスワードとして割り当てられたものを使用します。
ASFプロセスの環境変数に権限のないユーザーがアクセスできないことを確認してください。 この方法を使う目的を全て打ち負かすことになります
4 の ECryptoMethod として定義されたファイルベースのストレージ (おそらくASF設定ディレクトリの外側)。 ASFは、パスワードフィールドで指定されたファイルパスからパスワードを読み込みます(例: SteamPassword)。 指定するパスは絶対パス、または ASF の「home」の場所（内部に config ディレクトリがあるフォルダー。--path コマンドライン引数 を考慮します）からの相対パスのどちらでもかまいません。 このメソッドは、例えば **Docker secrets**で使用できます。 このようなファイルを使用するために作成しますが、適切なファイルを作成する場合はDockerの外でも使用できます。 たとえば、SteamPassword を /etc/secrets/MyAccount.pass に、PasswordFormat を 4 に設定すると、ASF は /etc/secrets/MyAccount.pass を読み取り、そのファイルに書かれている内容をアカウントのパスワードとして使用します。
パスワードを含むファイルが許可されていないユーザーによって読み取れないことを確認してください, この方法の全体の目的を打ち負かすように.
互換性が問題にならず、ProtectedDataForCurrentUser 方式の動作に納得できるのであれば、これは ASF でパスワードを保存するための推奨オプションです。最高のセキュリティと利便性を提供するためです。 AES 方式は、任意のマシンで設定を引き続き使用したい人に適した選択肢です。一方、PlainText はパスワードを保存する最も単純な方法ですが、JSON 設定ファイルを見れば誰でもそのパスワードを確認できることを気にしない場合に限ります。
攻撃者があなたのPCにアクセスできる場合、すべての暗号化方式は 安全でない とみなされることに注意してください。 ASFは暗号化されたパスワードを復号できる必要があり、マシン上で実行されているプログラムがそれを行うことができる場合。 同じマシン上で動作する他のプログラムも同様に動作することができます ProtectedDataForCurrentUser は最も安全な方式です。同じ PC を使用している別のユーザーであっても、これを復号できないためです。ただし、ASF 設定ファイルに加えて、ログイン資格情報とマシン情報を盗まれた場合は、データを復号される可能性があります。
高度な設定では、 EnvironmentVariable と File を利用できます。 これらは用途が限られています。何らかのカスタムソリューションでパスワードを取得し、メモリ内にのみ保存したい場合は EnvironmentVariable が適しています。一方、File は、たとえば Docker secrets と組み合わせる場合に適しています。 しかし、どちらも暗号化されていないので、基本的にリスクをASFの設定ファイルから選択したものに移動します。
上記で指定した暗号化方式に加えて、パスワードを完全に指定しないようにすることも可能です。 例えば、 SteamPassword のように、空文字列または null の値を使用します。 ASFが必要なときにパスワードを要求します。 それをどこにも保存しませんが、現在進行中のプロセスを記憶に留めておきましょう パスワードを扱う最も安全な方法である間(どこにも保存されていません)。 ASF実行ごとに手動でパスワードを入力する必要があるので、最も厄介なことです(必要なとき)。 それがあなたにとって問題でない場合は、存在しない何かを漏らすことはできないので、これはあなたの最善の賭けのセキュリティーワイズです。
ASFは暗号化されたパスワードを復号する方法をサポートしていません。なぜなら、復号メソッドはプロセス内のデータにアクセスするために内部的にのみ使用されるからです。 暗号化手順を元に戻したい場合、例: ProtectedDataForCurrentUserを使用して他のマシンにASFを移動する場合は、新しい環境で最初から手順を繰り返します。
ASF は現在、EHashingMethod の定義として、以下のハッシュ化方式をサポートしています：
| 値 | 名前 |
|---|---|
| 0 | プレーンテキスト |
| 1 | SCryptformat@@0 |
| 2 | Pbkdf2 |
それらの正確な説明と比較は以下で入手できます。
ハッシュを生成するには、たとえば IPCPassword で使用する場合、選択した適切なハッシュ方式と元の平文パスワードを指定して、hash コマンド を実行してください。 その後、取得したハッシュ化済み文字列を ASF 設定プロパティの IPCPassword として設定し、最後に IPCPasswordFormat を選択したハッシュ化方式に一致するものへ変更してください。
これは、 0 の EHashingMethod として定義された、パスワードをハッシュする最もシンプルで安全でない方法です。 ASFは元の入力に一致するハッシュを生成します。 これは最も使いやすく、すべてのセットアップと100%互換性があります。 秘密を保管する標準的な方法です安全に保管するには まったく安全ではありません
現在の基準で安全と見なされる SCrypt 方式でのパスワードハッシュ化は、EHashingMethod の 1 として定義されています。 ASF は、8 ブロック、8192 回の反復、32 のハッシュ長、およびソルトとしての暗号化キーを使用する SCrypt 実装を使って、バイト配列を生成します。 その結果得られたバイト列は、base64 文字列としてエンコードされます。
ASF では、--cryptkey コマンドライン引数 を通じて、この方式に使用するソルトを指定できます。最大限のセキュリティを確保するため、この方法を使用することをおすすめします。 これを省略した場合、ASF はアプリケーションにハードコードされた、既知の独自キーを使用します。つまり、ハッシュ化の安全性は低くなります。
適切に使用された場合 (カスタムソルト、長いパスワード)、安全なストレージのための非常に高いセキュリティを保証します。
現在の基準では弱いと見なされる Pbkdf2 方式でのパスワードハッシュ化は、EHashingMethod の 2 として定義されています。 ASF は Pbkdf2 実装を使用します。この実装では、10000 回の反復、32 のハッシュ長、ソルトとしての暗号化キー、および HMAC アルゴリズムとして SHA-256 を使用します。 その結果得られたバイト列は、base64 文字列としてエンコードされます。
ASF では、--cryptkey コマンドライン引数 を通じて、この方式に使用するソルトを指定できます。最大限のセキュリティを確保するため、この方法を使用することをおすすめします。 これを省略した場合、ASF はアプリケーションにハードコードされた、既知の独自キーを使用します。つまり、ハッシュ化の安全性は低くなります。
IPCPassword などの機密情報を保存するためにハッシュ化方式を使用したい場合は、カスタムソルト付きの SCrypt を使用することをおすすめします。ブルートフォース攻撃に対して、非常に十分な安全性を提供するためです。
Pbkdf2 は互換性の理由からのみ提供されます。 主な理由は、すでにSteamプラットフォーム全体で他のユースケースのために機能している(そして必要な)実装があるからです。 を選択します。 それはまだ安全と考えられていますが、代替品(例えば SCrypt)に比べて弱いです。
