如何獲取伺服器的認證方法

① 如何申請SSL證書

一、製作CSR文件
CSR就是Certificate Secure Request證書請求文件。這個文件是由申請人製作，在製作的同時，系統會產生2個密鑰，一個是公鑰就是這個CSR文件，另外一個是私鑰，存放在伺服器上。要製作CSR文件，申請人可以參考WEB SERVER的文檔，一般APACHE等，使用OPENSSL命令行來生成KEY+CSR2個文件，Tomcat，JBoss，Resin等使用KEYTOOL來生成JKS和CSR文件，IIS通過向導建立一個掛起的請求和一個CSR文件。另外，也可以通過沃通CA提供的CSR在線生成工具在線生成，或者聯系沃通CA工作人員協助生成。
二、CA認證
將CSR提交給我們的工作人員，一般有2種認證方式：
1、域名認證，一般通過對管理員郵箱認證的方式，這種方式認證速度快，但是簽發的證書中沒有企業的名稱；
2、企業文檔認證，需要提供企業的營業執照。一般需要3-5個工作日。
三、證書的安裝
在收到我們發給您的CA證書後，可以將證書部署上伺服器，一般APACHE文件直接將KEY+CER復制到文件上，然後修改HTTPD.CONF文件；TOMCAT等，需要將CA簽發的證書CER文件導入JKS文件後，復制上伺服器，然後修改SERVER.XML；IIS需要處理掛起的請求，將CER文件導入。
以上，依然不知道如何申請，可以聯系沃通CA為您提供更加詳細周到的幫助。

② 如何使用HttpClient認證機制

HttpClient三種不同的認證方案: Basic, Digest and NTLM. 這些方案可用於伺服器或代理對客戶端的認證，簡稱伺服器認證或代理認證。
1．伺服器認證(Server Authentication)
HttpClient處理伺服器認證幾乎是透明的，僅需要開發人員提供登錄信息(login
credentials)。登錄信息保存在HttpState類的實例中，可以通過 setCredentials(String realm,
Credentials cred)和getCredentials(String realm)來獲取或設置。
HttpClient內建的自動認證，可以通過HttpMethod類的setDoAuthentication(boolean doAuthentication)方法關閉，而且這次關閉隻影響HttpMethod當前的實例。

1.1搶先認證(Preemptive Authentication)
在這種模式時，HttpClient會主動將basic認證應答信息傳給伺服器，即使在某種情況下伺服器可能返回認證失敗的應答，這樣做主要是為了減少連接的建立。使用該機制如下所示：
client.getParams().setAuthenticationPreemptive(true);

搶先認證模式也提供對於特定目標或代理的預設認證。如果沒有提供預設的認證信息，則該模式會失效。
Credentials defaultcreds = new UsernamePasswordCredentials("username", "password");
client.getState().setCredentials(new AuthScope("myhost", 80, AuthScope.ANY_REALM), defaultcreds);

Httpclient實現的搶先認證遵循rfc2617.
A
client SHOULD assume that all paths at or deeper than the depth of the
last symbolic element in the path field of the Request-URI also are
within the protection space specified by the Basic realm value of the
current challenge. A client MAY preemptively send the corresponding
Authorization header with requests for resources in that space without
receipt of another challenge from the server. Similarly, when a client
sends a request to a proxy, it may reuse a userid and password in the
Proxy-Authorization header field without receiving another challenge
from the proxy server.

1.2伺服器認證的安全方面考慮
當需要與不被信任的站點或web應用通信時，應該謹慎使用預設的認證機制。當啟動(activate)搶先認證模式，或者認證中沒有明確給出認證域，主機的HttpClient將使用預設的認證機制去試圖獲得目標站點的授權。
如果你提供的認證信息是敏感的，你應該指定認證域。不推薦將認證域指定為AuthScope.ANY。（只有在debugging情況下，才使用）
// To be avoided unless in debug mode
Credentials defaultcreds = new UsernamePasswordCredentials("username", "password");
client.getState().setCredentials(AuthScope.ANY, defaultcreds);

2.代理認證(proxy authentication)
除了登錄信息需單獨存放以外，代理認證與伺服器認證幾乎一致。用 setProxyCredentials(String realm, Credentials cred)和 getProxyCredentials(String realm)設、取登錄信息。
3.認證方案(authentication schemes)
3.1Basic
是HTTP中規定最早的也是最兼容的方案，遺憾的是也是最不安全的一個方案，因為它以明碼傳送用戶名和密碼。它要求一個UsernamePasswordCredentials實例，可以指定伺服器端的訪問空間或採用默認的登錄信息。

3.2 Digest
是在HTTP1.1 中增加的一個方案，雖然不如Basic得到的軟體支持多，但還是有廣泛的使用。Digest方案比Basic方案安全得多，因它根本就不通過網路傳送實際的密碼，傳送的是利用這個密碼對從伺服器傳來的一個隨機數(nonce)的加密串。
它要求一個UsernamePasswordCredentials實例，可以指定伺服器端的訪問空間或採用默認的登錄信息。

3.3 NTLM
這是HttpClient支持的最復雜的認證協議。它Microsoft設計的一個私有協議，沒有公開的規范說明。一開始由於設計的缺陷，NTLM的安全性比 Digest差，後來經過一個ServicePack補丁後，安全性則比較Digest高。
NTLM需要一個NTCredentials實例。
注意，由於NTLM不使用訪問空間(realms)的概念，HttpClient利用伺服器的域名作訪問空間的名字。還需要注意，提供給
NTCredentials的用戶名，不要用域名的前綴 - 如: "adrian" 是正確的，而 "DOMAIN\adrian" 則是錯的。
NTLM認證的工作機制與basic和digest有很大的差別。這些差別一般由HttpClient處理，但理解這些差別有助避免在使用NTLM認證時出現錯誤。
[1] 從HttpClientAPI的角度來看，NTLM與其它認證方式一樣的工作，差別是需要提供'NTCredentials'實例而不是'UsernamePasswordCredentials'(其實，前者只是擴展了後者)
[2] 對NTLM認證，訪問空間是連接到的機器的域名，這對多域名主機會有一些麻煩。只有HttpClient連接中指定的域名才是認證用的域名。建議將realm設為null以使用默認的設置。
[3]
NTLM只是認證了一個連接而不是一請求，所以每當一個新的連接建立就要進行一次認證，且在認證的過程中保持連接是非常重要的。
因此，NTLM不能同時用於代理認證和伺服器認證，也不能用於HTTP1.0連接或伺服器不支持持久連接(keep-alives)的情況。
關於NTLM認證機制更詳細的研究 。

3.4選擇認證
一些伺服器支持多種認證方案。假設一次只能使用一種認證方案，HttpClient必須選擇使用哪種。HttpClient選擇是基於NTLM, Digest, Basic順序的。
在具體情況下，可以更改該順序。可通過參數'http.auth.scheme-priority'來實現，該參數值應該被存放在一個String類型的List中。選擇優先順序是按插入順序確定的。
HttpClient client = new HttpClient();
List authPrefs = new ArrayList(2);
authPrefs.add(AuthPolicy.DIGEST);
authPrefs.add(AuthPolicy.BASIC);
// This will exclude the NTLM authentication scheme
client.getParams().setParameter(AuthPolicy.AUTH_SCHEME_PRIORITY, authPrefs);

③ ssl 伺服器如何驗證

主機偵探SSL證書商城()專售Symantec、Geotrust、Comodo以及RapidSSL等多家全球權威CA機構的SSL數字證書。我們提供多品牌、多類型SSL證書申請和安裝服務，免手續費，全程專業技術指導。

④ WIFI要網路認證，怎麼認證，求解答！

網路連接被禁用，解決方法：

（1）在桌面點擊「控制面板」，進入控制面板頁面。

⑤ 目前在防火牆上提供了幾種認證方法

用戶是指訪問網路資源的主提，表示「誰」在進行訪問，是網路訪問行為的重要標識。

用戶分類：

上網用戶

內部網路中訪問網路資源的主體，如企業總部的內部員工。上網用戶可以直接通過FW訪問網路資源。

接入用戶

外部網路中訪問網路資源的主體，如企業的分支機構員工和出差員工。接入用戶需要先通過SSL VPN、L2TP VPN、IPSec VPN或PPPoE方式接入到FW，然後才能訪問企業總部的網路資源。

管理用戶

認證分類：

防火牆通過認證來驗證訪問者的身份，防火牆對訪問正進行的認證方式有：

本地認證

訪問者通過Portal認證頁面將標識其身份的用戶名和密碼發送給FW，FW上存儲了密碼，驗證過程在FW上進行，該方式稱為本地認證。

伺服器認證（Radius，LDAP等）

訪問者通過Portal認證頁面將標識其身份的用戶名和密碼發送給FW，FW上沒有存儲密碼，FW將用戶名和密碼發送至第三方認證伺服器，驗證過程在認證伺服器上進行，該方式稱為伺服器認證。

RADIUS（Remote Authentication Dial In User Service）、HWTACACS（HuaWei Terminal Access Controller Access Control System）、AD、LDAP（Lightweight Directory Access Protocol）認證伺服器，並在認證伺服器上存儲了用戶/組和密碼等信息。對於RADIUS、HWTACACS伺服器，管理員需要根據現有的組織結構，在FW上手動創建或者使用文件批量導入相應的用戶/組。對於AD或LDAP伺服器，管理員可以將AD或LDAP伺服器中的用戶信息導入到FW上，以便後續管理員可以在FW上通過策略來控制不同用戶/組對網路的訪問行為。

單點登錄

訪問者將標識其身份的用戶名和密碼發送給第三方認證伺服器，認證通過後，第三方認證伺服器將訪問者的身份信息發送給FW。FW只記錄訪問者的身份信息不參與認證過程，該方式稱為單點登錄（Single Sign-On）。

簡訊認證

訪問者通過Portal認證頁面獲取簡訊驗證碼，然後輸入簡訊驗證碼即通過認證。FW通過校驗簡訊驗證碼認證訪問者。

認證的目的：

在FW上部署用戶管理與認證，將網路流量的IP地址識別為用戶，為網路行為控制和網路許可權分配提供了基於用戶的管理維度，實現精細化的管理：

基於用戶進行策略的可視化制定，提高策略的易用性。基於用戶進行威脅、流量的報表查看和統計分析，實現對用戶網路訪問行為的追蹤審計。解決了IP地址動態變化帶來的策略控制問題，即以不變的用戶應對變化的IP地址。上網用戶訪問網路的認證方式：

免認證：

FW通過識別IP/MAC和用戶的雙向綁定關系，確定訪問者的身份。進行免認證的訪問者只能使用特定的IP/MAC地址來訪問網路資源。

會話認證：

當用戶訪問HTTP業務時，FW向用戶推送認證頁面，觸發身份認證。

一般指的都是本地認證） ----內置Portal認證
先發起HTTP/HTTPS業務訪問-------防火牆推送重定向認證頁面-----------客戶輸入用戶名和密碼----------認證成功，如果設置跳轉到最近的頁面，就跳轉。如果沒有設置跳轉，就不跳轉

事前認證

當用戶訪問非HTTP業務時，只能主動訪問認證頁面進行身份認證。

單點認證

AD單點登錄：企業已經部署了AD（Active Directory）身份驗證機制，AD伺服器上存儲了用戶/組和密碼等信息。管理員可以將AD伺服器上的組織結構和賬號信息導入到FW。對於AD伺服器上新創建的用戶信息，還可以按照一定的時間間隔定時導入。以便後續管理員可以在FW上通過策略來控制不同用戶/組對網路的訪問行為。

認證時，由AD伺服器對訪問者進行認證，並將認證信息發送至FW，使FW能夠獲取用戶與IP地址的對應關系。訪問者通過AD伺服器的認證後，就可以直接訪問網路資源，無需再由FW進行認證，這種認證方式也稱為「AD單點登錄」。

Agile Controller單點登錄

RADIUS單點登錄

RADIUS認證原理：

圖：旁路模式下RADIUS單點登錄示意圖

RADIUS單點登錄交互過程如下:

訪問者向接入設備NAS發起認證請求。

NAS設備轉發認證請求到RADIUS伺服器，RADIUS伺服器對用戶賬號和密碼進行校驗，並將認證通過的結果返回給NAS設備。NAS設備向RADIUS伺服器發送計費開始報文，標識用戶上線。

FW解析計費開始報文獲取用戶和IP地址的對應關系，同時在本地生成在線用戶信息。不同部署方式，FW獲取計費開始報文的方式不同：

直路：FW直接對經過自身的RADIUS計費開始報文進行解析。

旁路：NAS設備向RADIUS伺服器發送計費開始報文的同時還會向FW發送一份，FW對計費開始報文進行解析並對NAS設備做出應答。

此種部署方式需要NAS設備支持向FW發送計費開始報文的功能。

鏡像引流：NAS設備和RADIUS伺服器之間交互的計費開始報文不經過FW，需要通過交換機鏡像或分光器分光的方式復制一份計費開始報文到FW。FW對計費開始報文進行解析後丟棄。

訪問者注銷時，NAS設備向RADIUS伺服器發送計費結束報文，標識用戶下線。FW獲取計費結束報文並解析用戶和IP對應關系，然後刪除本地保存的在線用戶信息，完成注銷過程。

另外在用戶在線期間，NAS設備還會定時向RADIUS伺服器發送計費更新報文維持計費過程，FW獲取計費更新報文後將刷新在線用戶的剩餘時間。

接入用戶訪問網路資源的認證方式：

使用SSL VPN 技術

訪問者登錄SSL VPN模塊提供的認證頁面來觸發認證過程，認證完成後，SSL VPN接入用戶可以訪問總部的網路資源。

使用IPSec VPN技術

分支機構與總部建立IPSec VPN隧道後，分支機構中的訪問者可以使用事前認證、會話認證等方式觸發認證過程，認證完成後，IPSec VPN接入用戶可以訪問總部的網路資源。

L2TP VPN接入用戶

用戶認證原理用戶組織結構：

用戶是網路訪問的主體，是FW進行網路行為控制和網路許可權分配的基本單元。

認證域：用戶組織結構的容器。區分用戶，起到分流作用

用戶組/用戶：分為： 父用戶組 子用戶組 。

注意：一個子用戶組只能屬於一個父用戶組

用戶： 必配： 用戶名 密碼，其它都可以可選

用戶屬性：賬號有效期 允許多人登錄 IP/MAC綁定（不綁定 單向 雙向）

安全組：橫向組織結構的跨部門群組。指跨部門的用戶

規劃樹形組織結構時必須遵循如下規定：default認證域是設備默認自帶的認證域，不能被刪除，且名稱不能被修改。設備最多支持20層用戶結構，包括認證域和用戶，即認證域和用戶之間最多允許存在18層用戶組。每個用戶組可以包括多個用戶和用戶組，但每個用戶組只能屬於一個父用戶組。一個用戶只能屬於一個父用戶組。用戶組名允許重名，但所在組織結構的全路徑必須確保唯一性。用戶和用戶組都可以被策略所引用，如果用戶組被策略引用，則用戶組下的用戶繼承其父組和所有上級節點的策略。用戶、用戶組、安全的來源：手動配置CSV格式導入（批量導入）伺服器導入設備自動發現並創建在線用戶：

用戶訪問網路資源前，首先需要經過FW的認證，目的是識別這個用戶當前在使用哪個IP地址。對於通過認證的用戶，FW還會檢查用戶的屬性（用戶狀態、賬號過期時間、IP/MAC地址綁定、是否允許多人同時使用該賬號登錄），只有認證和用戶屬性檢查都通過的用戶，該用戶才能上線，稱為在線用戶。

FW上的在線用戶表記錄了用戶和該用戶當前所使用的地址的對應關系，對用戶實施策略，也就是對該用戶對應的IP地址實施策略。

用戶上線後，如果在線用戶表項超時時間內（預設30分鍾）沒有發起業務流量，則該用戶對應的在線用戶監控表項將被刪除。當該用戶下次再發起業務訪問時，需要重新進行認證。

管理員可以配置在線用戶信息同步，查看到已經通過認證的在線用戶，並進行強制注銷、全部強制注銷、凍結和解凍操作。

用戶認證總體流程：

圖：認證流程示意圖認證策略:

認證策略用於決定FW需要對哪些數據流進行認證，匹配認證策略的數據流必須經過FW的身份認證才能通過。

預設情況下，FW不對經過自身的數據流進行認證，需要通過認證策略選出需要進行認證的數據流。

如果經過FW的流量匹配了認證策略將觸發如下動作：

會話認證：訪問者訪問HTTP業務時，如果數據流匹配了認證策略，FW會推送認證頁面要求訪問者進行認證。事前認證：訪問者訪問非HTTP業務時必須主動訪問認證頁面進行認證，否則匹配認證策略的業務數據流訪問將被FW禁止。免認證：訪問者訪問業務時，如果匹配了免認證的認證策略，則無需輸入用戶名、密碼直接訪問網路資源。FW根據用戶與IP/MAC地址的綁定關系來識別用戶。單點登錄：單點登錄用戶上線不受認證策略控制，但是用戶業務流量必須匹配認證策略才能基於用戶進行策略管控。

認證匹配依據：

源安全區域、目的安全區域、源地址/地區、目的地址/地區。

注意：認證策略在匹配是遵循從上往下的匹配策略。

預設情況下，FW通過8887埠提供內置的本地Portal認證頁面，用戶可以主動訪問或HTTP重定向至認證頁面（https://介面IP地址:8887）進行本地Portal認證。

在線用戶信息同步功能的服務埠，預設值是8886。

用戶認證配置思路會話認證配置思路：第一步： 基本配置（通信正常） 第二步：新建用戶（供本地認證使用） 第三步：認證選項設置重定向跳轉到最近的頁面 注意：要點應用 第四步：默認重定向的認證埠為8887，需要放行安全策略 ip service-set authro_port type object service 0 protocol tcp source-port 0 to 65535 destination-port 8887 sec-policy rule name trust_loacl source-zone trust destination-zone local service authro_port action permit 第五步：配置認證策略 auth-policy rule name trust_untrust source-zone trust destination-zone untrust source-address 10.1.1.0 mask 255.255.255.0 action auth -------------------默認不認證，修改為認證 第六步：檢查 成功以後必須要有在線用戶 1617181920212223242526272829免認證配置思路：配置： auth-policy rule name no_auth source-zone trust destination-zone untrust source-address 10.1.1.2 mask 255.255.255.255 action no-auth 12345671234567AD單點登錄配置流程：

插件

Server伺服器部分
第一步：安裝AD域
第二步：安裝DNS伺服器----配置轉發器
第三步：下載AD SSO（在防火牆下載）

第四步：AD域新建組織單元，新建組，新建用戶（關聯許可權）
第五步：PC 加域（DNS修改為伺服器地址）
第六步：安裝AD SSO (建議安裝二次AD SSO）

聯動AD域聯動FW

第七步：組策略配置登錄和注銷腳本
調用AD SSO產生的login
格式;
伺服器地址 運行埠（AD SSO是一樣） 0/1 設置密鑰（Huawei@123）

第八步：PC刷新組策略

防火牆部分

第一步：新建防火牆與AD伺服器聯動

第二步：新建認證域

第三步：把AD伺服器用戶導入FW ，新建導入策略

第四步： 修改認證域新用戶，新用戶調用導入策略

第五步：導入用戶，到用戶列表檢查

第六步：配置認證策略
Trust區域到伺服器區域（DMZ）不能做認證

第七步：配置安全策略，匹配條件只能是AD域的用戶

注意：
FW本地到AD伺服器的安全策略
AD伺服器到FW本地安全策略

DNS的策略

檢查：
一定要看到在線用戶-----採用單點登錄

參考文檔：華為HedEx防火牆文檔。

⑥ 微信小程序 HTTPS 請求，如何獲取免費證書配置伺服器

一、SSL證書，信任符合ATS要求不存在免費，需要簽發機構辦理認證的：網頁鏈接

二、微信小程序ATS程序要求：伺服器支持TLSv1.2協議、PFS（完全正向保密）ECDHE

三、HTTPS請求需要一台獨立伺服器，並且拿到證書需要專業人員部署到伺服器才可以運行，當然如果不會安裝可以讓簽發機構代理部署。

註：如果是商業用途，有一定經濟目的的，使用正規的收費產品，很多質量與安全是買來的。

⑦ https怎麼獲得證書，網站https訪問證明弄

HTTPS認證、HTTPS證書，可以在淘寶裡面找到Gworg申請。

申請HTTPS證書：

解釋原因：

1. 確定並且列出具體需要的域名。

2. 進入淘寶中找到Gworg並且選擇HTTPS證書。

3. 根據提示完成HTTPS域名認證。

4. 獲得HTTPS證書並且安裝到伺服器。

解決辦法：Gworg認證並且活動和HTTPS證書。

⑧ 如何實現用戶認證授權系統

一旦用戶注冊之後，用戶信息就保存在伺服器端（DB/Cache）。關鍵在於用戶需要提供身份憑證，一般是用戶名和密碼。即常見的登陸頁面：用戶輸入username和password，勾選Remember Me（可選，一般是記住一周），點擊登陸，提交請求到服務端（這里一般是走HTTPS）。服務端根據用戶名和密碼到資料庫查詢是否匹配，如果匹配的話，說明身份認證成功。這是一次普通的身份認證過程。非常好理解。

關鍵在於HTTP是無狀態的，用戶登陸過一次，但是如果你沒有做一些狀態管理操作的話，用戶登陸後請求同一個頁面，伺服器仍然要求其登陸。這時候就需要做一些狀態處理了。一般是通過伺服器頒發一個登陸憑證(sessionkey/token/ticket)實現的。那麼這個登陸憑證是怎麼生成的？又是怎樣安全的頒發給客戶端呢？

方案一：session集群 + 隨機sessionId
用戶登陸成功之後，伺服器為其隨機生成的一個sesionId，保存在session伺服器中，將這個sessionId與用戶關聯起來：sessionId=>userId。然後通過cookies方式將sessionId頒發給客戶端，瀏覽器下次請求會自動帶上這個sessionId。伺服器根據sessionId從session伺服器中拿到關聯的userId，比較是否與請求的userId相同，如果是則認為是合法請求。

sessionId是隨機生成的，基本來說是不可能被猜測出來的，所以這方面的安全還是有一定保障的。

方案二：session-less + 加密演算法
上面的Authentication方式其實是用到了session和cookies。我們知道session這東西是服務端狀態，而服務端一旦有狀態，就不是很好線性擴展。其實對於身份驗證來說，服務端保留的也這是一個簡單的value而已，一般是userId，即session['sessionId']==>userId。然後再根據userId去DB獲取用戶的詳細信息。如果我們把userId作為一個cookies值放在客戶端，然後把用幾個cookies值（比如userId）做一個特殊的簽名演算法得到的token也放在cookie中，即f(userId, expireTime)==>token。這樣服務端得到用戶請求，用同樣的簽名演算法進行計算，如果得到的token是相等，那麼證明這個用戶是合法的用戶。注意這個簽名演算法的輸入因子必須包含過期時間這樣的動態因子，否者得到的token永遠是固定的。這種實現方式其實是仿造CSRF防禦機制anti-csrf.md。是筆者自己想出來的，不清楚有沒有人用過，個人感覺行得通。

然而上面的做法安全性取決於簽名演算法的隱蔽性，我們可以更進一步的，可以參考API中的簽名驗證方式，把password作為secretKey，把userId, expireTime, nonce, timestamp作為輸入參數，同樣用不公開的演算法（這個與API簽名不同）結合password這個secretKey進行計算，得到一個簽名，即f(userId, expireTime, nonce, timestamp, password)==>sign。每次客戶端傳遞userId, expireTime, nonce, timestamp和sign值，我們根據userId獲取到password，然後進行f(userId, expireTime, nonce, timestamp, password)==>sign計算，然後比較兩個sign是否一致，如果是，表示通過。這種方式比起上面的方式其實區別在於增加了password作為輸入參數。這樣首先增加簽名的破解難度。還帶來一個額外的好處，就是當用戶修改了password之後，這個token就失效了，更合理安全一些。

具體步驟如下：

1. 客戶端 >>>

用戶輸入userId和password，form表單提交到後台進行登錄驗證（這里最好走HTTPS）。
2. <<< 服務端

服務端根據userId，從用戶信息表中得到用戶注冊時保存的密碼簽名：S=md5(password)。
伺服器驗證用戶信息：userId == DB.userId; md5(password) == DB.S。
如果驗證通過，說明用戶身份認證通過。這時候伺服器會為客戶端分配一個票據(簽名)：token=md5(userId;tokenExpiryTime;S;secretKey)。其中secretKey是一個後台統一的密鑰，而且跟DB是分開的，一般是寫在配置文件中。目的很明顯，就是避免將雞蛋放在同一個籃子中。然後服務端將這個token值存放在cookies中。同樣放入cookies中的還有userId和tokenExpiryTime。這些cookies的過期時間都是tokenExpiryTime。
3. 客戶端 >>>

客戶端每次請求都要帶上這個三個cookies(瀏覽器自動會帶上)。
4. <<< 服務端

伺服器首先檢查tokenExpiryTime是否過期了，如果過期就要求用戶重新登錄。否則，根據userId cookie從用戶信息表中獲取用戶信息。然後計算expectedToken=md5(userId;tokenExpiryTime;S;secretKey)。然後比較expectedToken是否跟用戶提交的token相同，如果相同，表示驗證通過；否則表示驗證失敗。
說明

為了增加安全性，可以進一步將userId, tokenExpiryTime; token 這個三個cookies進行一次對稱加密: ticket=E(userId:tokenExpiryTime:token)。
雖然cookies的值是沒有加密的，但是由於有簽名的校驗。如果黑客修改了cookie的內容，但是由於他沒有簽名密鑰secretKey，會導致簽名不一致。
google了一下，發現這篇文章跟我的觀點不謀而合Sessionless_Authentication_with_Encrypted_Tokens。另外看了一下Spring Security的Remember Me實現，原來這種方式是5.2. Simple Hash-Based Token Approach方式。他的hash因子中也有password，這樣當用戶修改了password之後，這個token就失效了。

這種基於password和secretKey做token的鑒權方式實現非常簡單，而且客戶端沒有任何計算和驗證邏輯，非常適合於BS架構的。不過這種方式在安全性方面還有一些問題：

客戶端沒法驗證伺服器的真實性。域名劫持的情況很容易偽造伺服器。
token放在cookies中，還是容易被盜取（比如XSS漏洞，或者網路竊聽）。使用動態token可以避免這個問題，但是需要持久化token，比較麻煩，而且對性能有消耗5.3 Persistent Token Approach。
一個簡單而有效的解決方案就是使用HTTPS。HTTPS使用CA證書驗證伺服器的合法性，全程會話（包括cookies）都是經過加密傳輸，剛好解決了上面的兩個安全問題。很多網站都是使用這種鑒權認證方案。比如GitHub。不過安全性要求不是很高的網站還是採用的是登陸認證的時候HTTPS，其他情況HTTP的方式，比如新浪微博、亞馬遜、淘寶、quora等。

TIPS SSO

上面的鑒權方式依賴於Cookies來傳遞sessionId，而我們知道Cookies具有跨域限制。不過可以通過一些方式解決。具體可以看一下這篇文章，寫的非常好。Building and implementing a Single Sign-On solution。

上面的想法是把password作為一個secretKey或者Salt進行簽名。還有另一種思路，就是把password作為對稱密鑰來進行加密解密。具體步驟如下：

1. 客戶端 >>>

用戶輸入userId和password
客戶端用userId和password 計算得到一個簽名：H1=md5(password), S1'=md5(H1 + userId)
客戶端構造一個消息：message=randomKey;timestamp;H1;sigData。其中randomKey是一個16位的隨機數字；SigData為客戶端的基本信息，比如userId, IP等。
客戶端用對稱加密演算法(推薦使用性能極高的TEA)對這個消息進行加密：A1=E(S1', message)，對稱密鑰就是上面的S1'，然後將userId和A1發送給服務端。
2. <<< 服務端

接收客戶端發送的userId和A1。
根據userId，從用戶信息表中得到用戶注冊時保存的簽名S1=md5(H1 + userId)。注意伺服器保存的不是H1。這個簽名就是前面對稱加密(TEA)的對稱密鑰。而且正常情況應該跟客戶端根據用戶輸入的userId和password計算出來的S1'是一樣的。
服務端嘗試用S1解密A1。如果解密異常，則提示登陸失敗。如果解密成功，則按照約定格式，得到message=randomKey;timestamp;H1;sigData
伺服器對message中的用戶信息進行驗證
比較 message.sigData.userId == DB.userId; 如果不一樣，那麼很有可能數據曾被篡改，或者這是一個偽造的登錄的請求，提示登錄失敗；
比較 message.timestamp與伺服器當前的時間，如果差距較大，則拒絕登錄，可以從很大程度上防止重放攻擊。大家可能都有過經驗，當本地時間與真實時間有較大差距的時候，總是會登錄失敗，其實就是伺服器對客戶端時間進行校驗的原因。
比較 md5(message.H1 + message.sigData.userId) == DB.S1。如果不一致，則登陸失敗。
如果驗證通過，說明用戶身份認證通過，伺服器同樣構造了一個消息：serverMessage=whaterver you want，一般是登陸憑證，如sessionkey或者token. 然後用客戶端發送過來的randanKey進行對稱加密：A2=E(randanKey, serverMessage)，然後把A2返回給客戶端。
3. 客戶端 >>>

客戶端拿到A2，用randanKey進行解密，如果可以解密成功，則認為是來自真實伺服器的數據，而不是一台偽造的伺服器，整個登陸流程完成。這個步驟主要是為了防止伺服器偽造。這個步驟很容易被忽略，客戶端應該和伺服器一樣，要對接受的數據保持不信任的態度。
這個方案雖然沒有使用HTTPS，但是思路跟HTTPS很類似。安全性也很高。

說明

上面的認證過程其實就是著名的網路認證協議Kerberos的認證過程。Kerberos是一種計算機網路認證協議，它允許某實體在非安全網路環境下通信，向另一個實體以一種安全的方式證明自己的身份。它的設計主要針對客戶-伺服器模型，並提供了一系列交互認證——用戶和伺服器都能驗證對方的身份。Kerberos協議可以保護網路實體免受竊聽和重復攻擊。QQ的登錄協議都是基於Kerberos的思想而設計的。不過Kerberos也有一些安全性的問題。SRP協議Secure Remote Password protocol要更安全一些。據說是目前安全性最好的安全密碼協議。
為什麼DB保存S1而不是H1。這是為了提高批量暴力破解的成本。對經過兩次MD5加密，再加上userId作為salt，得到的S1進行暴露反推pasword基本是不可能的。而反推H1的話，由於H1的是password的MD5值，相對於password來說強度要增強不少。這個讀者可以自己試試md5('123456')看得到的H1就有直觀的認識了。
為什麼服務端解開對稱加密後的message之後還要對message的內容進行驗證。這是為了避免拖庫後的偽造登錄。假設被拖庫了，黑客拿到用戶的S1，可以偽造用戶登錄（因為我們的加密演算法是公開的）。它能夠通過伺服器第一個驗證，即服務端使用存儲的S1能夠解開消息；但是無法通過第二個驗證，因為H1隻能是偽造的，這是因為根據S1反推H1是很困難的（原因見上面Note.2）。
但是雖然上面的協議可以防止黑客拖庫後偽造用戶登陸，卻無法防止黑客拖庫後偽造伺服器，以及進行中間人攻擊。拖庫之後，黑客擁有DB.S1，協議又是公開的，這相當於黑客擁有了偽造Server的能力。黑客通過DB.S1解開客戶端發送的A1，得到userId, H1=MD5(pwd), 以及randomKey。這樣，黑客就可以輕易的得到被監聽用戶的H1了，而不需要通過S1進行反推。黑客就可以直接用H1偽造合法的用戶登錄請求了。如果pwd不夠復雜，那麼還很容易被暴力破解。黑客攔截客戶請求，利用破解得出的randomKey回復一個假的響應，達到偽造Server的目的。黑客還可以同時偽造用戶和Server，進行中間人攻擊，從而達到竊聽用戶會話內容的目的。美國「棱鏡門」就是類似案例。甚者在必要的時候對會話內容進行篡改。當然，黑客拖庫後只能破解他監聽網路所截取到的受害用戶的MD5(pwd)，比起伺服器存MD5(pwd)的影響面窄多了，所以建議伺服器還是不要直接存MD5(pwd)。
可以在現有登陸流程基礎上加上密鑰交換演算法（如ECDH）解決上面的問題。具體流程如下：

==前置條件==

服務端生成一對私鑰serverPrivateKey和公鑰serverPublicKey，公鑰直接hardcode在客戶端，而不是通過網路傳輸。
1. 客戶端 >>>

用戶輸入userId和password
客戶端用對稱加密演算法對消息進行加密：A1=TEA(S1', randomKey;timestamp;H1;userId)，對稱密鑰S1'=md5(md5(password) + userId)`
客戶端生成自己的一對公鑰clientPublicKey和密鑰clientPrivateKey。
客戶端用serverPublicKey對A1和clientPublicKey進行非對稱加密: ECDH(serverPublicKey, userId + A1 + clientPublicKey)，然後將加密結果發送給服務端。
2. <<< 服務端

使用serverPrivateKey對客戶端發送信息進行解密，得到userId, A1 和 clientPublicKey。
根據userId，得到DB.S1。然後嘗試用DB.S1解密A1。如果解密異常，則提示登陸失敗。如果解密成功，則按照約定格式，得到message=randomKey;timestamp;H1;userId
伺服器對message中的用戶信息進行驗證:
比較 message.sigData.userId == DB.userId
比較 message.timestamp與伺服器當前的時間，如果差距較大，則拒絕登錄，可以從很大程度上防止重放攻擊
比較 md5(message.H1 + message.sigData.userId) == DB.S1
如果驗證通過，說明用戶身份認證通過。伺服器用客戶端發送過來的randanKey進行對稱加密：A2=TEA(randanKey, sessionKey + 業務票據)
服務端使用clientPublicKey對A2進行加密: ECDH(clientPublicKey, A2)， 然後把加密結果返回給客戶端。
3. 客戶端 >>>

客戶端使用clientPrivateKey對伺服器回包進行解密，得到A2。
用randanKey對A2進行解密，如果可以解密成功，則認為是來自真實伺服器的數據，而不是一台偽造的伺服器，整個登陸流程完成。
4. ==後續通訊==

由於非對稱加密演算法(如RSA、ECC)的計算復雜度相比對稱加密高3個數量級，不太可能用作通信數據的加密。所以驗證通過之後，服務端和客戶端利用ECDH交換密鑰演算法獨自計算出一樣的密鑰，後面的通訊應該還是基於對稱加密。這個跟HTTPS是類似的。

說明

加上非對稱加密之後，即使黑客知道了S1，也沒有辦法偽造伺服器，因為他不知道serverPrivateKey。黑客也不可能偽造客戶端。因為即使黑客拖庫知道S1，並且通過反編譯客戶端應用程序知道serverPublicKey，如果不是通過竊聽網路得到A1，用S1解密A1從而得到A1中的H1的情況下，基本是不可能通過S1反推H1的。現在A1包在不對稱加密演算法上，黑客如果不知道serverPrivateKey和clientPrivateKey就無法解開會話信息。

這里看到serverPublickKey是HardCode在客戶端的，而不是通過公鑰推送下發的。這里是為了保證客戶端的serverPublicKey是真正的serverPublicKey，而不是來自偽造伺服器的。如果serverPublicKey通過網路傳輸下發給客戶端的，那麼偽造伺服器在劫持網路的情況下，完全可以攔截客戶請求，發回偽造伺服器自己的fake_serverPublickKey，客戶端在不知情的情況就用fake_serverPublickKey向偽造伺服器發數據，因為fake_serverPublicKey是黑客構造的，他當然有對應的fake_serverPrivateKey解開。當然，黑客還需要知道S1才能解開A1。當然，將serverPublicKey硬編碼在客戶端會導致更換密鑰需要強制客戶端一起升級，否則老版本的客戶端將無法登陸。

客戶端自己也生成了公鑰和私鑰，目的是為了驗證伺服器是真正的伺服器，這個得以成立的前提是公鑰是真正的伺服器公鑰，如果是偽造伺服器的公鑰，那等於向黑客公開了自己加密的內容，黑客就知道了客戶端的公鑰，就能偽造伺服器的返回數據。

採用ECDH非對稱加密演算法包裹後的登陸認證協議，安全級別已經跟SRP差不多。相對於SRP協議的問題是ECDH安全性依賴於私鑰的保密性，如果私鑰泄漏安全性回到跟未加ECDH的時候一樣。ECDH的私鑰保密有以下一些辦法（考慮到實現成本，推薦方案2）

私鑰加強保密，做到絕密，不用換，也不準備換；例如用USBKEY等硬體方式。
私鑰密碼級別安全，定期更換，換的時候讓客戶端拉取。具體實現方法是第一步驗密的成功的以後，發現要更新公鑰，在返回的加密信道中返回新的公鑰。
使用Verisign等第三方證書，確保公鑰的合法性，在2的基礎上不會增加網路交互。
完全使用TLS的協議，會導致每次登錄增加一次交互。
另外，採用不對稱加密演算法，會有一個伺服器間共享密鑰的安全VASKEY的問題：

換key困難，架構設計導致
網路上對稱加密傳輸新密鑰，可能被破解
可能的解決方案：

VASKEY的業務Key管理目前是對稱加密的方式，可以考慮換成ECDH或類似的密鑰交換協議來動態更新Key。
集中驗證簽名和解密，不共享密鑰。
這里推薦採用方案2。

最後一個容易忽略的地方是注冊。採用HTTP注冊相當於明文傳遞用戶名和密碼，存在劫持、中間人攻擊的危險。將注冊入口全部改為HTTPS，封掉HTTP注冊可以去掉上述危險。但是如果黑客劫持網路，給用戶返回HTTP的頁面，代理請求的HTTPS注冊介面，也能竊取密碼。

TIPS && THOUGHTS

基本上所有的安全的登陸鑒權協議都是採用HTTPS的思想：使用不對稱密鑰演算法進行登陸驗證以及對稱密鑰交換。通過之後，後續會話就用對稱加密演算法加密。但是與HTTPS採用CA證書不同的是，一般通過密鑰本身來驗證客戶端和伺服器的合法性。
對於對稱加密演算法安全性問題更好的解決辦法是加密演算法協商，而不在於尋找破解難度更大的演算法。在驗密碼之前協商後續會話使用的對稱加密演算法，如果有安全性更好的演算法或者正在使用的演算法被破解了，只需要Server增加對更安全演算法的支持，新版本的客戶端就可以使用安全性更好的演算法。支持對稱加密演算法協商以後可以隨時動態的升級或替換加密演算法，不用擔心對稱加密演算法被破解的安全風險。HTTPS就是這樣的一種思路。
HTTP登錄無法防劫持，HTTPS登錄可以防劫持，但是無法防止後續對業務會話的竊聽。另外，CA也容易被偽造。
關於暴力登錄。處理方式有幾種：1. 驗證碼； 2. 一定時間內密碼錯誤次數超過正常值，鎖定賬戶； 3. 客戶IP監控。
第三方爆庫、釣魚、掃號、撞庫如果解決？這些問題等同於用戶明文密碼被盜，靠密碼登錄體系沒有辦法對抗，比較好的方式是對已知泄漏密碼的用戶進行封停，強制要求用戶改密碼等運營方式減少用戶的財產損失。
上面所有的驗證方式，每次請求都需要根據userId去資料庫拉取用戶信息（password）。所以最好結合緩存進行處理，畢竟用戶信息變化頻率還是比較小的。
這種鑒權認證方式，相對於前面的token方式而言，客戶端有比較多的計算和驗證邏輯，比較適合於CS架構，特別是手機App。而且，它不依賴於Cookies，所以天然具有SSO功能。

More about 密碼強度 && 暴力破解
1. 加鹽之外我們還可以做些什麼？
加鹽以後的密碼存儲體系已經有效的對抗批量暴力破解、彩虹表攻擊、字典攻擊。為了對抗針對單個密碼的暴力破解，我們可以通過密鑰加強(Key Stretching)、提高密碼長度等方式來提高安全性。

密鑰加強的基本思路是讓每次鑒權的時間復雜度大到剛好不影響用戶體驗，但是黑客暴力破解或構建彩虹表的成本大幅度提高，目前標準的演算法有BCRYPT、SCRYPT、PBKDF2等。密鑰加強演算法的本質是通過加鹽以及迭代計算多次增加計算量，迭代次數增加1000次計算量翻1000倍，這種方式對單個密碼的暴力破解作用不大。

提高密碼長度對構建彩虹表暴力破解的成本影響非常大，提高密碼長度提升單個帳號的密碼安全價值很大。以目前暴力破解MD5能力最強的FPGA NSA@home計算量來估算（大概用一台pc電腦的功耗，每秒鍾可進行30億次的8位密碼（密碼空間64個字元）嘗試），假設有1萬個NSA@home集成電路，19秒就能破解8字元的密碼（70個字元的密碼空間），所以現在的很多密鑰檢驗要求的最小長度6個字元其實是不安全的，如果把密碼長度增加到12個字元，則需要1年才能破解。

2. GPU，FPGA，ANIC對上述密碼強度有何挑戰？
FPGA MD5暴力破解工具目前比較成熟的是NSA@home，大概用一台pc電腦的功耗，每秒鍾可進行30億次的8位密碼（密碼空間64個字元）嘗試。Lightning Hash Cracker[7]使用9800GX2 GPU每秒能夠完成密碼MD5計算608M次。

類似FPGA，GPU這種暴力破解方式受密碼字元空間、密碼長度、密碼計算強度影響比較大，可以通過提升密碼長度、密碼計算強度來提升安全性。只替換密碼Hash演算法對這種破解作用不大，SHA2的計算量不到MD5計算量的一倍，把MD5換成SHA2隻是讓暴力破解的計算量增加了一倍，但是如果密碼長度增加1位對計算量的提升是非常巨大的。

對於對稱加密演算法，沒有專門針對TEA的硬體設計，針對AES演算法，有一篇論文針對AES128專門設計的類似GPU的硬體計算速度能達到1012次/秒（約240次/s），AES128暴力破解需要288秒，這個計算量目前也是安全的。這種對稱加密演算法的暴力破解只能通過提升密鑰長度來對抗。128位的AES與TEA安全級別差不多，AES支持最長256位密鑰，長遠來看對抗暴力破解AES更有優勢。然而，對於對稱加密演算法安全性問題更好的解決辦法是加密演算法協商，而不在於尋找破解難度更大的演算法。

⑨ 移動App如何與伺服器端進行身份認證

OAuth2一般不適用公司內部API調用，因為它的主要目的是解決資源授權的問題，而且OAuth2裡面角色對於C/S結構的app來說太過於繁雜了，不太有必要折騰。
移動app比較簡單的方法還是使用token（一種類似與httpcookie的東西），登錄之後得到token，任何請求都必須帶上它。因為是內部賬戶體系，登錄也可以直接使用用戶名密碼，驗證成功伺服器就返回token，沒有必要做各種code/token交換的事情。
不過如果公司資源變得非常獨立和分離了，OAuth2還是很有價值的。部門公司，為了讓公司內部統一用戶名密碼，就實現了一個基本的OAuth2流程，負責給各種內網網站授權，確實比較方便。