@hxlx 面试当然要写算法 但是重点不在于你会不会高难度的算法已经结果怎么样
而是过程怎么样 corner case 和 异常 处理如何
代码是否精炼 是否有坏习惯 以及对需求的沟通交流过程

当然 如果是面 Google FB 这些算法题都是一堆一堆的
在 corner case 和 异常处理的前提下 迅速刷完就好了
对于他们而言 算法都是基础

对于面试一般的公司 对于 strstr 这样的算法题
我认为 用暴力算法然后 refine 比上来直接 kmp 要效果好

@zx120120 工程也有构架设计这样很有学问的东西 只有比较初级的才是堆砌重复代码
设计合理的架构 同时编写清晰可测试的代码难度 不会比学通这些算法简单

@wshcdr 除了 C/C++做核心 /底层开发 实在很难想到需要自己写 kmp 这样的算法
而且我记得现在已经有更好的算法来做这个事情了
不过理解这些算法的原理 并灵活使用还是非常值得的

NodeJS 是单线程的 没办法
只能通过调用多进程来解决

你只要说服M$ 把 Office2016 发布到 MAS 就有了 :)

KMP 是有些难度的
但是除了面试 根本用不到
而且就算是面试 如果一上来就 KMP 估计也没啥意义
面试官考这个又不是考验你记忆力的
而且估计面试官也可能搞不定 KMP

@gantEleCode 不一定哦 只能说明是刷过题 但是还是不能体现真实能力
除非是面试顶级大公司 这种作为基础题 刷过 KMP 也算不了什么

只有看代码才能最看得出实力
代码是否整齐是否符合标准就可以把不少人滤掉了（比如缩进是乱的之类）

@rtyurtyu 我之前也是这么认为的 但是现在觉得是一个选择 如果对安全的需求比较高的话

对于 “说个其他方面的副作用： 所有记住密码的功能、扩展、插件等等都会失效 妨碍了用户的正常使用功能”
这个问题并不大 目前很多webapp已经都是使用 Ajax 来提交用户信息 而不是直接通过Form来提交
所以不会导致修改Form引起插件、扩展抓到hash后的密码
目前国内有些网站是这样做的 我也觉得不太好

对于ajax提交而不是form提交 一些插件、扩展抓取不到
是这些都是他们自己的问题 因为我用的1password以及Chrome／Safari都没问题 可以抓取
说明其他的插件、扩展也可以做到

@Numbcoder 就算可以认为https协议本身是安全的 但是不能说明他的实现都是安全的
heartbleed 就是一个例子 而且openSSL也是适用最广泛的实现 而且之后还出现了很多很多漏洞
足以说明仅仅依靠https传输明文密码已经没有想象中那么安全可靠

而且我是说 “https一定要用” 而不是“有漏洞就不能用”
既然一套系统不够安全可靠 那么可以依赖多套系统叠加增加破解的难度
就算采用了 https 但是也不能默认他是安全的 因为硬件升级和算法的更新
很多https支持的老算法和设置也逐渐变的不再安全 比如 MD5 RC4 SHA1 SSL3 这样的算法或版本
你需要做一些额外的设置和机制 才可以跟上安全的步伐

更况切 对于 “https + 服务端 bcrypt(password + salt)” 就足够 我并没有反对
LZ这个帖子主要是为了解决后端慢哈希函数bcrypt效率低下 可能有DoS的风险
所以把一部分计算量放到前端来实现的想法 这个和用https并不冲突
只是LZ的想法还不够完善 所以我把我之前的想法发出来供LZ和大家讨论
我的想法的核心思想是 必须拥有原始密码才可以通过验证 而且把尽量多的运算量移到前端
后端只需要一部分的计算量就可以达到 原本需要很大计算量的效果

@Numbcoder @iyangyuan

我之前也是这么想的 所以没有去实现 可是https已经颜面扫地了
现在看来 https 只是最低保障 —— 不用https是肯定不行的
但是用https就没问题么？heartbleed 不就可以泄漏用户原密码么
所以前端做预处理 还是有点意义的 可以保护用户的原始密码
至少可以让弱密码看上去也不那么弱 就算是弱密码也得算个半天

@zjcqoo @Numbcoder @feiyuanqiu

其实这个方案我很久以前就考虑过
LZ的方案还不够完善 导致前端hash变得几乎没有意义

不过前端hash还是有办法弄得更加安全的
我之前想出来的办法就是多次分开加密

注册时候
password --> browser: bcrypt + client salt (2000x) --> server:bcrypt + client salt + server salt (100x) -> db

验证的时候
password --> browser: bcrypt + client salt (random 1k+ times) --> server: bcrypt + client salt (2000-client random times) --> server:bcrypt + client salt + server salt (100x) == db

这样就避免了“前端的哈希就完全没有意义了”的问题
然后 由于用同样算法 只是循环次数不同
分一大部分浏览器做 另一小部分服务器做 只要总数一定 结果就应该一样
然后再换一个算法另外一个salt（可以是固定的）保存到数据库 来避免直接脱库的问题
在注册的时候 浏览器做了最大次数的加密
在验证的时候 由于浏览器是随机选择次数 所以可以做到每次结果不一样 避免了和注册时候传输同样的密文

@eae29qvc 麻烦的就是那些比较重要的网站（但不至于重要到必须记住密码）
举个🌰 比如 QQ 和 微信 账号密码相同但是场景不同的情况
比如 密码被泄漏 必须换密码的情况
比如一些网站一开始是 最多16位不可以特殊字符
然后改成8-20位 必须 大小写＋数字＋可选某些特殊字符 不可以空格

另外不管我怎么改进扩展 就是没有Chrome自带的或1p或lastpass 自动输入方便

@lzhtony @eae29qvc

https://i.v2ex.co/91160IvX.png

一开始要求输入主密码用来解密算法的js代码
Map 是 hardcode 替换了某些特殊字符

之前也是做了Chrome 扩展 自动提取场景和密码要求

当时认为只需要记住主密码就够了
顶多记住 round 数 如果密码泄漏 需要重新生成密码
后面发现最大障碍还是不同的密码需求以及网站的变更
比如网站域名有多个 或者变了
或者密码要求变了之类
一开始不觉得有大问题 但是生成了200+个密码后 问题就比较明显了
不得不依赖密码存储

@lzhtony 这样一来 不同场景 存储不同 KeyMap 造成的困难比记忆困难的问题还难以解决了
而且不仅仅是 KeyMap 储存各种参数的困难已经不小了
如果需要数据库来帮你保存 那么安全性和方便性还不如1p lastpass

图片我分开回复你

我没办法提供源码是因为代码本身也被我加密了
就算是在内存解密并把代码导出来也是被混淆过的
而真正的源代码 被我加密保存到了某个角落
而且是用我自己修改过的编译器和工具链才能编译运行
而这些东西我也找不到了

@eae29qvc iOS 不需要开发app 直接打开dropbox或者自己服务器上面的网页也可以
另外就是要在别人电脑上输入密码的时候太痛苦了

忘了说一个 5. 某些情况使用及其不方便

尤其是有些时候需要输入密码 但是又不方便打开这个网页重新生成密码
比如手机上面的app 或者你到别人的电脑上用的时候

就算是你可以用这个重新生成
用手输入的时候 简直想撞墙

@yyork 我已经付诸实践了
你这些问题确实是最大的问题
基本上没办法解决
还是得靠1p或者lastpass
这样一来 就显得完全没有必要了

问题按重要性排序

1. 记不住场景 （尤其当不得不更换场景 或者有多个场景 的时候）
2. 每个网站密码要求不同 （有的要求短密码不能有特殊字符 有的要求长复杂密码 而且还会变）
3. 保存密码意义不大 重新生成密码又不方便
4. 不得不修改密码的时候太麻烦

@lzhtony 几年前 CSDN 我的老的密码被盗后就写了一个这样的东西了
选项比你这个多 而且我还做了 Chrome 扩展

其实这个思路还是有问题的
我坚持用了2年后放弃改用Chrome或者1p自动生成的密码了

主要的问题还是需要记忆或者保存某些东西不能丢失
当然一个Master Key是问题不大
首先 你这个情况 这个 Key Map 你怎么记 万一丢了怎么办

更重要的原因是当你要用密码的时候怎么办
把密码直接记录到1pass keepass lastpass 那不如直接随机密码来的方便
不记得话 就要重新生成
但是你重新生成怎么保证一致性 你记得规则吗 你的 Map Pass Salt 是什么
不要想象的那么简单 等你生成的密码多了 就算是那个 salt 你都会记不住
然后 万一自动生成的密码还被泄露的怎么办？再生成一个又要怎么办？

另外一个非常非常麻烦的可用性问题就是
不同的网站规则不同
有些网站必须8-16 位 可以有特殊字符/不可以有特殊字符/必须要特殊字符 之类
你如何处理？

另外你要的话我可以把我做的功能截图发上来
不过源代码我可能已经丢了
功能上我比你这个考虑的功能多 而且当年还为这个写过paper来着
而且我那个所有参数都可以记忆 没有那个map必须保存在电脑上面

Thunderbolt 得有多贵啊

也就 DeltaWalker Pro 有点兴趣

现在哪还有用 EJB 的项目啊
连 struts 都开始慢慢过时了吧