的用戶名和密碼

Question

考慮的網址： https://foo:password@example.com

是否在上述例子中，用戶名/密碼部資格作爲「URL參數」，如在this question定義？

Answer 1

當您將用戶名和密碼放在主機前時，這些數據不會以這種方式發送到服務器。而是根據所使用的身份驗證模式轉換爲請求頭。大多數情況下這將是我在下面描述的Basic Auth。類似的（但是顯着不常使用的）認證方案是當今提供可比較的安全特徵的Digest Auth。

使用基本身份驗證，從問題的HTTP請求將是這個樣子：

GET/HTTP/1.1 
Host: example.com 
Authorization: Basic Zm9vOnBhc3N3b3Jk 

像串散列可以看到有由瀏覽器創建這樣的：base64_encode(username + ":" + password)。

對於HTTPS傳輸的外部人員，這些信息是隱藏的（就像HTTP級別的其他所有內容一樣）。儘管如此，您應該注意登錄客戶端和所有中間服務器。用戶名通常會顯示在服務器日誌中，但密碼不會。但這並不能保證。當您使用例如客戶端在客戶端上調用該URL時curl，用戶名和密碼將在進程列表中清晰可見，並可能在bash歷史記錄文件中顯示。

當您使用the approach by ayush，用戶名和密碼將總是在你的web服務器的服務器日誌，應用程序服務器，緩存轉起來，......除非你專門配置了服務器無法登錄了。這僅適用於能夠讀取未加密的http數據的服務器，例如應用服務器。

基本認證是標準化的，由瀏覽器通過顯示這個小小的用戶名/密碼彈出來實現。當您將用戶名/密碼放入通過GET或POST發送的HTML表單中時，您必須自己實現所有登錄/註銷邏輯（這可能是一個優點）。但你應該從來沒有通過GET參數傳輸用戶名和密碼。如果必須，請使用POST。防止默認情況下記錄此數據。

當今天通常使用帶有用戶/密碼輸入表單和隨後的基於cookie的會話來實現身份驗證機制時，您必須確保密碼是使用POST請求傳輸的，還是使用其中一種標準化身份驗證僅限上述方案。

結論我可以說，通過HTTPS傳輸數據是安全的，只要您注意密碼不會出現在意想不到的地方。但該建議適用於以任何方式傳輸任何密碼。