怎么用xcode写一个激活授权系统

一旦用户注册之后，用户信息就保存在服务器端（db/cache）。关键在于用户需要提供身份凭证，一般是用户名和密码。即常见的登陆页面：用户输入username和password，勾选rememberme（可选，一般是记住一周），点击登陆，提交请求到服务端（这里一般是走https）。服务端根据用户名和密码到数据库查询是否匹配，如果匹配的话，说明身份认证成功。这是一次普通的身份认证过程。非常好理解。关键在于http是无状态的，用户登陆过一次，但是如果你没有做一些状态管理操作的话，用户登陆后请求同一个页面，服务器仍然要求其登陆。这时候就需要做一些状态处理了。一般是通过服务器颁发一个登陆凭证(sessionkey/token/ticket)实现的。那么这个登陆凭证是怎么生成的？又是怎样安全的颁发给客户端呢？方案一：session集群+随机sessionid用户登陆成功之后，服务器为其随机生成的一个sesionid，保存在session服务器中，将这个sessionid与用户关联起来：sessionid=>userid。然后通过cookies方式将sessionid颁发给客户端，浏览器下次请求会自动带上这个sessionid。服务器根据sessionid从session服务器中拿到关联的userid，比较是否与请求的userid相同，如果是则认为是合法请求。sessionid是随机生成的，基本来说是不可能被猜测出来的，所以这方面的安全还是有一定保障的。方案二：session-less+加密算法上面的authentication方式其实是用到了session和cookies。我们知道session这东西是服务端状态，而服务端一旦有状态，就不是很好线性扩展。其实对于身份验证来说，服务端保留的也这是一个简单的value而已，一般是userid，即session['sessionid']==>userid。然后再根据userid去db获取用户的详细信息。如果我们把userid作为一个cookies值放在客户端，然后把用几个cookies值（比如userid）做一个特殊的签名算法得到的token也放在cookie中，即f(userid,expiretime)==>token。这样服务端得到用户请求，用同样的签名算法进行计算，如果得到的token是相等，那么证明这个用户是合法的用户。注意这个签名算法的输入因子必须包含过期时间这样的动态因子，否者得到的token永远是固定的。这种实现方式其实是仿造csrf防御机制anti-csrf.md。是笔者自己想出来的，不清楚有没有人用过，个人感觉行得通。然而上面的做法安全性取决于签名算法的隐蔽性，我们可以更进一步的，可以参考api中的签名验证方式，把password作为secretkey，把userid,expiretime,nonce,timestamp作为输入参数，同样用不公开的算法（这个与api签名不同）结合password这个secretkey进行计算，得到一个签名，即f(userid,expiretime,nonce,timestamp,password)==>sign。每次客户端传递userid,expiretime,nonce,timestamp和sign值，我们根据userid获取到password，然后进行f(userid,expiretime,nonce,timestamp,password)==>sign计算，然后比较两个sign是否一致，如果是，表示通过。这种方式比起上面的方式其实区别在于增加了password作为输入参数。这样首先增加签名的**难度。还带来一个额外的好处，就是当用户修改了password之后，这个token就失效了，更合理安全一些。具体步骤如下：1.客户端>>>用户输入userid和password，form表单提交到后台进行登录验证（这里最好走https）。2.>>客户端每次请求都要带上这个三个cookies(浏览器自动会带上)。4.>>用户输入userid和password客户端用userid和password计算得到一个签名：h1=md5(password),s1'=md5(h1+userid)客户端构造一个消息：**=randomkey;timestamp;h1;sigdata。其中randomkey是一个16位的随机数字；sigdata为客户端的基本信息，比如userid,ip等。客户端用对称加密算法(推荐使用性能极高的tea)对这个消息进行加密：a1=e(s1',**)，对称密钥就是上面的s1'，然后将userid和a1发送给服务端。2.>>客户端拿到a2，用randankey进行解密，如果可以解密成功，则认为是来自真实服务器的数据，而不是一台伪造的服务器，整个登陆流程完成。这个步骤主要是为了防止服务器伪造。这个步骤很容易被忽略，客户端应该和服务器一样，要对接受的数据保持不信任的态度。这个方案虽然没有使用https，但是思路跟https很类似。安全性也很高。说明上面的认证过程其实就是著名的网络认证协议kerberos的认证过程。kerberos是一种计算机网络认证协议，它允许某实体在非安全网络环境下通信，向另一个实体以一种安全的方式证明自己的身份。它的设计主要针对客户-服务器模型，并提供了一系列交互认证——用户和服务器都能验证对方的身份。kerberos协议可以保护网络实体免受**和重复攻击。 的登录协议都是基于kerberos的思想而设计的。不过kerberos也有一些安全性的问题。srp协议secureremotepasswordprotocol要更安全一些。据说是目前安全性最好的安全密码协议。为什么db保存s1而不是h1。这是为了提高批量****的成本。对经过两次md5加密，再加上userid作为salt，得到的s1进行暴露反推pasword基本是不可能的。而反推h1的话，由于h1的是password的md5值，相对于password来说强度要增强不少。这个读者可以自己试试md5('123456')看得到的h1就有直观的认识了。为什么服务端解开对称加密后的**之后还要对**的内容进行验证。这是为了避免拖库后的伪造登录。假设被拖库了，黑客拿到用户的s1，可以伪造用户登录（因为我们的加密算法是公开的）。它能够通过服务器第一个验证，即服务端使用存储的s1能够解开消息；但是无法通过第二个验证，因为h1只能是伪造的，这是因为根据s1反推h1是很困难的（原因见上面note.2）。但是虽然上面的协议可以防止黑客拖库后伪造用户登陆，却无法防止黑客拖库后伪造服务器，以及进行中间人攻击。拖库之后，黑客拥有db.s1，协议又是公开的，这相当于黑客拥有了伪造server的能力。黑客通过db.s1解开客户端发送的a1，得到userid,h1=md5(pwd),以及randomkey。这样，黑客就可以轻易的得到被**用户的h1了，而不需要通过s1进行反推。黑客就可以直接用h1伪造合法的用户登录请求了。如果pwd不够复杂，那么还很容易被****。黑客拦截客户请求，利用**得出的randomkey回复一个假的响应，达到伪造server的目的。黑客还可以同时伪造用户和server，进行中间人攻击，从而达到**用户会话内容的目的。美国“棱镜门”就是类似案例。甚者在必要的时候对会话内容进行篡改。当然，黑客拖库后只能**他**网络所截取到的受害用户的md5(pwd)，比起服务器存md5(pwd)的影响面窄多了，所以建议服务器还是不要直接存md5(pwd)。可以在现有登陆流程基础上加上密钥交换算法（如ecdh）解决上面的问题。具体流程如下：==前置条件==服务端生成一对私钥serverprivatekey和公钥serverpublickey，公钥直接hardcode在客户端，而不是通过网络传输。1.客户端>>>用户输入userid和password客户端用对称加密算法对消息进行加密：a1=tea(s1',randomkey;timestamp;h1;userid)，对称密钥s1'=md5(md5(password)+userid)`客户端生成自己的一对公钥clientpublickey和密钥clientprivatekey。客户端用serverpublickey对a1和clientpublickey进行非对称加密:ecdh(serverpublickey,userid+a1+clientpublickey)，然后将加密结果发送给服务端。2.>>客户端使用clientprivatekey对服务器回包进行解密，得到a2。用randankey对a2进行解密，如果可以解密成功，则认为是来自真实服务器的数据，而不是一台伪造的服务器，整个登陆流程完成。4.==后续通讯==由于非对称加密算法(如rsa、ecc)的计算复杂度相比对称加密高3个数量级，不太可能用作通信数据的加密。所以验证通过之后，服务端和客户端利用ecdh交换密钥算法独自计算出一样的密钥，后面的通讯应该还是基于对称加密。这个跟https是类似的。说明加上非对称加密之后，即使黑客知道了s1，也没有法伪造服务器，因为他不知道serverprivatekey。黑客也不可能伪造客户端。因为即使黑客拖库知道s1，并且通过反编译客户端应用程序知道serverpublickey，如果不是通过**网络得到a1，用s1解密a1从而得到a1中的h1的情况下，基本是不可能通过s1反推h1的。现在a1包在不对称加密算法上，黑客如果不知道serverprivatekey和clientprivatekey就无法解开会话信息。这里看到serverpublickkey是hardcode在客户端的，而不是通过公钥推送下发的。这里是为了保证客户端的serverpublickey是真正的serverpublickey，而不是来自伪造服务器的。如果serverpublickey通过网络传输下发给客户端的，那么伪造服务器在**网络的情况下，完全可以拦截客户请求，发回伪造服务器自己的fake_serverpublickkey，客户端在不知情的情况就用fake_serverpublickkey向伪造服务器发数据，因为fake_serverpublickey是黑客构造的，他当然有对应的fake_serverprivatekey解开。当然，黑客还需要知道s1才能解开a1。当然，将serverpublickey硬编码在客户端会导致更换密钥需要强制客户端一起升级，否则老版本的客户端将无法登陆。客户端自己也生成了公钥和私钥，目的是为了验证服务器是真正的服务器，这个得以成立的前提是公钥是真正的服务器公钥，如果是伪造服务器的公钥，那等于向黑客公开了自己加密的内容，黑客就知道了客户端的公钥，就能伪造服务器的返回数据。采用ecdh非对称加密算法包裹后的登陆认证协议，安全级别已经跟srp差不多。相对于srp协议的问题是ecdh安全性依赖于私钥的保密性，如果私钥泄漏安全性回到跟未加ecdh的时候一样。ecdh的私钥保密有以下一些法（考虑到实现成本，推荐方案2）私钥加强保密，做到绝密，不用换，也不准备换；例如用u**key等硬件方式。私钥密码级别安全，定期更换，换的时候让客户端拉取。具体实现方法是第一步验密的成功的以后，发现要更新公钥，在返回的加密信道中返回新的公钥。使用ver**ign等第三方证书，确保公钥的合法性，在2的基础上不会增加网络交互。完全使用tls的协议，会导致每次登录增加一次交互。另外，采用不对称加密算法，会有一个服务器间共享密钥的安全vaskey的问题：换key困难，架构设计导致网络上对称加密传输新密钥，可能被**可能的解决方案：vaskey的业务key管理目前是对称加密的方式，可以考虑换成ecdh或类似的密钥交换协议来动态更新key。集中验证签名和解密，不共享密钥。这里推荐采用方案2。最后一个容易忽略的地方是注册。采用http注册相当于明文传递用户名和密码，存在**、中间人攻击的危险。将注册入口全部改为https，封掉http注册可以去掉上述危险。但是如果黑客**网络，给用户返回http的页面，代理请求的https注册接口，也能窃取密码。tips&&thoughts基本上所有的安全的登陆鉴权协议都是采用https的思想：使用不对称密钥算法进行登陆验证以及对称密钥交换。通过之后，后续会话就用对称加密算法加密。但是与https采用ca证书不同的是，一般通过密钥本身来验证客户端和服务器的合法性。对于对称加密算法安全性问题更好的解决法是加密算法协商，而不在于寻找**难度更大的算法。在验密码之前协商后续会话使用的对称加密算法，如果有安全性更好的算法或者正在使用的算法被**了，只需要server增加对更安全算法的支持，新版本的客户端就可以使用安全性更好的算法。支持对称加密算法协商以后可以随时动态的升级或替换加密算法，不用担心对称加密算法被**的安全风险。https就是这样的一种思路。http登录无法防**，https登录可以防**，但是无法防止后续对业务会话的**。另外，ca也容易被伪造。关于**登录。处理方式有几种：1.验证码；2.一定时间内密码错误次数超过正常值，锁定账户；3.客户ip监控。第三方爆库、钓鱼、扫号、撞库如果解决？这些问题等同于用户明文密码被盗，靠密码登录体系没有法对抗，比较好的方式是对已知泄漏密码的用户进行封停，强制要求用户改密码等运营方式减少用户的财产损失。上面所有的验证方式，每次请求都需要根据userid去数据库拉取用户信息（password）。所以最好结合缓存进行处理，毕竟用户信息变化频率还是比较小的。这种鉴权认证方式，相对于前面的token方式而言，客户端有比较多的计算和验证逻辑，比较适合于cs架构，特别是手机app。而且，它不依赖于cookies，所以天然具有sso功能。moreabout密码强度&&****1.加盐之外我们还可以做些什么？加盐以后的密码存储体系已经有效的对抗批量****、彩虹表攻击、字典攻击。为了对抗针对单个密码的****，我们可以通过密钥加强(keystretching)、提高密码长度等方式来提高安全性。密钥加强的基本思路是让每次鉴权的时间复杂度大到刚好不影响用户体验，但是黑客****或构建彩虹表的成本大幅度提高，目前标准的算法有bcrypt、scrypt、pbkdf2等。密钥加强算法的本质是通过加盐以及迭代计算多次增加计算量，迭代次数增加1000次计算量翻1000倍，这种方式对单个密码的****作用不大。提高密码长度对构建彩虹表****的成本影响非常大，提高密码长度提升单个帐号的密码安全价值很大。以目前****md5能力最强的fpgansa@home计算量来估算（大概用一台pc电脑的功耗，每秒钟可进行30亿次的8位密码（密码空间64个字符）尝试），假设有1万个nsa@home集成电路，19秒就能**8字符的密码（70个字符的密码空间），所以现在的很多密钥检验要求的最小长度6个字符其实是不安全的，如果把密码长度增加到12个字符，则需要1年才能**。2.gpu，fpga，anic对上述密码强度有何挑战？fpgamd5****工具目前比较成熟的是nsa@home，大概用一台pc电脑的功耗，每秒钟可进行30亿次的8位密码（密码空间64个字符）尝试。lightninghashcracker[7]使用9800gx2gpu每秒能够完成密码md5计算608m次。类似fpga，gpu这种****方式受密码字符空间、密码长度、密码计算强度影响比较大，可以通过提升密码长度、密码计算强度来提升安全性。只替换密码hash算法对这种**作用不大，sha2的计算量不到md5计算量的一倍，把md5换成sha2只是让****的计算量增加了一倍，但是如果密码长度增加1位对计算量的提升是非常巨大的。对于对称加密算法，没有专门针对tea的硬件设计，针对aes算法，有一篇论文针对aes128专门设计的类似gpu的硬件计算速度能达到1012次/秒（约240次/s），aes128****需要288秒，这个计算量目前也是安全的。这种对称加密算法的****只能通过提升密钥长度来对抗。128位的aes与tea安全级别差不多，aes支持最长256位密钥，长远来看对抗****aes更有优势。然而，对于对称加密算法安全性问题更好的解决法是加密算法协商，而不在于寻找**难度更大的算法。 20210311