Visual RFC.
ALL RFCs / RFC 7617
Read the RFC ↗
RFC 7617 / HTTP BASIC AUTHENTICATION

Protect transport and check the recipient

05

The same Basic value can cross an exposed network or an HTTPS-protected connection. The server still receives the password in either case.

DIAGRAMRead RFC section 4 ↗
RFC 7617 · § 4EXAMPLE
3 / 3
Protect transport and check the recipientAn unprotected Basic exchange exposes a recoverable password to a network observer. Correctly established HTTPS protects the network path, while the intended server still sees the password. In a separate wrong-host example the client stops before sending credentials to other.example; TLS alone cannot make an unintended recipient appropriate.Transport protection and recipient choiceSeparate wrong-host caseClientother.examplewrong recipient: stopExpected host: api.exampleCandidate: other.exampleNo password sent in this exampleIts HTTPS connection would not justify disclosureHTTPS does not fix password reuse or database leaks
03
Stop before sending to an unintended host.

In this separate example the expected host is api.example but the candidate is other.example. Do not send the reusable password. A counterfeit server could collect it even over its own HTTPS connection.

Source for this drawing: RFC 7617 · Read RFC section 4 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A message needs an address.

Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.

Helpful first, if these ideas are unfamiliar

RFC 9110 HTTP RFC 4648 Base encodings RFC 8446 TLS 1.3

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Terms in this drawing
TLS
Transport Layer Security, used by HTTPS to protect the connection.
Credential
Data presented to authenticate; its handling and intended recipient matter.
Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

Because passwords are transmitted as recoverable credentials, Basic SHOULD NOT protect sensitive or valuable information without enhancements such as HTTPS.

  • Because passwords are transmitted as recoverable credentials, Basic SHOULD NOT protect sensitive or valuable information without enhancements such as HTTPS.
  • HTTPS protects the network exchange; Base64 itself does not. A recipient server can decode the credential after TLS terminates.
  • A counterfeit server can ask for and retain passwords. A secure connection alone does not justify sending a reusable password to an unintended host.
  • Password reuse increases harm across sites. Servers ought to protect stored passwords, avoiding plaintext and unsalted digests; TLS does not solve database leaks.
DETAILS

The first state is an explicitly unsafe comparison, not deployment advice. The second assumes correctly established HTTPS to the intended server. The third separates a wrong-recipient risk from a secure transport: the client stops before sending to other.example. No claim that Basic provides phishing resistance, freshness, replay prevention or password storage protection. Do not type real credentials into this educational site.

Read the RFC section ↗

All chapters in RFC 7617

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗