@lobbk1209 那是没办法 因为 Outlook 本身本来就并不仅仅是一个邮箱而已
Outlook 本身就集成 邮件 日历 联系人 任务 和 笔记
作为移动 app 当然也得支持这些啊 不让就没办法叫做 Outlook 了
虽然其实它以前叫做 Acompli 来着

不是 安卓棉花糖 吗

@Strikeactor 当然可以啊 只是之前开的没办法收回来咯

个人感觉应该问题不大 主要就是内置锂电池和升级 BT 4.2

个人希望可以稍微改进设计
目前的 MM 用起来还是有些不舒服 边缘太锋利 拿起来很不合手
而键盘太平 如果可以像 MBP 那样的键盘就好了 稍微有点弧度

@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. 不得不修改密码的时候太麻烦