認證
密碼:只有本人才會知道的字串資訊。
動態令牌:僅限本人持有的裝置內顯示的一次性密碼。
數字證書:僅限本人(終端)持有的資訊。
生物認證:指紋和虹膜等本人的生理資訊。
ic 卡等:僅限本人持有的資訊。
web 伺服器與通訊客戶端之間進行的認證方式。
digest 認證同樣使用質詢 / 響應的方式(challenge/response),但不會像 basic 認證那樣直接傳送明文密碼。
所謂質詢響應方式是指,一開始一方會先傳送認證要求給另一方,接著使用從另一方那接收到的質詢碼計算生成響應碼。最後將響應碼返回給對方進行認證的方式。
digest 認證概要
步驟 1: 請求需認證的資源時,伺服器會隨著狀態碼 401authorization required,返 回帶 www-authenticate 首部欄位的響應。該字段內包含質問響應方式認證所需的臨時質詢碼(隨機數,nonce)。首部字段 www-authenticate 內必須包含 realm 和 nonce 這兩個欄位的資訊。客戶端就是依靠向伺服器回送這兩個值進行認證的。nonce 是一種每次隨返回的 401 響應生成的任意隨機字串。該字串通常推薦由 base64 編碼的十六進製制數的組成形式,但實際內容依賴伺服器的具體實現。
步驟 2: 接收到 401 狀態碼的客戶端,返回的響應中包含 digest 認證必須的首部字段 authorization 資訊。首部字段 authorization 內必須包含 username、realm、nonce、uri 和response 的字段資訊。其中,realm 和 nonce 就是之前從伺服器接收到
的響應中的字段。
username 是 realm 限定範圍內可進行認證的使用者名稱。uri(digest-uri)即 request-uri 的值,但考慮到經****後request-uri 的值可能被修改,因此事先會複製乙份副本儲存在 uri內。
response 也可叫做 request-digest,存放經過 md5 運算後的密碼字串,形成響應碼。
響應中其他的實體請參見第 6 章的請求首部字段 authorization。另外,有關 request-digest 的計算規則較複雜,有興趣的讀者不深入學習一下 rfc2617。
步驟 3: 接收到包含首部字段 authorization 請求的伺服器,會確認認證資訊的正確性。認證通過後則返回包含 request-uri 資源的響應。並且這時會在首部字段 authentication-info 寫入一些認證成功的相關資訊。
步驟 1: 當請求的資源需要 basic 認證時,伺服器會隨狀態碼 401authorization required,返回帶 www-authenticate 首部欄位的響應。該字段內包含認證的方式(basic) 及 request-uri 安全域字串(realm)。
步驟 2: 接收到狀態碼 401 的客戶端為了通過 basic 認證,需要將使用者 id 及密碼傳送給伺服器。傳送的字串內容是由使用者 id 和密碼構成,兩者中間以冒號(:)連線後,再經過 base64 編碼處理。假設使用者 id 為 guest,密碼是 guest,連線起來就會形成 guest:guest 這樣的字串。然後經過 base64 編碼,最後的結果即是z3vlc3q6z3vlc3q=。把這串字串寫入首部字段 authorization 後,傳送請求。當使用者**為瀏覽器時,使用者僅需輸入使用者 id 和密碼即可,之後,瀏覽器會自動完成到 base64 編碼的轉換工作。
步驟 3: 接收到包含首部字段 authorization 請求的伺服器,會對認證資訊的正確性進行驗證。如驗證通過,則返回一條包含 request-uri資源的響應。basic 認證雖然採用 base64 編碼方式,但這不是加密處理。不需要任何附加資訊即可對其解碼。換言之,由於明文解碼後就是使用者 id和密碼,在 http 等非加密通訊的線路上進行 basic 認證的過程中,如果被人竊聽,被盜的可能性極高。
ssl 客戶端認證是借由 https 的客戶端證書完成認證的方式。憑藉客戶端證書認證,伺服器可確認訪問是否來自已登入的客戶端。
為達到 ssl 客戶端認證的目的,需要事先將客戶端證書分發給客戶端,且客戶端必須安裝此證書。
步驟 1: 接收到需要認證資源的請求,伺服器會傳送 certificaterequest 報文,要求客戶端提供客戶端證書。
步驟 2: 使用者選擇將傳送的客戶端證書後,客戶端會把客戶端證書資訊以 client certificate 報文方式傳送給伺服器。
步驟 3: 伺服器驗證客戶端證書驗證通過後方可領取證書內客戶端的公開金鑰,然後開始 https 加密通訊。
ssl 客戶端認證採用雙因素認證
ssl 客戶端認證不會僅依靠證書完成認證,一般會和基於表單認證(稍後講解)組合形成一種雙因素認證(two-factorauthentication)來使用。
第乙個認證因素的 ssl 客戶端證書用來認證客戶端計算機,另乙個認證因素的密碼則用來確定這是使用者本人的行為。
客戶端會向伺服器上的 web 應用程式傳送登入資訊(credential),按登入資訊的驗證結果認證。根據 web 應用程式的實際安裝,提供的使用者介面及認證方式也各不相同。
認證多半為基於表單認證
session 管理及 cookie 應用基於表單認證的標準規範尚未有定論,一般會使用 cookie 來管理session(會話)。
基於表單認證本身是通過伺服器端的 web 應用,將客戶端傳送過來的使用者 id 和密碼與之前登入過的資訊做匹配來進行認證的。
步驟 1: 客戶端把使用者 id 和密碼等登入資訊放入報文的實體部分,通常是以 post 方法把請求傳送給伺服器。而這時,會使用 https通訊來進行 html 表單畫面的顯示和使用者輸入資料的傳送。
步驟 2: 伺服器會發放用以識別使用者的 session id。通過驗證從客戶端傳送過來的登入資訊進行身份認證,然後把使用者的認證狀態與session id 繫結後記錄在伺服器端。向客戶端返回響應時,會在首部字段 set-cookie 內寫入 sessionid(如 phpsessid=028a8c...)。你可以把 session id 想象成一種用以區分不同使用者的等位號。然而,如果 session id 被第三方盜走,對方就可以偽裝成你的身份進行惡意操作了。因此必須防止 session id 被盜,或被猜出。為了做到這點,session id 應使用難以推測的字串,且伺服器端也需要進行有效期的管理,保證其安全性。另外,為減輕跨站指令碼攻擊(xss)造成的損失,建議事先在 cookie內加上 httponly 屬性。
步驟 3: 客戶端接收到從伺服器端發來的 session id 後,會將其作為cookie 儲存在本地。下次向伺服器傳送請求時,瀏覽器會自動傳送cookie,所以 session id 也隨之傳送到伺服器。伺服器端可通過驗證接收到的 session id 識別使用者和其認證狀態。
此外,還有 windows 統一認證(keberos 認證、ntlm 認證)
一種安全的儲存方法是,先利用給密碼加鹽(salt) 1 的方式增加額外資訊,再使用雜湊(hash)函式計算出雜湊值後儲存
0x08標誌型別的RTMPE RTMPTE協議分析
fms 3.5.1以上 flash player 10.0.22.87及以上 一些配置 暫不詳 這樣的組合之間的rtmp連線會使得伺服器端握手資訊的第一位元組為0x8，而不是以前常見的0x6，並且握手資訊2的摘要資訊和以前的生成規則不同了 暫不詳 想必這是adobe在rtmte協議被破解後做出的改變...
徹底搞定0x0d和0x0a
我只在arm linux c和vc 下做了試驗，請大家在接觸其它語言環境下，小心推廣，不行就自己動手做試驗，最可靠。在arm linux c和vc 下回車換行的意義如下。回車 cr ascii碼 r 十六進製制，0x0d，回車的作用只是移動游標至該行的起始位置 換行 lf ascii碼 n 十六進製...
關於0x0d與0x0a的ASCII。
今天發現乙個有趣的現象 在 ma 我用的版本是6.11 中作彙編時發現，0x0d與0x0a有著不同的作用。比如 dead for dream 在這個字串後只加上0x0d則得到 游標移到開頭的那個d下面，而沒有換行 再輸入字元的話，將原來的字元著改掉。在這個字串上只加上0x0a則得到 游標移到末尾m字...