从安全和体验上解析移动App的登录

转载自：http://blog.csdn.net/a345017062/article/details/8630771

App登录需要解决的问题有两个：安全、体验。它们分别对应着登录过程的用户认证，以及用户登录过程操作复杂度两个问题。

一、登录过程的用户认证，常见的手段有密码加密传输、动态密码、验证码等。


1、密码加密。
目前互联网行业的移动APP有不少在使用最简单的做法：根据密码生成一个散列值，把散列值发送给服务器。服务器计算库中用户密码的散列值，然后和客户端传来的散列值比较，一致的话，登录成功。
如果安全性要求更高一些的话，常见的做法就是公钥加密。具体做法是这样，登录前先向服务器请求一个公钥密钥，用公钥密钥加密一串根据密码生成的散列值，然后发送给服务器。服务器使用私钥密钥解密，然后与根据数据库中的用户密码计算出来的散列值进行比较，一致的话，登录成功。当然，还可以做的更优化一些，就是控制公钥密钥的有效期来增强安全性，比如公钥10秒钟失效、只能使用一次等。
关于公钥加密，可以参考这篇文章：http://www.360doc.com/content/11/0406/17/4146412_107621805.shtml


2、动态密码。
关于动态密码，其本质就是选择另外一种可以识别用户身份唯一性的方式来和用户的静态密码一起做用户认证。具体常见的几种实现手段，可以参考这篇文章：http://baike.soso.com/v5973952.htm
目前市面上适合App使用的最常见的方式是利用手机短信进行动态密码认证。即用户常规登录时，如果服务器发现有异常，可以向用户手机发送一条包含动态密码的短信，用户在有效期（常见的是30秒到1分钟）内把用户名、用户密码、动态密码一起发送给服务器进行验证。这个对用户来说，操作门槛比较低，也很方便。


3、验证码。
服务器一旦发现登录有异常，如IP变化、短时间内登录次数过多等，会向App下发一个图片，用户把图片中要求输入的数据和用户名、用户密码一起提交给服务器。


为了降低用户登录过程的复杂性，通常情况下，用户只需要输入用户名和密码，只有服务器发现异常情况才会启用验证码、动态密码等机制。


二、减少用户输入次数的自动登录。
App登录成功后，服务器会告诉App一个session，后续交流都使用session。但通常为了安全起见session都是要设置有效期的，从1星期到20天都见过。那么，为了不让用户在session失效后重新登录，减少用户的手动输入用户名和用户密码的次数，引入了“自动登录”概念。
流程如下：
登录成功后，服务器给App下发sesion的同时，还下发一个认证token，客户端把token做为应用程序的私有数据存储起来。以后，每当session过期后，就把token发送给服务器获取新的session。整个过程都是对用户透明的，对用户来说，输入一次用户名和密码后，就再也没有登录这个事情了。
当然，这种自动登录的前提，是能保证token的安全性远大于session。我们知道，由于手机OS的安全机制，token做为应用程序的私有数据，对其它应用是不可见的，可以保证token的安全性。我们还可以再上一个锁，把token和用户使用App的那个设备做绑定。可供选择的绑定数据有imsi,mac等。这样的话，只要用户手机不丢，就没事。


没有一种安全机制是绝对安全的，我们需要在实际应用过程中综合运用App使用场景、具体业务类型、用户习惯等各种方式来平衡安全性、用户体验还有商业应用中很重要的成本。