TeCHiScy 發表于 2023-2-4 21:21
理論上是這樣，不過如果能在非 https 環境下提供一種基線安全也是好的。

對于像校園網、企業內部論壇這 ...

恰好相反，雖說很多單位內網對安全性的重視不如專業的運營商，但他們往往可以保證所有的網絡資產都完全由自己人在管理。相比公眾網絡，途中接入了來自攻擊者的不可信設備的可能性要更小。至少在中間人攻擊這一個方面，此類網絡相對來說是更安全的。

另外http不安全這種事情不需要網站應用程序去做，瀏覽器自己就做了。
而且現實當中也并非所有網絡都是不可信的，在可信的網絡下http也不會造成安全影響。

hopejyb 發表于 2023-2-4 20:54
不https何談安全性，是不是？
另外的問題是，前端是沒有salt值的。

理論上是這樣，不過如果能在非 https 環境下提供一種基線安全也是好的。

對于像校園網、企業內部論壇這種不重視安全的環境，或者一些懶癌、不懂技術admin，用戶只能冒著被截獲明文密碼的可能去用這些論壇，可能不太友好吧。

還是要說一下，https 肯定是最佳方案。

另外也在想，是不是在 admincp 首頁以及其它顯著位置，反復強調、提醒 “在非 https 環境下使用 Discuz 可能存在密碼安全隱患”，讓站長重視起來。

TeCHiScy 發表于 2023-2-4 15:00
如果前端不是簡單 md5(password) 而是 md5(md5(password)+salt) 呢？

考慮到 md5 的碰撞和彩虹表等已知 ...

不https何談安全性，是不是？
另外的問題是，前端是沒有salt值的。

TeCHiScy 發表于 2023-2-4 15:00
如果前端不是簡單 md5(password) 而是 md5(md5(password)+salt) 呢？

考慮到 md5 的碰撞和彩虹表等已知 ...

剛想起來，PHP 為什么要放棄自選 salt 的功能，就是很多人根本不具備生成一個好 salt 的水平。
至于開放 Hash 算法自選嘛，先不論業務實現層面的困難，就以用戶水平來說就很難做到安全。

Ref: https://externals.io/message/85595

自從 password_hash() 在 PHP 5.5 中引入以來，我一直在盡可能多地觀察它的用法。我已經設置了 Google 警報以及我在 GitHub 上找到的審計實現，試圖了解它是如何使用的。
我已經非常清楚一件事：鹽選項很危險。我還沒有看到 salt 選項的單一用法達到不錯的水平。每種用法的范圍都從糟糕（傳遞 mt_rand() 輸出）到危險（靜態字符串）再到瘋狂（將密碼作為自己的鹽傳遞）。
我得出的結論是，我認為我們不應該允許用戶指定鹽。如果用戶需要生成自己的鹽， crypt() API 仍然存在。將它放在簡化的 API 中只是簡單地增加了一個風險因素，沒有任何重要的理由。

TeCHiScy 發表于 2023-2-4 15:00
如果前端不是簡單 md5(password) 而是 md5(md5(password)+salt) 呢？

考慮到 md5 的碰撞和彩虹表等已知 ...

md5 算法不用考慮了，之前討論過黑客已具備暴力破解帶 salt 密碼的能力，另外 salt 默認公開會降低 salt 的效力，如果我想知道一個人的密碼，先拿到 salt 構建彩虹表是可以和日服務器并行的。

有能力自選 Hash 和算法的，大概率用戶層面能接受密碼管理器，站點層面能標配 HTTPS 支持。沒能力的只會創造出大量登錄不上去的案例，業務上面不現實。

pcyi 發表于 2023-2-4 13:48
看了下上下文討論內容
針對密碼安全性方面，X3.5是不是必須要配置Https呢？ ...

HTTPS 對于公網站點來說一直是推薦配置。

TeCHiScy 發表于 2023-2-4 15:06
嗯，的確是這樣，明白了。在想類似“同態哈希”的方式是否可能對非https情況下保護明文有用。 ...

非https的情況下目前的確沒有穩妥的辦法保護密碼，https能起到安全作用的核心還是在操作系統層面提供的根證書體系，這個在網頁里無論如何都不可能模擬出來。走http傳輸公鑰就等于放在那等著被人替換。
別的方法也不行，凡是走明文傳遞給用戶的參數都可能被中間人替換。

順帶說一下，做這個弊大于利的主要因素還是這2點（不然哪怕沒有用留著當個障眼法也好）：
1. 一旦前端用md5加密一次，后端存儲的時候就必須嵌套一層md5在里面。我們已經更換為使用安全系數極高的 bcrypt / argon2i 等算法，套一層md5在里面會大幅度降低存儲時的安全性。
2. 現實世界當中，十幾年前的老系統普遍沒有安全意識，密碼在數據庫里存儲的形式真的就只是md5(password)，不加鹽。這樣的老系統現實當中太多太多了，甚至于我親眼見過前幾年還有自稱十幾年開發經驗的老開發者還在寫這種代碼。當這樣的系統被拖庫了，對前端使用md5(password)加密的站點會產生不小的影響。
現實場景里面，實施拖庫的概率要遠遠大于做中間人監聽，前者一般的黑客挖到了洞就能實施，后者的要求可不簡單。

---

順帶一提，做這些安全措施的核心還是保護自己的安全性。
確實可能存在自己前端md5，被人抓走了結果不能用在其他人前端未md5的站點上這種情況。
但是這不成了犧牲自己保護他人么？別人如果md5漏了反而還會影響到自己。
拿自己站點的安全性當代價去給別人提升安全性這種事情還是不要做比較好……

pcyi 發表于 2023-2-4 13:48
看了下上下文討論內容
針對密碼安全性方面，X3.5是不是必須要配置Https呢？ ...

想要安全性的話必須配置https，否則通信中的任何內容，不只是密碼，都有可能被第三方截獲。

實際情況的話，這種事情在多數情況下需要運營商級別的能力才能實施盜取密碼這種事情。而國內的運營商雖然早期https未普及的時候確實經常干那種往別人網頁里植入廣告代碼之類的事情，但是盜取密碼一般還是沒聽說過，可能還是有底線的。目前的寬帶和手機蜂窩網絡大體上還算安全。
目前比較明顯的弱點一般會發生在公共場所無密碼的WiFi上，這種場景容易被第三方監聽。

專家 發表于 2023-2-4 15:02
你再好好想一想，salt的意義就是每個用戶的salt都不相同。
你如何在前端用戶還未登錄的情況下給輸入框匹 ...

嗯，的確是這樣，明白了。在想類似“同態哈希”的方式是否可能對非https情況下保護明文有用。