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

　　App登陆须要解决的问题有两个：安全、体验。它们分别对应着登陆过程的用户认证，以及用户登陆过程操做复杂度两个问题。 1、登陆过程的用户认证，常见的手段有密码加密传输、动态密码、验证码等。

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

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

三、验证码。 服务器一旦发现登陆有异常，如IP变化、短期内登陆次数过多等，会向App下发一个图片，用户把图片中要求输入的数据和用户名、用户密码一块儿提交给服务器。 为了下降用户登陆过程的复杂性，一般状况下，用户只须要输入用户名和密码，只有服务器发现异常状况才会启用验证码、动态密码等机制。 2、减小用户输入次数的自动登陆。 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使用场景、具体业务类型、用户习惯等各类方式来平衡安全性、用户体验还有商业应用中很重要的成本。