我的安全模型有什麼問題 - 或者它如何受到攻擊？

我正在做一個個人項目，其中安全性非常重要，並且我已經考慮了一段時間的最佳方法來做到這一點。現在我正在尋找一些關於良好做法的外部幫助。目標是將個人文本數據儲存在伺服器上（如 wifi 密碼等）並通過密碼獲取。我想為幾個朋友創建使用者帳戶，以便我們每個人都可以安全地儲存文本片段並在其他人不知道的情況下檢索它們。這是我的資料結構：

// Account
- Username
- Password
- Salt

// StoredData
- Title
- Info
- User

好的，現在是有趣的部分。這是我混淆數據的方式。當朋友創建帳戶時，他們的使用者名會在伺服器配置文件中加鹽（這是 Rails 順便說一句，所以 ENV

$$ ‘SALT’ $$) 然後 SHA256’d。密碼是通過 BCrypt 生成的。我唯一不確定的是要為 BCrypt 做多少輪，以便伺服器保持敏捷；現在它是 ruby​​ 的 bcrypt 庫的預設設置。一個隨機鹽也保存在帳戶中以供下一步使用。

Username = SHA256(username + SERVER_SALT)
Password = BCrypt(password)
Salt = BCrypt.generateSalt

當朋友保存他們的數據時，會使用 AES-256 對其進行加密。因此，為此，使用他們的明文使用者名和密碼的組合生成 AES 密鑰，以及在帳戶創建中生成的鹽。該密鑰永遠不會儲存在伺服器上，而是在執行時在設備上創建。

        PBKDF2_HMAC_SHA1(secret, salt, rounds)
AESKey = PBKDF2_HMAC_SHA1((usernamepassword), Account.Salt, 20000)
Title = AES-256(AESKey, title)
Info = AES-256(AESKey, info)

最後但並非最不重要的一點是，每次登錄時，您都會獲得一個 SessionKey，使您能夠執行任何功能，例如編輯或創建新數據。此 SessionKey 在每次操作後滾動。所以，在登錄時你會得到 S1，然後你製作一條新數據，S1 被刪除，S2 給你。等等等等。每個 SessionKey 也有一個小時的時間限制。這是我的資料結構：

// SessionKey
- Key (32-bit GUID)
- HashedUser
- ExpirationDate

此外，整個事情都是通過 SSL 來回發送的，儘管在最近的爆料之後，我不太確定它有多安全了。我對社區的問題是——我做錯了什麼？我沒有推出任何加密實現，我只是使用多個庫存實現。BCrypt 是 10 輪，PBKDF2 現在是 20,000。對於當代密碼學和我知道有些人擁有的電腦系統，這些是否足夠高？有沒有大洞？整個事情都是一廂情願嗎？

使用者名

散列的使用者名很好；實際上對於安全偏執狂來說是一個好主意。如果所有使用者名記錄都使用相同的鹽，那麼理論上可能會發生彩虹攻擊 - 就像知道使用者擁有 X 條安全資訊（加上時間戳等）一樣。但是如果使用者名是元組選擇機制，則每個表都需要一個鹽。

秘密片段（標題/資訊/可見時間戳）

根據該服務提供的其他功能，密碼不需要儲存在伺服器端來保護秘密片段；從而避免了 bcrypt 的時間成本。如果使用者輸入錯誤的密碼，您的服務可以愉快地解密並返回語義垃圾。如果使用者輸入了一個不匹配的使用者名，伺服器可以愉快地發明一個隨機可編輯的隨機數據列表；打破關於可行使用者名的任何線索。客戶端代理可以使用特定於上下文的標誌或校驗和驗證來丟棄解密的垃圾。

在伺服器上儲存密碼通常用於身份驗證而不是保密。電腦是否應該為某人做某事——而不是返回的數據是否適合用途。如果使用者不想刪除或修改他們的數據，他們可以簡單地被告知選擇一個無法猜測的使用者名；以類似於一次性電子郵件收件箱的方式。如果使用者名被猜到，內容仍然無法理解。

會話密鑰

似乎是合法的。如果會話不包含解密密碼或聚合 AES 密鑰，並且使用者希望看到明文內容，則使用者的客戶端將需要記憶體密碼或明文；或者持久會話仍然會在每次頁面刷新時讓使用者輸入密碼。

其他想法

或者，如果服務只是儲存安全資訊；然後可以在客戶端使用 ad-hoc 公鑰方法進行解密。是的，對於那些反對者來說，您可以未經驗證地使用公鑰；如果服務對使用使用者名的人是否已更改或只是他們的密碼無動於衷。SSL 框架提供針對中間人攻擊的保護。如果沒有 - 你必須重新發明一個更大的輪子。

引用自：https://crypto.stackexchange.com/questions/10132