久久久久av_欧美日韩一区二区在线_国产精品三区四区_日韩中字在线

Discuz! 官方交流社區

標題: X3.5登陸方式直接用明文了嗎？ [打印本頁]

作者: hopejyb 時間: 2023-1-28 17:21
標題: X3.5登陸方式直接用明文了嗎？
(, 下載次數: 33)
印象中之前是md5加密之后傳遞的，現在X3.5直接明文傳遞了嗎？

作者: cornersoft 時間: 2023-1-28 17:27
原有的md5加密后傳輸登錄的方式因存在一定的安全隱患(如撞庫攻擊)，已在3.5版本移除
3.5版本使用了業界公認的安全實踐方案來保存密碼。

順帶一提：明文傳輸密碼并不會降低安全性，前提是論壇需要使用https加密。

雖然也有少量業界實現會考慮在網頁內使用非對稱加密的方式再加密一次，但由于沒有基于操作系統底層支持的公鑰體系，這樣的加密約等于掩耳盜鈴，除了應付安全部門檢查以外沒有什么實際作用。

作者: hopejyb 時間: 2023-1-28 17:31

cornersoft 發表于 2023-1-28 17:27
原有的md5加密后傳輸登錄的方式因存在一定的安全隱患(如撞庫攻擊)，已在3.5版本移除
3.5版本使用了業界公認 ...

多謝答疑。

作者: jacky9595 時間: 2023-1-28 18:18

cornersoft 發表于 2023-1-28 17:27
原有的md5加密后傳輸登錄的方式因存在一定的安全隱患(如撞庫攻擊)，已在3.5版本移除
3.5版本使用了業界公認 ...

搭個帖問一下，請問閣下的reCAPTCHA云驗證碼什么時候支持x3.5？非常感謝

作者: 老周部落 時間: 2023-1-28 18:24

cornersoft 發表于 2023-1-28 17:27
原有的md5加密后傳輸登錄的方式因存在一定的安全隱患(如撞庫攻擊)，已在3.5版本移除
3.5版本使用了業界公認 ...

另外從安全角度補充一點具體的隱患（以下都是基本常識或者公開內容，不涉及秘密）。

撞庫攻擊指的是因為 MD5 哈希實現在前端，程序無法區分是用戶輸入明文密碼被哈希還是攻擊者直接從其他使用 md5(password) 密碼存儲方式的其他網站獲取的數據庫進行嘗試，因此是存在安全隱患的。
非對稱加密的問題是無法抵御中間人攻擊，中間人可以在服務器和客戶端之間建設服務器，將服務器下發的公鑰替換為自己的公鑰實現截取密碼數據，也可以在解密之后重新用服務器下發的公鑰加密讓用戶無感知泄露密碼。解決中間人攻擊的唯一手段就是使用操作系統內置的根證書對服務器下發的公鑰進行簽名，也就是 HTTPS 使用的 CA 證書體系。

作者: cornersoft 時間: 2023-1-28 21:39
本帖最后由 cornersoft 于 2023-1-28 21:40 編輯

jacky9595 發表于 2023-1-28 18:18
搭個帖問一下，請問閣下的reCAPTCHA云驗證碼什么時候支持x3.5？非常感謝

仍然在開發當中，預計會支持X3.5，以及提供一些全新的功能。
時間無法確定。
另外可以嘗試將X3.4版本的本插件直接復制至X3.5當中使用。理論上電腦端應該不會有不兼容的問題出現。手機端目前無法確定。

作者: TeCHiScy 時間: 2023-2-4 11:46
本帖最后由 TeCHiScy 于 2023-2-4 11:49 編輯

前端 md5 也不是完全沒用吧。

假定 A 站沒有 https 且使用明文，有人在 A 站上實施 MITM，這樣就可以拿到 A 站用戶的明文密碼，這時候它可以直接用明文密碼去撞 B、C、D 等其它站。
如果有前端 md5，MITM 拿到的就是 hash，雖然這時候攻擊者還是能用 hash 直接登錄 A 站，但是應該沒辦法撞 B、C、D，因為同一個用戶即使明文密碼一樣，但是在別的站的 salt 各不相同，用從 A 拿到的 hash 在別的站不能使用。

感覺，這里實際上要不就是明文密碼撞，要不就是 hash 值撞，感覺用戶設置相同的明文密碼的可能性很高，這樣明文撞是不是更危險一些？

當然，如果 A 站有 https 那肯定沒問題，但是實際是不是都正確配置了 https 就難說了，全部用明文感覺有點一刀切了。

作者: 老周部落 時間: 2023-2-4 12:53

TeCHiScy 發表于 2023-2-4 11:46
前端 md5 也不是完全沒用吧。

假定 A 站沒有 https 且使用明文，有人在 A 站上實施 MITM，這樣就可以拿到 ...

1. 如果 BCD 也是同樣的 md5(password) 做前端上傳，那這個 hash 就可以通用。salt 是應用和數據庫之間的交互，前端登錄不涉及 salt 。
2. 如果不選用 HTTPS ，那任何其他方式包括公私鑰都解決不了 MITM 的問題。現在黑客普遍也逐步具備解 md5(md5(password)+salt) 的能力了，而 MITM 的實施難度又遠高于拖數據庫，這么看來反倒是現狀更合理。
3. 我覺得要加最多也就是套一層公私鑰，對于只能監聽不能 MITM 的場景會好于現狀。

作者: pcyi 時間: 2023-2-4 13:48

老周部落發表于 2023-2-4 12:53
1. 如果 BCD 也是同樣的 md5(password) 做前端上傳，那這個 hash 就可以通用。salt 是應用和數據庫之間的 ...

看了下上下文討論內容
針對密碼安全性方面，X3.5是不是必須要配置Https呢？

作者: TeCHiScy 時間: 2023-2-4 15:00

老周部落發表于 2023-2-4 12:53
1. 如果 BCD 也是同樣的 md5(password) 做前端上傳，那這個 hash 就可以通用。salt 是應用和數據庫之間的 ...

如果前端不是簡單 md5(password) 而是 md5(md5(password)+salt) 呢？

考慮到 md5 的碰撞和彩虹表等已知問題，這里甚至可讓用戶自由選擇一種 hash 和具體拼接算法

這樣至少在無 https 的情況下還能提供一些安全性

作者: 專家 時間: 2023-2-4 15:02

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

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

你再好好想一想，salt的意義就是每個用戶的salt都不相同。
你如何在前端用戶還未登錄的情況下給輸入框匹配正確的salt呢？

作者: TeCHiScy 時間: 2023-2-4 15:06
本帖最后由 TeCHiScy 于 2023-2-4 15:13 編輯

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

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

作者: 專家 時間: 2023-2-4 15:14

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

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

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

作者: 專家 時間: 2023-2-4 15:38

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漏了反而還會影響到自己。
拿自己站點的安全性當代價去給別人提升安全性這種事情還是不要做比較好……

作者: 老周部落 時間: 2023-2-4 18:06

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

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

作者: 老周部落 時間: 2023-2-4 18:14

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

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

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

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

作者: 老周部落 時間: 2023-2-4 18:25

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 中只是簡單地增加了一個風險因素，沒有任何重要的理由。

作者: hopejyb 時間: 2023-2-4 20:54

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

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

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

作者: TeCHiScy 時間: 2023-2-4 21:21

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

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

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

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

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

作者: 專家 時間: 2023-2-4 22:30

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

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

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

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

歡迎光臨 Discuz! 官方交流社區 (http://www.9999xn.com/)