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（）這個方法也一樣