如今移动互联网应用一般都会採用用户注冊登录机制以便增强用户粘性。
那么为了安全设计。用户的password应该怎样传输？在云端又怎样保存？这个问题我思考过许久。总结下面一些思路。主要涉及到不可逆加密的使用原则。
如果用户的注冊/登录过程均是在全然安全的环境下进行，你能够地设计得非常easy: 注冊就是把设置的password直接保存起来，登录就是直接比較password。
这过程不涉及到不论什么加密技术。
然而在实际应用中。整个过程可能是在不安全的环境下进行，比如保存password的系统可能被黑客攻击，password的传输可能被黑客截获。。。
。这样的环境下，你怎样能保证你的登录过程不会被其它别实用心的人冒充？password怎样不泄露？
下面是注冊和登录过程中password及由它推导出来的信息（我称之为信任信息）的传递示意图:
注冊:
password---->传输---->持久保存
登录:
手机应用 云端server
password---->传输---->与持久保存的信息比較
因为传递过程的不安全性，每多一次信息的传递步骤。就多一次信息泄露的可能性。为了保证信任信息的安全，应该保证信任信息的传递过程是不可逆的。比如哈希加密算法（比如md5,sha1,sha256, PBKDF2, bcrypt等）可达到这一目的。
这些算法可保证无法通过下游的信息推算出上游的信息（比如password）。另外这类算法还可保证同样的输入和參数经过计算可得到同样的输出，这样云端就能够比較两方的结果就可以判断出原始的信息（如password）是否同样的。以达到用户认证的效果。
那么就上述的场景而言。怎样在各环节（如传输/保存）对password进行加密处理?
简单地说，用户在注冊时输入了password。能够先做一次哈希加密。再进行网络传输，云端server收到后，再做一次哈希加密。然后保存起来。登录时的过程类似，云端server所得到或使用的信息是经过了多次（这里是2)哈希加密后的结果。
相比之下，眼下有非常多文章关注的不过password做哈希处理后保存到云端server这一过程。
其实，一个复杂的系统可能存在多个泄露风险的环节, 因此需一一识别出来，并添加必要的哈希加密步骤。
详细而言，比如上述的注冊或登录过程， 假设只做一级哈希加密。 虽然达到保护原始password的效果。但仍存在安全风险的：假设不过云端保存前做哈希加密，那么传输过程仍使用password明文。存在泄露风险。
反之假设不过传输前做哈希加密，一旦该哈希值泄露了。则easy被伪造登录： 。
总结一下：
在信任信息由高信任域向低信任域传递的过程中，不可逆哈希加密处理能够有效控制高信任级别的信息直接扩散到较低信任域。假设在一个系统中存在多级这样的场景。那就应该多次使用不可逆加密处理。
注：
1) 上述提到的一次不可逆加密处理不代表仅仅能是一次哈希加密算法迭代。其实为了加大算法强度，有时可能是使用非常多次哈希加密算法的迭代。
2）在不可逆加密处理中，往往还须要加入盐值。以抵抗彩虹表攻击，这里不做具体阐述。