@wy315700 哈哈哈客户真奇葩。

@wy315700 那也不能怪 TLS 喽，明明是大家的使用姿势不正确~

不过我以前也干过这样的事，客户端配置 TLS 的时候不验证服务器证书，以为这样就能省张 SSL 证书的钱了~ 正确的省钱姿势是安装自己的根证书。

@dallaslu 上面只讨论了攻击者没有取得代码的情况。遇到这种私有的复杂哈希函数的话，攻击者会想办法取得代码的。

我觉得正确的思路应该是 PBKDF2 那样，大大增加计算彩虹表的时间成本。即使有了代码也没法破解。

client / server 之间的通信安全，TLS / HTTPS 算是实现起来成本最低，最安全的一种方式。
为了节省一张 SSL 证书的钱，各位也真拼。。。

此外 HMAC 原本的设计就不是用于密码保存的，它是用于带身份验证的完整性校验的。HMAC 的输入应该是 hash 和 key，而不是 hash 和 salt。key 和 salt 的区别是 key 应该是保密的，由传送接受双方预共享，私下保存。salt 是存在数据库的，对攻击者是公开的。


https://news.ycombinator.com/item?id=1998198
这里有一个很好的解释

@wy315700
@zhicheng

用 HMAC 代替手写 hash+salt 算法并没有什么明显的安全优势。
用 PBKDF2 代替手写 hash+salt 算法是安全的。

这里举例说明：
假定攻击者已经取得了完整的数据库权限，但是没法看到代码实现。
攻击者想要获取用户 foo 的明文密码，下面分别讨论针对几种种密码存储方式攻击方式：

1. 密码明文存储
直接从数据库读出来，最不安全，大家都知道。

2. 不加盐 hash
攻击者知道 hash。但是不知道用什么哈希算法生成的 hash，可能是 md5(password)，可能是 md5(sha1(password))。攻击者可以利用已知的彩虹表查出 hash 可能对应的明文，分别去尝试登录。如果不是复杂的哈希算法，都有对应的现成彩虹表可查。

3. HMAC
攻击者知道 hash 和 salt。接下来和 2 是类似的，只不过哈希算法在 2 的基础上套了一层 HMAC，变成了这样 hash = HMAC(originalHash, salt)。因为 salt 是随机的，需要自己针对这个 salt 生成彩虹表，没法利用现成的彩虹表。

4. 加盐 hash
攻击者知道 hash 和 salt。和 3 类似，区别就是，在 3 里 hash = HMAC(originalHash, salt)，在这里 hash = myFunc(originalHash, salt)，攻击者需要想办法知道 myFunc 是什么，这个在不看代码的情况下是很难推出的。

5. PBKDF2
攻击者知道 hash 和 salt。同上，这次换成 hash = PBKDF2(password, salt)。注意 PBKDF2 算法的第一个参数直接就是 password，不需要先计算 originalHash。与 3 相比，攻击者无需推算 originalHash 是怎么得出的，可以直接计算针对此 salt 的彩虹表。但关键的地方来了，PBKDF2 是一个非常慢的算法，这个算法内部会进行多次 HMAC 的迭代，如果指定的迭代次数足够大，通常计算一次哈希值需要 500ms 以上，这时计算足够大的彩虹表是非常困难的。

对上面各种方式的安全性从低到高来个排序，大概是这样：
1<2<3=4<5

3 的难点在于 HMAC 算法通常也不是很快，计算彩虹表成本较高，但是只要有足够时间和设备还是可以计算出来的。4 的难点在于没法知道 myFunc 是什么，攻击具有不确定性，但通常低水平开发者写出的 myFunc 很简单，比如 md5($originalHash . $salt) 这样，这是非常容易猜出来的。所以上面给 3 和 4 画了个等号，两种方式可比性不强，安全性相当。

PBKDF2 算法是可以指定迭代次数的，只要有需要，完全可以把每个哈希值的计算时间调到 10s 以上，大大增加了彩虹表的计算难度。

程序员就是呆萌，真有意思。

@qinfensky 建议你反思一下，码农这一行是否真的适合自己。学了这么久，还是这样的技术能力，换任何 leader 都看不过去的。只不过 LZ 这位 leader 的处理方式有些不妥罢了。毕竟你学习态度很好，也许换个行业会更有助于发展。
我认识的几个喜欢编程的初中生，看起来能力可能也比你强。IT 这一行，真的需要天赋。

文档数据库是最佳选择。
在应用层做数据约束好处是可以很方便的水平扩展。坏处是如果没有很清晰的文档和规范，基本没人能 100% 做到位。

前端长期以来得不到重视，这两年被大公司重视起来，引入了不少软件工程的科学方法，才变得像样了点。
想知道楼上各位期望的应届生毕业薪资到底是多少......

不考虑一下 Surface Pro 3 吗？

@Khlieb woff 只是对 ttf/otf 的二次封装。如果还原成 ttf/otf 的话，只要是 TrueType 标准实现的，就可以分割，如果是 PostScript 标准实现的话，那就得先借助别的工具转换 TrueType 格式才行。

@LucasW 完整字库在服务端，服务器根据客户请求的文字，生成只包含相应文字的 ttf 子集，客户端动态插入 css 来引入字体。
ttf 的解析器和分割器是自己重造的轮子（C#），没有用现成的（大多是 node.js 和 py）

iconfont 那个感觉应该是从完整的 svg 字体分割子集的。svg 比 ttf 解析起来容易很多。

千万千万千万别买原装。
自从来了V2，一直对原装有种信仰。不到半年坏掉了三根原装线，自此再也不买原装了。

想问问前端用到了哪些框架组件？
最近也想实现一个布局不复杂，但是细节比较多的界面，如果全部从头写觉得好烦。。。

@typcn clock() 的精度是 100ms 级的。如果要获得更精确的时间，需要用到平台相关的 API。C++11 新增的 std::chrono::high_resolution_clock 似乎也可以。

下次找房东的时候带几个面相凶煞的哥们一起去