标签:
假如,明明和丽丽相互不认识,明明想给丽丽写一封情书,让隔壁老王送去
大家都知道最近几年闹的沸沸扬扬的网络安全事件,之前的CSDN密码泄露,不久前的网易邮箱密码泄露,那么如果你的密码泄露,除了本身的网站外,还有很多人其它很多地方甚至银行密码都使用相同的密码,从而带来了很大的麻烦,据说“半个” 互联网的库都被人拖过。
拿我自己经历的一件事来说,前不久,我和一个朋友一起定了趟机票去上海,出发前两小时,收到一个短信说我预定的航班由于天气原因被取消,我需要改签另一个航班,让我拨打航空公司400的电话,由于马上要出发去机场,也没有去查具体航空公司的电话,就打了这个电话,对方的整套系统客服系统和流程几乎和航空公司一模一样,知道我的姓名,身份证,订的航班号等等都一清二楚,最后再说改签需要给用户补偿,需要给你转钱,所以你需要提供银行卡号,然后确认后才能改签,我这样说大家可能觉得如果是自己不太可能上当,但是你们都忽略了人的心里因素,第一你的私密信息他都知道(就像一个陌生人让你爸转钱说你需要钱,说是你的好朋友,知道你的所有只有你爸和你知道的信息), 第二你很着急,因为你在目的地的酒店已定,后面去别的地方的机票、火车票已定,所以你必须这个时间起飞等等。
最后我没有上当的原因,是因为我问骗子,航站楼是哪一个,他说是4号航站楼,因为西安就没有4号航站楼,当然这个应该是骗子的失误。
我们所有的人觉得自己百分之百不会上当的人,那是因为你没碰上骗子高手!
我总结了大部分骗子能够骗成功的最主要的原因,是因为我们的私密信息被泄露了!可见网络安全的重要性,而针对我的这个事件,我不知道是航空公司还是某订票网站把我的信息泄露,当然,骗子可能组合多个地方的泄露信息。
而这些信息系统是谁开发和维护的呢? 是程序员!
所以我们程序员需要学习安全知识,保护用户数据,同时防止自己被骗,对那些安全性不高的网站尽量不要使用,对那些安全不高的系统尽量不使用。
作为一个多年的程序员,我对网络安全相关的知识也非常少,我知道一些常规的东西,比如敏感数据加密存储,网站尽量使用https等,但是由于对后面的原理知道的太少,所以有的时候不一定做出了正确地选择,直到最近有的程序员说密码MD5存储了,就一定是安全的,这让我感觉了害怕,而且我看有的系统也真的只是MD5了一下,所以我开始决定学点安全的常识,记录一点“大家” 常用的程序安全知识, 在这里和大家共同进步,由于我对这对理解的不深,要学习的东西很多,所以也希望大家帮忙指出错误的地方。
在很多网站的早期,甚至是现在仍然有一些网站,当你点击忘记密码功能时,你的邮箱会收到一封邮件,然后里面赫然写着你的密码,很多普通用户还会觉得庆幸,总算是找回来了,殊不知,这是多么可怕地一件事,说明了网站是“几乎是”明文存储你的密码,一旦数据用户数据泄露或者被拖库,那么用户密码将赤裸裸的暴露了,想想之前几次互联网密码泄露事件。
那么如何解决呢?
为了不让密码明文存储,我们需要对密码进行加密,这样即使数据库用户密码暴露,也是加密后的。但是如何让加密后的数据难以解密呢?我们现在比较流行的做法就是把密码进行Hash存储。
哈希算法将任意长度的二进制值映射为较短的固定长度的二进制值,这个小的二进制值称为哈希值。哈希值是一段数据唯一且极其紧凑的数值表示形式. 典型的哈希算法包括 MD2、MD4、MD5 和 SHA-1
Hash算法是给消息生成摘要,那么什么是摘要呢?
举个例子:
比如你给你女朋友写了一封邮件,确保没被人改过,你可以生成这样一份摘要 “第50个字是我,第100个字是爱, 第998个字是你”,那么你女朋友收到这个摘要,检查一下你的邮件就可以了。
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的密码后,攻击者也可以通过比对的方式,比如你的密码是4218
2
.2.3:008
>
putsDigest::MD5.hexdigest(‘4218‘)
d278df4919453195d221030324127a0e
那么攻击者可以把1到4218个数字都MD5一下,然后和你密码的MD5对比一下,就知道你原密码是什么了。
曾经我的密码箱密码忘了,我把锁给撬了,后来我才想起可以用穷举法,最多就999次不就打开了?那么问题来了,你的密码箱还安全吗?
除了穷举法外,由于之前的密码泄露,那么攻击者们,手上都有大量的彩虹表,比如"I love you",生日等等,这个表保存了这些原值以及MD5后的值,那么使用时直接从已有库里就可以查出来对应的密码。
那么,由于简单的对密码进行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
}
由于这个是写给程序员,当然是说在前端用户注册时密码应该如何设置,很简单,我们要求用户必须输入强密码!但是,我知道很多用户觉得很烦,这样你就失掉了一个用户,但我们需要做一个适当的折中,比如至少有一个大写字母,小写字母和数字的组合。
我们来看看解决了之前文章下面例子的什么问题。
假如,明明和丽丽相互不认识,明明想给丽丽写一封情书,让隔壁老王送去
通过了解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由于只有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 =
newbyte
[] {
1,
2,
3,
4,
5,
6,
7,
8};
using
(MemoryStream ms =
newMemoryStream())
{
using
(RijndaelManaged AES =
newRijndaelManaged())
{
AES.KeySize =
256;
AES.BlockSize =
128;
var
key =
newRfc2898DeriveBytes(passwordBytes, saltBytes,
1000);
AES.Key = key.GetBytes(AES.KeySize /
8);
AES.IV = key.GetBytes(AES.BlockSize /
8);
AES.Mode = CipherMode.CBC;
using
(
varcs =
newCryptoStream(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 =
newbyte
[] {
1,
2,
3,
4,
5,
6,
7,
8};
using
(MemoryStream ms =
newMemoryStream())
{
using
(RijndaelManaged AES =
newRijndaelManaged())
{
AES.KeySize =
256;
AES.BlockSize =
128;
var
key =
newRfc2898DeriveBytes(passwordBytes, saltBytes,
1000);
AES.Key = key.GetBytes(AES.KeySize /
8);
AES.IV = key.GetBytes(AES.BlockSize /
8);
AES.Mode = CipherMode.CBC;
using
(
varcs =
newCryptoStream(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;
}
}
}
我们对数据进行了加密
但是上面的问题是明明和丽丽必须提前知道秘钥,但是如果双方提前不知道秘钥,那么明明就需要“隔壁的王叔叔" 把秘钥告诉丽丽,这个显然是风险太大了,因为”隔壁王叔叔“有了秘钥和密文,那么就等于有了明文。
1976年,美国学者Dime和Henman为解决信息公开传送和密钥管理问题,提出一种新的密钥交换协议,允许在不安全的媒体上的通讯双方交换信息,安全地达成一致的密钥,这就是“公开密钥系统”。相对于“对称加密算法”这种方法也叫做“非对称加密算法”。
与对称加密算法不同,非对称加密算法需要两个密钥:公开密钥(publickey)和私有密钥(privatekey)。公开密钥与私有密钥是一对,如果用公开密钥对数据进行加密,只有用对应的私有密钥才能解密;如果用私有密钥对数据进行加密,那么只有用对应的公开密钥才能解密。因为加密和解密使用的是两个不同的密钥,所以这种算法叫作非对称加密算法。
4.
YA=a^XA mod p=
5^
36mod
97=
50
5.
YB=a^XB mod p=
5^
58mod
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算法对数进行了加密,那么如果王叔叔在交换秘钥的过程中做了手脚呢?
如何做手脚?看下图:
至此,邮件内容又赤裸裸地被王叔叔看到了,怎么办呢?我们下文继续解释。
上面几步还是不够的,比如王叔叔在交换秘钥的过程中做了手脚呢?
如何做手脚?看下图:
那么明明如何知道王叔叔给的公钥就是丽丽的公钥呢?那么就引入了数字证书
那么王叔叔要让明明相信他给的公钥就是丽丽的公钥,那么他可以开一个证明,比如找权威机构“敏捷的水”给开个介绍信,介绍信上给加个公章。那么这里的介绍性就是数字证书, 公章就是数字签名, 那么"敏捷的水"就是颁发证书的机构CA(Certificate Authority),也就是证书授权中心。
CA CA
是“Certificate Authority”的缩写,也叫“证书授权中心”。
它是负责管理和签发证书的第三方机构,就好比例子里面的“敏捷的水”。一般来说,CA
必须是大家都信任的、认可的。因此它必须具有足够的权威性。只有明明和丽丽都信任的人才能来证明,对吧?
CA证书: CA 证书,就是CA颁发的证书。
证书之间的信任关系: 用一个证书来证明另一个证书是真实可信。
证书信任链: 证书之间的信任关系,是可以嵌套的。比如,A 信任 A1,A1 信任 A2,A2 信任 A3......,这就是证书的信任链。只要你信任链上的第一个证书,那后续的证书,都是可以信任的。
根证书(Root Certificate): 下图,处于最顶上的树根位置的那个证书,就是“根证书”。除了根证书,其它证书都要依靠上一级的证书来证明自己。那谁来证明“根证书”?根证书自己证明自己,这时候我们用户就需要自己选择是否相信某个根证书。
根证书是整个证书体系安全的根本。如果某个证书体系中,根证书不再可信了,那么所有被根证书所信任的其它证书,也就不再可信了。
我们看一下亚马逊的证书,当我们点击浏览器左边绿色的锁时,我们可以看到如下的证书。
我们挑重点的解释一下
这个我们在前面介绍公钥密码体制时介绍过,公钥是用来对消息进行加密的。
这个证书是发布给谁的,或者说证书的所有者,一般是某个人或者某个公司名称、机构的名称、公司网站的网址等。
就是指的这个数字证书的数字签名所使用的加密算法,这样就可以使用证书发布机构的证书里面的公钥,根据这个算法对指纹进行解密,指纹的加密结果就是数字签名。
这个是用来保证证书的完整性的,也就是说确保证书没有被修改过,其原理就是在发布证书时,发布者根据指纹算法(一个hash算法)计算整个证书的hash值(指纹)并和证书放在一起,使用者在打开证书时,自己也根据指纹算法计算一下证书的hash值(指纹),如果两者一致,就说明证书没有被修改过,因为证书的内容被修改后,根据证书的内容计算的出的hash值(指纹)是会变化的。 注意,这个指纹会使用CA这个证书机构的私钥用签名算法(Signature algorithm)加密后和证书放在一起,只有用CA的公钥才能解开这个签名。
注意 权威机构的证书都是内置在操作系统里的。
由此可见,一个证书受不受信任,那就要看你要不要添加到操作系统里,权威的认证机构的证书都内置在操作系统里的。
另外,我们自己也可以制作自签名的证书,但是需要别人认可你,这个在企业内部或者开发阶段是可以,我们可以自己制作一个证书添加到操作系统里。
那么,问题来了,当你访问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.
动态密码: 一个OTP(One Time Password) 是一个密码仅用于一次登录会话或者交易,使用过后,这个密码就无效了。
静态密码的问题:
使用动态口令主要有2个方面价值:
有两种方法,生成动态密码:
基于事件同步的令牌,其原理是通过某一特定的事件次序及相同的种子值作为输入,在DES算法中运算出一致的密码,其运算机理决定了其整个工作流程同时钟无关,不受时钟的影响,令牌中不存在时间脉冲晶振。但由于其算法的一致性,其口令是预先可知的,通过令牌,你可以预先知道今后的多个密码,故当令牌遗失且没有使用PIN码对令牌进行保护时,存在非法登陆的风险,故使用事件同步的令牌,对PIN码的保护是十分必要的。同样,基于事件同步的令牌同样存在失去同步的风险,例如用户多次无目的的生成口令等,对于令牌的失步,事件同步的服务器使用增大偏移量的方式进行再同步,其服务器端会自动向后推算一定次数的密码,来同步令牌和服务器,当失步情况已经非常严重,大范围超出正常范围时,通过连续输入两次令牌计算出的密码,服务器将在较大的范围内进行令牌同步,一般情况下,令牌同步所需的次数不会超过3次。但在极端情况下,不排除失去同步的可能性,例如电力耗尽,在更换电池时操作失误等。此时,令牌仍可通过手工输入由管理员生成的一组序列值来实现远程同步,而无需寄回服务器端重新同步。
基于令牌和服务器的时间同步,通过运算来生成一致的动态口令,基于时间同步的令牌,一般更新率为60S,每60S产生一个新口令,但由于其同步的基础是国际标准时间,则要求其服务器能够十分精确的保持正确的时钟,同时对其令牌的晶振频率有严格的要求,从而降低系统失去同步的几率,从另一方面,基于时间同步的令牌在每次进行认证时,服务器端将会检测令牌的时钟偏移量,相应不断的微调自己的时间记录,从而保证了令牌和服务器的同步,确保日常的使用,但由于令牌的工作环境不同,在磁场,高温,高压,震荡,入水等情况下易发生时钟脉冲的不确定偏移和损坏,故对于时间同步的设备进行较好的保护是十分必要的。对于失去时间同步的令牌,目前可以通过增大偏移量的技术(前后10分钟)来进行远程同步,确保其能够继续使用,降低对应用的影响,但对于超出默认时间(共20分钟)的同步令牌,将无法继续使用或进行远程同步,必须返厂或送回服务器端另行处理。同样,对于基于时间同步的服务器,应较好地保护其系统时钟,不要随意更改,以免发生同步问题,从而影响全部基于此服务器进行认证的令牌。
** 以上两种方式在生成密码的过程都不需要与服务器通信,所以极大的保证了密码的安全。**
http://tools.ietf.org/html/rfc6238
标签:
原文地址:http://www.cnblogs.com/snowbook/p/5345874.html