Restful HMAC认证
我們在設(shè)計(jì)REST(Representational State Transfer)風(fēng)格的Web service API,有一個(gè)問題經(jīng)常要考慮,就是如何設(shè)計(jì)用戶認(rèn)證的體系(Authentication).?
比較傳統(tǒng)的做法是首先有一個(gè)登陸的API,然后服務(wù)器返回一個(gè)session ID,后續(xù)的操作客戶端都必須帶上這個(gè)session ID,但是這樣的,服務(wù)就變成了有狀態(tài)了,不符合REST風(fēng)格的原則。另外,由于負(fù)載均衡的存在,必須有公共存儲(chǔ)來保存用戶的Session,這也增加了系統(tǒng)的復(fù)雜度。?
所以比較好的做法是每次都傳遞認(rèn)證信息,這樣系統(tǒng)就是無狀態(tài)的,當(dāng)然由于每次都需要認(rèn)證,必然降低了一些效率,必要的時(shí)候要考慮緩存用戶信息在服務(wù)器端。?
有幾點(diǎn)要注意:?
1.密碼不能傳播?
一個(gè)比較低級的錯(cuò)誤是通訊時(shí),由客戶端傳遞用戶名和密碼到服務(wù)器端認(rèn)證,這樣很容易被黑客攻擊造成密碼泄露。?
標(biāo)準(zhǔn)的做法是使用HMAC(Hash-based Message Authentication Code),想法就是不傳播password,而傳播content和password的混合hash值。我們來看看Amazon S3怎么做認(rèn)證的。?
Amazon對每一個(gè)用戶有一個(gè)AWSAccessKeyId和一個(gè)AWSSecretAccessKey,每次HTTP請求需要一個(gè)Id和一個(gè)Autherticantion信息。 比如:?
GET /photos/puppy.jpg HTTP/1.1? Host: johnsmith.s3.amazonaws.com? Date: Tue, 27 Mar 2007 19:36:42 +0000 Authorization: AWS 0PN5J17HBGZHT7JJ3X82: xXjDGYUmKxnwqr5KXNPGldn5LbA=? 這個(gè)Authorization的頭是這樣產(chǎn)生的: 其中YourSecretAccessKeyID用的就是AWSSecretAccessKey。? Authorization = "AWS" + " " + AWSAccessKeyId + ":" + Signature;? Signature = Base64( HMAC-SHA1( UTF-8-Encoding-Of( YourSecretAccessKeyID, StringToSign ) ) );?StringToSign = HTTP-Verb + "\n" +? Content-MD5 + "\n" +? Content-Type + "\n" +? Date + "\n" +? CanonicalizedAmzHeaders +? CanonicalizedResource;?CanonicalizedResource = [ "/" + Bucket ] +? <HTTP-Request-URI, from the protocol name up to the query string> +? [ sub-resource, if present. For example "?acl", "?location", "?logging", or "?torrent"];? CanonicalizedAmzHeaders = <described below>?這樣服務(wù)端就很容易根據(jù)用戶信息來驗(yàn)證信息的正確與否。?
驗(yàn)證信息的位置?
驗(yàn)證信息可以放在HTTP HEADER里面也可以放在HTTP URL里面,象這樣:?
GET /photos/puppy.jpg?AWSAccessKeyId=0PN5J17HBGZHT7JJ3X82&Expires=1141889120&Signature=vjbyPxybdZaNmGa%2ByT272YEAiv4%3D HTTP/1.1? Host: johnsmith.s3.amazonaws.com? Date: Mon, 26 Mar 2007 19:37:58 +0000?放在HTTP HEADER里面的好處是URL比較干凈整潔,適合放在internet與人分享,而放在URL里面則有利于發(fā)布私有的訪問權(quán)限給第三方。?
如何防范重放攻擊(Replay attack)??
理論上,黑客可以竊取你的通訊報(bào)文,然后重新發(fā)送來通過認(rèn)證。有幾種可能的solution.?
客戶端所以向服務(wù)器申請一個(gè)隨機(jī)數(shù),然后這個(gè)隨機(jī)數(shù)作為下次通訊的key,一旦使用過后就立即失效,也就是所謂的”一次一密”。這種方法的好處是很安全,但是增加通訊量,而且由于負(fù)載均衡的存在,必須有公共存貯保存這個(gè)key。?
b.服務(wù)器端保存使用過的authertication信息,只要是使用過的就拒絕再次使用。這種方法不需要客戶端支持,但是需要公共空間來保持歷史記錄。?
c.使用時(shí)間戳。做法就是認(rèn)證信息中含有時(shí)間信息,這樣服務(wù)器端就可以拒絕時(shí)間相隔太長的請求,認(rèn)為其已經(jīng)過期。這種做法需要服務(wù)器端和客戶端有某種形式的時(shí)間同步。?
4.要不要使用HTTPS??
如果安全度要求很高或者是針對internet的API,無疑應(yīng)該使用HTTPS,來避免內(nèi)容被竊取的可能。?
如果只是在局域網(wǎng)范圍或者可信賴的計(jì)算環(huán)境,則使用HTTP來提高一點(diǎn)效率。?
創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來咯,堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)總結(jié)
以上是生活随笔為你收集整理的Restful HMAC认证的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 数据结构与算法总结(完结)
- 下一篇: 软件过程