維基百科討論:密碼方針
外觀
訂立密碼方針
[編輯]在2015年12月,英文版有兩名ADMIN的密碼因使用DOB和6位數字而被破。中文版過去亦發生過管理員被盜號的事件。
為此,我提議訂立密碼方針,要求管理員以上職階使用強式密碼,並定期接受審查(即基金會人員會定期嘗試破解密碼)。
--Temp3600(留言) 2017年7月8日 (六) 18:30 (UTC)
剛好有網站能測密碼強度[1],不過還是強烈(+)支持設立方針(#4279計算過程 2017年7月9日 (日) 06:07 (UTC)
(-)反對第一,上述的網站只能算是一個測試網站,嚴格來說和維基百科扯不上邊。第二,維基工具要如何發展此一工具?,第三,如果要這麼討論,不如順便設個密碼為限制好了,過短的密碼應重設-Z7504(留言) 2017年7月9日 (日) 12:04 (UTC)- (:)回應網站和提案無關。基金會已在英文版實施本政策,故無須擔心無法實行的問題。--Temp3600(留言) 2017年7月9日 (日) 13:21 (UTC)
- 一些補充資料:
- 經管理員測試,原來現在已經不能訂立8位以下的密碼。大家希望將限制擴展至所有用戶,又或增加更多限制嗎?--Temp3600(留言) 2017年7月9日 (日) 15:02 (UTC)
- (?)疑問@Temp3600:是請誰測試呢?--Z7504(留言) 2017年7月9日 (日) 15:34 (UTC)
- (:)回應會由security team負責。--Temp3600(留言) 2017年7月9日 (日) 17:48 (UTC)
- security team,慢慢整修版本吧,改(+)支持了--Z7504(留言) 2017年7月10日 (一) 01:36 (UTC)
- (:)回應會由security team負責。--Temp3600(留言) 2017年7月9日 (日) 17:48 (UTC)
- (+)支持具有影響站務權限的用戶密碼需自我有所防備,當被不法入侵會引響多數頁面造成困擾,個人贊同此提議,另外八位數以下在有心與有技術的人在數分鐘的數小時內破解,八位元以上的時間差數倍以上,具有較好的保護能力,如果包含用戶頁上的一些資訊如生日在密碼上更容易破解,拒絕傻瓜密碼、連號密碼。--Zest 2017年7月9日 (日) 16:20 (UTC)
- (!)意見技術上不知道可不可行,如果有人試圖破解密碼則通知用戶(密碼多次打錯、短時間內多次輸入)提醒修改密碼或增加第二層驗證行為。--Zest 2017年7月9日 (日) 16:20 (UTC)
- 在Phabricator上已有類似提案(T11838︰多次嘗試登入失敗後發送通知予帳戶持有人)。而最後進度報告指已經交付測試。--J.Wong 2017年7月9日 (日) 16:51 (UTC)
- 任何限制密碼格式的行為本質上都是縮小密鑰空間的行為,並沒有意義。維護強壯密碼是管理員的責任,必須假設任何管理員至少具備這個能力。Bluedeck 快速存檔 2017年7月9日 (日) 22:27 (UTC)
- 其實查核員也應要有這能力吧,不然很難被相信算是個真正的用戶查核員(雖然一般密碼盜密機率不像傀儡這麼多...)--Z7504(留言) 2017年7月10日 (一) 01:39 (UTC)
- 任何限制密碼格式的行為本質上都是縮小密鑰空間的行為,並沒有意義。維護強壯密碼是管理員的責任,必須假設任何管理員至少具備這個能力。Bluedeck 快速存檔 2017年7月9日 (日) 22:27 (UTC)
- 在Phabricator上已有類似提案(T11838︰多次嘗試登入失敗後發送通知予帳戶持有人)。而最後進度報告指已經交付測試。--J.Wong 2017年7月9日 (日) 16:51 (UTC)
- (:)回應的確,社群信任管理員能管理好自己的帳號。但如果多次使用弱密碼,屢勸不聽,自然可以作為失職事由要求解職。--Temp3600(留言) 2017年7月10日 (一) 14:09 (UTC)
- 這個不是說已經實施了麼?難道我記錯了?--百無一用是書生 (☎) 2017年7月10日 (一) 02:13 (UTC)
- 建議@Temp3600:詳細說明上述問題?--Z7504(留言) 2017年7月10日 (一) 03:31 (UTC)
- 的確,META方針已經實行。本案目的有二:
- 提供META方針的中文版本。
- 如有需要,給予社群機會討論是否需增加額外限制,如討論password audit的次數和方式。--Temp3600(留言) 2017年7月10日 (一) 05:39 (UTC)
- 這個只能是通過技術實現才行啊。規定有什麼用呢--百無一用是書生 (☎) 2017年7月10日 (一) 06:13 (UTC)
- (:)回應需要先有本地共識才能交到PHAB,在技術實面上落實。--Temp3600(留言) 2017年7月10日 (一) 14:07 (UTC)
- 這個只能是通過技術實現才行啊。規定有什麼用呢--百無一用是書生 (☎) 2017年7月10日 (一) 06:13 (UTC)
- 如果這個密碼方針通過後,如何實施呢。這得要求管理員使用高強度的密碼吧,如何證明管理員使用了高強度的密碼?——꧁༺星耀晨曦༻꧂(留言) 2017年7月10日 (一) 07:24 (UTC)
- (:)回應星耀晨曦的問題:
- 第一,技術上,會向PHAB請求,禁止管理員使用某些弱密碼(事實上目前管理員已經不能使用8位以下的密碼,這裏討論是否需要再加強)
- 第二,會向wmf安全組請求,讓他們定期對本地admin進行密碼測試,嘗試攻入帳號。如果密碼一攻就破,強度自然成疑。--Temp3600(留言) 2017年7月10日 (一) 14:16 (UTC)
- (+)支持為什麼要反對呢 ?--我要真普選 Asdfugil (留言 | 簽名) 留言於香港特別行政區。 2017年8月16日 (三) 01:22 (UTC)
整理
[編輯](我覺得cwek君的問題是很好的重點整理,特搬來此處﹐方便回應。)--Temp3600(留言) 2017年7月10日 (一) 14:56 (UTC)
- 我覺得先討論幾個問題吧:
- 是否支持對ABCO組啟用強密碼定期例行測試,甚至二步驗證功能?
- 基金會是否有相應工作小組允許例行或請求進行密碼挑戰測試?(看上去已經有了)例行的頻率多長?自我申請的話允不允許?
- 如何判斷是強密碼?或者怎樣驗證或強密碼的要求?
- 三個問題能給出詳細方案的話,才好進行確立共識吧。——路過圍觀的Sakamotosan 2017年7月10日 (一) 07:04 (UTC)
- (:)回應
- 問題一:技術上二者皆可行。ABCO現在已經可以申請2FA,而強密碼定期例行測試則需要在獲取本地共識後,和基金會安全組再申請。但既然英文組亦有類似計劃,無理由中文區弄不出來。
- 問題二:基金會安全組。例行的頻率未確定(英文區尚未定案),我個人提議半年一次。自我申請不清楚,但meta看來對低權限用戶的密碼保安不太在意。
- 問題三:目前meta方針已禁止8位以下密碼。如果社群認為有必要,可要求加長,增加大小階/數字/符號要求,要求定期改密碼等等。個人對此未有太大想法,偏向維持目前要求。本案目的主要是新增password audit,但如果社群有意收緊密碼要求(如要所有用戶使用強密碼),當然可以提出。--Temp3600(留言) 2017年7月10日 (一) 15:09 (UTC)
- 如果我來回答的話,結合enRFC的做法
- 支持ABCO組定期進行密碼審計,ABCO組可以申請或建議一定要開二步認證(尤其C組)
- 如果基金會支持一經申請能定期自動審計並公布結果的話,就可以申請定期審計計劃,並按時公布結果。否則由本地定期去申請審計並接收結果並公布。周期初步為半年,不建議超過一年。個人申請的話感覺太麻煩,每次自己改完密碼然後申請審計再說我改了密碼沒問題的,太彆扭了。不要求自行改密碼就要申請審計,但不反對自行申請審計。
- 好像現在A組默認開啟長度要求,至於其他細則的話,例如大小寫數字符號非字典化單詞組合或個人公開信息等,可以作為一個至少倡議去約束,如果技術已實現的話,也可以去實行,密碼強度也有提供一些強度測試網站,可以用來自我初步測試。en的要求就是長於8字節和非常用密碼表en:Wikipedia:Most_common_passwords/10000中則可。——路過圍觀的Sakamotosan 2017年7月11日 (二) 01:44 (UTC)
- 另外本地群組不建議全部實現密碼強度限制,只要重要管理組(即ABCO)強制要求則可,另不知道普通用戶有沒興趣允許使用二步驗證的設定?——路過圍觀的Sakamotosan 2017年7月11日 (二) 01:46 (UTC)
- 就算是普通用戶也要有一定的密碼強度,避免攻破後淪陷為破壞者的傀儡。4279計算過程 2017年7月11日 (二) 02:44 (UTC)
- 不強制吧,畢竟不是這麼多人有這麼高的安全需求。——路過圍觀的Sakamotosan 2017年7月11日 (二) 03:29 (UTC)
- 就算是普通用戶也要有一定的密碼強度,避免攻破後淪陷為破壞者的傀儡。4279計算過程 2017年7月11日 (二) 02:44 (UTC)
- 元維基現正諮詢是否開放予普通用戶使用二步驗證。--J.Wong 2017年7月11日 (二) 05:23 (UTC)
- 兩步認證太可怕。wikitech上我的帳號就莫名其妙被兩步認證鎖死了,wmf那邊都沒辦法....所以對這個玩意,我一直心有餘悸不敢用--百無一用是書生 (☎) 2017年7月11日 (二) 06:52 (UTC)
技術上怎麼檢查密碼的強弱。。服務器上用戶的密碼都是被加密過的。——꧁༺星耀晨曦༻꧂(留言) 2017年7月12日 (三) 08:25 (UTC)
- 在存入數據庫之前是還沒有加鹽加hash的,而且瀏覽器提交之前也沒有做客戶端加密,所以這之間仍是明文,提交前的檢驗可以在這裡檢測。而後期審計,無非就是模擬登陸去撞,這是撞的密碼會加鹽加hash後和數據庫存儲的對比,並無問題。——路過圍觀的Sakamotosan 2017年7月12日 (三) 08:54 (UTC)
- 也就是說已經存在數據庫里的密碼無法檢驗。在用戶主動提交密碼的時候檢驗?——꧁༺星耀晨曦༻꧂(留言) 2017年7月12日 (三) 08:59 (UTC)
- 要看是檢驗什麼。--A2093064#Talk 2017年7月12日 (三) 09:08 (UTC)
- 已有的就是做審核,看一些已知的碰撞工具,可能包括彩虹表、字典、常用密碼表等去試撞,撞中了就可以認為密碼安全有問題了。——路過圍觀的Sakamotosan 2017年7月12日 (三) 09:28 (UTC)
- 還要檢查密碼是否有在其他網站使用(如YouTube、Facebook、Google、Niconico動畫等)--林勇智 2017年7月13日 (四) 12:06 (UTC)
- 我不喜歡這個提議,密碼強度夠為何還需檢查其他網頁,這屬私人事情了,其他網站的帳戶保安也要自己管,何況刻意嘗試密碼是否相同會給其他網站或用戶造成困擾(FB密碼錯又愛封解又要時間)。--Zest 2017年7月13日 (四) 12:13 (UTC)
- 如何檢查?無法檢查吧。--A2093064#Talk 2017年7月13日 (四) 12:28 (UTC)
- 英文版同樣因無法檢查而放棄此要求,然而我們應提醒管理員們。--Temp3600(留言) 2017年7月13日 (四) 14:05 (UTC)
- 還要檢查密碼是否有在其他網站使用(如YouTube、Facebook、Google、Niconico動畫等)--林勇智 2017年7月13日 (四) 12:06 (UTC)
- 也就是說已經存在數據庫里的密碼無法檢驗。在用戶主動提交密碼的時候檢驗?——꧁༺星耀晨曦༻꧂(留言) 2017年7月12日 (三) 08:59 (UTC)
- 反對限制密碼格式和長度的行為。如果要規避弱密碼,請使用真正能規避弱密碼的方法——信息熵限制。限制格式(大小寫、特殊符號等)這種方法對非字典窮舉攻擊是無效的。好的密碼強度算法應該是bin(optimalCompress(passphrase).length)>=80 && entropy(passphrase)>=80。如果真要限制,按這個限制。Bluedeck 劉曉波 2017年7月19日 (三) 20:54 (UTC)
對於「基金會將對管理員的密碼進行定期查核」這一點,英文版的方針里也早有類似的內容,但是似乎也並沒有落實。的確有能力實現嗎-- Ben.mq 2017年8月5日 (六) 21:02 (UTC)
添加一些新限制
[編輯]- 為了進一步提高帳戶可靠性,建議採取下列措施。
所有管理員都需使用Template:User_committed_identity或類似措施。中文版對本項認知過低,不宜強行開展。- CUer的選舉中,增加一條必答題:你會在上任後啓用2fa嗎?如不會,請解釋。
- 對現有的cuer,邀請他們補答,並將結果存檔。
- 草稿:密碼方針已初步完工。
- 為了方針的一致性,需在Wikipedia:管理員的離任#解任理由增加"多次違反密碼方針"一項。--Temp3600(留言) 2017年7月26日 (三) 07:19 (UTC)
- PING人回來@TEntEn4279、Z7504、蘭斯特、Wong128hk、Bluedeck:--Temp3600(留言) 2017年7月27日 (四) 19:51 (UTC)
- PING人回來@Shizhao、cwek、A2093064、D2513850:--Temp3600(留言) 2017年7月27日 (四) 19:57 (UTC)
- (+)支持:順便修改了對應連結下--Z7504(留言) 2017年7月27日 (四) 19:56 (UTC)
- committed identity很頭痛啊。首先一個問題是社群里有幾個人知道committed idnetity的protocol是什麼?我看並不多。committed identity需要絕大多數參與成員都擁有很高的程序意識,而且一旦設定不能更改,原像一但丟失,就再也無法證明身份,而且無法重新設定,並且所有社群成員必須不承認重新設定的散列值。請問設定committed idnetity的人和社群有這個覺悟嗎。一年前,我曾經公開過一次自己的身份原像,但是我可以肯定地說:直到現在為止沒有一個人去驗證過,因為我使用的算法是一個罕見算法,網上沒有現成的驗證程序,也沒有人來問我要驗證程序,也沒有人來問我要散列paper去編程,也沒有人來問散列強壯型證明。這樣的committed identity等於沒有。而且散列值分布式存儲也是一個頭很大的問題。我的結論是committed identity在中文維基百科基本無用,安全性就只能靠良好的密碼practice和2FA。Bluedeck 2017年7月27日 (四) 20:00 (UTC)
- 確實如此。故改為建議,望日後有足夠認為後再立為方針。--Temp3600(留言) 2017年7月31日 (一) 08:47 (UTC)
- committed identity很頭痛啊。首先一個問題是社群里有幾個人知道committed idnetity的protocol是什麼?我看並不多。committed identity需要絕大多數參與成員都擁有很高的程序意識,而且一旦設定不能更改,原像一但丟失,就再也無法證明身份,而且無法重新設定,並且所有社群成員必須不承認重新設定的散列值。請問設定committed idnetity的人和社群有這個覺悟嗎。一年前,我曾經公開過一次自己的身份原像,但是我可以肯定地說:直到現在為止沒有一個人去驗證過,因為我使用的算法是一個罕見算法,網上沒有現成的驗證程序,也沒有人來問我要驗證程序,也沒有人來問我要散列paper去編程,也沒有人來問散列強壯型證明。這樣的committed identity等於沒有。而且散列值分布式存儲也是一個頭很大的問題。我的結論是committed identity在中文維基百科基本無用,安全性就只能靠良好的密碼practice和2FA。Bluedeck 2017年7月27日 (四) 20:00 (UTC)
- (+)支持:不能用低密碼強度的密碼(包括但不限於GitHub的資料或密碼強度條目所提及的密碼)--林勇智 2017年7月28日 (五) 08:25 (UTC)
- (?)疑問哪些會成為方針,Draft:密碼方針而已嗎,還是CUer和User_committed_identity也是?--A2093064#Talk 2017年7月28日 (五) 09:05 (UTC)
- (:)回應那部分開放給大家討論,我未寫進草案裏。--Temp3600(留言) 2017年7月28日 (五) 12:33 (UTC)
- (!)意見:根據「噗浪技術部」在噗浪的貼文,被駭客入侵的帳號所使用到的密碼大部分為其他網站洩漏的帳號密碼--林勇智 2017年7月28日 (五) 12:46 (UTC)
- 然而我們無法檢查維基人是否重用了密碼;最多只能在他們因重用密碼而被盜號時處罰他們而已。--Temp3600(留言) 2017年7月31日 (一) 08:47 (UTC)
結論?
[編輯]- 近日已無討論。既然如此,決議:
- 在草稿:密碼方針之上,添加Cuer必答題"你會在上任後啓用2fa嗎?如不會,請解釋。",及修改對應Wikipedia:管理員的離任#解任理由。而WMF方的定期密碼檢查,則初步定為半年一檢。(這個要和WMF相討後才有最終答案)
- 現公示七日。--Temp3600(留言) 2017年8月3日 (四) 15:03 (UTC)
- Cuer必答題可直接加入{{RfA}}模板。--A2093064#Talk 2017年8月5日 (六) 03:21 (UTC)
- 無法執行。下面說明。試想,必答題寫好了,請問CUer怎麼回答社群算滿意呢?我有這麼幾個答案,你們看你們滿意嗎:
- 我不用2FA因為我經常損壞手機,2FA會把我自己鎖住。我使用24位強密碼。
- 我不用2FA。因為我使用24位強密碼足夠強,不想再麻煩。
- 我不使用2FA,我使用8位強密碼。
- 我不使用2FA,因為我沒有手機。
- 我不使用2FA,我定期修改密碼。
- 我使用2FA,同時我的密碼提供40位安全。
- 我使用2FA,同時我的密碼提供80位安全。
- 想好之後,看看我怎麼評論這些答案的,然後你是否覺得這仍然是一個可執行的提議。Bluedeck 2017年8月5日 (六) 06:58 (UTC)
- 回答得好不好由社群自行決定,如果有人覺得答得不好,自然會追問,或是投反對票。--Temp3600(留言) 2017年8月6日 (日) 03:28 (UTC)
- 你這是想吧問題丟給社群,我正是覺得這樣不可行才有此評論——社群的密碼學知識不足,無法判斷,甚至不知道自己無法判斷一個候選人提供的密碼信息是否在可能安全的範圍內。Bluedeck 2017年8月10日 (四) 01:05 (UTC)
- 回答得好不好由社群自行決定,如果有人覺得答得不好,自然會追問,或是投反對票。--Temp3600(留言) 2017年8月6日 (日) 03:28 (UTC)
- 無法執行。下面說明。試想,必答題寫好了,請問CUer怎麼回答社群算滿意呢?我有這麼幾個答案,你們看你們滿意嗎:
- Cuer必答題可直接加入{{RfA}}模板。--A2093064#Talk 2017年8月5日 (六) 03:21 (UTC)
- 另外,就「修改對應Wikipedia:管理員的離任#解任理由」而言,個人無法理解這句。是要為提高保安而創造另一個保安漏洞?如此解任豈不等於昭告天下該人帳戶不安全,歡迎去攻擊?--J.Wong 2017年8月5日 (六) 08:25 (UTC)
- 英文版將「把無法保障自己帳戶的管理員解職」的權力交給了ARBCOM,但中文版沒有arbcom,只好將這項權力交給社群了,不然本項無法執行。--Temp3600(留言) 2017年8月6日 (日) 03:33 (UTC)
- (?)疑問這個密碼方針草稿的一部分是基於WMF會對管理員的賬號進行安全審查。是否有數據說明WMF會定期審查管理員賬號?如果沒有,那麼這個方針就沒有強制性,誰違反了這個方針都不知道。——꧁༺星耀晨曦༻꧂(留言) 2017年8月5日 (六) 21:15 (UTC)
- 這一項的詳細內容要和WMF相議才有最終答案,但要先有本地共識才可以提上去PHAB。--Temp3600(留言) 2017年8月6日 (日) 03:25 (UTC)
- 意思是,得有本地共識,WMF才會對zhwiki的管理員進行安全審查?——꧁༺星耀晨曦༻꧂(留言) 2017年8月6日 (日) 06:04 (UTC)
- 正是如此,只能摸着石頭過河。--Temp3600(留言) 2017年8月7日 (一) 14:39 (UTC)
- 不建議作為方針,作為指引尚可。--百無一用是書生 (☎) 2017年8月8日 (二) 01:47 (UTC)
- @Shizhao:這個與WMF談判有關,我不確定拿指引過去是否可行。--Temp3600(留言) 2017年8月11日 (五) 16:39 (UTC)
讓我正經地談一談這個問題:
- 作為方針而言,它沒有可操作性:雖然可以要求WMF去檢查,但是仍然無法在本地判斷方針是否已經得到執行。「違反上述要求的管理員可能會被暫時除權,直到他們解決保安問題為止」,那麼本地社區如何得知他違反要求和解決問題呢?
- 它沒有解決問題:因為強密碼不意味着安全,而且安全不一定必須通過強密碼來實現。另外證明自己身份的方法很多,「User committed identity」只是其中一種,而且我們也無法保證管理員們能夠正確地使用這個工具(所以幸虧沒提出強制要求來命令管理員使用這個東西)。
- 後果過重:發現問題解決就行——改個密碼而已,沒必要以「除權」來威脅。當然我們可以威脅「一旦賬號被盜並且產生了嚴重後果,那麼會導致除權」,相比之下這個更實際吧,而且同樣可以起到督促保障賬號安全的作用。
- 「添加Cuer必答題你會在上任後啓用2fa嗎?如不會,請解釋」這個問題有很多缺陷:
- 2FA只是保護安全的方式之一,我們為什麼非要通過這一種方法來解決安保問題呢?如果非要問,不如問「你採用了哪些辦法來保護賬號安全?」
- 前面Bluedeck已經提到,社區沒法對答案進行評估,或者說因為大家可能並不懂這個東西,得出的結論很可能是偏頗的。一個只在維基百科有活動的管理員可能只要開了2FA,密碼設成123456789也無所謂,而在各個網站註冊賬號的管理員即使把密碼設到20位也有安全風險——實際上是哲學問題。
- 續這個問題,對於維基百科而言,10位密碼和100位密碼對提高安全程度來說可能沒什麼區別。拒絕常見弱密碼已經足夠。
- 監督員也是簽署過隱私協議的人,難道監督員不需要回答嗎?為什麼只有查核員需要回答這個問題呢?
- 雖然我們沒法要求管理員必須遵守方針,但是我們可以「強烈建議」,而且以實際後果進行威脅「一旦真的出事了,……」
- 用一句話總結一下:「密碼方針」是君子協定,而且其出發點有偏差,所以可以考慮換角度思考(賬號安全)、降低成建議級的要求(例如星耀晨曦所言)或考慮修訂解任方案。
--逆襲的天邪鬼(留言) 2017年8月13日 (日) 12:34 (UTC)
- 與數位維基人交流後,在下決定撤回此提案,願日後由更熟識本方面的用戶處理帳號安全問題。--Temp3600(留言) 2017年8月16日 (三) 17:28 (UTC)
- 雖然這個方案不太可能通過成為方針。但是可以在這個基礎上,建立一個建議用戶提升自己賬戶安全的指引。——꧁༺星耀晨曦༻꧂(留言) 2017年8月16日 (三) 19:06 (UTC)
- 同意星耀晨曦--百無一用是書生 (☎) 2017年8月17日 (四) 02:28 (UTC)