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