restkhz

@sillydaddy 素数那个办法太好了

用加湿器，买温度和湿度计，时刻监控温度湿度。
我也有鼻炎，我发现我鼻炎貌似和相对湿度有点关系。

洗鼻子有用，但只是临时的。

躺下就鼻子堵，侧躺重力感应，朝哪里哪个鼻子就堵。早上醒来鼻子里面干的像裂了。然后疯狂打喷嚏。换季的时候能打喷嚏到鼻子出血。
从小就有这个问题，时间长了我逐渐习惯了靠着墙半坐着睡。

用加湿器有一定缓解。

好问题，我想了想，如果是更加“本土化”和抽象的概念至少按照我目前的知识水平认为这无法做到。
我不了解小说，不知道叶文洁具体发送了什么。
除非叶文洁发了大量信息，其中包含中文语言的无线电编码模式和大量中文文本。能让外星人了解中文语法结构，还用通过统计学分析出一些信息之类的。
如果只是发几个字的话应该没法理解。熵太高了。如果在这里写一个 zsgrd 你们谁能猜出是什么意思呢？(左手乱按的)

但是数字是很好被破译和理解的。比如我们可以发送一段 3.1415926535897932.....这里可以包含足够多的数字编码模式信息。还可以带上一些别的物理常量。这样可以帮助外星人了解我们的数字编码系统进而了解我们整个无线电波编码方式。

另外定位是有可能的。如果三体人已经看懂我们的数字编码系统，我们可以发送地球和 4 颗脉冲星的频率和距离，我想应该可以定位。不同的脉冲星应该有自己的频率。这样可以识别出脉冲星的特征，然后根据三维空间 4 点定位。甚至带上一些太阳系有关的数据方便验证。

当然或许也可能三体有足够精度的设备能够定位无线电波。

我之前只是想过 4 光年的距离岂不是在眼皮底下...太阳系的奥尔特云都有两光年了。可能设计为 4 光年只是为了后续剧情吧。
当然我不是那么了解这部作品就是了。

@ryan4yin 我认为你说的有道理。这种场景这么做是有意义的。送一个感谢。

摸个大鱼，写个长文。
很多人都在说：
”多次迭代 hash 很多人都在说第二次输入范围变小“。我就不一一 at 了。

@YGHMXFAL 关于多次迭代的问题我先说，多算法嵌套的问题我下文说。
我们来做一个脑内实验：
如果我们用同一个 hash 算法，进行几乎[无穷]多次迭代，那么一定会在某一次碰撞，对吧？毕竟 hash 值域空间有限。

而且，根据鸽巢原理，随着迭代次数增加，和之前迭代过程中 hash 碰撞概率也随之增加。比如迭代了 1 亿次，
这个碰撞来临的可能比我们预想的快（生日悖论）。

我们这样写：a 经过 hash 成为 b ，b 再 hash 成 c ，我们在这里写成 a->b->c

a->b->c->d->e->f->g

到此为止，一切都好。但是在下一时刻，g 经过 hash 后发生了碰撞成了[e]
于是最后这个 hash 就成了

a->b->c->d-> e->f->g-> e->f->g-> e->f->g-> e->f->g......

你会发现这个 hash 碰撞后会不可避免地陷入了一个循环。
最后结果就在 efg 这三个结果之间，实际上的值域变小。此后再多迭代次数也没有意义。我只要知道这个环里的元素 efg ，知道迭代次数，我们就可以推算出具体哪个元素可以构成碰撞。

比如上面就是 hash(a)*8=f, 我们不知道 a, 但是我们可以 8mod3=2 ，hash(g)*8=f=hash(a)*8 这样构造出碰撞。

然而对于一个健壮的 hash 算法来说出现上述情况很难，或者说你只迭代一千次一万次完全没问题。甚至就算有碰撞，这个环也可能大到难以探测。


再说组合不同算法：
假设一个不安全 hash 叫做 weak, 只输出 1 位。不是 0 就是 1.碰撞概率五五开。
你 sha-512 然后 weak ，会怎么样？碰撞概率依旧五五开。组合 hash 算法安全性取决于最差的那个 hash 。调换顺序也没用。

@gbadge 不可以替代 salt 。多次迭代会增加算力消耗没错。salt 让彩虹表无法复用，而且在空间和计算上都制造难度。
@jim9606 长度扩展攻击...可能不会让破解变得容易。至少我不知道。因为长度扩展攻击可以在我只知道 MD5(pwd)和 salt 的情况下算出 MD5(pwd+salt)但是我的确不知道怎么算 pwd 或者 MD5(pwd)...不管怎样，反正 MD5 ，SHA-1 的确就别再用了。

其他人懒得一个个回复了。

最后好好回复给 OP：
理论上：OP 的做法意义不大。虽然应该不会更不”随机“，但是安全性取决于最差的那个算法。而且只要有一个算法有问题那整个都变弱。迭代是有意义的，代价就是可以忽略的碰撞概率增加。

实际上：OP 的做法很有意义。黑客喜欢用现成的服务比如 hash 查询。黑客看到你这种骚操作很可能骂娘后直接放弃。但是弱密码依旧有可能被破解。
把黑客恶心死，也是一种安全。

多次迭代拖慢暴力，奇葩嵌套无法查询，加盐对抗彩虹表，密码策略防止弱密码对抗字典。

（所以...为什么不用 bcrypt 这些呢?）

经常看到这种争论，我平时很少在这种争论中说话。

回复 OP 一楼：理论上，对于 SHA-256 这种成熟可靠的算法，多次迭代不会有问题。实际上很多地方有在用这种做法。
回复 OP 四楼：我也同样不认为在实践中对于普通业务 https 下还前端 hash 密码有多好的安全性，除非是某些特别场景。前端加密能保护的东西太有限了。
回复 OP10 楼：是这样的。如果服务器被 pwn 那么最重要的还是数据库里的东西。该加盐的加盐就好了。

HTTPS 后前端 hash 到底保护啥了？防止 HTTPS 被破解？还是服务器那边 https 解密后的过程？如果我都拿下服务器了我为什么不注入脚本钓鱼？

我看过 11 楼在另一个帖子里自己发明的方法，是好的想法，但有点鸡肋。拔网线了意味着黑客同时也不可能嗅探到 https 流量。只能对着之前拖的库里的 hash with salt(应该有两层 salt) 干瞪眼。但是可能只有极其极端情况下才有用。其实同样的，我曾经也想过一样的问题。但是我的对策是 pwd+salt+challenge-response 。
另外纠正一下，真正对彩虹表有完全克制作用的是 salt 而不是迭代。迭代只是减缓破解速度。

实践上呢？
黑客拖库后通常不是搞什么集群 FPGA ，ASIC 暴力破解，而是直接提交给某个老牌网站批量查。
没经验的搞不出来就放弃了，有经验的会看代码，然后发现批量破解成本太高，破半天搞出几个弱密码。
一般黑客也不会劫持 web 服务软件去读用户请求，还不如上一个 xmr 矿机搞 ddos 闷声发大财(其实基本都是 bot 在做)除非你的用户价值非常非常高，高到别人愿意花多少万来专门搞你的用户。

唉，有时候禁止用户用弱密码反而可能是一个不错的方案。

这个有点钻牛角尖，个人理解，我打个比方吼：

如果有项目组(进程)，那么至少应该有一名员工在做事(执行流)。如果要有一名员工办事，那么至少应该给他一个办公桌（栈）。一个有办公桌能拿文档的能做事的员工叫做线程。

所以 OP 的问题可以当作：
项目组有自己的办公桌吗？