版权声明:本文为横云断岭原创文章,未经博主同意不得转载。微信公众号:横云断岭的专栏 https://blog.csdn.net/hengyunabc/article/details/34623957

update 2018-06-04

2015年出的一个规范 JSON Web Token (JWT)  https://tools.ietf.org/html/rfc7519 

JWT 官网: https://jwt.io/  

八幅漫画理解使用JSON Web Token设计单点登录系统: http://blog.leapoahead.com/2015/09/07/user-authentication-with-jwt/ 

JSON Web Encryption (JWE) : https://tools.ietf.org/html/rfc7516 

JSON Web Signature (JWS) : https://tools.ietf.org/html/rfc7515 

update 2017-9-6 

微信交互协议和加密模式研究:https://github.com/hengyunabc/hengyunabc.github.io/files/1280081/wechat.pdf

---

移动App该怎样保存用户password?

这个实际上和桌面程序是一样的。

先看下一些软件是怎样保存用户password的:

  • 我们先来看下QQ是怎么保存password的:

參考:http://bbs.pediy.com/archive/index.php?t-159045.html,

桌面QQ在2012的时候把passwordmd5计算之后,保存到本地加密的Sqlite数据库里。

  • 再来看下手机淘宝是怎么做的:

參考:http://blog.csdn.net/androidsecurity/article/details/8666954

手机淘宝是通过本地DES加密,再把password保存到本地文件中的,假设拿到ROOT权限,能破解出password明文。

  • 再来看下微软是怎么保存用户password的:

參考:http://www.freebuf.com/tools/37162.html 

我实际測试了下。能够轻松得到全部帐号的password明文。

  • 再来看下Linux是怎么保存用户password的:

參考:http://blog.csdn.net/lqhbupt/article/details/7787802

linux是通过加盐(salt),再hash后,保存到/etc/shadow文件中的。

貌似曾经的发行版是md5 hash,现在的发行版都是SHA-512 hash。

linux用户password的hash算法: http://serverfault.com/questions/439650/how-are-the-hashes-in-etc-shadow-generated

实际上是调用了glic里的crypt函数,能够在man手冊里查看相关的信息。

能够用以下的命令来生成:
mkpasswd --method=SHA-512 --salt=xxxx

当中salt參数,能够自己设置,最好是随机生成的。
能够用 mkpasswd --method=help 来查看支持的算法。

用户password该怎样保存,还有能做到哪种程度?

看完上面一些软件的做法之后,我们来探讨下,用户password该怎样保存。还有能做到哪种程度?

  • 假定本地存储的hash串/加密串,和加密算法,攻击者都能够得到,或者逆向分析到。

实际上也是如此,通过上面QQ和淘宝的样例,允分说明了加密串是能够得到的。Linux更是一切都是公开的,仅仅要有权限就能够读取到。包含salt值,shah算法,(salt+password) hash之后的结果。

  • 防止攻击者得到用户password的明文。

    这个实际上是从用户的角度出发。即使数据泄露了。影响降到最低。

  • 防止攻击者拿到hash串或者加密串之后。一直都能够登陆。

    这点对于移动设置是非常重要的。比现在天用户连到了一个恶意的wifi,假设攻击者截获到请求,要防止攻击者潜伏几天,或者几个月之后的攻击。

    必需要让请求的凭据在一天或者几天内失效。

加盐(salt)

假如不加盐,那么攻击者能够依据相同的hash值得到非常多信息。

比方站点1的数据库泄露了,攻击者发现用户A和用户B的hash值是一样的,然后攻击者通过其他途径拿到了用户A的password。那么攻击者就能够知道用户B的password了。

或者攻击者通过彩虹表。暴力破解等方式能够直接知道用户的原来password。

所以。每一个用户的salt值都要是不一样的,这点參考linux的/etc/shadow文件就知道了。

client本地存储password的算法

应该用哪种算法来存储?

从上面的资料来看。手机淘宝是本地DES对称加密,显然非常easy就能够破解到用户的真实password。

QQ也是对称加密的数据库里,存储了用户password的md5值。

显然对称加密算法都是能够逆向得到原来的数据的。那么我们尝试用非对称加密算法,比方RSA来传输用户的password。

那么用户登陆的流程就变为:

  1. client用公钥加密用户password。保存到本地;
  2. 用户要登陆时,发送加密串到server;
  3. server用私钥解密,得到用户的password。再验证。

有的人会说。假设server的私钥泄露怎么办?

server端换个新的密钥,强制client下载新的公钥或者升级。

能够考虑有一个专门的硬件来解密,这个硬件仅仅负责计算。私钥是一次性写入不可读取和改动的。搜索 rsa hardware,貌似的确有这种硬件。

当然。即使真的私钥泄露,世界一样运转。像OpenSSL的心血漏洞就可能泄露server私钥。但大家日子一样过。

非对称加密算法的优点:

  • 即使数据被盗。攻击者拿不到password的明文
  • 假设发现有部分用户的数据被盗了(公钥加密后的数据),能够通过升级server和client的版本号。让用户又一次输入password。用户还是原来的password。可是攻击者却登陆不了了。
  • 对于安全要求严格的应用,还能够定期更新私钥,来保证用户的数据安全。

怎样防止本地加密串泄露之后,攻击者可能潜伏非常久?

这点实际上是怎样让client保存的加密串及时的失效。

比方:

  1. 强制要求client保存的加密串一周失效;
  2. 用户手机中病毒了,攻击者窃取到了加密串。可是清除病毒之后。用户没有够时的改动password。

    攻击者是否会潜伏非常久?

  3. 发现某木马大规模窃取到了大量的用户本地加密串,能否够强制用户的本地加密串失效,client不用升级,用户不用改动password,也不会泄露信息?

以下提出一种 salt + 非对称加密算法的方案来解决问题:

  1. 用户填写password。client随机生成一个salt值(注意这个salt仅仅是防止中间人拦截到原始的password的加密串)。用公钥把 (salt + password)加密,设置首次登陆的參数。发送到server。
  2. server检查參数,发现是首次登陆,则server用私钥解密,得到password(抛弃salt值),验证,假设通过。则随机生成一个salt值,并把salt值保存起来(保存到缓存里。设置7天过期)。然后用公钥把(salt + username)加密,返回给client。

  3. client保存server返回的加密串。完毕登陆。
  4. client下次自己主动登陆时。把上次保存的加密串直接发给server。并设置二次登陆的參数。

  5. server检查參数。发现是二次登陆。用私钥解密。得到salt + username。然后检查salt值是否过期了(到缓存中查找,假设没有。即过期)。假设过期,则通知client。让用户又一次输入password。假设没有过期,再验证password是否正确。假设正确。则通知client登陆成功。

  6. 假设发现某帐户异常,能够直接清除缓存中相应用户的salt值。这样用户再登陆就会失败。

    同理,假设某木马大规模窃取到了大量的用户本地加密串,那么能够把缓存中全部用户的salt都清除,那么全部用户都要又一次登陆。注意用户的password不用改动。

  7. 第2步中server生成的salt值,能够带上用户的mac值,os版本号等,这样能够增强检验。

注意,为了简化描写叙述,上面提到的用户的password,能够是先用某个hash算法hash一次。

详细的登陆流程:

浏览器登陆的流程:

浏览器的登陆过程比較简单,仅仅要用RSA公钥加密password就能够了。

防止中间人截取到明文的password。 

 

App登陆保存数据流程

App由于要实现自己主动登陆功能。所以必定要保存一些凭据。所以比較复杂。

 

App登陆要实现的功能: 

  • password不会明文存储,而且不能反编绎解密; 
  • 在server端能够控制App端的登陆有效性,防止攻击者拿到数据之后,能够长久地登陆。 
  • 用户假设password没有泄露,不用改动password就能够保证安全性; 
  • 能够区分不同类型的client安全性;比方Android用户受到攻击。仅仅会让Android用户的登陆失效。IOS用户不受影响。

     

App第一次登陆流程:

  • 用户输入password,App把这些信息用RSA公钥加密:(username,password,时间,mac,随机数),并发送到server。 
  • server用RSA私钥解密。推断时间(能够动态调整1天到7天)。假设不在时间范围之内,则登陆失败。假设在时间范围之内,再调用coreservice推断username和password。

     

这里推断时间,主要是防止攻击者截取到加密串后。能够长久地利用这个加密串来登陆。 

  • 假设server推断用户成功登陆。则用AES加密:(随机salt,username,client类型,时间)。以(username+Android/IOS/WP)为key,存到缓存里。

    再把加密结果返回给client。 

  • client保存server返回的加密串 

App自己主动登陆的流程:

  • App发送保存的加密串到server,(加密串,username。mac,随机数)==>RSA公钥加密 
  • server用RSA私钥解密。再用AES解密加密串。推断username是否一致。假设一致。再以(username+Android/IOS/WP)为key到缓存里查询。假设推断缓存中的salt值和client发送过来的一致,则用户登陆成功。否则登陆失败。 

不用AES加密,用RSA公钥加密也是能够的。AES速度比RSA要快。RSA仅仅能存储有限的数据。

其他的一些东东:

多次md5或者md5 + sha1是没什么效果的。

RSA算法最好选择2048位的。

搜索" rsa 1024 crack"有非常多相关的结果,google已经将其SSL用的RSA算法升级为2048位的。

怎样防止登陆过程的中间人攻击。能够參考,魔兽世界的叫SPR6的登陆算法。

总结:

对于网页登陆,能够考虑支持多种方式:

  • 不支持JS的。用原始password登陆。

  • 支持JS的,能够考虑传递hash算法加密字符串。

    严格要求的应用,最好用JS实现RSA加密。在github上找到的一个JS RSA库:https://github.com/travist/jsencrypt

  • client应用,一律应当用RSA算法,并加盐来保存用户password。单纯的hash或者对称加密算法都不靠谱。

server用salt(存数据库的) + hash算法来保存用户的password。

用salt(存缓存的,注意和上一行的salt是不同的)+ RSA算法来加密用户登陆的凭证。

这样server能够灵活控制风险,控制用户登陆凭据的有效期,即使用户数据泄露。也不需要改动password。

移动App该怎样保存用户password的更多相关文章

  1. 移动App该如何保存用户密码(转)

    原文地址:http://blog.csdn.net/hengyunabc/article/details/34623957 移动App该如何保存用户密码? 这个实际上和桌面程序是一样的. 先看下一些软 ...

  2. 移动APP怎样保存用户password

    <span style="font-size:14px;">为了更好的用户体验,移动APPclient一般都会将用户信息进行保存以便兴许能够自己主动登录.</sp ...

  3. jQuery cookie插件保存用户登陆信息

    通过jquery cookie插件保存用户登录信息. 代码: <html>  <head>  <title>cookies.html</title>  ...

  4. Android 自定义ToggleButton+用SharedPreferences保存用户配置

    布局文件:   <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" androi ...

  5. php使用session来保存用户登录信息

    php使用session来保存用户登录信息 使用session保存页面登录信息 1.数据库连接配置页面:connectvars.php <?php //数据库的位置 define('DB_HOS ...

  6. Android记录4--自定义ToggleButton+用SharedPreferences保存用户配置

    Android记录4--自定义ToggleButton+用SharedPreferences保存用户配置 2013年8月14日Android记录 很多应用都会有用户设置,用户的一些偏好可以由用户来决定 ...

  7. 基于注解的简单SSH保存用户小案例

    需求:搭建SSH框架环境,使用注解进行相关的注入(实体类的注解,AOP注解.DI注入),保存用户信息 效果: 一.导依赖包 二.项目的目录结构 三.web.xml配置 <?xml version ...

  8. [加入用户]解决useradd 用户后没有加入用户Home文件夹的情况,Linux改变文件或文件夹的訪问权限命令,linux改动用户password,usermod的ysuum安装包。飞

    usermod的yum安装包: shadow-utils 将nobody用户加入到nogroup 组: usermod -g nogroup nobody cat /etc/passwd|grep n ...

  9. 利用Cookie保存用户身份信息实现免登录

    <%@page import="sun.misc.BASE64Encoder"%> <%@page import="java.util.Base64.E ...

随机推荐

  1. linux基础学习8

      管理主机每天任务: 查询登录档.追踪流量.监控用户使用主机状态.主机各项硬设备状态. 主机软件更新查询.其他使用者要求: 因此shell script 就必须要学啊,虽然可以说绝大部分shell能 ...

  2. xamarin.ios 半圆角按钮Readerer

    xamarin.from上可以使用本身的button实现圆角带图标的按钮,但是没有半圆角的按钮实现,需要自己使用Renderer重新写过来重写一个button. 下面是一个重写的带边框的方式,代码如下 ...

  3. eclipse安装Memory Analyzer

    转载:http://blog.csdn.net/lindir/article/details/8743610 2个月没有写博客了,最近一直在考虑自己未来的方向,再加上项目较紧,一直未更新.今天想着要好 ...

  4. 【React Native开发】React Native控件之DrawerLayoutAndroid抽屉导航切换组件解说(13)

    ),请不要反复加群! 欢迎各位大牛,React Native技术爱好者增加交流!同一时候博客左側欢迎微信扫描关注订阅号,移动技术干货,精彩文章技术推送! 该DrawerLayoutAndroid组件封 ...

  5. Redhat Crash Utility-Ramdump

    Redhat Crash Utility edit by liaoye@2014/9/16 http://blog.csdn.net/paul_liao Crash utility是redhat提供的 ...

  6. tyvj-1460 旅行

    题目描写叙述: A国有n座城市,每座城市都十分美,这使得A国的民众们很喜欢旅行. 然而,A国的交通十分落后,这里仅仅有m条双向的道路.而且这些道路都十分崎岖,有的甚至还是山路.仅仅能靠步行.通过每条道 ...

  7. 使用jquey的css()方法改变样式,

    $("#tip").css("display","none"); $("#tip").css("display ...

  8. java 中 instanceof 和 isInstance区别

    两者的功能是等价的.区别: 1.instanceof 是一个操作符(类似new, ==等): 使用方法: if (ins instanceof String) { //logic } 2.isInst ...

  9. GitHub上编程语言流行度分析

    GitHub已然是全球最流行的开源项目托管平台,项目数量眼下已经达到了千万级别.Adereth在Counting Stars on GitHub一文提供了一个很有意思的思路,那就是籍GitHub用户通 ...

  10. 栈(C++)

    简介: 限定仅在表尾进行插入或删除操作的线性表 表尾端称为栈顶(top),表头端称为栈底(bottom) 特点: 在栈中,后入栈的元素先出栈 C语言版本 用于测试的文件,以及测试结果可以去作者GitH ...