Mikel
[转载]加密与解密 ，URL请求保护，注册码-Android开发经验分享-eoe 移动开发者论坛 – Powered by Discuz!.
懒得排版，懒得给代码，懒得写太多。大牛绕道。伸手党绕道。
加密分很多种，但是按其方向来分就两个。
单向加密，加密之后永远得不到最初的密码。
可加可解,加密之后通过双方约定的钥匙来解密。
用途：单向加密自然就不希望别人知道密码，在校验的时候只需要比较加密后的信息是否相同进行通过就可以了，可以保护原始信息，也是较为安全的方式。
MD5 SHA等等基本都是这个的思路。很多人会提到，这些东西安全个什么，稍微厉害的服务器就可以反找密码。试想，如果在MD5上在加上你自己的加密算法可能会有人解出来？
跑题…
可加可解：可加可解，既然要解，所以肯定加密后的密码不仅仅是用于校验，还有一部分信息是需要提取的，用于其他用途，至于干嘛，稍后例子详解。
URL请求保护
有人问，怎么保证数据库的信息安全，我需要怎么写，怎么加密？
其实我遇到这种问题很反感，太宽泛。但是本人又不是大牛，大哲，只好把一些琢磨的思路扔出来。
想把所有数据都加密再解密，除非是非常严格需求，否则根本不现实。尤其在Android这种移动设备上，仅仅是为了数据安全做这些东西。所以我是不建议在输入输出流上做文章。
因此就有了请求保护的想法，其实请求保护说穿了就是oath认证的一些东西。但我在这里不拔oath的东西，有兴趣的可以去研究。
下面就说一下实现思路，
简单的思路，定义一个软件私有key 做单向加密 ， 服务器做同样处理看两次加密后结果是否一致，一致则通过。
这个方案有什么问题呢？你的加密后的口令一旦被泄露，就可以被所有人都使用了。你只能通过升级版本来改变key值。
稍微复杂的思路，定义一个软件私有key，做 单向加密Code1。时间戳做双向加密Code2，Code1和Code2做双向加密CodeSum。服务器 得到密码CodeSum 解密得到Code1和Code2。可以得到时间和校验口令。这里要注意，时间戳要自己定义时间延时量。一般根据网速定一个合理的范围，只要时间差的不多就 放行。
这个方案比较第一个已经相当不错了，黑客就算截取了你的一次请求，顶多就在几秒内可用。而且黑客加密复杂度极高做不到逆向解码。
扩展思路，上面的需求基本都是一个用户的信息，在实际处理中往往涉及到多用户的请求。只需要稍微对上面的加密方式进行修改就可以了，在加密因子里面加上加密的sessionID作为处理。
没有什么真知灼见，但是这样处理你是解决的每次请求，有效的避免了非法请求。也是互联网应用的不同，需要实效性。
注册码
注册码的校验分为很多情况，可以服务器校验，可以手机客户端校验。针对不同场景不同方案。
服务器校验每次激活需要联网HTTPS，然后客户端获取权限进行使用。流程：手机传递IMEI和激活码，验证成功后 服务器保存激活码，返回可以激活口令，客户端进行激活。扩展：给用户提供解绑定功能，和多台IMEI激活等设定。IMEI其实和PC的硬盘码 机器码十分类似。（注意：平板没IMEI）
客户端校验：用户不需要联网，在指定网站上根据IMEI购买后直接注册，一个IMEI对应一个手机。（稍微霸道）
写在后面：其实这些校验的东西说的再细，都要建立在优秀的混淆包，防DECODE的基础上，否则再强大的加密模式都毫无意义。但是一个好的加密方式会给你很多补救，也不会泄漏用户信息。（吐槽CSDN？）
明文要不得啊，只加SHA无异于明文啊！
