Wireshark Part 05 — See why plaintext credentials and cookies are dangerous

Demonstrate plaintext password and cookie exposure safely with dummy values on loopback, then identify the right protections.

Series index · Previous: Web and TLS · Next: Wi-Fi password auditing

18 September 2026 · Official documentation source-checked; this exercise has not been run on THL hardware. Expected observations are teaching expectations, not measured results.

Question: What does a packet observer learn when an application sends authentication data over plain HTTP? Outcome: A loopback-only demonstration using invented credentials and an invented cookie, plus a practical remediation checklist.

This is a legitimate way to explain a security finding to a developer or verify that a test client sends sensitive fields. Harmful misuse would be harvesting credentials or session cookies from other people and using them to impersonate those people. The demonstration stops at inspecting dummy values on your own computer. Do not substitute real passwords, real cookies, or someone else’s capture; do not test whether an observed real token can be replayed.

Understand what is exposed

HTTP Basic authentication represents a username/password pair with Base64. Base64 is reversible encoding, not encryption or a password hash, and Basic requires an external confidentiality mechanism such as TLS. This is different from the captured Wi-Fi authentication material discussed elsewhere in the series. HTTP Basic specification

A cookie is not automatically an authentication credential, but a real session cookie may confer access. This lab’s lab_session value has no associated account and cannot authenticate anything. Its purpose is to make the exposure visible without putting a real session at risk.

Prepare an isolated local exercise

Use Wireshark, Python, and curl.exe already installed on your own Windows computer. Create an empty lab folder outside shared or synchronized storage. Python’s server serves its directory, so avoid folders containing secrets. It is not a production server. Python HTTP server documentation

The capture point is loopback, because both endpoints are the same computer. On Windows, select the Npcap loopback interface, commonly labelled Adapter for loopback traffic capture. On other platforms, use the available loopback interface, often lo or lo0. If you lack loopback capture, resolve that prerequisite before continuing; selecting Wi-Fi will not show this local exchange. Npcap loopback support

Generate and inspect one harmless exchange

  1. Open a terminal in the empty lab folder and start the server:

    python -m http.server 8000 --bind 127.0.0.1

    Keep the binding exactly as shown so it listens only on local IPv4 loopback. If that port is already occupied, stop here and choose a different unused lab port consistently in all commands and filters.

  2. Open Capture → Options, select loopback, and set the capture filter to tcp port 8000. Start capturing. The filter limits what is stored, although another local process using that port could still appear.

  3. In a second PowerShell window, issue the dummy request:

    curl.exe --noproxy "*" --http1.1 --basic --user "lab-user:DUMMY-NOT-A-PASSWORD" --header "Cookie: lab_session=DUMMY-NOT-A-TOKEN" "http://127.0.0.1:8000/"

    The proxy override keeps this request direct to loopback. --user supplies the invented Basic credentials; the header supplies the invented cookie. The server does not validate either one. Receiving a page therefore demonstrates transport, not successful authentication. curl options

  4. Stop the capture. Apply the display filter tcp.port == 8000 and http.request. Select the request and expand Hypertext Transfer Protocol. Inspect Authorization and Cookie. Wireshark may also display decoded Basic credentials. To locate either sensitive field within this lab, use tcp.port == 8000 and (http.authorization or http.cookie). HTTP display fields

  5. If the HTTP filter is empty, replace it with tcp.port == 8000 so undecoded TCP packets are visible. If the lab exchange appears but is not decoded as HTTP, select one of its packets, open Analyze → Decode As…, and assign HTTP to the lab’s TCP port. Reapply the HTTP filter. If the TCP filter is also empty, check the capture interface, port, and request result first. A port number alone does not establish the application protocol. Decode As controls

  6. Select the request and choose Analyze → Follow → TCP Stream. Locate the request line, encoded Authorization value, and readable dummy cookie. This assembles captured TCP content into a conversation. Close the stream window and clear its resulting display filter before further inspection. Following streams

  7. Save only if needed for the exercise, then stop the Python server with Ctrl+C. Remove any temporary Decode As rule you added.

What the result establishes

The expected result is readable HTTP containing the dummy cookie and recoverable Basic credentials. No password cracking is involved. A failed filter does not establish that the values were protected: wrong interface, wrong port, missing packets, or decoding failure could explain it. Check the unfiltered lab exchange before drawing a conclusion.

This loopback demonstration also does not prove that any remote user can see your traffic. An observer requires a suitable capture position; permission is a separate requirement for legitimate analysis. With properly configured HTTPS, the HTTP fields are encrypted in transit; an endpoint capture supplied with legitimate TLS secrets can still expose them, as Part 04 explains.

Mitigation and completion exercise

Require HTTPS throughout authenticated flows and protect credentials from logs and captures. For session cookies, configure Secure, consider HttpOnly and an appropriate SameSite policy, and implement expiration and revocation. These flags address different risks; HttpOnly does not encrypt a network connection. MDN Set-Cookie reference

Completion exercise: Identify the two exposed dummy fields, explain why Basic is not a hash, and write the remediation you would request from a developer. If a real secret ever appears during authorized work, stop sharing the capture and follow the owner’s incident process, including revocation or rotation where appropriate. Do not validate exposure by attempting impersonation.