我正在製作REST-API，可以直接進行BASIC身份驗證登錄。然後讓HTTPS保護連接，以便在使用api時保護密碼。
這可以被認為是安全的嗎？
HTTP基本身份驗證存在一些問題：
其中，使用SSL只能解決第一個問題。即使這樣，SSL也僅在網絡服務器保護之前-任何內部路由，服務器日誌記錄等都將看到純文本密碼。
因此，就像查看所有圖片一樣，很重要。
HTTPS是否在傳輸過程中保護密碼？是的。
夠了嗎？通常不會（我想說的是，永遠不會-但這實際上取決於您的網站是什麼以及網站的安全性。）
嘗試這樣思考：當您使用SSL登錄任何網站時，您很有可能通過HTTPS以純文本格式傳遞密碼（例如GMail）。
唯一的區別Basic-Auth所做的是用戶名/密碼在請求標頭中傳遞，而不是在請求正文中傳遞（GET / POST）。
因此，使用basic-auth + https比通過HTTPS進行基於表單的身份驗證更安全或更安全。
基於HTTPS的基本Auth很好，但是並不完全安全。與 Fiddler用於SSL調試的工作方式類似，公司的HTTPS代理管理Web瀏覽器與代理之間的連接（其IP地址出現在Web服務器日誌中）。在這種情況下，HTTPS密碼將被解密，然後在公司代理中重新加密。
取決於誰在管理代理以及如何使用其日誌，從您的角度來看，這可能是可接受的，也可能是壞事。
有關如何進行SSL攔截的更多信息，請參見以下鏈接：
當SSL代理攔截SSL連接時，它將向客戶端瀏覽器提供模擬的服務器證書。客戶端瀏覽器向最終用戶發出安全彈出窗口，因為該瀏覽器不信任ProxySG使用的發行者。如果SSL代理使用的頒發者證書作為客戶端瀏覽器的證書存儲區中的受信任根導入，則不會出現此彈出窗口。
ProxySG使所有配置的證書都可以通過其管理控制台下載。您可以要求最終用戶通過Internet Explorer或Firefox下載頒發者證書，並將其作為受信任的CA安裝在他們選擇的瀏覽器中。這樣就消除了模擬證書的證書彈出窗口...
一些公司通過將GMP部署（代理）根證書到每個工作站來解決上述證書彈出問題。儘管這只會影響使用Microsoft證書存儲的軟件。 Firefox等軟件需要進行不同的更新。
您注意到需要對客戶端進行身份驗證，並詢問通過SSL的HTTP基本身份驗證的安全性。這就是SSL的設計目的，只要密碼是一個好的密碼，它就可以正常工作。如果您確實是為單個客戶端設置的，則可以通過選擇一個較長的隨機密碼來確保這一點，例如使用良好的隨機性源或本網站上討論的其他技術，可以輸入12個字符。在您所描述的情況下，如所引用的python ssl頁所述使用自簽名證書就可以了。
完全取決於其安全性。通過ssl進行的基本身份驗證仍將以純文本形式發送憑據，這意味著您只有一層保護。
您最好使用隨機數來哈希密碼，或者最好使用聲明模型將身份驗證傳遞給受信任的第三方。
我在很多事情上都在使用它，只要您不忽略來自瀏覽器的TLS警告就可以了。
TLS在HTTP下工作，因此任何通過HTTP傳輸的數據將被加密。它將像提交任何密碼表一樣安全。
儘管建議不要使用自簽名證書，而建議使用讓我們的加密。它們提供免費證書，並且受到Microsoft，Mozilla等的信任，因此不會在瀏覽器中發出TLS警告。我認為最好使用此證書代替自簽名證書。如果您看到TLS錯誤，就知道它是真實的，而不僅僅是因為您的證書是自簽名的。
到目前為止（我想）還沒有提到的另一個論點是，許多智能手機等移動設備在通過瀏覽器中的HTTPS進行基本身份驗證時都不允許用戶檢查證書。這意味著與基於表單的身份驗證不同，您不能繞過基本身份驗證彈出窗口，該彈出窗口是大多數移動平台上的模式對話框，用於在輸入憑據之前檢查證書。當攻擊者使用有效證書時，這可能會帶來風險。
這裡有更多的歷史背景。就像其他人說的那樣，如果您可以有一些限制生活 b>，那麼基於TLS的基本身份驗證就可以很好地工作。
在客戶端上使用，您可能需要處理會話管理，使用基本身份驗證很難。
在後端上，基本身份驗證效果不錯，但完全依賴TLS 以確保機密性和完整性。它類似於基於令牌的身份驗證。如果您還需要其他聲音，請考慮使用簽名方案或 TLS客戶端身份驗證。