维基百科讨论:密碼方針
外观
訂立密碼方針
[编辑]在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)