闪星花密v2:对花密的试改进

花密是我介绍过的一款可记忆的独立密码解决方案。不同于随机生成密码然后存储起来管理的方案,花密不需要用户储存管理,也能为每个账户提供高强度的独立密码

当初介绍花密的时候,我还是个初中生,只觉得花密好厉害,但没有查阅其算法的能力。如今,我已学过一些算法,也算是懂得一点密码学的知识。在建立自己的花密镜像后,觉得花密还有提升空间。于是斗胆试着改进一下。

花密算法简介

原版花密算法可以用 JavaScript 这样表示:

    var str = '01279abe' //sunlovesnow1990090127xykab

    var md5one = md5(password, key);
    var md5two = md5(md5one, 'snow');
    var md5three = md5(md5one, 'kise');
    
    var rule = md5three.split('');
    var source = md5two.split('');
    for (var i=0; i<=31; i++) { 
        if (isNaN(source[i])) {
            if (str.search(rule[i]) !== -1) {
                source[i] = source[i].toUpperCase();
            }
        }
    }
    var code32 = source.join('');
    if (isNaN(source[0])) {
        var code16 = code32.slice(0, 16);
    }else{
        var code16 = 'K' + code32.slice(1, 16);
    }

    //code16 is the result

代码量其实没多少,也很简单。它的思路是,根据用户输入的记忆密码(password)和区分代号(key)生成散列值(哈希值或杂凑值,取决于你怎么翻译 hash value) md5one,再对得到的散列值 md5one 散列得到不同值的 md5two 和 md5three,md5two 是生成密码(code16)的主体,md5three 用来调整生成密码中字母的大小写。最后,保证生成密码第一位是字母;如果不是,替换为 K。

这里用到的核心算法是 HMAC-MD5。MD5 是常见的散列函数。如果你还不了解,散列函数根据一个字符串生成固定长度的值,这个过程是不可逆的,并且(一般来说)输入字符串的微小改变都会导致散列值的不同。而 HMAC 函数可以在散列的时候加上 key,在这里实际上相当于加盐。加盐是为了缓解彩虹表攻击。用 HMAC 加盐相比直接追加字符串更安全,比如能预防哈希长度拓展攻击。总之,进行这些操作后,攻击者几乎不可能从生成密码逆推出记忆密码和区分代号——至少理论上是这样的。

原版算法的瑕疵

我们知道,花密的生成密码是以字母开头的、包含大小写字母和数字的 16 位字符串(事实上花密原本也提供 32 位的生成密码,本文不讨论)。而通过算法进一步分析出,因为生成密码会是十六进制形式的哈希值,所以所谓的“大小写字母”其实只包含 AaBbCcDdEeFf,再往后的字母是不会出现的(除了首字符可能是 K)。于是乎,生成密码的可能组合数是 13*(22^15),约为 1.78e+21 或者 2^70.6。这样的强度其实算高了,但 26 个字母只会出现 6 个,显然不能说充分利用了所有空间。理论上,16 位含所有大小写字母和数字的组合数是 62^16,约为 4.77e+28 或 2^95.3,所以提升空间很大。换句话说,攻击者得知你的密码是 16 位大小写字母和数字的组合,会认为最多要尝试 2^95.3 次才算完,然而知道你是在用花密后,马上坍缩到 2^70.6 次,水平只是略接近于 12 位大小写字母和数字的密码

再次说明,这个强度已经算高了。只是,如果我们提升组合数,就能进一步增加暴力破解的难度,符合我们对 16 位密码的期望。同时,如果我们把增加的组合数用于表达散列值,也更能减少生成密码“碰撞”的几率。

另外一个比较明显的瑕疵是,花密使用的散列函数是 MD5。MD5 不安全。我由于水平原因,没法具体解释怎么不安全,大概是已知有手段更容易发生碰撞,但不确定这里是否受影响。不过,既然要进行改进,无妨使用更安全的散列函数。

改进版:闪星花密v2

首先,用 SHA-256 替代 MD5。SHA-256 是目前推荐的安全的散列算法,使用广泛,是 MD5 和 SHA-1 的主要替代者。

编码的部分,不再使用十六进制形式。容易想到一种常见的编码方式是 Base64,把 3 个 8 位字节转化为 4 个 6 位的字节,即一个字符(8 位)能表达 6 位信息,比起 bin2hex 式的只表达 4 位信息要高效许多。但 Base64 编码表的 64 个字符中,包含两个特殊符号,需要特别考虑。

一不做二不休,我索性决定不仅容纳两个特殊符号,还强制使每个生成密码包含特殊符号(说强制是因为 Base64 编码后的串并不一定出现那两个特殊字符)。我将强制引入的特殊符号放到第一位。于是生成密码由原版的以字母开头,变成以符号开头。我想,如今似乎已经见不到那种要求密码以字母开头的网站,却有更多的网站要求密码中包含特殊符号,因而这么做是合理的。事实上,这样做降低了密码强度,只有在别人不知晓你用闪星花密v2的情形下才能说更“安全”(根据现代密码学思想,我们不能依赖算法的保密性,因此最好不要依赖这一点),算是牺牲一点安全性来换取便利,在要求特殊字符的网站不必手动添加符号。特殊符号不放到末尾则是为了裁剪密码时不丢失特殊符号。

特殊符号理论上可以使用所有 ASCII 可打印符号。但我遇到的一些网站,只认其中一部分,否则仍然认为你不符合它们的强度要求。另外考虑到具体的场景如 Oracle Identity Manager、Microsoft Active Directory,有些符号不能出现。于是我决定,首字符限定从 !@#$% 中产生,因为网站应该都至少认这几个在键盘上连续的符号;其后的符号只允许出现 /\,代替 Base64 原本的 +/,这算是为了好看,只在很小的程度上能避免让人发现这是 Base64 编码(这个目的其实没意义,原因同上)。

原本还想使用诸如 PBKDF2 的方式,多次迭代使得彩虹表更难产生,想来意义不大,还增加耗电,作罢。

实现代码如下:

(注:由于所使用库不同,这里的 sha256.hmac 参数顺序为 sha256.hmac('key', 'Message to hash'),与上例中 md5 相反)

    var symbol = "!@#$%!@#$%!@#$%!@#$%!@#$%!@#$%";
    var head, hash, code16;
    hash = sha256.hmac(key, password);
    hash = sha256.hmac.update("ShansingPv2", hash).array();
    code16 = hash.slice(0, 12);
    code16 = btoa(String.fromCharCode.apply(null, code16));
    head = code16.charCodeAt(0);
    if (head >= 65 && head <= 90) head = symbol[head-65];
    else if (head >= 97 && head <= 122) head = symbol[head-97];
    else if (head >= 48 && head <= 57) head = symbol[head-47];  //-48+1, history issue
    else if (head === 43) head = symbol[3]; // + -> $
    else if (head === 47) head = symbol[4]; // / -> %
    code16 = head + code16.slice(1).replace(/\+/g, "/").replace(/\//g, "\\");

    //code16 is the result

基于 Base64 的特性,要生成 16 位(字符)的密码,就取 12 字节的值。这里的问题是,SHA-256 原本提供的散列值是 256 (二进制)位的,直接截断为 12*8=96 位是否安全。我找寻到的资料说是安全的,除了显然会增加碰撞概率外。(这是相对于 256 位来说的。而相对于原版最多 4*16=64 位,这里的碰撞可能更小。)

因为 Base64 已经能提供大写和小写字母,所以不需要另外决定生成密码中字母的大小写。

容易算出,闪星花密v2 生成密码可能的组合数是 5*(64^15),约 6.19e+27 或 2^92.3,非常接近我们对 16 位密码的期望。

简单比较

根据我的简单测试,闪星花密v2 与原版算法速度差不多。

列出特性对比如下:

比较项花密闪星花密v2
核心算法HMAC-MD5HMAC-SHA256
首字符类型字母AaBbCcDdEeFfK特殊符号!@#$%
允许的非首字符AaBbCcDdEeFf和所有数字所有大小写字母和数字,和符号/\
log2(组合数)*≈70.6≈92.3

*参考值:16位含大小写字母和数字的密码 ≈95.3。

在线试用:https://shansing.com/passwords/ (勾选“使用闪星花密v2算法”)

注意,尽管我想尽力设计出完善的算法,但成品的相关效果(包含安全性)没有保证。本人不是密码学专业人士,水平可能非常业余,请谨慎使用。当然,如果发现不妥,非常欢迎在下面留言指出。

2019-6-25 17:28 P.S.更新闪星花密v2代码,但未作实际变动。

若无特别说明,本文系原创,遵循 署名-非商业性使用 3.0 (CC BY-NC 3.0) 协议,转载文章请注明来自【闪星空间】,或链接上原文地址:http://shansing.com/read/477/

33 条评论

  1. 讲解很透彻,好评!算法流程简化到可以简单记忆的话,就算手头没有花密网站也可以快速写代码生成密码啦~

  2. 大大的帅哥 大大的帅哥

    很厉害,但是有的网站不大支持符号作为密码。我觉得每次都输入一次密码和标识符很麻烦,能否让第一个框就储存密码,第二个框是自己设置的下拉列表,每次不用输密码在下拉列表选一个网站就生成密码,点击复制 很爽很爽的

    1. 感谢支持。如果网站不支持含符号的密码,我通常认为它是落伍的,会使用原版花密算法,这样生成的最终密码就没有符号了。

  3. 大大的帅哥 大大的帅哥

    能够在第一版基础上增加其他26个大小写字母和其他算法已经很安全了,大神,能不能储存标识符作为列表,初始密码也储存就更好,适合我这种懒人。

    1. 之后会考虑网页版增加本地存储功能,存储记忆密码和设置项。区分代号可能不会储存,因为通常来说不会很长,而项却很多,因而允许下拉框选择提升的便利性也不大。

  4. 大大的帅哥 大大的帅哥

    我用excel的宏做了一个md5的密码板,输入一个密码 所有网站的密码都出来了,还可以指定密码位数,嘻嘻,但没你的算法安全

  5. 当密码达到一定位数和复杂性的时候就已经不会被盗了,你又不是什么特别重要的人,没人会盯着你的账号破解个多少天,而且网络登录都是有错误几次就锁定的机制。

    因此密码是否安全不在于花密的复杂性了,而是在于你的使用习惯。

    当机制足够安全时,问题一定出现在内部。

    因此我认为最佳的密码就是你孤身在外没有任何帮助时,也可以自己组合出来的密码,比如taobao转译为哪些数字,然后你的基本密码,两个用计算器加在一起,再转为大小写字母+数字就已经是一个很不错的密码了。

    例:
    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
    a b c d e f g h i j k l m n o p q r s t u v w x y z

    TAOBAO=190141014,基本密码是19990909
    相加得到210,131,923,根据三位千分符来规定优先二位数 可以组合出21,0,13,1,9,23
    答案就是v,a,n,b,j,x,然后加入数字和大小写(规定头尾是大写,第二位起开始穿插1999)就是:V1a9n9b9JX

    这个密码已经足够安全了,平时使用iphone扫码登陆,不支持扫码的在自己家里安全电脑上chrome记忆密码,外出时全部扫码,应及时手动运算,最多也就5分钟。

    1. 更安全的东西当然是要有的,至于用不用那是自己的选择,其中包括使用场景和个人性格等。
      比如说你提到网络登录,这当然是一个场景,也可能是最主要的场景。但压缩包加密呢?
      比如就我个人,很注意安全,不太在外面登录账号,几乎都用电脑。现在花密可以让我以极小成本获得高安全性,我当然就选择它。
      就你的前提,有些人甚至会觉得,应该在保持独立密码的同时尽可能简单:字母索引、加法什么的太麻烦了,不如搞个十来位的基本密码,在其中穿插三四位字母就行了。
      所以说呢,在综合考虑的情况下,适合自己的就是好的。

      1. 是的,所以过度追求密码又短又好记和过度追求密码复杂性都是不可取的,应当选择一个合适自己的。

        至于你说的压缩包密码,第一考量要务应该是有什么人愿意花什么样的代价来破解你的压缩包。

        鉴于此,我的建议是右键压缩包,选择容量的那一行数字进行穿插组合,得到的密码也是足够安全的,至少得用月来计算破解时间。

        总结来说就是,密码只应该存在你的脑子里,任何算法都不应该有书面记录。

        1. 压缩包密码只是个例子,还有各种本地文件加密,包括虚拟磁盘的那种方式。后者由于文件时常变动,不适合以总大小作为密码。
          根据保密强度和记忆性需求,我可能会选择简单密码、可记忆复杂密码(花密)、随机字符或者后两者的组合,作为文件加密密码。
          就密码(password、passphrase)来说,“算法”保密确实可以看作一件重要的事。我在文中说,
          “根据现代密码学思想,我们不能依赖算法的保密性,因此最好不要依赖这一点”。这个原则叫作柯克霍夫原则。我没有修密码学,我想这主要是针对生成密钥(key stretching)的算法、带密钥(key、cipher)的加密算法等来说的。比如通常来说,自己闭门造车编出来的加密算法,实际上经不起检验,容易受现代手段如统计学分析等攻击。对于密码“规则”,确实难说一定适用于这里的“算法”概念,因为能够记忆的密码里肯定有很多“规律”,这些东西不应该告之于人。
          我之所以在文中提到不能依赖算法保密性,其实是因为花密的做法近似于密钥生成。像哈希算法就常用来从密码生成密钥(当然可能要加盐,要经过多次迭代,如文章提到的 PBKDF2),只是在花密的例子中,生成出来的字符串仍被我们当作密码使用。这就把花密算法纳入现代密码学领域。花密的算法应当符合最佳实践,即使公开出来也没关系。保密性主要由记忆密码提供。
          并且,这样应该是更安全的。人们可以检验,在花密中,只要所使用的哈希算法可靠,即使得到最终密码,也不可能分析出原文(需要记忆密码够强,使得彩虹表不可行),更别说对密码进行词频分析、社会工程学攻击了。显然,这比你不管什么方式,而最后得到的密码仍然存在有迹可循的明文字符更安全。
          当然,接着又回到上面的评论,要不要这些安全性,决定权在自己。

          1. 有一定的道理,从客观层面来说,依赖算法保密性的确也不是正确的道路。

            依靠算法保密带来的后果就是一旦算法丢失就会全线崩溃,对于企业和多人应用环境来说,算法丢失是可预见性的。

            但是我不太明白的是,我们的思路好像并没有什么较大的不同,仅仅只是密码运算方式有所区别。
            但是从被盗的具体几率来看,感觉是一样高的。

            我设计的密码是依靠基本密码+应用层关键词(网站域名、文件大小、文件名称等)再经过自行建立的简单换算逻辑换算出相对较为复杂的十多位数密码,由大小写与数字组成。
            从算法被盗的逻辑判断,只有密码与基本密码同时被盗,并且再被几个数学家几天几夜的匹配,否则几乎没有。
            基本密码和算法不存在于现实世界中的任何地方,仅存在于人类记忆中。
            哪怕我现在告诉所有人我的算法,但是想要推演出具体密码却还需要得到我的基本密码与应用层关键词设计方式,而这两点却仅保存在我的脑中。
            这也是符合柯克霍夫原则的,具体原因结尾我会阐述。
            而基本密码是一个非吉祥数字,非常见数字,非生日等可猜测数字,非历史密码的数字串,因此也几乎不存在被盗的可能。
            优势在于,不依靠任何第三方资源可以较为快捷的自行还原密码,暴力破解的难度超过了我的社会地位。
            我的算法有口头告知过我的妻子,因此当我出现意外状况时,她也可以凭借着如此简单的算法来换算出我的各个账号的密码。

            你的这个花密也是依靠记忆密码(基本密码)+应用层关键词,再经过sha256的各种形式运算,而这个运算是建立在一个程序或者网站上的。
            算法被盗概率很难评出高低,具体逻辑是,基本密码和运算程序/网站同时被盗,或者说是先行在你的电脑中植入了病毒,发现了你的密码运算软件,然后对此进行监控,使得你的应用层关键词使用逻辑与基本密码同时丢失,全线阵亡。
            优势在于依托于现代人类前沿科技使密码强度非常高,暴力破解难度近似于无限。
            但是劣势也过于明显了,首先你不应该使用别人发布的算法网站或者软件来运算你的密码,比如你的闪星花密也仅只能你自己使用,也可以离线存为bat或html之类的方式来运算。因此在民众普及性推广来说太低了。
            其次是,一旦算法丢失,或者是在无法与算法联系的情况下,你无法运算出你的密码,造成不可挽回的损失。而这一点反而不符合柯克霍夫原则。

            依据柯克霍夫原则(系统=加密规则与方式):
            1、即使非数学上不可破解,系统也应在实质(实用)程度上无法破解。
            这句话的含义是,破解密码的成本高于破解密码后所取得的收益,我相信对于你我和普通民众来说,把我们两的算法取用三分之一的复杂性都足以高于破解收益了。
            因此你我均已符合该原则。

            2、系统内不应含任何机密物,即使落入敌人手中也不会造成困扰。
            这句话的含义是,哪怕你的算法完完整整的公开给敌人,只要你的密钥(key,基本密码,记忆密码)未泄露,就不会出现风险。
            这点你我也符合。

            3、密匙必须易于沟通和记忆,而不须写下;且双方可以容易的改变密匙。
            这句话含义是,哪怕还有10秒生命,只要吐字清晰,就可以快速的告知另一人key,而且不需要另一人记录下来,就可以快速记忆住。
            这点你我也可以符合。

            4、系统应可以用于电讯。
            历史问题,无需探讨。

            5、系统应可以携带,不应需要两个人或以上才能使用(应只要一个人就能使用)。
            这点只有我完整符合,你的算基本符合,我的系统存在于记忆中,你的系统必须有相应的设备进行计算。

            6、系统应容易使用,不致让用户的脑力过分操劳,也无需记得长串的规则。
            这点只有我可以符合,你的系统无法通过脑力运算。

            总而言之,密码设计的关键在于你的密码要足够复杂到不会被暴力破解,并且取得你的密码所付出的成本高于改密码可获得的收益。
            又足够简单到不会丢失与快速运算取得而无需借助第三方工具。

            鉴于此,你的这个花密改进方法是技术层面很重要的一项进步,也让你我双方乐意去探讨它。
            但是从民用层角度出发,可能实用性低了一些,这就相当于你的防盗门如果需要破门会造成很大的噪音或者是你需要携带很厉害的工具。
            而破门产生的风险与刑罚已经超出了你所取得的收益。
            在这个基础之上,你仍然增加了你防盗门的防盗性能,甚至已经到了如果你自己丢了钥匙就再也回不去的地步。
            这是不可取的。

            话说。。。你是我见过最活跃的博主了,我已经很多年没能和人聊这些了,希望你有认为咱们在聊天和探讨,而不是认为我在砸场子~

            1. 我接下来讨论的主要是网站账号的密码。
              从暴力破解的角度,你我的密码强度应该都够了。只是说,万一密码遭受明文泄露,花密几乎不可能还原出明文。而你的密码相对容易被“数学家”破解。我没有专业到能分析密码规则,不过在你举的例子中(当然我相信这不是你实际的密码规则),最后穿插固定的“1999”像是败笔,显著降低了密码的熵。使得在 10 位的“V1a9n9b9JX”中几乎只有 6 位的“VanbJX”是包含信息的,这还没有说强行大写在这里的尴尬境地(原版花密也有类似的疑虑,强行大写使得表达的信息比表面上少,更容易建立彩虹表)。
              当然,一定强度后密码被盗风险本来就小,明文泄露风险更小,足够多明文密码泄露(到能够分析密码规则)的风险又小到不知道哪里去了,所以以上仅是一个概率的比较。安全本来就是一个对抗的过程。你或者其他很多人,不需要对抗这么一点点概率,我是可以理解的。(不过我还是建议你不要公开自己的密码规则。)
              你提到的网站/电脑植入恶意程序,我是无保留地认同的。相较于你可以在脑中/纸上运算自己的密码,使用花密必须是在一个可靠的电子环境,保证环境安全无毒。也包括,我推荐有需求的人自建花密镜像:对于在线使用,即使没有自己的服务器,至少托管于一个可信赖的服务商(GitHub Pages 等)。鉴于此,我本来就没指望推广开来(我也暂时没有计划编写移动客户端)。即使是原版花密,得到的客户群也应该不大。我知道还有很多需要安全性的人会使用 1Password 一类的密码管理工具,他们的场景/需求又跟我们有所不同。
              对于柯克霍夫原则,很遗憾我其实只知道它的核心思想。我想你是从维基百科摘抄的这几条内容,但不知道你括号中“系统=加密规则与方式”是怎么得来的。就我看来,这里所说的系统更像是一个硬件系统,包含加密解密的元件和操作机关,或者由此抽象出来的软件集合。考虑到现代密码学各种加密算法(如 AES),“系统”里面的硬件元件/软件算法应该不可能简单到允许人脑简单记忆(至少不会像你的那么简单)。于是我要为自己辩白第5、6条。你应该不会想说 AES 不符合柯克霍夫原则,AES 系统不方便携带,“让用户的脑力过分操劳”。那么由主流哈希算法轻度包装来的花密也是如此。我认为第6条说的是使用接口/使用方法,而不是内部构造。
              在这个时代,我也不认为这种网页能轻易丢失。如果灭霸毁灭了一半互联网网页,我倒是愿意接受网络账号不能登录的事实。丢了钥匙(记忆密码+区分代号)而进不了门,也是我接受的。你丢了钥匙也需要花费大工夫破门,只是在不限制尝试频率的情形下,你进行自我暴力破解(这次是通过尝试原始密码的组合),会比我更快;但倘若你的记忆密码真的很强,你的规则也像你说的那么安全,那么暴力破解对敌人不可能,对自己也是不可能的。我们就算扯平了。
              最后,很开心能跟你交流。理性的交流都是欢迎的。也希望你不是认为我在强词夺理。我对花密的改进并非很重要的进步,原版花密也并非不能这么做,它可能有它的考虑~

    2. 非常期待你的回复,可惜还没收到。我在这期间更进一步(但仍显粗略)地看了你举出的密码规则,想了想当密码规则公开,并且有人掌握一些明文密码(最终密码)时,大概可以怎么分析。

      上一则回复中,我提到最后几乎只有 6 位字母是包含信息的。这不是偶然,因为密码规则如此。我想,如果基本密码的数更凑巧一些(我想基本密码应该是一串数,因为下一步是相加,即使是字母也会转化为数),如 99999999,与 TAOBAO 的 190141014 相加得 352,525,251。这里我不太确定 352 该怎么划分,我想应该会形成 3 个字母。‬于是最终密码应该有 7 位字母。但为了快速判断,请允许我免去数学计算,用粗略的直觉认为,基本密码位数 m 与最终密码中计算得到的字母数 n(不含固定穿插的字符,例子中是 1999)的比例为 4:3。如果你有比较严格的数学说明(无论证明证伪),欢迎贴出讨论。

      现在考虑常见的网络账号,密码最多允许 16 位。你在例子中穿插了 4 位(个)的固定字符(如果我没理解错,这些字符确实是固定的。如果是需要用户自定的,那么便是一个冗余的第三项输入,会违背柯克霍夫原则第6条)。那么计算得到的字母最多允许 12 位。根据上一段所说的比例,基本密码为 16 位数字。也就是说,要在 16 位密码下达到你密码规则的极限,基本密码大概要设为 16 位数字。

      16 位数字有什么问题呢?由 Math.log(Math.pow(10,16))/Math.log(65) 算得 8.83,意味着强度不到 9 位的大小写字母数字混合密码。够用也许是够用了,我觉得有点少。可这不还有应用层密码吗?(原谅我接下来叫作区分代号)但区分代号跟基本密码同位的话,组合数也只是乘以 2,强度仍然只相当于 9 位大小写字母数字混合密码。

      这里的一个突破口,是可以将区分代号设得更长一些。于是可以带动熵增长。

      另一个突破口是,最后不要穿插 4 位那么多固定字符。为了方便计算,取 1 位好了。那么计算得到的字母为 15 位,基本密码则为 20 位。这下强度有 11 位大小写字母数字混合密码还多一点了。与此同时,区分代号需要拉长。因为如果区分代号(对应的数值)短于基本密码,相加之后会直接泄露高位基本密码。

      这样,区分代号也需要设得更长,跟前面是相通的。

      我相信你确实使用了复杂的区分代号,这样还算比较安全。不过我估计计算起来不太简单。又想到你用浏览器记忆密码,就舒服很多(我又想到这里需要“安全电脑”,花密也需要安全电脑/手机,这一方面我们的劣势算是半斤八两。)区分代号需要设得复杂有点反直觉,但显然也有好处:基本密码的泄露不至于很快猜出各个独立密码。你的这套规则,自用应该是可以了,提供出来则会少了一种选择,即选择使用简单的区分代号。

      当然,这些结论都遵循那个 4:3 的前提。我感觉实际上 3 会更大,那么基本密码就更短。你看,最终密码位数与基本密码位数的关系不直观,最终密码的位数也就不太好控制。我推测你在实际中偏向使用短一些的基本密码。

      当区分代号位数长于基本密码时,区分代码的高位也可能泄露。而区分代码可以认为更容易猜测(比如从淘宝密码泄露看到 ta,基本上能猜出 taobao 进而猜测是否域名等),加上实际中所使用的基本密码又比较短而强度不高,于是风险更加大。

      综上,我不知道你要如何控制基本密码和区分代号的相对长度,才能安全地生成密码。我觉得在保证安全的前提下,要使用这套规则比较困难。或是你可能认为基本密码、区分代号的高位泄露不重要,或是这种密码规则公开、明文泄露的情况不重要。

      1. 昨天太晚了,思维比较迟钝。发现有两个我不应该忽视的地方。主要是忽略区分代号的贡献导致的。

        根据加法交换律,在你举出的密码规则中,基本密码和区分代号的地位是对等且是能互换的。当然这导致一个结果,互换以后不改变最终密码,从理论上说这有点不好,在实际中不太有影响。不过另一个结果是,在我的讨论中,基本密码位数几乎达极限的情况下,区分代号也不能设得更长(也许能适当长一位,但长不了多少)。

        还有我说“区分代号跟基本密码同位的话,组合数也只是乘以 2”,在那里不太合适。从原始的区分代号和基本密码的组合看,当然是两者位数相乘,那么在我的例子中,应该是算对数结果 8.83*2 = 17.66,超过 17 位大小写字母数字混合密码的可能组合了。问题在于,你用了加法,而两个同位的数相加后位数不变,或只增加确定的一位数(也就是高位 1)。相加后的中间结果,熵值就与基本密码的或区分代号的差不多了。也就是,加法使得密码熵值急剧降低。用户需要记住复杂的基本密码,为每个账户设定复杂的区分代号,结果却在这一步操作降低了密码强度,可以说是吃力不讨好。在这里加法也可看作是一种双值输入的哈希算法,只不过是非常糟糕的哈希算法。一前一后熵值降低那么多,必定损失了很多信息,增加了碰撞概率。比如说,123+456 与 110+469 的结果是相同的。如果这套规则不只你一人使用,有不同的基本密码和区分代号,会有较大可能出现相同的最终密码。这在设计上应当也是不好的。

        1. 哈哈哈哈哈,感谢你如此不厌其烦的和我探讨这个不知道有没有意义的故事。
          我前两天出差,所以没看你blog。

          关于原则中的系统,这个系统的定义其实你可以认为有硬件,但是硬件的加入其实也仅仅是算法和规则而已。
          比如说你可以认为拥有一台专门制造的计算器,该计算器可以自动根据当前时间运算出实时密码(类似银行U盾和网易将军令),但是归根结底也仅仅只是算法而已,包括你的sha256,其实也是可以手动运算的,所以我们无需探讨硬件还是软件,因为最终就是算法和规则。

          另外关于你说的我实际有用信息是VanbJX,这里我们要明确一个关键点。
          这个VanbJX是如何获取到的,一定是在公共电脑被盗或者类似情况导致的,这种情况下VanbJX逆向破解的概率很大吗,其实也不大,因为可能盗号的SB会以为VanbJX就是我的密码,而不会去想到这是一个运算规则,他最多会想,哦,这个人生日是1999,然后拿这个他熟悉的字母穿插出来的密码。

          我一直有一个观点,有一点点涉及人身攻击,请海涵! 别以为自己是什么重要的人。

          至于我说你不符合第6条原则的想法是,我认为民用级的密码第一要务就是民用,如果你设计的密码生成器让用户丢失后无法找回,就不可以算作是民用,因为操作难度以及超出民用范围了,以广大网友的思路来说,哇,你这特么是黑客技术啊!真牛逼~(请原谅我的低俗,但是大多数网有内心想法应该是这样的)。
          如果你说,将你的密码sha256运算后进行人工组合即可,我会认同你的观点,但是你的密码经过了你闪星花密的加密方案后,民众是无法恢复出来的,这是致命缺陷,因为你要考虑到民众不一定会听从你的建议,而直接使用你提供的网页,但是我相信你也不愿意承担如此大的责任,而且网络喷子的力量是很大的~
          通俗来说,如果你问我老婆如何还原我的密码,她可以流利地说:把他的*转化为-的数字(我的真实运算表不是0到25,也不是1-26,而是类似于5-30这种),再网站域名的首字母,再把数字乘以*(是一个数字),然后千分符转化为字母后前后大写,中间穿插生日,就是密码了。
          “####” 网站域名首字母 “#” =>X1x9x9x9xxxX,是通俗易懂的。

          而你的伴侣可能只能说,嗯。。。好像是。。。嗯。。。。。。
          又或者你得事先将你的网址或者运算bat交给她,但是这样就很不安全了。

          如果是261这样前2个数字小于26的,会直接换算为Z和A,如果大于26,例如271,则会换算为3个字母。

          为了保持密码安全性我在之前的确没有完整的说出具体设计方案,我是希望可以抛砖引玉让大家设计自己的算法和密码,因为其实你的密码哪怕是基本密码+-*/简单进行一个个位数的四则运算也是可以达到很好的加密效果了。

          在实际使用中,我曾经有过一个版本的密码是这样设计的:
          基本密码是我的电子邮箱,imxyd@qq.com
          81223243@1616。21412
          假设是淘宝账号的话则是taobao
          QQ的话则是QQ
          阿里云就是aliyun
          亚马逊就是amazon
          通过QQ其实你可以看出区分密码并不与基本密码等价,实际最重要的是基本密码与运算公式,或者说我的这套密码设计思路是希望降低每一个步骤的记忆与运算难度,并且可以获得一个“足够安全”的密码。

          我当时的版本是这样设计的。
          81223243Q+1616Q+21412*Q=1,299,940,336
          而@和。其实也会在这时候插入,比如@我定义为2,也就是和键盘上相同的按键。
          点我定义为1(瞎说的),然后将1299940336*2/1得到终极密码。
          但是符号环节我们暂时跳过,避免冗余。

          根据千分符来运算就是
          A,B,J,J,J,E,A,D,D,G

          再在这个密码的基础上添加大小写和数字(非真实)。得到的是
          A3b5j4j6j e a d d G
          这就是终极密码了。

          在这里我大概说一下这个密码的缺陷:
          1、该密码运算起来还是过于复杂了,我后期又修改了一个版本,也就是本楼层开始提到的规则,运算起来更简单,也更短一些了。
          2、对于无法暴力破解的情况来说,比如网站之类的,我一般为了平时也可以方便记忆,免运算手动输入,我会采用截取前6个字母的方式,虽然密码位数更短了,但是也不存在暴力破解的可能,毕竟不是password
          3、密码的大小写和数字其实设计思路是为了绕过“网站”必须要大小写和数字的,因为在我看来并没有那么的重要。
          4、对于压缩包来说,我一般是利用压缩包当天的日期,和运算公式得到的,的确存在被暴力破解的可能,但是从客观角度分析,A3b5j4j6jeaddG,对于第三人来说,他不知道我的密码是几位数,有没有符号,有没有大小写字母,他在爆破的时候是要全部加入进行运算的。这个密码暴力破解也是非常吃力的,根本不知道要运算多少天,但是的确还是有爆破可能,比如几个月或者一两年,不像你这个要一辈子。

          所以总而言之言而总之,我们两的设计思路完全是渐行渐远了。

          我倾向于将自己认为对的东西尽可能地简化,并且普及给大家,让大家都可以便利的使用。
          并且只做90%,不做最后的10%,因为那10%想要做好可能需要付出70%,对于民众来说这是不划算的。

          你倾向于将它完美化,使它达到坚不可摧,功不可破的地步。

          所以如果咱们是谈论如何普及一个让广大民众都能受益的密码设计思路,我的从推广性来说一定比你的好,也比1password这种要好得多。
          因为我在公布时就会很简单的告诉大家,密码一定可以破解,只在于破解的难度与成本,我的这个密码设计需要**小时被破解,请你自己衡量会不会有人这么来对付你。

          但是如果我们在谈论谁的密码更安全,这个毋庸置疑,你是牛逼的~

          1. 我提出对“系统”概念的异议,主要是它应该还包括使用方法。这一点我确实没强调清楚。考虑 AES 等加密算法后,我认为第6条说的是使用方法,因而我的是符合其原则的,如是而已。顺带一提,既然搬出这么些原则,就不该是在普通(大多数)民用的层级。要不然干脆视而不见好了。

            你说要考虑“VanbJX是如何获取到的”,这是当然的。我一直在强调,这些情况是发生了明文密码泄露,并且你说出了你的密码规则(因为你认为安全到可以公开出来);或者是你并没有说出密码规则,而是有足够多密码泄露后,在某种程度上分析出了密码规则。并且我也说了,这些概率都是极小的,只是我个人仍然要对抗这些概率(反正成本小,就是划算的)。

            我正是考虑到实际应用中区分代号和基本密码不等价,而在你的(举例的)密码规则中,地位却是相等的,于是我觉得这是一个设计缺陷。区分代号和基本密码长度不相等,会造成高位泄露,是另一个缺陷。另外,也不好控制最终生成密码的位数。在步骤中主动降低密码强度,是不应该的。比寻常情况有更大的碰撞几率,也是不好的。现在你又确实引入了除基本密码、区分代号外的第三输入项(生日1999),增加了使用复杂度。

            我一直不理解你强调紧急/意外这种特殊情况。按道理,最常见的情况是日常生成密码。闪星花密做成了现成的网页,分明十秒钟就能用一次(或者需要自建,也只是额外有最开始部署的劳动)。而你因为一直坚持手算/脑算,反而才需要在使用时付出很多劳动。这使得你自己都不得不将密码(至少是其中一部分)保存在浏览器中。如果非要提到紧急情况,给伴侣透露自己的密码。假设我愿意,我想先前就会给其透好口风,就好像你会在生活正常的情况下就告诉伴侣密码规则。对网页进行长期备份(或可靠托管),或给算法代码拍照也不是什么麻烦事。(顺便问一下,你说给他网址不安全是为什么?)

            也请你原谅我这么认为:由于设计上有很多缺陷,使用(运算)起来也绝不算简单,你这个规则不适合普及给民众。相反,我会乐意看见 1Password 普及(最好配备随机的独立密码)。甚至于,当不需要这么高安全性时,我都觉得十位的基本密码穿插六位区分代号(可以有类似于 a→@ s→$ 这样简单的替换)是可以接受的,用起来方便多了。

            1. 对于暴力破解的补充:

              我承认,理论上你确实能让密码短期内破解不了,而长期可以破解。但这是不现实的。你得考虑当花费时间以年、十年计的时候,自己会不会愿意(以及有财力)去破解。如果这东西让你这么想破解,一定很重要,为何当初要设一个相对简单的密码?退一步,假设这样的情况是存在的,那么其实也很难控制密码破解需要的时间(通常情况下只能给出量级)——一个人会需要考虑机器性能的统计分布,需要考虑性能的进步(如摩尔定律)等。另一方面,如我之前所说,在你的密码规则中,最终密码的长度是比较难控制的(比如三位千分符有时对应两位,有时对应三位字母),这也造成了破解时间不好控制。(当然,你又举例说你的压缩包密码规则是另一回事,就当我没说过这话了。)

              再退一步讲,闪星花密也并非不能暴力破解。通常来说暴力破解是尝试最终密码的可能组合。但你还记得我的括号的话,是可以“通过尝试原始密码的组合”去破解的。最终密码的强度决定于其最薄弱的环节:在闪星花密中,通常我认为是记忆密码。一个人即使总是能得到 16 位的复杂密码,但实际强度也许并不如表面面的高。也就是说,通过控制记忆密码(适当考虑区分代号)的强度,同样可以造出相对弱的最终密码,为暴力破解提供可能。而且这是完全可行的。不像你的规则,在闪星花密中,这种强度是比较直观好控制的。

            2. 好吧,如果你一定要说生成器丢失,那我就来讨论一下。首先要明确我目前没有推广的计划,在闪星花密的页面中“用闪星花密v2算法”是标记为“测试中”的,只是满足基本需求,网页安全性当然还不是特别高。

              如果要推广,我会怎么做呢?在这里不谈用户自建。如之前提到的 GitHub Pages,将闪星花密托管在 GitHub。如此只要 GitHub 是可信的(世界上很多重要项目源码也托管在 GitHub),用户只要审计一次,后续就能轻易查看是否有更改,保证代码安全。国内也有类似的服务。再考虑绑定自定义域名等。就现状推测,这样的网页在五年内基本上都能存在,在可预见未来存在的可能性也极大,基本不可能丢失。

              哪怕网站是挂了,我总可以再建使其恢复的吧,除非那时互联网发生了翻天覆地的变化(比如灭霸来了)。甚至还有类似互联网档案馆这一类的网站保存存档。再如我先前评论里说的,总是可以拍照的,或是可以留书面稿等。在这种极端情况下,极客总是能恢复自己的密码;如果不计较代码安全性(请注意这是极端情况),普通民众也能拿回他们的密码。几乎不可能出现你说的永久丢失。相比之下,如果你的密码规则要求不留书面记录,仅存于记忆(头脑)中,多年后的“丢失”情况也不比花密乐观。

              总结一下就是,你的密码规则设计充满了矛盾。在开始为了安全,要保密规则不留书面记录,而后在具体规则中又踩了各种安全性的雷。又说要对民众(普通民众,下同)易用,却要求他们在生成密码时进行不简单的手动运算。你可以对我说狠话:别以为自己是什么重要的人。我也可以对你说(同样无意冒犯):别以为民众都是受虐狂——民众不想计算多位数加法,不想处理“三位千分符”,不喜欢每次得到密码要花费最多“5分钟”。这些才应该是你说的“操作难度”,是柯原则说的需要“记得长串规则”和“过分操劳”。

              这才总而言之言而总之,闪星花密起码做好了一件事;而你的密码规则既已承认欠缺安全性,在民众易用性上其实也是自欺欺人而已。

            3. 嗯。。。可能你理解错了我的意思,我们的出发点完全相悖了。

              不论你是否有努力让自己闪星花密被众人所得知,但是内心里还是很希望得到大家的肯定和使用的,这一点对于我们任何一位博主来说都是不可否认的。

              因此我们更应该承担起自己发布的作品让民众造成麻烦的责任。
              因此我们想的应该更多一些,比如民众是否会有一些不应该具有的“常识”。
              比如不要在公共电脑上打开花密网页并计算出自己的密钥,比如不要在家里浏览某些网站,不要在非官方渠道下载软件。

              而这些对于民众来说不是常识,我公司有很多员工就会做这些事情,比如认为难得在公共电脑登陆一次,应该不会被盗号吧?比如会在百度搜索QQ,然后选一个标着“xx下载站”的网页去下载QQ,问其缘由他会说因为我要下载啊,不是要进官网,我不知道官网下载QQ怎么下。
              我们不要去探讨以上情况是否多发,只需要去看看360全家桶有多少人在用就可以佐证。

              以上是关于民众知识普及度的。

              接下来我说一下关于广谱性的问题。
              我只是介绍一下我的思路,抛砖引玉,让大家能够尽快的将自己每个应用的密码都变得不同而已。
              哪怕他的密码是Abcd1234,但是只要他肯按照我的思路做一些调整,改为淘宝的首字母=19乘以1234=23446,将密码改为Abcd23446。QQ首字母=16乘以1234=19744,密码改为Abcd19744。
              你肯定觉得这个密码不够安全,但是在我看来这个密码已经非常安全。

              对于民众来说,我的这个密码它只需要手机计算器就能算出来了,而你的太过于复杂,就像1password无法普及一样的原因。
              你可能觉得打开一个网页很简单,但是我告诉你,30%以上的网民不知道QQ的网址是www.qq.com,这是有权威调查依据的。
              你可以做一个实验,如果你的父母是普通父母的话,你可以把你的密码和我上述的密码,例如xinxin8816改为Xinxin167504,你问问你的父母愿意选择哪一种,我相信他们肯定很排斥你的密码,但是对我的密码至少不会排斥。

              再解释一下所谓的紧急/意外状况的意思,不论你的还是我的设计方式,大多数情况都是不需要使用的,比如浏览器记忆密码,比如iphone指纹,人脸登录种种。
              但是如果出现了意外状况,需要你运算密码登录的时候,请你告诉我,你如何能够确保安全,你的网页很容易出现被盗风险,因为只要需要输入密码,就一定要打开网页,只要打开网页,无论是家里还是外面的电脑,都存在木马风险。

              而我这个虽然暴力破解安全系数低,但是也仅仅只有暴力破解方面的安全系数低,在其他任何方面都是足够强大了的。
              还是那句话,如果你的数据不是那么的重要,别人不会花十几二十万暴力破解的,你不需要把自己太当回事。
              如果你的数据真的很重要,别人也有花十几二十万来暴力破解的,这个网页运算的闪星花密也不够安全,你要做的应该是买一个硬件计算器。

              另外一点就是我曾经遇到过几次的,我之前有几个项目是南京军区空军指挥中心的战斗指挥室,里面屏蔽一切网络,但是有一个非常重要的系统是强加密的,密码根据当天日期运算出来的,0-8时、9-16时、16-23时,分三个密码段,然后基本密码和当天日期,时间段运算出来,输入电脑的。因此每天会滚动三次密码,永远不会重复。

              就这个环境来看,你的这个闪星花密也无法使用,而且也起不到强加密的作用。

              ==================== 总结 ====================

              目前很多软件和网站的密码都已经设计的很好了,强制你大小写字母和数字,因此我们来假设一下。
              如果目前有70%的民众使用了不安全密码(所有应用相同密码),20%民众使用了标准安全密码(几乎每个重要软件都是独立密码),而使用你这种和1password的只会有不到千分之一。
              而我的思路可以让那些深受被盗号烦恼但是又不懂为啥被盗号的人更加快捷高效的转变到那20%的人群去。

              你的思路是让那10%的高安全人群变得更安全,一方面是难度很大,就像你95分的想要努力到100分一样,另一方面是很可能有缺陷,害了别人,他们的数据肯定很重要,否则不会这么高安全。
              你一直停留在防止暴力破解上,但其实现今最不怕的就是暴力破解,而你的这个闪星花密最大的痛点也就是电脑中毒,这是最容易被盗的方式了,也是你这种密码设计方式最无法解决的问题。

              我的思路是让那70%不安全人群变得标准安全或是几乎标准安全,从广义上来看,会大幅降低盗号损失率,推广起来也更加容易。

              所以请原谅我一开始的说明可能不够明确,导致了你的误解。
              我认为你这样设计的密码并不能更好的解决高安全人群的被盗号概率,也不能很好的推广给低安全人群使用,因此可能不会有具体的意义。
              我的密码是一个设计思路,设计方式,而不是什么具体的算法和逻辑,他是可以变通的,可以变得更简单也可以变得更复杂,所以你才会认为我说的话前后矛盾。
              因此我才将我的思路推荐给你,或许可以帮到你一些。

            4. 密码被盗的方式很多,盗取难度也各不相同
              当密码达到一定位数和复杂性的时候就已经不会被暴力破解了,
              你又不是什么特别重要的人,没人会盯着你的账号破解个多少天,
              而且网络登录都是有错误几次就锁定的机制。

              因此可以归结出以下几种情况:
              1、在风险PC上输入了你的账号密码,导致被盗。该情况与密码复杂性无关。
              2、在储存了密码的电脑(chrome储存的密码)上运行了风险软件,导致被盗。该情况与密码复杂性无关。
              3、被你身边的人偷窥到密码。该情况与密码复杂性有关,但对于有心盗取你密码的人来说,并不是很困难的事情。
              4、你的密码很复杂,可能是通过某些算法或者纸笔或者TXT文档记录下来的,但是你的算法被因为上述三种情况被暴露,导致被盗。
              因此密码是否安全不在于花密的复杂性了,而是在于你的使用习惯。
              当机制足够安全时,问题一定出现在内部。

              这是我之前已经说过了的,但是我相信你自己也明白,这是你这套花密系统最大的痛点。
              你的回复是保证环境安全无毒,使用github托管等,由于这些硬伤,所以也不指望能够推广开来,但是我也相信,你内心是无比希望可以将自己研究的玩意推广起来的。

              所以我才提一些建议,或许你可以综合我的这种设计思路来设计一个既不需要托管,人脑和计算器即可计算的密码,又足够的安全。

            5. 我当然想推广开来,但是我即便不深知,也知道普通民众的局限性。所以我强调过,只适合某些群体(场景/需求)。也就是说,我并不指望安全意识不高的民众去使用闪星花密。可是同样地,你也不应该指望民众每次都要取字母索引,要做多位数加法,并处理“三位千分符”。当然你说,只是取个索引,做个乘法,算是简化很多了,也许可行,虽然我仍然不看好。你的问题在于把复杂的内部构造同使用接口融合了,这注定是无法推广给普通民众的。1Password 无法普及也是因为目标群体不是普通民众。

              如果开始推广了(注意,仍然不是将普通民众作为目标群体),手机 APP 也是可以做的。比如现在花密就有 APP。那么便可以避免输入网址,也能在外面比较安全地生成密码(手机可以视为相对安全的设备)。APP 这事我是提过的。

              如我再三强调的,你这个并非只有暴力破解的安全系数低。相反,暴力破解的强度可能已经够了(虽然某些字符可能比另一些更容易出现)。而是在设计上有诸多我发现没发现的缺陷,使其不是一个好的设计,包括但不限于可能泄露原始代码。同样地,我也并非停留在防暴力破解上(我前面讲了一堆关于不可逆,白费心思了?),不赘述。

              在锁定一部分群体的前提下,我认为安全性应该是普遍可得的。还是那句话,需不需要是你的事。算法安全性我想做足(用户可以通过控制基本密码调整实际强度)。当然,如果你认为自用电脑不保证安全,个人手机也不安全,那花密方案确实无解。我认为,在很大程度上安全性和易用性(或算法安全性和代码安全性)无法兼顾:想要非常安全,密码规则就比较复杂,这时交由人脑计算就过分操劳,需要自动化程序;反之人脑可以计算,那么规则就简单,就不那么安全。你的出发点是好的,也谢谢你的评论,但我认为倘若不能提出一种具体的好规则,也可以说是“不会有具体的意义”。像我说的,“十位的基本密码穿插六位区分代号”,已经能解决大部分常见安全性需求(总体仍是相对低的安全性),那我又取索引又开计算器的,意义在哪呢?

              目前的证据没有显示 SHA-256 不安全,即使考虑到专用 GPU 建立彩虹表。也没有看到可能组合数为 92 的密码有望在若干年内被暴力破解。因此你说闪星花密不够安全,请拿出论证过程来。甚至于,类似花密提供 32 位(字符)扩展密码,闪星花密也提供 40 位的扩展密码(虽然一般不建议使用)可选,只要基本密码选择得当,可达 236 位(比特)强度,强到可以作为密钥使用。要知道 AES-128 便可用来加密机密文件,192 以上长度的 AES 加密被估计数十年不会破解。战斗指挥室的密码系统我不了解,不评论。

            6. 你可能没仔细看我那大段的文字,我表示理解,但是我并不开心。
              我并没有说要三位千分符什么的,我说的很简单,我只是提供一个设计思路,我认为改为淘宝的首字母=19乘以1234=23446,将密码改为Abcd23446。QQ首字母=16乘以1234=19744,密码改为Abcd19744。就已经足够安全了,而这个步骤已经简单到不能再简单了。
              你不要说T转换为19很复杂,因为我也觉得很复杂,但是我说了这是一个设计思路,换算为3行不行?换算为5行不行?都可以,这要看用户自己如何定义这个换算方法,比如T是一横一竖就是2行不行?也行。
              至于10位基本密码穿插区分代号,是一个不安全的方式,因为太过简单了,1t2a3o4b5a6o,鬼都知道是123456+taobao,黑客很可能会枚举尝试其他网站和应用。

              ========================================================================

              至于民众是否愿意用计算器,这是一个实际案例问题,这是全互联网从业者都在努力解决的问题,就像微软、谷歌和apple也在更改用户密码的要求强度一样。
              现在几乎所有浏览器都有保存密码功能,再配合上手机的指纹,人脸识别免密码功能,大规模场景是不需要再输入密码了,在少数场景需要输入密码时可以理解为这个场景并不安全,大概率是网吧和公共电脑,此时你的花密就失去了“安全”,因为他们大多是键盘记录器和视频采集卡。
              在这个基础之上,教育民众使用一下计算器是要比任何一种花密手段要来的更加简单和容易的。

              ========================================================================

              我也没有说你的闪星花密本身不安全,我说的是闪星花密仍然无法解决从内部破解的问题,这是不安全的地方。
              我也没有忽略不可逆的概念,但我只是认为这个概念不算特别重要,你可以了解一下wifi密码被盗的情况,你可以的到一串64位代码,但是却无法转换为标准密码,但是仍然可以被盗。
              这是一个逻辑问题。
              1、你的东西很重要,所以需要强加密。
              2、你的东西很重要,所以对方也会加大成本来破解你。
              3、对方加大成本来破解你,最简单的途径是让NB黑客使用0day黑入你的电脑。
              4、无论你的密码多么复杂,你都会被盗。

              由于你的设计思路是确保最终的安全,那么对于最终安全来说,他并不安全,这才是我说的不安全的地方。

              至于我为什么说不要使用网站托管,因为一旦推广这样的东西,就会有各种平台,各种app,各种网站做各种加密工具,我相信你会明白我的意思。
              你觉得这样还能安全吗?反而变得更不安全,用户也不知道哪个平台会比较安全。

              =========================================================================
              最后我来说一下你提到的:但我认为倘若不能提出一种具体的好规则,也可以说是“不会有具体的意义”。
              如果真的是这样只对你说no,而不说更多是很不尊重人的行为,所以我并没有这么做,但是你可能没能理解我的意思。
              我自始至终没有说出任何具体的规则,但是也说出了非常具体的规则。
              我认为对于互联网从业者来说,当务之急要解决的是让用户将各个应用的密码相互独立起来,解决70%的不安全密码问题。
              所以我觉得推广一个相对强度较低,但是运算简单,无需记忆,无需外力的密码设计思路,就可以让整个互联网世界一下子提高30%以上的安全性。
              这才是一个真正伟大的工作,而不是代替商业化安防公司为那0.1%的人去设计啥并不会有人用的高端密码。

            7. 前面我好像漏了一些,我解释一下。

              “我也没有忽略不可逆的概念,但我只是认为这个概念不算特别重要,你可以了解一下wifi密码被盗的情况,你可以的到一串64位代码,但是却无法转换为标准密码,但是仍然可以被盗。”

              我明白你不可逆是为了避免基本密码泄露而导致满盘皆输。
              但结合我上面的逻辑我是想说,当用户如此强加密一个东西的时候,基本密码泄露与否都已经是非常危险的了。

          2. 0day 入侵不能说简单吧,当然我明白你的意思。我也知道你是想提出这么一个想法,只是我觉得,如果安全性和易用性之间的矛盾是不言自明的,其实都是可以想到某一边的解决方案的。只是很不巧你具体提出了一个在我认为不那么好的方案(千分符那个方案)。

            我认为字母(按序)取索引并不是一个好的方案,也暂时想不到有什么简单的字母转化为数字的方法(按键盘布局?)。我觉得适当的混淆其实是很多人都能做到的,却不能推广给普通民众。比如按 QWERT 键盘布局对应的字母转换为数字(类似于 Q 在 1 下面,所以转换为 1,或者还因为在第一行而转换为 11),因为方法真的普及以后,针对性攻击也会变多(也许不要普及这么个具体方法会更好,但缺乏举例又不太直观)。四则运算我也觉得有点操劳,即便是开计算器,我对此并不看好人性,但也许是可行的。教育民众使用更复杂的密码,我也是赞同的,这绝对是一个伟大的工作。

            至于十位基本代号穿插五位基本密码,想也知道用起来不可能字母数字泾渭分明让人看出吧。 比如 ctpatobbtaptpcp,我觉得算是比较能接受的(反正大概看不出了,这种需求下不可逆也“不算特别重要”)。

            我承认花密方案必须有一个可信设备,不适合需要在陌生设备登录很多账号的人。事实上,像我这种人,在外会尽量选择只在手机上登录账号,以免盗号发生(像你说的,键盘记录器什么的算是比较普遍,即便被盗后能改密码我也觉得膈应)。实在需要输入密码,就用手机的闪星花密对照输入电脑。自始至终闪星花密只是为特定的人群提供的设计,需要配套的习惯才能实现其安全性。我的设计思路并不是保证最终安全性,算法上做好安全性保障就行了,这时使用习惯(如同你一开始就说的)才是决定最终安全性的。我是希望能想到使用习惯这一层的人成为闪星花密的潜在用户,而绝非普通民众。

            强调一下,为民众推广更强的密码是一项伟大的工作。我虽然自己比较悲观,但很希望有人能做到。如果你要做的话,还是不要首先就拿最开始那一套出来,很容易劝退民众的。但我认同你提升普通民众密码复杂度的核心理念。

            1. 感谢你的回复,我们探讨了如此如此如此冗长也真是令人壮观,在这个blog几乎消逝的年代。

              我觉得我们已经探讨完毕了,也可以给其他观众一些启发。

              最后,祝愿你一切顺利!

            2. 我也觉得这很壮观。很高兴能有你这位评论者。如果造成不开心,我在这里道个歉。

              祝你工作顺利。

            3. 探讨而已,没什么开不开心的,能有机会聊聊就很开心了。

              从“自认为会成为一个了不起的人”到“不知道以后有没有出路”。
              我们已经认识很多年了。

              所以,千万别有任何的芥蒂。

            4. “不知道以后有没有出路”是说你自己还是我在哪篇文章中写的

            5. 为防止有人看到这里,真的去用闪星花密的扩展长度密码加密非常重要的东西,在此补充澄清一下:

              扩展长度不建议一般人使用,因而在网页上我以“高级”字样标注。

              不建议使用的首要原因是,一般人会选择一个(相对)强度很弱的记忆密码,造成虽然得到扩展长度的最终密码,却只是“表面安全”(参见上述关于暴力破解的补充)。如果要使用扩展长度的密码,请至少保证记忆密码的强度与最终密码相当,我会建议至少 39 位大小写字母和数字混合。(但你们会发现,这样很难谈得上是“记忆”密码。)

              再就是背后的逻辑原因。如 @惆怅而又凄凉 所述,这么强的密码通常代表其加密对象极其重要,那么这时使用花密方案是不合适的。他是对的。花密方案本来就是在可记忆前提下设计的独立密码方案,闪星花密也是在这个前提下尽力提升安全性。但这种可记忆性本身就意味着安全性对易用性的妥协。记忆密码通常来说只有一个或少数几个,一旦泄露(哪怕可能性小,这时也是要考虑的)后果严重。我会说这时应当抛弃这部分易用性,转为使用安全性更高的方案,如随机密码。

              总之,请自己权衡以后,有把握再使用扩展长度选项。

  6. 看文章学习 ❌
    看评论区论文 ✔

    1. 你们这群人还在蹦跶啊。。。
      很多年没看到你了。

      1. 大概没有以前活跃了。看到老面孔还是很欣慰的( 或者该怎么说),看来我要多更新博客啊。

  7. 不错 学习了

发表评论»

NO SPAMS! 不要发垃圾评论哦!

表情