Security zh TW
ASF目前支援以下加密方式，作為ECryptoMethod的定義：
| 值 | 名稱 |
|---|---|
| 0 | PlainText（純文字） |
| 1 | AES（進階加密標準） |
| 2 | ProtectedDataForCurrentUser |
| 3 | EnvironmentVariable（環境變數） |
| 4 | File（文字檔） |
以下提供了它們的詳細說明及比較。
要生成加密的密碼，例如在SteamPassword中使用，您可以執行encrypt指令，並加上您所選的適當的加密方式及您密碼的原始純文字。 然後，將您獲得的加密字串輸入SteamPassword Bot設定屬性，並修改PasswordFormat對應至您所選的加密方法。 某些格式不需要encrypt指令，例如EnvironmentVariable或File，只需給予適合的路徑。
這是最簡單也最不安全的密碼儲存方式，指定ECryptoMethod為0。 ASF字串應為純文字⸺即原始形式的密碼。 它是最容易使用的，且與所有設定100%相容，因此它是儲存私密資料的預設方式，但對於安全儲存來說毫無安全性可言。
依照現今的標準，可以將AES儲存密碼的方式視為安全的，指定ECryptoMethod為1。 ASF字串應為AES加密的位元組陣列轉換成Base64編碼的字元序列，需含有初始向量及ASF加密鍵來解密。
上述方法保證了安全性，只要攻擊者不知道用於加密及解密的ASF加密鍵。 ASF使您能夠透過--cryptkey命令列引數來獲得最大的安全性。 若您決定省略它，ASF將會使用自己已知硬編碼至應用程式中的金鑰，這代表任何人都可以逆轉ASF的加密，並獲得解密的密碼。 雖然這需要一些時間且不容易做到，但它還是有可能的。這就是為什麼您總應一起使用AES及您自己的--cryptkey來加密。 ASF使用的AES方法提供了令人滿意的安全性，它在簡單的PlainText及複雜的ProtectedDataForCurrentUser間取得了平衡，並強烈建議您與自訂的--cryptkey一起使用。 若使用得當，就能保證安全儲存的良好安全性。
這是目前ASF提供最安全的密碼加密方式，比上述的AES方法還安全的多，您需將ECryptoMethod設為2。 這種方法的主要優點同時也是主要缺點：並不使用加密金鑰（如同AES），資料是使用當前登入使用者的憑證來加密的，也就是說它只能在加密設備上解密，除此之外也只能被加密使用者所使用。 若您使用此方法加密Bot.json的SteamPassword，即使您將整個檔案傳送給其他人，那麼要是他沒有直接存取您PC的權限，也無法解密密碼。 這是一種非常優秀的安全措施，但同時也有一個巨大的缺點，那就是幾乎沒有相容性可言，因為使用這種方法加密的密碼會與其他使用者或設備不相容：假設您打算重新安裝作業系統，這也將包含您自己的設備。 不過這仍是儲存密碼的最好方法，若您擔心PlainText的安全性，也不想要每次都輸入密碼，只要您不會在其他設備上存取您的設定檔，那麼這就是您最好的選擇。
請注意，這個選項目前只適用於執行Windows作業系統的設備。
基於記憶體的儲存方法，ECryptoMethod為3。 ASF會從環境變數中讀取密碼，且名稱需指定於密碼欄位中（例如SteamPassword）。 舉例來說，把SteamPassword設定成ASF_PASSWORD_MYACCOUNT、PasswordFormat設定成3，就能讓ASF讀取環境變數${ASF_PASSWORD_MYACCOUNT}作為帳號的密碼。
基於檔案的儲存方法（可在ASF設定資料夾外），ECryptoMethod為4。 ASF會從密碼欄位（例如SteamPassword）指定的路徑中讀取密碼。 指定的路徑可以是絕對路徑，也可以相對於ASF的「主要」位置（就是含有config資料夾的資料夾，並與--path命令列引數相符）。 此方法可用於Docker secret，它會建立這類檔案以供使用，但若您自行建立檔案，亦可在Docker外使用。 舉例來說，把SteamPassword設定成/etc/secrets/MyAccount.pass、PasswordFormat設定成4，就能讓ASF讀取/etc/secrets/MyAccount.pass檔案內容作為帳號的密碼。
記住，請確保未授權的使用者無法讀取含有密碼的檔案，因為這樣就違背了使用本方法的目的。
若相容性對您而言並不是個問題，且您可以接受ProtectedDataForCurrentUser方法的運作方式，那麼建議使用此選項來在ASF中儲存密碼，因為它擁有最好的安全性。 AES方法對於那些想要在其他設備上使用設定的使用者來說是個不錯的選擇，而若您不介意其他人都可以查閱JSON設定檔，那PlainText是最簡單儲存密碼的方法。
請注意，若攻擊者存取您的PC，則上述3種方法都被視為不安全。 ASF必須能解密被加密的密碼，但若您設備上執行的程式能解密，那麼在相同設備上執行的其他程式亦能解密您的密碼。 ProtectedDataForCurrentUser是最安全的方式，因為即使使用同一台PC的其他使用者，也無法解密密碼，但若有人能夠竊取您的登入憑證、設備資訊及ASF設定檔，則仍能解密這些資料。
對於進階的設定，您可以使用EnvironmentVariable與File。 它們的用途有限，若您希望透過某種自訂方式來獲得密碼，並只儲存於記憶體中，使用EnvironmentVariable比較好；而例如使用Docker secret的情形則更適合使用File。 不過，它們都並未加密，因此基本上是將風險從ASF設定檔轉移到您選擇的這兩個方法的位置上。
除了上述指定的加密方法外，也可以完全不指定密碼，例如在SteamPassword設定成空字串，或null值。 ASF會在需要時向您詢問密碼，且不會儲存於任何地方，而是儲存於當前執行程序的記憶體中，直到您關閉它。 雖然這是儲存密碼最安全的方式（密碼並未儲存於任何地方），但也是最麻煩的，因為您需要在每次執行ASF時手動輸入密碼（若需要）。 若這對您而言並不是個問題，那這就是您在安全性方面最好的選擇。
ASF不支援解密已加密密碼的任何方式，因為解密方式只在內部使用，用於存取程序裡的資料。 若您需要反轉加密過程，例如使用了ProtectedDataForCurrentUser後將ASF移動至另一台設備上，只需在新環境中重新開始上述流程即可。
ASF目前支援的雜湊方法EHashingMethod定義如下：
| 值 | 名稱 |
|---|---|
| 0 | PlainText（純文字） |
| 1 | SCrypt |
| 2 | Pbkdf2 |
以下提供了它們的詳細說明及比較。
若要生成雜湊，如在IPCPassword中使用，您應執行hash指令，並選擇適合您的雜湊方法及原始的純文字密碼。 之後將雜湊字串放入IPCPassword ASF設定屬性，最後修改IPCPasswordFormat對應至您選擇的雜湊方法。
這是最簡單也最不安全的密碼雜湊方式，指定EHashingMethod為0。 ASF會生成與原始輸入相同的雜湊值。 它是最容易使用的，且與所有設定100%相容，因此它是儲存私密資料的預設方式，但對於安全儲存來說毫無安全性可言。
依照現今的標準，可以將SCrypt雜湊密碼的方式視為安全的，指定EHashingMethod為1。 ASF以8個區塊、8192次迭代、32位雜湊長度，並使用加密鍵作為鹽的SCrypt，來生成字元組陣列。 生成的位元組字串以Base64編碼。
ASF使您能夠透過--cryptkey命令列引數指定鹽來增加此方法的安全性。 若您決定省略它，ASF將會使用自己已知硬編碼至應用程式中的金鑰，這代表雜湊將會較不安全。 若使用得當，就能保證安全儲存的良好安全性。
依照現今的標準，Pbkdf2雜湊密碼的方式較不安全，指定EHashingMethod為2。 ASF以10000次迭代、32位雜湊長度，並使用加密鍵作為鹽、SHA-256作為HMAC演算法的Pbkdf2，來生成字元組陣列。 生成的位元組字串以Base64編碼。
ASF使您能夠透過--cryptkey命令列引數指定鹽來增加此方法的安全性。 若您決定省略它，ASF將會使用自己已知硬編碼至應用程式中的金鑰，這代表雜湊將會較不安全。
若您想要以雜湊方法來儲存私密資料，例如IPCPassword，我們建議您加鹽使用SCrypt，因為它提供了非常好的安全性來防止暴力破解。 Pbkdf2是因為相容性問題才提供的，主要是因為我們已經為Steam平台上的其他功能（例如家庭監護PIN碼）提供了一個有效的（且需要的）實作功能。 它仍被認為是安全的，但與其他替代方案相比沒那麼安全（例如SCrypt）。
