webrsa加密
① web前端的数据如何加密
前端数据一般都需要在后台使用的所以必须要用可逆的加密方式 现在比较流行的就是非对称的加密方式比如RSA 具体方法是生成两个秘钥 公钥 私钥 前端使用js（可以网络下载）把数据利用公钥进行加密 加密结果传给后端 后端利用私钥解密方法对数据进行解密
② 常见密码技术简介
##
密码技术在网络传输安全上的应用
随着互联网电子商务和网络支付的飞速发展，互联网安全已经是当前最重要的因素之一。作为一名合格的软件开发工程师，有必要了解整个互联网是如何来保证数据的安全传输的，本篇文章对网络传输安全体系以及涉及到的算法知识做了一个简要的介绍，希望大家能够有一个初步的了解。
###密码技术定义
简单的理解，密码技术就是编制密码和破译密码的一门技术，也即是我们常说的加密和解密。常见的结构如图：
其中涉及到的专业术语：
1.秘钥：分为加密秘钥和解密秘钥，两者相同的加密算法称为对称加密，不同的称为非对称加密；
2.明文：未加密过的原文信息，不可以被泄露；
3.密文：经过加密处理后的信息，无法从中获取有效的明文信息；
4.加密：明文转成密文的过程，密文的长度根据不同的加密算法也会有不同的增量；
5.解密：密文转成明文的过程；
6.加密/解密算法：密码系统使用的加密方法和解密方法；
7.攻击：通过截获数据流、钓鱼、木马、穷举等方式最终获取秘钥和明文的手段。
###密码技术和我们的工作生活息息相关
在我们的日常生活和工作中，密码技术的应用随处可见，尤其是在互联网系统上。下面列举几张比较有代表性的图片，所涉及到的知识点后面都会一一讲解到。
1.12306旧版网站每次访问时，浏览器一般会提示一个警告，是什么原因导致的？ 这样有什么风险呢？
2.360浏览器浏览HTTPS网站时，点开地址栏的小锁图标会显示加密的详细信息，比如网络的话会显示```AES_128_GCM、ECDHE_RSA```，这些是什么意思？
3.在Mac系统的钥匙串里有很多的系统根证书，展开后有非常多的信息，这些是做什么用的？
4.去银行开通网上支付都会附赠一个U盾，那U盾有什么用呢？
##如何确保网络数据的传输安全
接下来我们从实际场景出发，以最常见的客户端Client和服务端Server传输文件为例来一步步了解整个安全体系。
####1. 保密性
首先客户端要把文件送到服务端，不能以明文形式发送，否则被黑客截获了数据流很容易就获取到了整个文件。也就是文件必须要确保保密性，这就需要用到对称加密算法。
** 对称加密： **加密和解密所使用的秘钥相同称为对称加密。其特点是速度快、效率高，适用于对较大量的数据进行加密。常见的对称加密算法有DES、3DES、AES、TDEA、RC5等，让我们了解下最常见的3DES和AES算法：
** DES(Data Encryption Standard)： **1972年由美国IBM研制，数学原理是将明文以8字节分组（不足8位可以有不同模式的填充补位），通过数学置换和逆置换得到加密结果，密文和明文长度基本相同。秘钥长度为8个字节，后有了更安全的一个变形，使用3条秘钥进行三次加密，也就是3DES加密。
**3DES：**可以理解为对明文进行了三次DES加密，增强了安全程度。
** AES(Advanced Encryption Standard)： **2001年由美国发布，2002年成为有效标准，2006年成为最流行的对称加密算法之一。由于安全程度更高，正在逐步替代3DES算法。其明文分组长度为16字节，秘钥长度可以为16、24、32(128、192、256位)字节，根据秘钥长度，算法被称为AES-128、AES-192和AES-256。
对称加密算法的入参基本类似，都是明文、秘钥和模式三个参数。可以通过网站进行模拟测试：[http://tool.chacuo.net/crypt3des]()。其中的模式我们主要了解下ECB和CBC两种简单模式，其它有兴趣可自行查阅。
** ECB模式(Electronic Codebook Book)： **这种模式是将明文分成若干小段，然后对每一段进行单独的加密，每一段之间不受影响，可以单独的对某几段密文进行解密。
** CBC模式(Cipher Block Chaining)： **这种模式是将明文分成若干小段，然后每一段都会和初始向量(上图的iv偏移量)或者上一段的密文进行异或运算后再进行加密，不可以单独解密某一断密文。
** 填充补位： **常用为PKCS5Padding，规则为缺几位就在后面补几位的所缺位数。，比如明文数据为```/x01/x01/x01/x01/x01/x01```6个字节，缺2位补```/x02```，补完位```/x01/x01/x01/x01/x01/x01/x02/x02```。解密后也会按照这个规则进行逆处理。需要注意的是：明文为8位时也需要在后面补充8个```/x08```。
####2. 真实性
客户端有了对称秘钥，就需要考虑如何将秘钥送到服务端，问题跟上面一样：不能以明文形式直接传输，否则还是会被黑客截获到。这里就需要用到非对称加密算法。
** 非对称加密： **加密和解密秘钥不同，分别称为公开秘钥(publicKey)和私有秘钥(privateKey)。两者成对出现，公钥加密只能用私钥解密，而私钥加密也只能用公钥加密。两者不同的是：公钥是公开的，可以随意提供给任何人，而私钥必须保密。特点是保密性好，但是加密速度慢。常见的非对称加密算法有RSA、ECC等；我们了解下常见的RSA算法：
** RSA(Ron Rivest、Adi Shamir、Leonard Adleman)： **1977年由麻省理工学院三人提出，RSA就是他们三个人的姓氏开头字母拼在一起组成的。数学原理是基于大数分解。类似于```100=20x5```，如果只知道100的话，需要多次计算才可以试出20和5两个因子。如果100改为极大的一个数，就非常难去试出真正的结果了。下面是随机生成的一对公私钥:
这是使用公钥加密后结果：
RSA的这种特性就可以保证私钥持有者的真实性，客户端使用公钥加密文件后，黑客就算截获到数据因为没有私钥也是无法解密的。
** Tips： **
+** 不使用对称加密，直接用RSA公私钥进行加密和解密可以吗？ **
答案：不可以，第一是因为RSA加密速度比对称加密要慢几十倍甚至几百倍以上，第二是因为RSA加密后的数据量会变大很多。
+** 由服务端生成对称秘钥，然后用私钥加密，客户端用公钥解密这样来保证对称秘钥安全可行吗？ **
答案：不可行，因为公钥是公开的，任何一个人都可以拿到公钥解密获取对称秘钥。
####3. 完整性
当客户端向服务端发送对称秘钥加密后的文件时，如果被黑客截获，虽然无法解密得到对称秘钥。但是黑客可以用服务端公钥加密一个假的对称秘钥，并用假的对称秘钥加密一份假文件发给服务端，这样服务端会仍然认为是真的客户端发送来的，而并不知道阅读的文件都已经是掉包的了。
这个问题就需要用到散列算法，也可以译为Hash。常见的比如MD4、MD5、SHA-1、SHA-2等。
** 散列算法(哈希算法)： **简单的说就是一种将任意长度的消息压缩到某一固定长度的消息摘要的函数。而且该过程是不可逆的，无法通过摘要获得原文。
** SHA-1(Secure Hash Algorithm 1)： **由美国提出，可以生成一个20字节长度的消息摘要。05年被发现了针对SHA-1的有效攻击方法，已经不再安全。2010年以后建议使用SHA-2和SHA-3替代SHA-1。
** SHA-2(Secure Hash Algorithm 2)： **其下又分为六个不同算法标准：SHA-224、SHA-256、SHA-384、SHA-512、SHA-512/224、SHA512/256。其后面数字为摘要结果的长度，越长的话碰撞几率越小。SHA-224的使用如下图：
客户端通过上面的散列算法可以获取文件的摘要消息，然后用客户端私钥加密后连同加密的文件发给服务端。黑客截获到数据后，他没有服务端私钥无法获取到对称秘钥，也没有客户端私钥无法伪造摘要消息。如果再像上面一样去掉包文件，服务端收到解密得到摘要消息一对比就可以知道文件已经被掉包篡改过了。
这种用私钥对摘要消息进行加密的过程称之为数字签名，它就解决了文件是否被篡改问题，也同时可以确定发送者身份。通常这么定义：
** 加密： **用公钥加密数据时称为加密。
** 签名： **用私钥加密数据时称为签名。
####4. 信任性
我们通过对称加密算法加密文件，通过非对称加密传输对称秘钥，再通过散列算法保证文件没被篡改过和发送者身份。这样就安全了吗？
答案是否定的，因为公钥是要通过网络送到对方的。在这期间如果出现问题会导致客户端收到的公钥并不一定是服务端的真实公钥。常见的** 中间人攻击 **就是例子：
** 中间人攻击MITM(Man-in-the-MiddleAttack)： **攻击者伪装成代理服务器，在服务端发送公钥证书时，篡改成攻击者的。然后收到客户端数据后使用攻击者私钥解密，再篡改后使用攻击者私钥签名并且将攻击者的公钥证书发送给服务器。这样攻击者就可以同时欺骗双方获取到明文。
这个风险就需要通过CA机构对公钥证书进行数字签名绑定公钥和公钥所属人，也就是PKI体系。
** PKI(Privilege Management Infrastructure)： **支持公钥管理并能支持认证、加密、完整性和可追究性的基础设施。可以说整个互联网数据传输都是通过PKI体系进行安全保证的。
** CA(Certificate Authority)： **CA机构就是负责颁发证书的，是一个比较公认的权威的证书发布机构。CA有一个管理标准：WebTrust。只有通过WebTrust国际安全审计认证，根证书才能预装到主流的浏览器而成为一个全球可信的认证机构。比如美国的GlobalSign、VeriSign、DigiCert，加拿大的Entrust。我国的CA金融方面由中国人民银行管理CFCA，非金融CA方面最初由中国电信负责建设。
CA证书申请流程：公司提交相应材料后，CA机构会提供给公司一张证书和其私钥。会把Issuer,Public key,Subject,Valid from,Valid to等信息以明文的形式写到证书里面，然后用一个指纹算法计算出这些数字证书内容的一个指纹，并把指纹和指纹算法用自己的私钥进行加密。由于浏览器基本都内置了CA机构的根证书，所以可以正确的验证公司证书指纹（验签），就不会有安全警告了。
但是：所有的公司其实都可以发布证书，甚至我们个人都可以随意的去发布证书。但是由于浏览器没有内置我们的根证书，当客户端浏览器收到我们个人发布的证书后，找不到根证书进行验签，浏览器就会直接警告提示，这就是之前12306打开会有警告的原因。这种个人发布的证书，其实可以通过系统设置为受信任的证书去消除这个警告。但是由于这种证书机构的权威性和安全性难以信任，大家最好不要这么做。
我们看一下网络HTTPS的证书信息：
其中比较重要的信息：
签发机构：GlobalSign Root CA；
有效日期：2018-04-03到2019-05-26之间可用；
公钥信息：RSA加密，2048位；
数字签名：带 RSA 加密的 SHA-256 ( 1.2.840.113549.1.1.11 )
绑定域名：再进行HTTPS验证时，如果当前域名和证书绑定域名不一致，也会出现警告；
URI：在线管理地址。如果当前私钥出现了风险，CA机构可以在线吊销该证书。
####5. 不可抵赖性
看起来整个过程都很安全了，但是仍存在一种风险：服务端签名后拒不承认，归咎于故障不履行合同怎么办。
解决方法是采用数字时间戳服务：DTS。
** DTS(digital time-stamp)： **作用就是对于成功的电子商务应用，要求参与交易各方不能否认其行为。一般来说，数字时间戳产生的过程为：用户首先将需要加时间戳的文件用Hash算法运算形成摘要，然后将该摘要发送到DTS。DTS在加入了收到文件摘要的日期和事件信息后再对该文件进行数字签名，然后送达用户。
####6. 再次认证
我们有了数字证书保证了身份的真实性，又有了DTS提供的不可抵赖性。但是还是不能百分百确定使用私钥的就是合法持有者。有可能出现被别人盗用私钥进行交易的风险。
解决这个就需要用到强口令、认证令牌OTP、智能卡、U盾或生物特征等技术对使用私钥的当前用户进行认证，已确定其合法性。我们简单了解下很常见的U盾。
** USB Key(U盾)： **刚出现时外形比较像U盘，安全性能像一面盾牌，取名U盾。其内部有一个只可写不可读的区域存储着用户的私钥(也有公钥证书)，银行同样也拥有一份。当进行交易时，所有涉及到私钥的运算都在U盾内部进行，私钥不会泄露。当交易确认时，交易的详细数据会显示到U盾屏幕上，确认无误后通过物理按键确认就可以成功交易了。就算出现问题黑客也是无法控制U盾的物理按键的，用户可以及时取消避免损失。有的U盾里面还有多份证书，来支持国密算法。
** 国密算法： **国家密码局针对各种算法制定了一些列国产密码算法。具体包括：SM1对称加密算法、SM2公钥算法、SM3摘要算法、SM4对称加密算法、ZUC祖冲之算法等。这样可以对国产固件安全和数据安全进行进一步的安全控制。
## HTTPS分析
有了上面的知识，我们可以尝试去分析下HTTPS的整个过程，用Wireshark截取一次HTTPS报文：
Client Hello: 客户端发送Hello到服务端443端口，里面包含了随机数、客户端支持的加密算法、客户端的TLS版本号等；
Server Hello: 服务端回应Hello到客户端，里面包含了服务端选择的加密套件、随机数等；
Certificate： 服务端向客户端发送证书
服务端计算对称秘钥：通过ECDH算法得到对称秘钥
客户端计算对称秘钥：通过ECDH算法得到对称秘钥
开始用对称秘钥进行加密传输数据
其中我们又遇到了新的算法：DH算法
** DH(Diffie-Hellman)： **1976年由Whitefield与Martin Hellman提出的一个奇妙的秘钥交换协议。这个机制的巧妙在于可以通过安全的方式使双方获得一个相同的秘钥。数学原理是基于原根的性质，如图：
*** DH算法的用处不是为了加密或解密消息，而是用于通信双方安全的交换一个相同的秘钥。 ***
** ECDH： **基于ECC(椭圆曲线密码体制)的DH秘钥交换算法，数学原理是基于椭圆曲线上的离散对数问题。
** ECDHE： **字面少了一个E，E代表了临时。在握手流程中，作为服务器端，ECDH使用证书公钥代替Pb，使用自身私钥代替Xb。这个算法时服务器不发送server key exchange报文，因为发送certificate报文时，证书本身就包含了Pb信息。
##总结
| 算法名称 | 特点 | 用处 | 常用算法名 |
| --- | :--- | :---: | ---: |
| 对称加密 | 速度快，效率高| 用于直接加密文件 | 3DES、AES、RC4 |
| 非对称加密 | 速度相对慢，但是确保安全 | 构建CA体系 | RSA、ECC |
| 散列算法 | 算出的摘要长度固定，不可逆 | 防止文件篡改 | SHA-1、SHA-2 |
| DH算法 | 安全的推导出对称秘钥 | 交换对称秘钥 | ECDH |
----
③ 请教webservice安全和加密的方法
众所周知，WebService访问API是公开的，知道其URL者均可以研究与调用。那么，在只允许注册用户的WebService应用中，如何确保API访问和通信的安全性呢？本文所指的访问与通信安全性包括：
访问安全性：当前访问者是注册合法用户
通信安全性：客户端与服务器之间的消息即使被第三方窃取也不能解密
本文安全的基本思路是：
注册用户登录时使用RSA加密
Web API调用参数使用DES加密（速度快）
Web API调用中包含一个身份票据Ticket
Web服务器保存当前Ticket的Session，包括：Ticket、DES加密矢量、注册用户基本信息
1 WebService身份验证
确保注册用户的访问安全，需要如下步骤：1）产生一个当前客户端机器票据（Ticket）；2）请求服务器RSA公钥（RSAPublicKey）；3）使用RSA加密登录口令及发布DES加密矢量（DESCipherVector）。
1.1 产生客户端机器票据Ticket
一般而言，可以由客户端机器根据自己的MAC、CPU序列号等唯一标识产生一个本机器的Ticket字符串票据，其目的是：唯一标识当前客户端，防止其它机器模仿本客户端行为。
1.2 请求服务器公钥RSAPublicKey
客户端携带票据Ticket向服务器请求RSA公钥RSAPublicKey。在服务器端，一般采取如下策略产生RSA加密钥匙：
Application_Start时产生一个1024或更长的RSA加密钥匙对。如果服务器需要长久运行，那么Application_Start产生的RSA可能被破解，替代方案是在当前Session_Start时产生RSA加密钥匙对
保存当前票据对应的客户帐号对象，即：Session[Ticket] = AccountObject，在确认身份后在填写AccountObject具体内容：帐号、RSA加密钥匙对、DES加密矢量
完成上述步骤后，服务器将RSAPublicKey传回给客户端。
1.3 加密登录口令及DES加密矢量
客户端获得RSAPulbicKey后，产生自己的DES加密矢量DESCipherVector（至少要8位及以上，该加密矢量用于以后的常规通信消息加密，因为其速度比RSA快）。接着，客户端使用RSAPublicKey加密登录帐号、口令及DESCipherVector，连同Ticket，发送到服务器并请求身份验证。登录API格式如下：
public void Login(string Ticket, string cipherLongID, string cipherPassword)；
如果验证成功，服务器将当前帐号信息、RSA钥匙、DESCipherVector等保存到会话Session[Ticket]中。
2 WebService通信安全性
2.1 加密WebService API参数
身份确认后，在客户端调用的WebService API中，必须包括参数Ticket，其它参数则均使用DESCipherVector加密。服务器端返回的消息也同样处理。例如，提交一个修改email的函数定义为：
public void ModifyEmail(string Ticket, string cipherEmai)；
2.2 客户端解密消息
客户端接收到服务器返回消息后，先做解密操作，如果成功则进入下步处理。否则抛出加密信息异常。
2.3 服务器端解密消息
服务器接收到客户提交的API请求后，首先验证Ticket的合法性，即查找Session中是否有该票据以验证客户身份。然后，解密调用参数。如果成功则进入下不操作，否则返回操作异常消息给客户端。
需要指出，如果第三方截获全部会话消息，并保留其Ticket，此时服务器端仍然认可这个第三方消息。但是，第三方不能浏览，也不能修改调用API的参数内容，此时解密参数时将抛出异常。
上面探讨了一个基于加密的WebService访问与通信安全方法，即使第三方获取消息，不能查看原始内容，也不能修改内容，保证了WebService API的安全性。
④ 如何对web.config进行加密和解密
一、如何对Web.config中数据库连接字符串进行加解密，避免明文方式。 1)概述：
Web.Config 中可以存储数据库连接语句，通常存于 <connectionString>配置节中，程序调用非常方便，但是在系统的应用过程中，利用明文存储这些敏感信息是不安全的，这就需要对配置信息进行加密，加密后即使攻击者获取了对配置文件的访问，也可以使攻击者难以获取对敏感信息的访问，从而改进应用程序的安全性。
使用 ASP.NET IIS 注册工具 (Aspnet_regiis.exe) 加密或解密 Web 配置文件的各节。而在在处理 Web.config 文件时，ASP.NET 将自动解密已加密的配置元素。
要加密配置文件的内容， 通过Aspnet_regiis.exe 工具与 –pe 选项以及要加密的配置元素的名称一起使用，利用.NET Framework 提供的2种受保护配置程序来实现节点加解密：
名为的 实例使用 Windows 数据保护 API (DPAPI) 对数据进行加密和解密。
名为的 实例使用 RSA 加密算法对数据进行加密和解密。该提供程序配置为默认提供程序
下面就这2中加密方式，分别进行举例如下：
2)使用 来加解密配置节
利用aspnet_regiis -pef connectionStrings 对web.config 加密 在服务器命令提示符下，输入如下命令：
C:\Windows\Microsoft.NET\Framework\v2.0.50727>aspnet_regiis -pef connectionStrings D:\程序\某系统\EpointBid_HuiYuan –prov 正在加密配置节„ 成功！
-pef 指定两个参数：
这里 connectionStrings 是要进行加密的配置节，后面是具体的程序路径 这里 D:\程序\某系统\EpointBid_HuiYuan 是要加密的配置文件所在的物理目录。
-prov 表示使用哪个驱动来加密，一共有两个驱动可选，在类似于
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG 的位置，我们可以找到 machine.config 文件，在其 configProtectedData 配置节，我们可以看到这两个驱动的名称，以及默认的驱动是哪一个。这两个驱动是 （类名 ，详细操作见下说明示例）和
（类名 ）。
如果不加驱动选项，则采用默认驱动进行加密。
⑤ 一般网页中的用户名和登录密码在传输过程中是通过什么加密的
对于打开了某个论坛,输入了用户名和密码，其实如果网站设计者重视安全问题的话一般会对输入的用户名和密码进行加密，加密后的用户名和密码用一连串的字符表示，所以即使别人窃取了你的用户名和密码和密码，他们如果不知道怎么解密，他们只能得到一连串的字符，所以这也是一道防线。
接下来就是网络安全方面的问题：
数据加密(Data Encryption)技术
所谓加密(Encryption)是指将一个信息(或称明文--plaintext) 经过加密钥匙(Encrypt ionkey)及加密函数转换,变成无意义的密文( ciphertext),而接收方则将此密文经过解密函数、解密钥匙(Decryti on key)还原成明文。加密技术是网络安全技术的基石。
数据加密技术要求只有在指定的用户或网络下,才能解除密码而获得原来的数据,这就需要给数据发送方和接受方以一些特殊的信息用于加解密,这就是所谓的密钥。其密钥的值是从大量的随机数中选取的。按加密算法分为专用密钥和公开密钥两种。
专用密钥,又称为对称密钥或单密钥,加密时使用同一个密钥,即同一个算法。如DES和MIT的Kerberos算法。单密钥是最简单方式,通信双方必须交换彼此密钥,当需给对方发信息时,用自己的加密密钥进行加密,而在接收方收到数据后,用对方所给的密钥进行解密。这种方式在与多方通信时因为需要保存很多密钥而变得很复杂,而且密钥本身的安全就是一个问题。
DES是一种数据分组的加密算法,它将数据分成长度为6 4位的数据块,其中8位用作奇偶校验,剩余的56位作为密码的长度。第一步将原文进行置换,得到6 4位的杂乱无章的数据组;第二步将其分成均等两段 ;第三步用加密函数进行变换,并在给定的密钥参数条件下,进行多次迭代而得到加密密文。
公开密钥,又称非对称密钥,加密时使用不同的密钥,即不同的算法,有一把公用的加密密钥,有多把解密密钥,如RSA算法。
在计算机网络中,加密可分为"通信加密"(即传输过程中的数据加密)和"文件加密"(即存储数据加密)。通信加密又有节点加密、链路加密和端--端加密3种。
①节点加密,从时间坐标来讲,它在信息被传入实际通信连接点 (Physical communication link)之前进行;从OSI 7层参考模型的坐标 (逻辑空间)来讲,它在第一层、第二层之间进行; 从实施对象来讲,是对相邻两节点之间传输的数据进行加密,不过它仅对报文加密,而不对报头加密,以便于传输路由的选择。
②链路加密(Link Encryption),它在数据链路层进行,是对相邻节点之间的链路上所传输的数据进行加密,不仅对数据加密还对报头加密。
③端--端加密(End-to-End Encryption),它在第六层或第七层进行 ,是为用户之间传送数据而提供的连续的保护。在始发节点上实施加密,在中介节点以密文形式传输,最后到达目的节点时才进行解密,这对防止拷贝网络软件和软件泄漏也很有效。
在OSI参考模型中,除会话层不能实施加密外,其他各层都可以实施一定的加密措施。但通常是在最高层上加密,即应用层上的每个应用都被密码编码进行修改,因此能对每个应用起到保密的作用,从而保护在应用层上的投资。假如在下面某一层上实施加密,如TCP层上,就只能对这层起到保护作用。
值得注意的是,能否切实有效地发挥加密机制的作用,关键的问题在于密钥的管理,包括密钥的生存、分发、安装、保管、使用以及作废全过程。
(1)数字签名
公开密钥的加密机制虽提供了良好的保密性,但难以鉴别发送者, 即任何得到公开密钥的人都可以生成和发送报文。数字签名机制提供了一种鉴别方法,以解决伪造、抵赖、冒充和篡改等问题。
数字签名一般采用不对称加密技术(如RSA),通过对整个明文进行某种变换,得到一个值,作为核实签名。接收者使用发送者的公开密钥对签名进行解密运算,如其结果为明文,则签名有效,证明对方的身份是真实的。当然,签名也可以采用多种方式,例如,将签名附在明文之后。数字签名普遍用于银行、电子贸易等。
数字签名不同于手写签字:数字签名随文本的变化而变化,手写签字反映某个人个性特征, 是不变的;数字签名与文本信息是不可分割的,而手写签字是附加在文本之后的,与文本信息是分离的。
(2)Kerberos系统
Kerberos系统是美国麻省理工学院为Athena工程而设计的,为分布式计算环境提供一种对用户双方进行验证的认证方法。
它的安全机制在于首先对发出请求的用户进行身份验证,确认其是否是合法的用户;如是合法的用户,再审核该用户是否有权对他所请求的服务或主机进行访问。从加密算法上来讲,其验证是建立在对称加密的基础上的。
Kerberos系统在分布式计算环境中得到了广泛的应用(如在Notes 中),这是因为它具有如下的特点:
①安全性高,Kerberos系统对用户的口令进行加密后作为用户的私钥,从而避免了用户的口令在网络上显示传输,使得窃听者难以在网络上取得相应的口令信息;
②透明性高,用户在使用过程中,仅在登录时要求输入口令,与平常的操作完全一样,Ker beros的存在对于合法用户来说是透明的;
③可扩展性好,Kerberos为每一个服务提供认证,确保应用的安全。
Kerberos系统和看电影的过程有些相似,不同的是只有事先在Ker beros系统中登录的客户才可以申请服务,并且Kerberos要求申请到入场券的客户就是到TGS(入场券分配服务器)去要求得到最终服务的客户。
Kerberos的认证协议过程如图二所示。
Kerberos有其优点，同时也有其缺点，主要如下：
①、Kerberos服务器与用户共享的秘密是用户的口令字,服务器在回应时不验证用户的真实性,假设只有合法用户拥有口令字。如攻击者记录申请回答报文,就易形成代码本攻击。
②、Kerberos服务器与用户共享的秘密是用户的口令字,服务器在回应时不验证用户的真实性,假设只有合法用户拥有口令字。如攻击者记录申请回答报文,就易形成代码本攻击。
③、AS和TGS是集中式管理,容易形成瓶颈,系统的性能和安全也严重依赖于AS和TGS的性能和安全。在AS和TGS前应该有访问控制,以增强AS和TGS的安全。
④、随用户数增加,密钥管理较复杂。Kerberos拥有每个用户的口令字的散列值,AS与TGS 负责户间通信密钥的分配。当N个用户想同时通信时,仍需要N*(N-1)/2个密钥
（ 3 ）、PGP算法
PGP(Pretty Good Privacy)是作者hil Zimmermann提出的方案, 从80年代中期开始编写的。公开密钥和分组密钥在同一个系统中,公开密钥采用RSA加密算法,实施对密钥的管理;分组密钥采用了IDEA算法,实施对信息的加密。
PGP应用程序的第一个特点是它的速度快,效率高;另一个显着特点就是它的可移植性出色,它可以在多种操作平台上运行。PGP主要具有加密文件、发送和接收加密的E-mail、数字签名等。
(4)、PEM算法
保密增强邮件(Private Enhanced Mail,PEM),是美国RSA实验室基于RSA和DES算法而开发的产品,其目的是为了增强个人的隐私功能, 目前在Internet网上得到了广泛的应用,专为E-mail用户提供如下两类安全服务:
对所有报文都提供诸如:验证、完整性、防抵 赖等安全服务功能; 提供可选的安全服务功能,如保密性等。
PEM对报文的处理经过如下过程:
第一步,作规范化处理:为了使PEM与MTA(报文传输代理)兼容,按S MTP协议对报文进行规范化处理;
第二步,MIC(Message Integrity Code)计算;
第三步,把处理过的报文转化为适于SMTP系统传输的格式。
身份验证技术
身份识别(Identification)是指定用户向系统出示自己的身份证明过程。身份认证(Authertication)是系统查核用户的身份证明的过程。人们常把这两项工作统称为身份验证(或身份鉴别),是判明和确认通信双方真实身份的两个重要环节。
Web网上采用的安全技术
在Web网上实现网络安全一般有SHTTP/HTTP和SSL两种方式。
（一）、SHTTP/HTTP
SHTTP/HTTP可以采用多种方式对信息进行封装。封装的内容包括加密、签名和基于MAC 的认证。并且一个消息可以被反复封装加密。此外,SHTTP还定义了包头信息来进行密钥传输、认证传输和相似的管理功能。SHTTP可以支持多种加密协议,还为程序员提供了灵活的编程环境。
SHTTP并不依赖于特定的密钥证明系统,它目前支持RSA、带内和带外以及Kerberos密钥交换。
（二）、SSL(安全套层) 安全套接层是一种利用公开密钥技术的工业标准。SSL广泛应用于Intranet和Internet 网,其产品包括由Netscape、Microsoft、IBM 、Open Market等公司提供的支持SSL的客户机和服务器,以及诸如Apa che-SSL等产品。
SSL提供三种基本的安全服务,它们都使用公开密钥技术。
①信息私密,通过使用公开密钥和对称密钥技术以达到信息私密。SSL客户机和SSL服务器之间的所有业务使用在SSL握手过程中建立的密钥和算法进行加密。这样就防止了某些用户通过使用IP packet sniffer工具非法窃听。尽管packet sniffer仍能捕捉到通信的内容, 但却无法破译。 ②信息完整性,确保SSL业务全部达到目的。如果Internet成为可行的电子商业平台,应确保服务器和客户机之间的信息内容免受破坏。SSL利用机密共享和hash函数组提供信息完整性服务。③相互认证,是客户机和服务器相互识别的过程。它们的识别号用公开密钥编码,并在SSL握手时交换各自的识别号。为了验证证明持有者是其合法用户(而不是冒名用户),SSL要求证明持有者在握手时对交换数据进行数字式标识。证明持有者对包括证明的所有信息数据进行标识以说明自己是证明的合法拥有者。这样就防止了其他用户冒名使用证明。证明本身并不提供认证,只有证明和密钥一起才起作用。 ④SSL的安全性服务对终端用户来讲做到尽可能透明。一般情况下,用户只需单击桌面上的一个按钮或联接就可以与SSL的主机相连。与标准的HTTP连接申请不同,一台支持SSL的典型网络主机接受SSL连接的默认端口是443而不是80。
当客户机连接该端口时,首先初始化握手协议,以建立一个SSL对话时段。握手结束后,将对通信加密,并检查信息完整性,直到这个对话时段结束为止。每个SSL对话时段只发生一次握手。相比之下,HTTP 的每一次连接都要执行一次握手,导致通信效率降低。一次SSL握手将发生以下事件:
1.客户机和服务器交换X.509证明以便双方相互确认。这个过程中可以交换全部的证明链,也可以选择只交换一些底层的证明。证明的验证包括:检验有效日期和验证证明的签名权限。
2.客户机随机地产生一组密钥,它们用于信息加密和MAC计算。这些密钥要先通过服务器的公开密钥加密再送往服务器。总共有四个密钥分别用于服务器到客户机以及客户机到服务器的通信。
3.信息加密算法(用于加密)和hash函数(用于确保信息完整性)是综合在一起使用的。Netscape的SSL实现方案是:客户机提供自己支持的所有算法清单,服务器选择它认为最有效的密码。服务器管理者可以使用或禁止某些特定的密码。
⑥ web渗透测试之攻破登录页面
当我们在做渗透测试时，无论厂商项目还是src众测项目，都会遇到给一堆登录系统的URL，然后让我们自己去测，能不能进去全看天的状况，本文将讲一下怎么突破这种封闭的web系统，从而进行更深层次的渗透 ，学完后你会发现，其实你就是系统管理员。
如果能直接绕过登录系统界面，后面的就比较好做了，目前常见的登录系统绕过方法有：
大部分情况下，系统登录页面都不存在xss，目录遍历，SQL注入等漏洞，这时候最常用的方法就是爆破和猜解登录口令，密码猜解最关键的就是字典要高效准确
https:// down.52pojie.cn/Tools/N etwork_Analyzer/Burp_Suite_Pro_v1.7.31_Loader_Keygen.zip
2.准确的用户名，密码字典是高效破解的重中之重 ，一般都是指定几个常见用户名 ，尝试 top500，top1000进行爆破 字典不必要太大，最重要的是针对性要强 ，下面是top1000：
链接: https:// pan..com/s/1-XztuB 8YTfpT5aUBVbmbzA 密码: 56pb
3.如果还是不能猜解成功，就要根据目标信息用字典生成器构造针对性的字典来猜解了，推 荐几个比较好的字典生成工具
pydictor：
LandGrey/pydictor
crunch:
crunch - wordlist generator
Cewl:
digininja/CeWL
Cupp:
Mebus/cupp
因为管理员权限较高，通常我都会先进行管理员口令的猜解，总结了一些常见的管理员用户名字典
<u>链接:</u> <u> https:// pan..com/s/1sOD1-u whnStaw_LfMOf-sQ </u><u>密码: 3yqe</u>
用此用户名字典，再加上弱口令top1000，同时爆破系统管理员用户名密码
链接: https:// pan..com/s/1-XztuB 8YTfpT5aUBVbmbzA 密码: 56pb
常见的普通用户用户名是姓名拼音，总结了普通用户字典
TOP3000姓名
<u>链接:</u> <u> https:// pan..com/s/1qN9kCF tymP4ugvu3FFkKbA </u><u>密码: hkzp</u>
TOP10w姓名
https:// github.com/rootphantome r/Blasting_dictionary/blob/master/top10W.txt
通常可以选择几个弱口令密码，比如：123456，123abc，111111，然后配合top10w来猜解登陆口令，一些初始化的默认密码也很简单，如果能找到配合top10w通常也能爆出登录口令
现在的业务系统口令传输到后端前都会进行加密处理 ，web常见的加密方式有 md5 加密、sha1 加密、RSA 加密，在此基础上总结了两种破解方式：
1.利用burpsuite的payload processing功能，把字典按照加密方式先加密再发包
2.用字典生成工具生成加密好的字典，然后burp直接加载加密字典
这里推荐的字典生成工具是pydictor，encode功能内置了多种加密算法，调用handler工具直接加密自己的明文字典
如果登录系统设置了IP地址白名单，我们可以通过下面的几个http头字段伪造IP地址，用burp抓包后将下面的某个http头字段加入数据包发送到服务器
<pre class="prettyprint hljs css" style="padding: 0.5em; font-family: Menlo, Monaco, Consolas, "Courier New", monospace; color: rgb(68, 68, 68); border-radius: 4px; display: block; margin: 0px 0px 1.5em; font-size: 14px; line-height: 1.5em; word-break: break-all; overflow-wrap: break-word; white-space: pre; background-color: rgb(246, 246, 246); border: none; overflow-x: auto;">Client-Ip: 127.0.0.1
X-Client-IP: 127.0.0.1
X-Real-IP: 127.0.0.1
True-Client-IP: 127.0.0.1
X-Originating-IP: 127.0.0.1
X-Forwarded-For: 127.0.0.1
X-Remote-IP: 127.0.0.1
X-Remote-Addr: 127.0.0.1
X-Forwarded-Host: 127.0.0.1</pre>
如果在系统登陆界面加上了验证码，那么上面的方法基本上就都失效了，那有什么方法可以绕过验证呢
1.图形验证码不刷新
在一段时间内只要不刷新页面，无论登录失败多少次都不刷新验证码，这个时候就可以使用同一个验证码根据上面的方式进行暴力破解
2.验证码失效
不管在验证码表单输入什么样的数据，都会判断通过，但这种情况很少见
3.图形验证码可被识别，抓包直接可以获得验证码
很多网站的验证码都可以在请求数据包中找到，或者隐藏在request的cookie中，response的源码中，可以利用burpsuite的macros来匹配response中的相应数据，具体的爆破方法参见下文：
burpsuite爆破密码（含验证码） - CSDN博客
4.图形验证码参数直接绕过
对于request数据: user=admin&pass=1234&vcode=brln，有两种绕过方法：
一是验证码空值绕过，改成 user=admin&pass=1234&vcode=；
一是直接删除验证码参数，改成 user=admin&pass=1234。
5.万能验证码
渗透测试的过程中，有时候会出现这种情况，系统存在一个万能验证码，如0000、9999，只要输入万能验证码，就可以无视验证码进行暴力破解。
6. 验证码可被识别
有些图形验证码加入的像素线条过于简单，使用图形验证码识别工具可以识别出每次更换的验证码，在平常的漏洞挖掘过程中，如果我们发现登录的验证码非常简单且易于识别，那我们就可以尝试使用自动化工具来进行登录破解了，如 PKAV 的 HTTP Fuzzer
7.使用机器学习算法识别验证码
主要是对特定网站的图形验证码训练识别模型，达到一定的准确率就可以调用进行模拟提交图形验证码的值了。可参考以下三篇文章进行学习：
使用KNN算法识别验证码:
http:// nlao.github.io/2016/0 9/22/%E9%AA%8C%E8%AF%81%E7%A0%81%E7%A0%B4%E8%A7%A3%E6%8A%80%E6%9C%AF%E5%9B%9B%E9%83%A8%E6%9B%B2%E4%B9%8B%E4%BD%BF%E7%94%A8K%E8%BF%91%E9%82%BB%E7%AE%97%E6%B3%95/
卷积神经网络识别验证码
http:// nlao.github.io/2016/0 9/23/%E9%AA%8C%E8%AF%81%E7%A0%81%E7%A0%B4%E8%A7%A3%E6%8A%80%E6%9C%AF%E5%9B%9B%E9%83%A8%E6%9B%B2%E4%B9%8B%E4%BD%BF%E7%94%A8%E5%8D%B7%E7%A7%AF%E7%A5%9E%E7%BB%8F%E7%BD%91%E7%BB%9C/
使用 TensorFlow 训练验证码
http:// nlao.github.io/2017/0 4/10/%E4%BD%BF%E7%94%A8TensorFlow%E8%AE%AD%E7%BB%83Weibo-cn%E9%AA%8C%E8%AF%81%E7%A0%81/
对于网站要求输入手机号，接收手机短信并校验短信验证码是否正确进行登录的系统，突破的主要思路有：
1.短信验证码生命期限内可暴力枚举
在验证码还未过期的时间段内，可枚举全部的纯四位数字、六位数字等较简单的短信验证码；
2. 短信验证码在数据包中返回
和图形验证码一样，在response中可以直接获取到短信验证码。
3. 修改请求数据包参数或 Cookie 值绕过
比如有 post 数据包：mobile=12435437658&userid=123456, Cookie中有：codetype=1
在特定步骤，修改 mobile=自己的手机号，自己手机就可以收到别人的验证码，后面再用别人的手机号和接收到的验证码登录；
修改 Cookie 中可疑的参数和值，进行绕过，比如上面修改 codetype=0；
4. 修改返回包绕过
提交错误的短信验证码，返回包中有： status=false，在Burpsuite中修改为 status=true，即可绕过前端判断，成功进入系统。具体还要结合实际的场景，灵活操作。
web系统登陆页面看似铜墙铁壁，但其实只要梳理一遍思路，右键看过每一行网站源码，弄懂每个参数的意义，查看每一个js文件，就会发现其实自己就是系统管理员，只是我把密码忘了，现在我要用上面的方式进入。
⑦ 如何对web.config进行加密和解密
你好，可以使用受保护配置来加密 Web 应用程序配置文件（如 Web.config 文件）中的敏感信息（包括用户名和密码、数据库连接字符串和加密密钥）。对配置信息进行加密后，即使攻击者获取了对配置文件的访问，也可以使攻击者难以获取对敏感信息的访问，从而改进应用程序的安全性。 针对asp.net 2.0的应用程序的数据库链接字符串进行加密：例如，未加密的配置文件中可能包含一个指定用于连接到数据库的连接字符串的节，如下面的示例所示： <configuration> <connectionStrings>
<add name="SampleSqlServer" connectionString="Data Source=localhost;Integrated Security=SSPI;Initial Catalog=Northwind;" />
</connectionStrings>
</configuration>
ASP.NET 2.0 中有一个新的安全特性.可以对 Web.config 文件中的任何配置节进行加密处理，可以通过手工运行工具aspnet_regiis或者编程来完成这个工作。如果你可以直接访问你的Web 服务器，你可以通过运行如下的命令行： cd %windows%/Microsoft.NET/Framework/versionNumber aspnet_regiis -pe "connectionStrings" -app "/SampleApplication" –prov -pd section
对配置节进行解密。此参数采用下面的可选参数： · -app virtualPath 指定应该在包含路径的级别进行解密。 · -location subPath 指定要解密的子目录。 · -pkm 指定应该对 Machine.config 而非 Web.config 文件进行解密。
-pdf section webApplicationDirectory
对指定物理（非虚拟）目录中的 Web.config 文件的指定配置节进行解密。
-pe section
对指定的配置节进行加密。此参数采用下面的可选修饰符： · -prov provider 指定要使用的加密提供程序。 · -app virtualPath 指定应该在包含路径的级别进行加密。 · -location subPath 指定要加密的子目录。 · -pkm 指定应该对 Machine.config 而非 Web.config 文件进行加密。
-pef section webApplicationDirectory
对指定物理（非虚拟）目录中的 Web.config 文件的指定配置节进行加密。
如果你是使用虚拟主机等不能访问物理的服务器,你仍然能够通过编程方式加密的连接字符串: 1 Configuration config = Configuration.GetWebConfiguration(Request.ApplicationPath);
2 ConfigurationSection section = config.Sections["connectionStrings"];
3 section.SectionInformation.ProtectSection("");;
4 config.Update ();或者 config.Save();
//加密web.Config中的指定节
private void ProtectSection(string sectionName)
{
Configuration config = WebConfigurationManager.OpenWebConfiguration(Request.ApplicationPath);
ConfigurationSection section = config.GetSection(sectionName);
if (section != null && !section.SectionInformation.IsProtected)
{
section.SectionInformation.ProtectSection("");
config.Save();
}
}
//解密web.Config中的指定节
private void UnProtectSection(string sectionName)
{
Configuration config = WebConfigurationManager.OpenWebConfiguration(Request.ApplicationPath);
ConfigurationSection section = config.GetSection(sectionName);
if (section != null && section.SectionInformation.IsProtected)
{
section.SectionInformation.UnprotectSection();
config.Save();
}
}
⑧ java ibm jdk rsa 怎么 加密
android和java webservice RSA处理的不同
1.andorid机器上生成的（密钥对由服务器在windows xp下生成并将公钥发给客户端保存）密码无法在服务器通过私钥解密。
2.为了测试，在服务器本地加解密正常，另外，在android上加解密也正常，但是在服务器中加密（使用相同公钥）后的密码同样无法在android系统解密（使用相同私钥）。
3.由于对RSA加密算法不了解，而且对Java RSA的加密过程也不清楚、谷歌一番，才了解到可能是加密过程中的填充字符长度不同，这跟加解密时指定的RSA算法有关系。
4. 比如，在A机中使用标准RSA通过公钥加密，然后在B系统中使用“RSA/ECB/NoPadding”使用私钥解密，结果可以解密，但是会发现解密后的原文前面带有很多特殊字符，这就是在加密前填充的空字符；如果在B系统中仍然使用标准的RSA算法解密，这在相同类型的JDK虚拟机环境下当然是完全一样的，关键是android系统使用的虚拟机（dalvik）跟SUN标准JDK是有所区别的，其中他们默认的RSA实现就不同。
5.更形象一点，在加密的时候加密的原文“abc”，直接使用“abc”.getBytes()方法获得的bytes长度可能只有3，但是系统却先把它放到一个512位的byte数组里，new byte[512]，再进行加密。但是解密的时候使用的是“加密后的密码”.getBytes()来解密，解密后的原文自然就是512长度的数据，即是在“abc”之外另外填充了500多字节的其他空字符。
⑨ Java写的RSA算法在WebSphere环境下报错，在本地tomcat下是好的
WAS6 的 JDK 版本太老了，是 IBM JDK1.4，没有实现 ECB，有条件的话，试试 WAS7(IBM JDK1.6)或者是WAS8
本地测试一般都是用的 Sun 的 JDK
每次加完密结果都会变化？是说同样的内容加密之后结果都不一样么？RSA 不会这样的咧
⑩ KeyFactory.getInstance("RSA");方式加密，返回的字符串，web访问和mian方法返回的不一样这是为什么
与 Provider 有关。
先用main方法看看keyFactory 里的数据。
再尝试用web方法调用下面的方法看看数据。
KeyFactory keyFactory = KeyFactory.getInstance("RSA", Providers.getProviderList().getProvider("SunRsaSign"));
同理Cipher.getInstance（）这个方法也一样