認(rèn)證與會(huì)話(huà)管理

認(rèn)證與會(huì)話(huà)管理

認(rèn)證和授權(quán)是兩個(gè)事情，認(rèn)證是為了認(rèn)出用戶(hù)是誰(shuí)，授權(quán)是為了決定用戶(hù)可以做什么。

密碼認(rèn)證

密碼是最簡(jiǎn)單編輯的認(rèn)證方式，但也是最容易被突破的方式。適當(dāng)增加密碼的長(zhǎng)度/密碼字符的復(fù)雜度以及排除簡(jiǎn)單字符組合，可以有效加強(qiáng)密碼強(qiáng)度。

密碼保存一般采用不可逆的加密算法，或者是單向散列函數(shù)算法加密后放到數(shù)據(jù)庫(kù)中。但是這樣還是有可能被黑客使用"彩虹表"的方法破譯。

彩虹表的策略是收集盡可能多的密碼原文和加密值的對(duì)應(yīng)，根據(jù)這樣的鍵值對(duì)去匹配就好了，應(yīng)對(duì)這樣的破譯最好的方法就是加一個(gè)salt。

slat 就是在加密密碼的時(shí)候加上一個(gè)隨機(jī)的字符串，只要這個(gè)隨機(jī)的 salt 不被竊取,破譯就是非常困難的。即便被竊取,彩虹表也需要根據(jù) salt 來(lái)調(diào)整。

多因素認(rèn)證

除了支付密碼外，手機(jī)動(dòng)態(tài)口令/數(shù)字證書(shū)/第三方證書(shū)甚至刷臉/指紋等都可以作為用戶(hù)認(rèn)證的手段

Session認(rèn)證

密碼和證書(shū)等認(rèn)證只能用在登錄的時(shí)候，登錄后就需要使用SessionID來(lái)認(rèn)證，常見(jiàn)的做法是把sessionId放到cookie中。因?yàn)閏ookie會(huì)隨著http請(qǐng)求發(fā)送,并且受到同源策略的保護(hù)

sessionID是用戶(hù)登錄后的唯一憑證，一旦被黑客使用XSS等方式竊取后，就可以偽裝成用戶(hù)來(lái)完成一系列操作

Session Fixation

簡(jiǎn)單來(lái)說(shuō)就是 X 先獲取一個(gè)未認(rèn)證的 seesionID,然后把這個(gè) id 給 Y，Y 去完成認(rèn)證后，X 就是使用這個(gè) sessionID 來(lái)偽裝成 Y 操作了

最關(guān)鍵的核心是服務(wù)器在 Y 完成認(rèn)證后，并沒(méi)有去更新 Y 的 sessionID，所以只要我們?cè)谟脩?hù)登錄后，重寫(xiě) SessionId，就可以有效的避免這個(gè)問(wèn)題.

單點(diǎn)登錄(SSO)

單點(diǎn)登錄希望用戶(hù)只需要登錄一次，就可以訪(fǎng)問(wèn)所有的系統(tǒng)

它的優(yōu)點(diǎn)在于風(fēng)險(xiǎn)集中，只需要保護(hù)好一個(gè)點(diǎn)就行,缺點(diǎn)在于風(fēng)險(xiǎn)太高，一旦被攻破，后果很?chē)?yán)重

比較流行的是 OpenId

訪(fǎng)問(wèn)控制

權(quán)限控制，抽象的說(shuō)，就是某個(gè)主體需要實(shí)施某種操作，而系統(tǒng)對(duì)這種操作的限制就是權(quán)限控制

垂直權(quán)限管理

訪(fǎng)問(wèn)控制實(shí)際上建立用戶(hù)和權(quán)限之間的對(duì)應(yīng)關(guān)系，下面我們介紹一種基于角色的訪(fǎng)問(wèn)控制 ( Role-Base Access Control ) RBAC

簡(jiǎn)單來(lái)說(shuō)就是一個(gè)系統(tǒng)會(huì)定義不同的角色，不同的角色有不同的權(quán)限，系統(tǒng)中的用戶(hù)會(huì)被分配多個(gè)不同的角色從而獲得不同的權(quán)限.系統(tǒng)在驗(yàn)證權(quán)限的時(shí)候，只需要驗(yàn)證角色就可以了。

常見(jiàn)的如 Spring Security 提供基于 url 和基于 method 的控制

不同的角色權(quán)限有高低之分，高權(quán)限訪(fǎng)問(wèn)低權(quán)限是可以的，低的訪(fǎng)問(wèn)搞的是被禁止的。如果低的獲取了高的權(quán)限,則發(fā)生了"越權(quán)訪(fǎng)問(wèn)"

配置權(quán)限,應(yīng)當(dāng)遵循最小權(quán)限原則，并且使用 默認(rèn)拒絕 的策略

水平權(quán)限管理

相對(duì)于垂直權(quán)限管理來(lái)說(shuō)，水平權(quán)限問(wèn)題出在同一個(gè)角色上，系統(tǒng)只驗(yàn)證了能訪(fǎng)問(wèn)數(shù)據(jù)的角色，而沒(méi)有對(duì)角色的用戶(hù)做細(xì)分，也沒(méi)有對(duì)數(shù)據(jù)子集做細(xì)分，因此缺乏一個(gè)用戶(hù)到數(shù)據(jù)的映射關(guān)系。由于水平權(quán)限管理是系統(tǒng)一個(gè)數(shù)據(jù)級(jí)的訪(fǎng)問(wèn)控制造成的，所以水平權(quán)限管理又稱(chēng)為 基于數(shù)據(jù)的訪(fǎng)問(wèn)控制。

OAuth

OAuth 解決授權(quán)問(wèn)題，OpenId 解決認(rèn)證問(wèn)題

OAuth 允許用戶(hù)在不將第三方網(wǎng)站的用戶(hù)密碼暴露的情況，授權(quán)其他網(wǎng)站使用第三方的數(shù)據(jù)

密碼

密碼系統(tǒng)的安全性應(yīng)該依賴(lài)于秘鑰的復(fù)雜性，而不是算法的保密性。

密碼管理最常見(jiàn)的錯(cuò)誤,就是把秘鑰硬編碼在代碼里，同樣的，將加密秘鑰/簽名的salt等 "key" 硬編碼在代碼中，是很不好的習(xí)慣。

硬編碼的秘鑰可能通過(guò)以下方式泄露:

• 代碼被廣泛傳播，常見(jiàn)于框架，或者被反編譯的代碼

• 團(tuán)隊(duì)成員都可以獲取，流動(dòng)性較大的話(huà)

常見(jiàn)的管理辦法是將秘鑰保存在配置文件或者數(shù)據(jù)庫(kù)中，能接觸到配置文件和數(shù)據(jù)庫(kù)的人要越少越好,權(quán)限控制要格外注意。

發(fā)布到生產(chǎn)環(huán)境的時(shí)候，需要生產(chǎn)新的密碼或密碼

source:https://www.yuque.com/heyuqing/hgukev/ihmsxo

喜歡，在看