web系統安全頁面加密

⑴ Web前端密碼加密是否有意義

在前端對密碼做一次MD5，看起來是防止明文傳輸了，事實上只有一種情況下它可以提高用戶的安全性，那就是用戶在別的網站上也用和你的網站一樣的密碼。並且在任何情況下都提高不了你自己網站的安全性。前面說的傳輸過程、內存里、日誌里……這些地方沒有明文密碼，其實都只能保護用戶本身的利益，對於自身服務的安全性是沒有提高的。因為，既然傳輸過程不是加密的，那麼包隨便發，至於發一個abc123，還是發一個，對你的程序沒有任何的區別，這時候你的程序都是小綿羊。這個過程可以看做，你的用戶都用了32位字元串的密碼，如是而已。從事實意義上講，在所有網站上用同樣密碼的用戶非常多，所以可以勉勉強強的說，這是有一丁丁點的意義的。但即使在前端做了簽名，因為hash暴露了，也還是很容易被撞庫。但是，對安全性沒有提高，就不做了嗎？當然要做，因為要應付審計。

⑵ Web前端密碼加密是否有意義

密碼在前端加密完全沒有意義，對密碼系統的安全性不會有任何提高，反而會引發不必要的麻煩。

(1)加密了也無法解決重放的問題，你發給伺服器端的雖然是加密後的數據，但是黑客攔截之後，把加密之後的數據重發一遍，依然是驗證通過的。直接監聽到你所謂的密文，然後用腳本發起一個http請求就可以登錄上去了。

http在網路上是明文傳輸的，代理和網關都能夠看到所有的數據，在同一區域網內也可以被嗅探到，你可以開個wireshark抓下區域網的包試試看。加密也沒有提高什麼攻擊難度，因為攻擊者就沒必要去解密原始密碼，能登錄上去就表示目標已經實現了，所以，難度沒有提高。

(2)既然是加密，那麼加密用的密鑰和演算法肯定是保存在前端的，攻擊者通過查看源碼就能得到演算法和密鑰。除非你是通過做瀏覽器插件，將演算法和密鑰封裝在插件中，然後加密的時候明文混淆上時間戳，這樣即使黑客攔截到了請求數據，進行重放過程時，也會很快失效。

⑶ Web前端密碼加密是否有意義

沒有意義

---

密碼前端的加密根本沒有意義，密碼系統的安全性沒有提高，但會造成不必要的麻煩。

首先，前端開發人員需要知道前端系統的控制完全掌握在用戶手中，也就是說前端所做的事情和用戶擁有完全的控制。據稱，前端做了MD5，後台不必做，這種方法會有什麼後果？如果有一天，系統資料庫泄露，黑客直接獲得每個用戶的密碼的MD5值，但這一次，因為黑客知道密碼的哈希的前面，所以他不需要鼓風的MD5對應什麼是原創，而是直接修改發送到伺服器的客戶端請求的在它的資料庫密碼欄位MD5，符合資料庫中的記錄，你可以直接登錄。這與直接存儲明文密碼沒有區別！！！所以不管前端密碼是否加密，後台使用哈希演算法的安全內容轉換都是必要的。（MD5不能使用BCrypt的，我以前回答類似：用圖形表現，當前快速發展的快速哈希演算法已成為不安全嗎？）有一個人同意這個答案，我希望你不要被錯誤的答案誤導。對方的回答，Linh說，是為了防止原始密碼被利用在一個不安全的HTTP連接。但問題是，因為你的登錄系統接受密碼代替原來的，竊聽者根本不需要原始密碼，只要哈希結果可以偽造請求登錄系統。這樣做只會防止攻擊者在社交攻擊時使用原始密碼，而不會提高網站的安全性。所以不管前面密碼是不是加密的，使用HTTPS安全連接登錄都是很有必要的。

⑷ 怎樣給html網頁加密

三、使用ASP程序密碼鎖

除了使用IIS伺服器來給網頁加密，我們還可以使用ASP程序來給網頁進行加密，一般來說利用程序來進行密碼驗證的方法比較通用，現在大多數網站都使用ASP程序，它對Web伺服器沒有具體要求，而其加密就是藉助資料庫及ASP程序進行設計，來實現一種通用網頁加密。

1. 打開Microsoft Access，建立一個「用戶名及密碼」的數據表，假設將這個表取名為User，資料庫名為lastcoco.mdb，數據表的結構如下：

欄位說明 欄位名稱 數據類型 數據長度

用戶名稱 ID文本 15

密碼 PWD 文本 15

2. 編輯一個PASS.ASP的驗證文件，源代碼如下：

＜%Function Check( ID, Pwd )Dim conn, par, rsSet conn = Server.CreateObject("ADODB.Connection")par = "driver={Microsoft Access Driver (*.mdb)} "conn.Open par && ";dbq=" && Server.MapPath("lastcoco.mdb ")sql = "Select ? From users Where ID='" && ID && "' And Pwd = '" && Pwd &&"'"Set rs = conn.Execute( sql )If rs.EOF ThenCheck= FalseElseCheck= TrueEnd IfEnd Function%＞＜%If IsEmpty(Session("Passed")) Then Session("Passed") = FalseHead = "請輸入用戶名和密碼"ID = Request("ID")Pwd = Request("Pwd")If ID = "" Or Pwd = "" ThenHead = "請輸入用戶名和密碼"Else If Not Check( ID, Pwd ) ThenHead = "用戶名稱或密碼有錯"ElseSession("Passed") = TrueEnd IfIf Not Session("Passed") Then %＞＜html＞＜head＞ ＜title＞＜/title＞ ＜/head＞＜body BGCOLOR="#FFFFFF"＞＜h2 ALIGN="CENTER"＞＜%=Head%＞＜/h2＞＜hr WIDTH="100%"＞＜form Action="＜%=Request.ServerVariables("PATH_INFO")%＞" Method="POST"＞＜table BORDER="1" CELLSPACING="0"＞＜tr＞＜td ALIGN="RIGHT"＞用戶名稱:＜/td＞＜td＞＜input Type="Text" Name="ID" Size="12" Value="＜%=ID%＞"＞＜/td＞＜/tr＞＜tr＞ ＜td ALIGN="RIGHT"＞密碼：＜/td＞＜td＞＜input Type="Password" Name="Pwd" Size="12" Value="＜%=Pwd%＞"＞＜/td＞ ＜/tr＞＜/table＞＜p＞＜input Type="Submit" Value="確定"＞ ＜/p＞ ＜/form＞＜hr WIDTH="100%" align="center"＞＜/body＞ ＜/html＞＜%Response.EndEnd If %＞

3. 在需要加密網頁的HTML代碼最前面加上〈! --#include file="pass.asp"--〉就可以了。由於這個驗證合法性的頁面具有通用性，所以非常方便使用。

四、使用軟體密碼鎖

現在給網頁加密的軟體非常多，這里就不一一講解，其基本原理都是利用javascript代碼，只不過是這些軟體都自動准備好了這些代碼，只需使用者將網頁源代碼粘進去按一下加密按鈕就OK了。

在這里我們介紹一款綠色的小軟體「世紀鳥網頁加密精靈」，大家不要小看這只鳥，通過這只小鳥，能更方便快速的對網頁進行加密。

下載雙擊打開這只小鳥，只見XP風格的界面跳到眼前，左邊豎著一排是加密選項按鈕，分別是「網頁代碼加密」、「網頁登錄密碼」「滑鼠右鍵屏蔽」、「網頁選擇屏蔽」、「滑鼠右鍵對話」、「框架包含限制」這些。右邊則是網頁代碼加密對話框，在這個對話框中進行對網頁的加密，而且在對話框上方給出每個選項的解釋，在對話框下方則是建議。

這里我用實例給大家講解使用「世紀鳥網頁加密精靈」的「網頁登錄密碼」選項來給網頁加密。

1. 打開要加密的網頁，復制出HTML源代碼，然後打開「世紀鳥網頁加密精靈」軟體，選擇「網頁登錄密碼」選項，這時在右邊就會出現一些輸入框內的代碼說明
2. 在「請輸入登錄密碼」的輸入框中輸入長度小於10位的密碼，然後單擊「生成並復制密碼頁面程序」按鈕，這時軟體會自動在下方的javascript代碼中加入你輸入的登錄密碼做為驗證信息，並將這段代碼復制到你的剪貼版中
3. 接下來再將這段代碼粘貼到網頁中，並將網頁改名為（你輸入的登錄密碼）.htm，這樣就可以對此文件加密了

⑸ 如何用IPS解決Web安全問題

（一）加密技術。
加密技術是電子商務採取的基本安全措施，交易雙方可根據需要在信息交換的階段使用。加密技術分為兩類，即對稱加密和非對稱加密。
（1）對稱加密。
對稱加密又稱私鑰加密，即信息的發送方和接收方用同一個密鑰去加密和解密數據。它的最大優勢是加/解密速度快，適合於對大數據量進行加密，但密鑰管理困難。如果進行通信的雙方能夠確保專用密鑰在密鑰交換階段未曾泄露，那麼機密性和報文完整性就可以通過這種加密方法加密機密信息、隨報文一起發送報文摘要或報文散列值來實現。
（2）非對稱加密。
非對稱加密又稱公鑰加密，使用一對密鑰來分別完成加密和解密操作，其中一個公開發布（即公鑰），另一個由用戶自己秘密保存（即私鑰）。信息交換的過程是：甲方生成一對密鑰並將其中的一把作為公鑰向其他交易方公開，得到該公鑰的乙方使用該密鑰對信息進行加密後再發送給甲方，甲方再用自己保存的私鑰對加密信息進行解密。
（二）認證技術。
認證技術是用電子手段證明發送者和接收者身份及其文件完整性的技術，即確認雙方的身份信息在傳送或存儲過程中未被篡改過。
（1）數字簽名。
數字簽名也稱電子簽名，如同出示手寫簽名一樣，能起到電子文件認證、核准和生效的作用。其實現方式是把散列函數和公開密鑰演算法結合起來，發送方從報文文本中生成一個散列值，並用自己的私鑰對這個散列值進行加密，形成發送方的數字簽名；然後，將這個數字簽名作為報文的附件和報文一起發送給報文的接收方；報文的接收方首先從接收到的原始報文中計算出散列值，接著再用發送方的公開密鑰來對報文附加的數字簽名進行解密；
（2）數字證書。
數字證書是一個經證書授權中心數字簽名的包含公鑰擁有者信息以及公鑰的文件數字證書的最主要構成包括一個用戶公鑰，加上密鑰所有者的用戶身份標識符，以及被信任的第三方簽名第三方一般是用戶信任的證書權威機構（CA），如政府部門和金融機構。用戶以安全的方式向公鑰證書權威機構提交他的公鑰並得到證書，然後用戶就可以公開這個證書。任何需要用戶公鑰的人都可以得到此證書，並通過相關的信任簽名來驗證公鑰的有效性。數字證書通過標志交易各方身份信息的一系列數據，提供了一種驗證各自身份的方式，用戶可以用它來識別對方的身份。

⑹ 如何對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();
}
}

⑺ Web前端密碼加密是否有意義

密碼在前端加密完全沒有意義，對密碼系統的安全性不會有任何提高，反而會引發不必要的麻煩。首先，做前端開發的人需要知道，前端系統的控制權是完全在用戶手裡的，也就是說，前端做什麼事情，用戶有完全的控制權。假設如同 @陳軒所說，前端做過了md5，後台就不用做了，這個做法會有什麼後果？如果某一天，這個系統的資料庫泄露了，黑客就直接拿到了每個用戶的密碼md5值，但此時，由於黑客知道密碼是在前端進行哈希的，所以他不需要爆破出該md5對應的原文是什麼，而是直接修改客戶端向伺服器發出的請求，把密碼欄位換成資料庫中MD5就可以了，由於與資料庫中記錄一致，直接就會登錄成功。這跟直接存儲明文密碼沒有任何區別！！！所以不管前端是不是加密了密碼，後台使用安全的哈希演算法對內容再次轉換是非常有必要的。（MD5可不行，要用bcrypt，我之前回答過一個類似的：隨著顯卡性能的高速發展，目前的快速Hash演算法是否已經變得不夠安全了？）這個回答還有一個人贊同，希望大家別被錯誤答案誤導了。另外一個答案 @林鴻所說，在非安全HTTP連接上，可以防止原始密碼被竊聽。但問題在於由於你的登錄系統接受的哈希過的密碼，而不是原文，竊聽者根本不需要原始密碼，只要通過哈希結果就可以偽造請求登錄系統。這樣做只能防止被竊聽到原文的密碼被攻擊者用在社會學攻擊上，而不能改善該網站的安全性。所以不管前端是不是加密了密碼，使用HTTPS安全連接進行登錄都是非常有必要的。以上我說的兩點，合起來看就是：不管前端是否加密了密碼，都不能以此為假設，讓後端設計的安全等級下降，否則就會有嚴重的安全問題。實際上，前端進行密碼加密，可以看做幫助用戶多進行了一次原文的轉換，不管用了什麼加密演算法，算出來的結果都是密碼原文，你該如何保護用戶的原始密碼，就該如何保護此處的加密結果，因為對你的登錄系統來說，它們都是密碼原文。以上這些，說明了密碼加密是沒有什麼意義的，接下來，我要說明前端加密會帶來什麼問題。有些人會認為前端進行了加密，可以降低後台的安全性需求，這種錯誤的觀念會造成系統的安全漏洞。實際上，你不能對前端做任何的假設，所有跟安全相關的技術，都必須應用在後台上。前端進行加密會造成頁面需要js腳本才能運行，那麼假設你的系統需要兼容不能運行js的客戶端，就必須再設計一個使用原文的登錄介面。由於前端是不是加密，所有安全機制都必須照常應用，所以為系統增加這樣的復雜性是完全沒必要的，即使傳輸明文密碼，只要正確使用了HTTPS連接和伺服器端安全的哈希演算法，密碼系統都可以是很安全的。