Auth · XB Field Notes

Basic auth carries a reusable credential

Thu, 11 Feb 2027 00:00:00 +0000

HTTP Basic authentication places an encoded username and password in an Authorization header. The encoding is reversible, so possession of that header can be equivalent to possession of the credential. Basic defines a challenge-response exchange, but it does not cryptographically bind a response to a fresh server nonce. A captured accepted value can be replayed while the server continues to accept that account and credential.

Understand the actual exchange

A server can reply with 401 and a WWW-Authenticate: Basic challenge naming a realm. The client may then retry with an Authorization header. A client can also send credentials preemptively within an appropriate protection space. This means authenticated requests carry the credential; it does not mean every initial request must already contain it. The realm helps identify the protection space, rather than granting permissions to every path with a similar label.

The encoded input joins the user identifier, a colon, and the password. The first colon is the separator, so a username cannot contain one while a password can. Neither field may contain control characters. Base64 is neither encryption nor password hashing. For non-ASCII credentials, character encoding matters: RFC 7617 leaves the default encoding unspecified within ASCII-compatible constraints and allows the challenge to indicate UTF-8. An ASCII demonstration does not validate every internationalized credential path.

Basic itself does not specify a session token or a logout protocol. An application may impose account expiry, disable an account, change authorization, or reject an old password. Therefore password rotation is not the only way to stop acceptance of a captured header. Define revocation and credential lifetime in the server’s actual account policy rather than assuming the wire scheme supplies them.

When it breaks

On an unprotected network path, an observer who reads the header can decode and reuse it. HTTPS with proper certificate validation protects transit to the TLS endpoint. It does not hide the credential from that endpoint, an authorized terminating proxy, or a careless application log. Protect subsequent hops and exclude Authorization values from routine traces, reports, and shared diagnostic captures.

Credentials with broad privileges magnify a leak. Use accounts appropriate to the task and its lifetime, and apply authorization after authentication. A valid credential does not imply permission to perform every operation. A realm label is not a tenant isolation mechanism. Restrict where a client sends credentials, particularly across redirects or when a script reuses a global header for unrelated destinations.

Repeated 401 responses can reflect missing, incorrect, expired, or unsupported credentials. In this example, 403 means the recognized demo account lacks the requested permission, but the general status does not prove that authentication succeeded in every implementation. Check the service’s contract and response challenge rather than inferring the entire identity state from one code.

The Basic challenge does not make the accepted header single-use. In this fixture, recognizing the credential and granting /admin permission are separate decisions.

Check it quickly

Save this as basic-auth.py and run python3 basic-auth.py. All credentials are deliberately synthetic: the username is DEMO and the password is NOT:A:SECRET. The server binds only to loopback and uses plain HTTP to make the protocol mechanics inspectable. Do not replace the demonstration values with real credentials. No TLS, persistent account store, or production authentication service is tested.

Validation (2026-10-17): The unchanged synthetic-credential exercise passed once on Python 3.14.4 (macOS arm64), with assertions enabled and loopback-only guards. The stated scope limits still apply.

from base64 import b64decode, b64encode
from http.client import HTTPConnection
from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer
from threading import Thread
import hmac
import json

synthetic = b'DEMO:NOT:A:SECRET'
authorization = 'Basic ' + b64encode(synthetic).decode('ascii')


class Handler(BaseHTTPRequestHandler):
 def do_GET(self):
 accepted = hmac.compare_digest(self.headers.get('Authorization', '').encode('latin1'),
 authorization.encode('ascii'))
 status = 401 if not accepted else 403 if self.path == '/admin' else 200
 data = {401: b'credentials required\n', 403: b'permission denied\n', 200: b'allowed\n'}[status]
 self.send_response(status)
 if status == 401:
 self.send_header('WWW-Authenticate', 'Basic realm="local-demo", charset="UTF-8"')
 self.send_header('Cache-Control', 'no-store')
 self.send_header('Content-Length', str(len(data)))
 self.end_headers()
 self.wfile.write(data)

 def log_message(self, *args):
 pass


server = ThreadingHTTPServer(('127.0.0.1', 0), Handler)
thread = Thread(target=server.serve_forever)
thread.start()
try:
 observed = []
 for path, credential in [('/', None), ('/', authorization), ('/', authorization),
 ('/admin', authorization), ('/', 'Basic invalid')]:
 connection = HTTPConnection('127.0.0.1', server.server_port, timeout=5)
 try:
 connection.request('GET', path, headers={'Authorization': credential} if credential else {})
 response = connection.getresponse()
 observed.append({'status': response.status,
 'challenge': response.getheader('WWW-Authenticate'),
 'body': response.read().decode()})
 finally:
 connection.close()
 assert [r['status'] for r in observed] == [401, 200, 200, 403, 401]
 assert observed[0]['challenge'] == 'Basic realm="local-demo", charset="UTF-8"'
 user, password = b64decode(authorization.split()[1], validate=True).split(b':', 1)
 assert user == b'DEMO' and password == b'NOT:A:SECRET'
 print(json.dumps({'responses': observed, 'synthetic_decoded_user': user.decode(),
 'synthetic_decoded_password': password.decode(), 'replay_accepted': True}))
finally:
 server.shutdown()
 thread.join()
 server.server_close()

The first request receives 401 with the Basic challenge. Two subsequent requests with the same encoded value both receive 200, demonstrating replay while that credential remains accepted. The demo account receives 403 for /admin, and an invalid header receives another 401. No server log records request headers.

The final assertions decode the synthetic value and split it at the first colon. The remaining colons belong to the password. This verifies reversible encoding, challenge delivery, repeated acceptance, and a separate permission decision. The handler recognizes one fixed demonstration value; it is not a complete authentication implementation. A production review must still examine credential storage, throttling, revocation, transport, and authorization together.

Sources

RFC 7617: Basic authentication, challenge, encoding, credential reuse, and protection spaces, checked 2026-09-13.
MDN: HTTP authentication, authentication headers and transport considerations, checked 2026-09-13.

SSH key hygiene is mostly limiting where a key works

Mon, 06 Jul 2026 00:00:00 +0000

SSH key hygiene starts with knowing which credential grants which access, who owns it, and how that access ends. A key comment helps people maintain an inventory, but it is not an authenticated owner record or an authorization rule. Track fingerprints alongside accountable owners, intended accounts, permitted operations, and a removal plan. Generating a modern key is only the beginning.

Scope the server-side permission

A public key in authorized_keys normally authorizes access to an account, subject to the server’s other controls. For automation, combine a narrowly privileged account with deliberately selected options. A forced command can restrict the executed operation, while from can limit source addresses. Neither magically confines the process to a working directory or makes an unsafe wrapper safe.

The restrict option disables forwarding, PTY allocation, and ~/.ssh/rc, but explicit companion options can re-enable individual facilities. It does not itself forbid shell or command execution, so an unattended job often also needs a carefully implemented forced command. A no-agent-forwarding option only blocks agent forwarding; it is not evidence that the key lacks general shell access. principals has a special meaning for trusted certificate-authority entries, not arbitrary ordinary keys.

Review the effective server configuration and alternative authorization sources. AuthorizedKeysCommand, certificate authorities, account privileges, and Match rules can change the result beyond one file. An inventory tool that sees an option name should report that observation, not issue a blanket “restricted and safe” verdict. Source restrictions also depend on the addresses actually seen by the server, including proxies and jump hosts.

Separate key types from signatures

An RSA public key line still uses the ssh-rsa key-type label even when authentication uses rsa-sha2-256 or rsa-sha2-512 signatures. OpenSSH 8.8 disabled the SHA-1 ssh-rsa signature scheme by default, not every RSA key. Inspect key size and actual negotiated signature support rather than labeling every RSA entry obsolete from its first word. DSA and weak or unsupported configurations require their own migration plan.

For new credentials, choose supported algorithms and suitable protection for the actual environment. A passphrase protects an encrypted private-key file against immediate use after copying, while hardware-backed keys can add different protections. Neither substitutes for a secure workstation, controlled agent access, and server-side scope. Automation that cannot prompt needs an explicit credential-storage and renewal design.

When it breaks

Rotation that only appends a new public key leaves the old credential authorized. Remove retired entries from every relevant authorization source, verify the replacement, and consider existing sessions separately. Ordinary raw public keys do not carry an automatic expiry. Enforce expiry through supported server options, SSH certificates, or deliberate lifecycle management; writing a date in a comment does nothing.

Permissions are another boundary, but the exact claim matters. Private keys should be owner-only, commonly mode 0600; a private directory commonly uses 0700. Public authorized_keys contents are not secret, and mode 0644 can be acceptable when ownership and write protections satisfy the server’s checks. A stricter 0600 policy is reasonable without pretending every other mode proves compromise. ACLs, parent directories, and platform rules need separate inspection.

Naively splitting authorized_keys on whitespace breaks commands containing quoted spaces. Escaped quotes and commas make a homemade parser especially easy to misread. Use OpenSSH to inspect key fingerprints, and review option semantics independently. A fingerprint match establishes which public key is present, not whether its restrictions are effective or its private half has a passphrase.

Inventory identifies a key; real authorization defines where it works. Key labels, negotiated signatures and retirement are distinct checks.

Check it quickly

Save as ssh_hygiene.py and run python3 ssh_hygiene.py with OpenSSH installed. It generates throwaway Ed25519 and 3072-bit RSA keys inside a temporary directory. Their empty passphrases are only for this disposable exercise. The script does not read or change your real SSH files, contact a host, or load an agent.

from pathlib import Path
import os
import stat
import subprocess
import tempfile


def run(*args):
 return subprocess.run(args, text=True, capture_output=True, check=True,
 env={'PATH': os.defpath}).stdout.strip()


with tempfile.TemporaryDirectory(prefix='ssh-hygiene-') as directory:
 work = Path(directory)
 # Throwaway, passphrase-less keys for this isolated fixture only.
 ed = work / 'demo_ed25519'
 rsa = work / 'demo_rsa'
 run('ssh-keygen', '-q', '-t', 'ed25519', '-N', '', '-C', 'fixture-ed', '-f', str(ed))
 run('ssh-keygen', '-q', '-t', 'rsa', '-b', '3072', '-N', '', '-C', 'fixture-rsa', '-f', str(rsa))
 public = ed.with_suffix('.pub').read_text().strip()
 auth = work / 'authorized_keys'
 auth.write_text('restrict,command="printf \\"two words\\"" ' + public + '\n')
 auth.chmod(0o600)
 parsed = run('ssh-keygen', '-l', '-f', str(auth))
 original = run('ssh-keygen', '-l', '-f', str(ed.with_suffix('.pub')))
 if parsed.split()[1] != original.split()[1]:
 raise RuntimeError('quoted options changed the key fingerprint')
 rsa_public = rsa.with_suffix('.pub').read_text().split()[0]
 if rsa_public != 'ssh-rsa':
 raise RuntimeError('unexpected RSA public key type')
 signatures = set(run('ssh', '-Q', 'key-sig').splitlines())
 if not {'rsa-sha2-256', 'rsa-sha2-512'} <= signatures:
 raise RuntimeError('client does not advertise RSA SHA-2 signatures')
 modes = {p.name: oct(stat.S_IMODE(p.stat().st_mode)) for p in (ed, rsa, auth)}
 if any(stat.S_IMODE(p.stat().st_mode) & 0o077 for p in (ed, rsa)):
 raise RuntimeError('fixture private key permissions are too broad')
 print('quoted authorized_keys fingerprint:', parsed)
 print('RSA key label:', rsa_public, '; SHA-2 signature algorithms supported')
 print('fixture modes:', modes)
 print('PASS: native key parsing, fingerprint agreement, RSA distinction, private modes')

Expect a matching Ed25519 fingerprint despite the quoted command, an ssh-rsa public-key label alongside advertised RSA SHA-2 algorithms, owner-only private-key modes, and PASS. Fingerprints and temporary paths change on each run. The context manager attempts to remove generated files on exit; this is not secure erasure. No private key contents are printed, and this source review generated no keys or reran this fixture.

The client algorithm query reports local capability, not a server’s accepted configuration. Likewise, ssh-keygen’s fingerprint parsing is not an end-to-end test of the forced command or every option. For a real audit, map each fingerprint to its owner, verify actual server authorization and command behavior in an isolated environment, and distinguish observed facts from controls that remain untested.

Sources

OpenBSD: sshd, authorized_keys format, options, and file ownership checks, checked 2026-10-15.
OpenSSH 8.8 release notes, RSA keys versus deprecated SHA-1 signatures, checked 2026-10-15.
OpenBSD: ssh-keygen, key generation and fingerprint inspection, checked 2026-10-15.
NIST IR 7966, SSH access inventory and lifecycle management, checked 2026-10-15.

Auth · XB Field Notes

Basic auth carries a reusable credential

Understand the actual exchange

When it breaks

Check it quickly

Sources

SSH key hygiene is mostly limiting where a key works

Scope the server-side permission

Separate key types from signatures

When it breaks

Check it quickly

Further reading

Sources