登錄密碼加密傳輸
㈠ 資料庫登陸時候,資料庫客戶端輸入的用戶名和密碼,在網路上傳輸是否加密
是的,password的加密手段是摘要加密演算法,比如MD5。id不需要加密。
以oracle為例,在默認的情況下,除了password之外,所有的數據都是明文傳送方式。但是DBA可以在伺服器端強制設置客戶端使用安全的連接方式,比如Kerberos,這時傳輸的所有數據包括password的摘要加密結果都要經過kerberos認證加密之後再傳送。其他的加密方式還有bs認證。
對於mysql,管理員可以設置ssl安全連接和ssh認證。
㈡ js點擊登錄按鈕獲取到賬號密碼文本框內容並加密傳輸
文本框和密碼框都是input元素,只是type屬性值不一樣,因此只要將type屬性由text修改為password即可實現文本框變密碼框。示例如下:
1、HTML結構
<inputtype="text"id="test"value="請輸入密碼"onclick="fun(this)">
2、javascript代碼
functionfun(obj){obj.value="";obj.type="password";}
3、效果演示
㈢ https如何進行加密傳輸
HTTPS在傳輸數據之前需要客戶端(瀏覽器)與服務端(網站)之間進行一次握手,在握手過程中將確立雙方加密傳輸數據的密碼信息。TLS/SSL協議不僅僅是一套加密傳輸的協議,更是一件經過藝術家精心設計的藝術品,TLS/SSL中使用了非對稱加密,對稱加密以及HASH演算法。握手過程的具體描述如下:
1.瀏覽器將自己支持的一套加密規則發送給網站。
2.網站從中選出一組加密演算法與HASH演算法,並將自己的身份信息以證書的形式發回給瀏覽器。證書裡麵包含了網站地址,加密公鑰,以及證書的頒發機構等信息。
3.瀏覽器獲得網站證書之後瀏覽器要做以下工作:
a) 驗證證書的合法性(頒發證書的機構是否合法,證書中包含的網站地址是否與正在訪問的地址一致等),如果證書受信任,則瀏覽器欄裡面會顯示一個小鎖頭,否則會給出證書不受信的提示。
b) 如果證書受信任,或者是用戶接受了不受信的證書,瀏覽器會生成一串隨機數的密碼,並用證書中提供的公鑰加密。
c) 使用約定好的HASH演算法計算握手消息,並使用生成的隨機數對消息進行加密,最後將之前生成的所有信息發送給網站。
4.網站接收瀏覽器發來的數據之後要做以下的操作:
a) 使用自己的私鑰將信息解密取出密碼,使用密碼解密瀏覽器發來的握手消息,並驗證HASH是否與瀏覽器發來的一致。
b) 使用密碼加密一段握手消息,發送給瀏覽器。
5.瀏覽器解密並計算握手消息的HASH,如果與服務端發來的HASH一致,此時握手過程結束,之後所有的通信數據將由之前瀏覽器生成的隨機密碼並利用對稱加密演算法進行加密。
這里瀏覽器與網站互相發送加密的握手消息並驗證,目的是為了保證雙方都獲得了一致的密碼,並且可以正常的加密解密數據,為後續真正數據的傳輸做一次測試。另外,HTTPS一般使用的加密與HASH演算法如下:
非對稱加密演算法:RSA,DSA/DSS
對稱加密演算法:AES,RC4,3DES
HASH演算法:MD5,SHA1,SHA256
㈣ 一般網頁中的用戶名和登錄密碼在傳輸過程中是通過什麼加密的
對於打開了某個論壇,輸入了用戶名和密碼,其實如果網站設計者重視安全問題的話一般會對輸入的用戶名和密碼進行加密,加密後的用戶名和密碼用一連串的字元表示,所以即使別人竊取了你的用戶名和密碼和密碼,他們如果不知道怎麼解密,他們只能得到一連串的字元,所以這也是一道防線。
接下來就是網路安全方面的問題:
數據加密(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實現方案是:客戶機提供自己支持的所有演算法清單,伺服器選擇它認為最有效的密碼。伺服器管理者可以使用或禁止某些特定的密碼。
㈤ 如何保證用戶登錄時提交密碼已經加密
如何保證用戶登陸時提交密碼已經加密?密碼是否已加密,需要客戶端和服務端建立約定,雙方按約定辦事就行了。
這里提到的另一個問題是,如何保證傳輸安全?
最理想的方案當然是走 HTTPS 協議. HTTPS
在理論上是可靠的,但在國內會打一些折扣:你可以隨便找一台電腦看看有沒有安裝商業公司或機構的根證書,這些根證書為線路某節點成為中間人提供了可能性;同時,在木馬橫行的年代,密碼在加密提交前可能就被拿到了,此時
HTTPS
成了擺設,這是為什麼國內流行密碼控制項的一個重要原因。
從成本和需求上考慮,對於眾多對安全性要求不高的個人網站,仍然可以考慮採用
HTTP 傳輸,密碼提交前通過 JavaScript 加密。由於
JavaScript
代碼暴露在客戶端,因此一般通過不可逆的加密方法加密密碼,而對於任何摘要式的加密演算法,都可以通過類似
md5 字典的方式直接查表獲知弱密碼,所以要混入
salt
以增加製作字典的成本。可想而知,解密只是時間成本的問題。因此這里的重要前提是「對安全性要求不高」。
如何驗證密碼呢?一個可行的方法是,客戶端提交
md5(password)
密碼(如上所述,此方法只是簡單保護了密碼,是可能被查表獲取密碼的)。服務端資料庫通過
md5(salt+md5(password)) 的規則存儲密碼,該 salt
僅存儲在服務端,且在每次存儲密碼時都隨機生成。這樣即使被拖庫,製作字典的成本也非常高。
密碼被 md5() 提交到服務端之後,可通過 md5(salt +
form['password'])
與資料庫密碼比對。此方法可以在避免明文存儲密碼的前提下,實現密碼加密提交與驗證。
這里還有防止 replay
攻擊(請求被重新發出一次即可能通過驗證)的問題,由服務端頒發並驗證一個帶有時間戳的可信
token (或一次性的)即可。
當然,傳輸過程再有 HTTPS 加持那就更好了。
最後,為什麼要密碼控制項?原因之一是上面說的,要防止密碼在提交前被截獲。