程序员之网络安全系列

转自：程序员之网络安全系列（一）：为什么要关注网络安全？

假如，明明和丽丽相互不认识，明明想给丽丽写一封情书，让隔壁老王送去

1. 如何保证隔壁老王不能看到情书内容？（保密性)
2. 如何保证隔壁老王不修改情书的内容？（完整性)
3. 如何保证隔壁老王不冒充明明？（身份认证)
4. 如何保证明明不能否认情书是自己写的？（来源的不可否认)

前言

大家都知道最近几年闹的沸沸扬扬的网络安全事件，之前的CSDN密码泄露，不久前的网易邮箱密码泄露，那么如果你的密码泄露，除了本身的网站外，还有很多人其它很多地方甚至银行密码都使用相同的密码，从而带来了很大的麻烦，据说“半个” 互联网的库都被人拖过。

亲身经历

拿我自己经历的一件事来说，前不久，我和一个朋友一起定了趟机票去上海，出发前两小时，收到一个短信说我预定的航班由于天气原因被取消，我需要改签另一个航班，让我拨打航空公司400的电话，由于马上要出发去机场，也没有去查具体航空公司的电话，就打了这个电话，对方的整套系统客服系统和流程几乎和航空公司一模一样，知道我的姓名，身份证，订的航班号等等都一清二楚，最后再说改签需要给用户补偿，需要给你转钱，所以你需要提供银行卡号，然后确认后才能改签，我这样说大家可能觉得如果是自己不太可能上当，但是你们都忽略了人的心里因素，第一你的私密信息他都知道（就像一个陌生人让你爸转钱说你需要钱，说是你的好朋友，知道你的所有只有你爸和你知道的信息), 第二你很着急，因为你在目的地的酒店已定，后面去别的地方的机票、火车票已定，所以你必须这个时间起飞等等。

最后我没有上当的原因，是因为我问骗子，航站楼是哪一个，他说是4号航站楼，因为西安就没有4号航站楼，当然这个应该是骗子的失误。

我们所有的人觉得自己百分之百不会上当的人，那是因为你没碰上骗子高手！

骗子可以得逞的罪魁祸首

我总结了大部分骗子能够骗成功的最主要的原因，是因为我们的私密信息被泄露了！可见网络安全的重要性，而针对我的这个事件，我不知道是航空公司还是某订票网站把我的信息泄露，当然，骗子可能组合多个地方的泄露信息。

而这些信息系统是谁开发和维护的呢？ 是程序员！

所以我们程序员需要学习安全知识，保护用户数据，同时防止自己被骗，对那些安全性不高的网站尽量不要使用，对那些安全不高的系统尽量不使用。

作为一个多年的程序员，我对网络安全相关的知识也非常少，我知道一些常规的东西，比如敏感数据加密存储，网站尽量使用https等，但是由于对后面的原理知道的太少，所以有的时候不一定做出了正确地选择，直到最近有的程序员说密码MD5存储了，就一定是安全的，这让我感觉了害怕，而且我看有的系统也真的只是MD5了一下，所以我开始决定学点安全的常识，记录一点“大家” 常用的程序安全知识, 在这里和大家共同进步，由于我对这对理解的不深，要学习的东西很多，所以也希望大家帮忙指出错误的地方。

程序员之网络安全系列（二）：如何安全保存用户密码及哈希算法

前言

在很多网站的早期，甚至是现在仍然有一些网站，当你点击忘记密码功能时，你的邮箱会收到一封邮件，然后里面赫然写着你的密码，很多普通用户还会觉得庆幸，总算是找回来了，殊不知，这是多么可怕地一件事，说明了网站是“几乎是”明文存储你的密码，一旦数据用户数据泄露或者被拖库，那么用户密码将赤裸裸的暴露了，想想之前几次互联网密码泄露事件。

那么如何解决呢？

加密

为了不让密码明文存储，我们需要对密码进行加密，这样即使数据库用户密码暴露，也是加密后的。但是如何让加密后的数据难以解密呢？我们现在比较流行的做法就是把密码进行Hash存储。

Hash

哈希算法将任意长度的二进制值映射为较短的固定长度的二进制值，这个小的二进制值称为哈希值。哈希值是一段数据唯一且极其紧凑的数值表示形式. 典型的哈希算法包括 MD2、MD4、MD5 和 SHA-1

Hash算法是给消息生成摘要，那么什么是摘要呢？

举个例子：

比如你给你女朋友写了一封邮件，确保没被人改过，你可以生成这样一份摘要 “第50个字是我，第100个字是爱， 第998个字是你”，那么你女朋友收到这个摘要，检查一下你的邮件就可以了。

Hash算法有两个非常主要的特征：

• 不能通过摘要来反推出原文
• 原文的非常细小的改动，都会引起Hash结果的非常大的变化

因此，这个比较适合用来保存用户密码，因为不能反推出用户密码，Hash结果一致就证明原文一致，我们来用Ruby代码试一下上面的第二点 （MD5是一种常用的Hash算法)

2.2.3 :003 > require 'digest/md5.so'

=> true

2.2.3 :004 > puts Digest::MD5.hexdigest('I love you')

e4f58a805a6e1fd0f6bef58c86f9ceb3

=> nil

2.2.3 :005 > puts Digest::MD5.hexdigest('I love you!')

690a8cda8894e37a6fff4d1790d53b33

=> nil

2.2.3 :006 > puts Digest::MD5.hexdigest('I love you !')

b2c63c3ca6019cff3bad64fcfa807361

=> nil

2.2.3 :007 > puts Digest::MD5.hexdigest('I love you')

e4f58a805a6e1fd0f6bef58c86f9ceb3

=> nil

2.2.3 :008 > 

那么我们在使用MD5保存密码时候的验证流程是什么呢？

• 用户注册时，把用户密码是MD5(password)后保存到数据库。
• 用户输入用户名和密码
• 服务器从数据库查找用户名
• 如果有这个用户，A=MD5(input password), B=Database password
• 如果A==B, 那么说明用户密码输入正确，如果不相等，用户输入错误。

为什么Hash(MD5)后仍然不够安全？

穷举

但是，如果你认为就只是这样密码就不会被人知道，那么就不对了，这只是比明文更安全，为什么？

因为，大部分人的密码都非常简单，当拿到MD5的密码后，攻击者也可以通过比对的方式，比如你的密码是4218

2.2.3 :008 > puts Digest::MD5.hexdigest('4218')

d278df4919453195d221030324127a0e

那么攻击者可以把1到4218个数字都MD5一下，然后和你密码的MD5对比一下，就知道你原密码是什么了。

曾经我的密码箱密码忘了，我把锁给撬了，后来我才想起可以用穷举法，最多就999次不就打开了？那么问题来了，你的密码箱还安全吗？

彩虹表

除了穷举法外，由于之前的密码泄露，那么攻击者们，手上都有大量的彩虹表，比如"I love you",生日等等，这个表保存了这些原值以及MD5后的值，那么使用时直接从已有库里就可以查出来对应的密码。

加盐 Salt

那么，由于简单的对密码进行Hash算法不够安全，那么我们就可以对密码加Salt，比如密码是"I love you", 虽然彩虹表里有这条数据，但是如果加上"安红我爱你"，这样MD5结果就大不一样.

jacks-MacBook-Air:~ jack$ irb

2.2.3 :001 > require 'digest/md5.so'

=> true

2.2.3 :002 > puts Digest::MD5.hexdigest('I love you')

e4f58a805a6e1fd0f6bef58c86f9ceb3

=> nil

2.2.3 :003 > puts Digest::MD5.hexdigest('I love you安红我爱你')

b10d890bf46b1a045eb99af5d43c7b13

=> nil

2.2.3 :004 > puts Digest::MD5.hexdigest('I dont love you')

c82294c9a7b6e4a372ad25ed4d6011c9

=> nil

2.2.3 :005 > puts Digest::MD5.hexdigest('I dont love you安红我爱你')

dce67bcdfdf007445dd4a2c2dc3d29c1

=> nil

2.2.3 :006 >

如此一来，因为攻击者很难猜到“安红我爱你”，那么自然彩虹表里是没有的，当然我建议你在实际项目中不要使用"安红我爱你"，你应该使用一个连你自己都猜不到的较长的字符串。

加盐了，就安全了吗？

实际上，加盐并不能100%保证安全，假如有人泄露了你的Salt呢？实际上通过反编译程序很容易可以拿到这个，由于WEB程序一般放在WEB服务器上，那么就需要保证服务器不被攻击，当然这个是运维人员去操心。

为了让加盐更安全，一般情况下我们可以使用一个“盐+盐”，也就是为每个用户保存一个"Salt"， 然后再使用全局的盐，我们可以对用户的盐使用自己的加密算法。那么代码就如下:

if MD5(userInputPpassword+globalsalt+usersalt)===user.databasePassword） 

{

    login success

}

普通用户如何做？

由于这个是写给程序员，当然是说在前端用户注册时密码应该如何设置，很简单，我们要求用户必须输入强密码！但是，我知道很多用户觉得很烦，这样你就失掉了一个用户，但我们需要做一个适当的折中，比如至少有一个大写字母，小写字母和数字的组合。

最后

我们来看看解决了之前文章下面例子的什么问题。

假如，明明和丽丽相互不认识，明明想给丽丽写一封情书，让隔壁老王送去

1. 如何保证隔壁老王不能看到情书内容？（保密性)
2. 如何保证隔壁老王不修改情书的内容？（完整性)
3. 如何保证隔壁老王不冒充明明？（身份认证)
4. 如何保证明明不能否认情书是自己写的？（来源的不可否认)

通过了解hash算法,"明明" 就有办法让丽丽知道信的内容没有修改，他可以对邮件进行Hash生成邮件的摘要，然后让"隔壁的李叔叔"把摘要送给丽丽，丽丽拿到邮件的摘要后，把邮件内容也Hash一下，然后把结果和"隔壁的李叔叔"给的摘要对比一下，然后通过比较结果就知道邮件有没有被"隔壁的王叔叔"更改过了。

程序员之网络安全系列（三）：数据加密之对称加密算法

上一节，我们使用了Hash算法保证了情书的完整性，也就是确保“隔壁王叔叔”没有修改明明的情书，那么这一节我们来看看如何保证“隔壁王叔叔”不能看到情书的内容，也就是保密性。

数据加密

要想不让别人看到数据，那么我们就们就需要对数据加密。

加密技术 是最常用的安全保密手段，利用技术手段把重要的数据变为乱码（加密）传送，到达目的地后再用相同或不同的手段还原（解密）。
加密包括两个元素：算法和密钥。一个加密算法是将普通的文本（或者可以理解的信息）与一窜数字（密钥）的结合，产生不可理解的密文的步骤，密钥是用来对数据进行编码和解码的一种算法。

举个例子：

假设我们要对LOVE加密，我们可以先定义字母的顺序ABCDEFGHIJKLMNOPQRSTUVWXYZ，然后我们让每个字母向后移动两位，那么LOVE就变为了NQXG

L------>N

O------>Q

V------>X

E------>

LOVE--->NQXG

我想这就是最简单的加密方式。

密钥加密技术的密码体制分为对称密钥体制和非对称密钥体制两种。

对数据加密的技术分为两类，即对称加密（私人密钥加密）和非对称加密（公开密钥加密）。对称加密以数据加密标准（DES，Data Encryption Standard）算法为典型代表，非对称加密通常以RSA（Rivest Shamir Ad1eman）算法为代表。对称加密的加密密钥和解密密钥相同，而非对称加密的加密密钥和解密密钥不同，加密密钥可以公开而解密密钥需要保密。

对称加密

对称加密采用了对称密码编码技术，它的特点是文件加密和解密使用相同的密钥，即加密密钥也可以用作解密密钥。
比如，我们给WORD文档设置密码1234, 那么其他人想要打开文档也必须输入1234才能打开。

常用加密算法:

• DES（Data Encryption Standard）：数据加密标准，速度较快，适用于加密大量数据的场合。
• 3DES（Triple DES）：是基于DES，对一块数据用三个不同的密钥进行三次加密，强度更高。
• AES（Advanced Encryption Standard）：高级加密标准，是下一代的加密算法标准，速度快，安全级别高；
• RC4，也是为 RSA Data Security, Inc. 开发的密码系统的商标名称。

传统的DES由于只有56位的密钥，从1997年开始，RSA公司发起了一个称作“向DES挑战”的竞技赛。在首届挑战赛上，罗克·维瑟用了96天时间破解了用DES加密的一段信息。1999年12月22日，RSA公司发起“第三届DES挑战赛（DES Challenge III）”。2000年1月19日，由电子边疆基金会组织研制的25万美元的DES解密机以22.5小时的战绩，成功地破解了 DES加密算法。DES已逐渐完成了它的历史使命。

高级加密标准（英语：Advanced Encryption Standard，缩写：AES），在密码学中又称Rijndael加密法，是美国联邦政府采用的一种区块加密标准。这个标准用来替代原先的DES，已经被多方分析且广为全世界所使用。经过五年的甄选流程，高级加密标准由美国国家标准与技术研究院（NIST）于2001年11月26日发布于FIPS PUB 197，并在2002年5月26日成为有效的标准。2006年，高级加密标准已然成为对称密钥加密中最流行的算法之一。

对称加密算法的优点：

• 算法公开
• 计算量小
• 加密速度快，加密效率高
• 加解密双方需要使用相同的秘钥
• 秘钥管理很不方便，如果用户很多，那么秘钥的管理成几何性增长
• 任何一方秘钥泄露，数据都不安全了

对称加密算法的缺点

最后

通过本节，我们知道当明明给丽丽情书时，可以用DES或者AES对数据进行加密，即使“隔壁王叔叔”拿到信件也看不懂内容，同时使用上一节的Hash算法保证了情书的内容完整，但是这就需要明明和丽丽提前设置一个秘钥。

代码示例

下面的代码输出如下结果

    I Love You, Li Li

    Encrypeted: 0t9glwGMmwtGs8B4QCotyZkKf091WElCwG659QiVVw0=

    Decrypeted: I Love You, Li Li

.NET 源码：

    using System;

    using System.Security.Cryptography;

    using System.IO;

    using System.Text;

    namespace AES

    {

        class MainClass

        {

            public static void Main (string[] args)

            {

                string password = "Don't believe wang shu shu";

                string orginTextToSent = "I Love You, Li Li";

                Console.WriteLine (orginTextToSent);

                string encryptedText=EncryptText(orginTextToSent, password);

                Console.WriteLine ("Encrypeted: " + encryptedText);

                string DecryptedText = DecryptText (encryptedText, password);

                Console.WriteLine ("Decrypeted: " + DecryptedText);

            }

            public static byte[] AES_Encrypt(byte[] bytesToBeEncrypted, byte[] passwordBytes)

            {

                byte[] encryptedBytes = null;

                // Set your salt here, change it to meet your flavor:

                // The salt bytes must be at least 8 bytes.

                byte[] saltBytes = new byte[] { 1, 2, 3, 4, 5, 6, 7, 8 };

                using (MemoryStream ms = new MemoryStream())

                {

                    using (RijndaelManaged AES = new RijndaelManaged())

                    {

                        AES.KeySize = 256;

                        AES.BlockSize = 128;

                        var key = new Rfc2898DeriveBytes(passwordBytes, saltBytes, 1000);

                        AES.Key = key.GetBytes(AES.KeySize / 8);

                        AES.IV = key.GetBytes(AES.BlockSize / 8);

                        AES.Mode = CipherMode.CBC;

                        using (var cs = new CryptoStream(ms, AES.CreateEncryptor(), CryptoStreamMode.Write))

                        {

                            cs.Write(bytesToBeEncrypted, 0, bytesToBeEncrypted.Length);

                            cs.Close();

                        }

                        encryptedBytes = ms.ToArray();

                    }

                }

                return encryptedBytes;

            }

            public static byte[] AES_Decrypt(byte[] bytesToBeDecrypted, byte[] passwordBytes)

            {

                byte[] decryptedBytes = null;

                // Set your salt here, change it to meet your flavor:

                // The salt bytes must be at least 8 bytes.

                byte[] saltBytes = new byte[] { 1, 2, 3, 4, 5, 6, 7, 8 };

                using (MemoryStream ms = new MemoryStream())

                {

                    using (RijndaelManaged AES = new RijndaelManaged())

                    {

                        AES.KeySize = 256;

                        AES.BlockSize = 128;

                        var key = new Rfc2898DeriveBytes(passwordBytes, saltBytes, 1000);

                        AES.Key = key.GetBytes(AES.KeySize / 8);

                        AES.IV = key.GetBytes(AES.BlockSize / 8);

                        AES.Mode = CipherMode.CBC;

                        using (var cs = new CryptoStream(ms, AES.CreateDecryptor(), CryptoStreamMode.Write))

                        {

                            cs.Write(bytesToBeDecrypted, 0, bytesToBeDecrypted.Length);

                            cs.Close();

                        }

                        decryptedBytes = ms.ToArray();

                    }

                }

                return decryptedBytes;

            }

            public static string EncryptText(string input, string password)

            {

                // Get the bytes of the string

                byte[] bytesToBeEncrypted = Encoding.UTF8.GetBytes(input);

                byte[] passwordBytes = Encoding.UTF8.GetBytes(password);

                // Hash the password with SHA256

                passwordBytes = SHA256.Create().ComputeHash(passwordBytes);

                byte[] bytesEncrypted = AES_Encrypt(bytesToBeEncrypted, passwordBytes);

                string result = Convert.ToBase64String(bytesEncrypted);

                return result;

            }

            public static string DecryptText(string input, string password)

            {

                // Get the bytes of the string

                byte[] bytesToBeDecrypted = Convert.FromBase64String(input);

                byte[] passwordBytes = Encoding.UTF8.GetBytes(password);

                passwordBytes = SHA256.Create().ComputeHash(passwordBytes);

                byte[] bytesDecrypted = AES_Decrypt(bytesToBeDecrypted, passwordBytes);

                string result = Encoding.UTF8.GetString(bytesDecrypted);

                return result;

            }

        }

    }

程序员之网络安全系列（四）：数据加密之非对称秘钥

我们对数据进行了加密

但是上面的问题是明明和丽丽必须提前知道秘钥，但是如果双方提前不知道秘钥，那么明明就需要“隔壁的王叔叔" 把秘钥告诉丽丽，这个显然是风险太大了，因为”隔壁王叔叔“有了秘钥和密文，那么就等于有了明文。

非对称秘钥

DH（Diffie-Hellman）算法

1976年，美国学者Dime和Henman为解决信息公开传送和密钥管理问题，提出一种新的密钥交换协议，允许在不安全的媒体上的通讯双方交换信息，安全地达成一致的密钥，这就是“公开密钥系统”。相对于“对称加密算法”这种方法也叫做“非对称加密算法”。

与对称加密算法不同，非对称加密算法需要两个密钥：公开密钥（publickey）和私有密钥（privatekey)。公开密钥与私有密钥是一对，如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。

算法原理及示例

1. 假如明明和丽丽希望交换一个密钥。
2. 明明取一个素数p =97和97的一个原根a=5，让隔壁的王叔叔告诉丽丽。

1. 明明和丽丽分别选择秘密密钥XA=36和XB=58，并计算各自的公开密钥，然后让隔壁的王叔叔帮忙交换公开秘钥。
2. 明明和丽丽交换了公开密钥之后，计算共享密钥如下：

4.  YA=a^XA mod p=5^36 mod 97=50

5.   

YB=a^XB mod p=5^58 mod 97=44

7.  明明：K=(YB) ^XA mod p=44^36 mod 97=75

8.   

丽丽：K=(YA) ^XB mod p=50^58 mod 97=75  

由于只有明明知道XA, 而只有丽丽知道XB, 那么“隔壁的王叔叔” 是不可能通过 P, A, YA, YB来得到最终密码K的。

DiffieˉHellman不是加密算法，它只是生成可用作对称密钥的秘密数值。

非对称加密特点

与对称加密算法不同，非对称加密算法需要两个密钥：公开密钥（publickey）和私有密钥（privatekey）。公开密钥与私有密钥是一对，如果 用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。

那么如果甲(收信方)想收到只有自己才能解读的加密信息，那么需要把自己的公钥告诉乙(发送发), 乙通过甲的公钥加密，把加密后的密文告诉甲，由于只有甲有私钥，那么也就只有甲才能加密。
由此可见，非对称加密只需要保存一对公钥和私钥，大大方便了秘钥管理。但是由于要做更多的计算，非对称加密只适合一些小数据量加密，一般情况都是用非对称加密算法来交换秘钥，随后通过对称加密算法来加密数据。

常用非对称加密算法

RSA、Elgamal、背包算法、Rabin、D-H、ECC（椭圆曲线加密算法）。

使用最广泛的是RSA算法，Elgamal是另一种常用的非对称加密算法。

最后

我们对数据的完整性使用Hash进行了保证，用DH算法交换了秘钥，使用RSA算法对数进行了加密，那么如果王叔叔在交换秘钥的过程中做了手脚呢？

如何做手脚？看下图：

1. 王叔叔自己生成一个公私钥，和明明以及丽丽交换。
2. 王叔叔冒充丽丽把自己的公钥发给明明。
3. 明明用王叔叔的公钥对信件加密。
4. 王叔叔用自己的私钥解密就可以看到明明给丽丽的邮件。
5. 王叔叔冒充明明把自己的公钥发给丽丽。
6. 丽丽用王叔叔的公钥对信件加密。
7. 王叔叔用自己的私钥解密就可以看到丽丽给明明内容。

至此，邮件内容又赤裸裸地被王叔叔看到了，怎么办呢？我们下文继续解释。

程序员之网络安全系列（五）：数字证书以及12306的证书问题

中间人攻击

上面几步还是不够的，比如王叔叔在交换秘钥的过程中做了手脚呢？

如何做手脚？看下图：

1. 王叔叔自己生成一个公私钥，和明明以及丽丽交换。
2. 王叔叔冒充丽丽把自己的公钥发给明明。
3. 明明用王叔叔的公钥对信件加密。
4. 王叔叔用自己的私钥解密就可以看到明明给丽丽的邮件。
5. 王叔叔冒充明明把自己的公钥发给丽丽。
6. 丽丽用王叔叔的公钥对信件加密。
7. 王叔叔用自己的私钥解密就可以看到丽丽给明明内容。

那么明明如何知道王叔叔给的公钥就是丽丽的公钥呢？那么就引入了数字证书

数字证书

概念介绍

那么王叔叔要让明明相信他给的公钥就是丽丽的公钥，那么他可以开一个证明，比如找权威机构“敏捷的水”给开个介绍信，介绍信上给加个公章。那么这里的介绍性就是数字证书, 公章就是数字签名, 那么"敏捷的水"就是颁发证书的机构CA(Certificate Authority)，也就是证书授权中心。

CA CA 是“Certificate Authority”的缩写，也叫“证书授权中心”。
它是负责管理和签发证书的第三方机构，就好比例子里面的“敏捷的水”。一般来说，CA 必须是大家都信任的、认可的。因此它必须具有足够的权威性。只有明明和丽丽都信任的人才能来证明，对吧？

CA证书: CA 证书，就是CA颁发的证书。

证书之间的信任关系: 用一个证书来证明另一个证书是真实可信。

证书信任链: 证书之间的信任关系，是可以嵌套的。比如，A 信任 A1，A1 信任 A2，A2 信任 A3......,这就是证书的信任链。只要你信任链上的第一个证书，那后续的证书，都是可以信任的。

根证书(Root Certificate): 下图，处于最顶上的树根位置的那个证书，就是“根证书”。除了根证书，其它证书都要依靠上一级的证书来证明自己。那谁来证明“根证书”？根证书自己证明自己，这时候我们用户就需要自己选择是否相信某个根证书。

根证书是整个证书体系安全的根本。如果某个证书体系中，根证书不再可信了，那么所有被根证书所信任的其它证书，也就不再可信了。　　

证书内容

我们看一下亚马逊的证书，当我们点击浏览器左边绿色的锁时，我们可以看到如下的证书。

我们挑重点的解释一下

• Issuer (证书的发布机构)
  指出是什么机构发布的这个证书，也就是指明这个证书是哪个公司创建的(只是创建证书，不是指证书的使用者)。对于上面的这个证书来说，就是指"Symantec Corporation"这个机构。
• Not valid before, Not valid after (证书的有效期)
• Public key (公钥)

这个我们在前面介绍公钥密码体制时介绍过，公钥是用来对消息进行加密的。

• Subject (主题)

这个证书是发布给谁的，或者说证书的所有者，一般是某个人或者某个公司名称、机构的名称、公司网站的网址等。

• Signature algorithm (签名所使用的算法)

就是指的这个数字证书的数字签名所使用的加密算法，这样就可以使用证书发布机构的证书里面的公钥，根据这个算法对指纹进行解密，指纹的加密结果就是数字签名。

• Thumbprint, Thumbprint algorithm (指纹以及指纹算法)

这个是用来保证证书的完整性的，也就是说确保证书没有被修改过，其原理就是在发布证书时，发布者根据指纹算法(一个hash算法)计算整个证书的hash值(指纹)并和证书放在一起，使用者在打开证书时，自己也根据指纹算法计算一下证书的hash值(指纹)，如果两者一致，就说明证书没有被修改过，因为证书的内容被修改后，根据证书的内容计算的出的hash值(指纹)是会变化的。 注意，这个指纹会使用CA这个证书机构的私钥用签名算法(Signature algorithm)加密后和证书放在一起，只有用CA的公钥才能解开这个签名。

证书是如何保证身份认证的

申请证书：

1. Amazon.com 向Symantec 公司(CA) 申请证书。
2. Symantec(CA) 生成一对公钥A和私钥B。
3. Symantec(CA) 有自己的公钥C和私钥D。
4. Symantec(CA) 把Issuer,公钥A,Subject(一般是网站的域名),Valid from,Valid to等信息以明文的形式写到证书里面，然后用一个指纹算法(SHA1或者MD5
   )计算出这些数字证书内容的一个指纹(摘要)，并把指纹和指纹算法用自己的私钥D进行加密，然后和证书的内容一起发给Amazon.com。
5. Symantec(CA) 把私钥B给Amazon.com.

如何使用证书

1. 用户访问amazon.com 这个网站
2. amazon.com 把证书发给用户
3. 浏览器读取证书。
4. 浏览器发现证书机构是Symantec，然后会在操作系统中受信任的发布机构的证书中去找Symantec的证书，如果找不到，那说明证书的发布机构是个假的，或者不是被权威机构认证的，证书可能有问题，程序会给出一个错误信息。
5. 如果在系统中找到了Symantec的证书，那么应用程序就会从证书中取出Symantec的公钥C，然后对amzon.com公司的证书里面的指纹和指纹算法用这个公钥C进行解密，然后使用这个指纹算法计算amazon.com证书的指纹，将这个计算的指纹与放在证书中的指纹对比，如果一致，说明amazon.com的证书肯定没有被修改过并且证书是Symantec发布的，证书中的公钥肯定是amazon.com的公钥A, 然后我们就可以用这个公钥A和amazon.com进行通信，因为只有amazon.com 有私钥B, 所以只有amazon.com才能解开信息。

注意 权威机构的证书都是内置在操作系统里的。

由此可见，一个证书受不受信任，那就要看你要不要添加到操作系统里，权威的认证机构的证书都内置在操作系统里的。

另外，我们自己也可以制作自签名的证书，但是需要别人认可你，这个在企业内部或者开发阶段是可以，我们可以自己制作一个证书添加到操作系统里。

那么，问题来了，当你访问https://www.12306.cn 时，你就会得到下面的结果

这是为什么呢？

我相信你看完本文应该清楚，那是因为12306 自己给自己发了个证书，而这个证书默认是没有被操作系统信任，

但是当我把根证书添加到操作系统后，依然是https://www.12306.cn 不行，然后我发现是证书对应的域名不对,证书对应的域名是https://kyfw.12306.cn 访问这个域名后，虽然证书验证通过，但是浏览器的锁还是没有变绿。

为什么呢？ 看提示，是因为12306使用了一个比较弱的机密算法（This site uses a weak security configuration (SHA-1 signatures), so your connection may not be private.），我猜他们是为了性能？？

但是，就算浏览器地址栏的锁不能变绿，我们还得订票不是吗？

我觉得12306可能需要一个操作系统内置的认证机构来发一个证书，不然普通的用户根本不知道怎么安装证书，如果不使用https，那么安全性如何得到保证呢？

最后

回到开头的例子，明明和丽丽可以找一个权威机构来发一个证书，而且自己都内置了这个权威机构的证书。当王叔叔把丽丽的证书给明明时，明明就可以知道证书是不丽丽给的，因此就可以确定证书里的公钥是否是丽丽的，如果可以确定是丽丽的，那么就可以确保加密的内容只有丽丽可以解开，因为只有丽丽有对应的私钥。

程序员之网络安全系列（六）：动态密码

我们使用了数字证书，确保了对方的公钥身份，也就是互联网中确定了要访问的网站就是你要访问的网站。

但是我们如何确定要访问这个网站的用户就是要访问的用户呢？ 对银行来说需要确保“敏捷的水”登录银行时，必须是"敏捷的水" 而不是别人，不然别人就把钱转走了。

虽然我们从通信，数据加密等方式确保用户密码不背攻击者破解，但是如果攻击者使用键盘记录器等工具知道了用户密码，那么就可以冒充用户了。

比如银行的U盾，因为我对这块业务不了解，我猜银行为每个用户发放了一个公钥？（ 知道的同学，可以帮忙解释一下银行的U盾都做了什么? )

我们用数字证书确定了银行的身份，那么银行如何确定我们的身份呢？

两步验证

那么什么是两步认证呢？两步认证就是在每次登陆时候填一个手机短信收取的验证码或者手机应用生成的验证码。当然接收验证码的手机号或者应用是需要绑定的，这样只有拿到这部手机并且知道你帐号密码的人才能登陆帐号。

为什么需要它？

对有些人来说，盗取密码比您想象的更简单

以下任意一种常见操作都可能让您面临密码被盗的风险：

• 在多个网站上使用同一密码
• 从互联网上下载软件
• 点击电子邮件中的链接

想像一下您无法访问自己的帐户及其中的内容，当别有用心的人盗取您的密码后，他们能让您无法访问自己的帐户，还可以执行以下操作：

• 翻看（甚至删除）您所有的电子邮件、联系人、照片等
• 冒充您给您的联系人发送垃圾邮件或有害的电子邮件
• 使用您的帐户重置您其他帐户（银行帐户、购物帐户等）的密码

两步验证可以将别有用心的人阻挡在外，即使他们知道您的密码也无可奈何。

如何工作？

现在大部分比较危险的操作都需要绑定手机号，因为手机号是你用的唯一的。接收到验证码后，我们再输入系统做第二次的验证。

但是由于我们这个验证码也有可能丢失，那么我们只需要让他在一定时间有效就可以了，这就是OTP.

动态口令 (One Time Password)

动态密码： 一个OTP(One Time Password) 是一个密码仅用于一次登录会话或者交易，使用过后，这个密码就无效了。

静态密码的问题：

• 容易被破解
• 容易被猜测
• 容易被盗劫
• 针对不同的网站，用户需要记忆大量的密码。

使用动态口令主要有2个方面价值：

• 防止由于盗号而产生的财产损失。
• 采用动态口令的单位无需忍受定期修改各种应用系统登录密码的烦恼。

有两种方法，生成动态密码：

Event-based OTP (EOTP)

基于事件同步的令牌，其原理是通过某一特定的事件次序及相同的种子值作为输入，在DES算法中运算出一致的密码，其运算机理决定了其整个工作流程同时钟无关，不受时钟的影响，令牌中不存在时间脉冲晶振。但由于其算法的一致性，其口令是预先可知的，通过令牌，你可以预先知道今后的多个密码，故当令牌遗失且没有使用PIN码对令牌进行保护时，存在非法登陆的风险，故使用事件同步的令牌，对PIN码的保护是十分必要的。同样，基于事件同步的令牌同样存在失去同步的风险，例如用户多次无目的的生成口令等，对于令牌的失步，事件同步的服务器使用增大偏移量的方式进行再同步，其服务器端会自动向后推算一定次数的密码，来同步令牌和服务器，当失步情况已经非常严重，大范围超出正常范围时，通过连续输入两次令牌计算出的密码，服务器将在较大的范围内进行令牌同步，一般情况下，令牌同步所需的次数不会超过3次。但在极端情况下，不排除失去同步的可能性，例如电力耗尽，在更换电池时操作失误等。此时，令牌仍可通过手工输入由管理员生成的一组序列值来实现远程同步，而无需寄回服务器端重新同步。

Time based OTP (TOTP)

基于令牌和服务器的时间同步，通过运算来生成一致的动态口令，基于时间同步的令牌，一般更新率为60S，每60S产生一个新口令，但由于其同步的基础是国际标准时间，则要求其服务器能够十分精确的保持正确的时钟，同时对其令牌的晶振频率有严格的要求，从而降低系统失去同步的几率，从另一方面，基于时间同步的令牌在每次进行认证时，服务器端将会检测令牌的时钟偏移量，相应不断的微调自己的时间记录，从而保证了令牌和服务器的同步，确保日常的使用，但由于令牌的工作环境不同，在磁场，高温，高压，震荡，入水等情况下易发生时钟脉冲的不确定偏移和损坏，故对于时间同步的设备进行较好的保护是十分必要的。对于失去时间同步的令牌，目前可以通过增大偏移量的技术（前后10分钟）来进行远程同步，确保其能够继续使用，降低对应用的影响，但对于超出默认时间（共20分钟）的同步令牌，将无法继续使用或进行远程同步，必须返厂或送回服务器端另行处理。同样，对于基于时间同步的服务器，应较好地保护其系统时钟，不要随意更改，以免发生同步问题，从而影响全部基于此服务器进行认证的令牌。

** 以上两种方式在生成密码的过程都不需要与服务器通信，所以极大的保证了密码的安全。**

算法的实现

http://tools.ietf.org/html/rfc6238