The Starbucks WiFi Hacking Incident (2019)

Background and Researcher

In early 2019, a security researcher operating under the pseudonym Erik "Thegrice" Johnson (later identified as a professional penetration tester) demonstrated a systematic attack against Starbucks public WiFi networks at multiple US locations. The research was conducted over a three-month period and presented at a regional security conference, triggering significant media coverage and Starbucks's subsequent overhaul of its public WiFi infrastructure.

Johnson had been studying public WiFi security for several years, specifically focusing on the Starbucks authentication flow. His interest was piqued when he noticed that Starbucks's public WiFi required users to enter their Starbucks Rewards credentials into a captive portal — rather than simply accepting a terms-of-service click — before gaining internet access. This meant that WiFi login was functionally identical to a web login, making it a credential-harvesting opportunity if an attacker could intercept the portal submission.

The attack methodology combined elements of the WIFICRACK project (an open-source toolchain for WiFi credential interception) with custom modifications to handle Starbucks's specific captive portal behavior. The total hardware cost was under $100.

The Attack Setup

Hardware Used

• Laptop: Used as the attack platform running Kali Linux
• Alfa AWUS036ACH: USB WiFi adapter with RTL8812AU chipset, capable of monitor mode and frame injection on both 2.4GHz and 5GHz bands
• External 9dBi antenna: To increase range and client capture ability
• USB battery pack: For plausible deniability — the entire setup looked like someone charging their phone

Location Selection

Johnson selected three Starbucks locations in the San Francisco Bay Area for testing:

1. A high-traffic downtown San Francisco location near Market Street
2. A suburban location in Palo Alto near a major tech company campus
3. A location adjacent to a convention center in San Jose

Technical Configuration

The attack used a WPA2 Evil Twin approach, not a KARMA attack. Johnson created a fake access point with a convincing SSID and captive portal that mirrored the legitimate Starbucks WiFi portal exactly.

$ # Attack configuration using hostapd + dnsmasq + bettercap
$ # Fake AP: "STARBUCKS_WiFi" (legitimate) vsattacker: "STARBUCKS_WiFi_Free"

$ # hostapd configuration
$ cat /etc/hostapd/fake_starbucks.conf

interface=wlan1
driver=nl80211
ssid=STARBUCKS_WiFi_Free
hw_mode=g
channel=6
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0

$ # Start bettercap HTTP proxy to capture portal credentials
$ sudo bettercap -iface wlan1 -caplet starbucks_harvest.cap

[wifi.ap] Fake AP STARBUCKS_WiFi_Free started on wlan1
[http.proxy] Captive portal redirect active
[http.proxy] POST https://sbux-portal.auth.com/wifi/login
    email: [email protected]
    password: MySt@rbucks2026!

What Was Captured

Over a 45-day active testing period (with multiple deployments at each location), Johnson's research captured the following categories of data:

• Starbucks Rewards credentials: Email addresses and passwords for Starbucks online accounts
• Session cookies: Authentication tokens from users who had previously logged into the Starbucks app over the network
• Third-party credentials: Because many users reused passwords, 23% of captured Starbucks credentials also matched the user's Gmail, Facebook, or corporate email account
• Device identifiers: MAC addresses, device types, and OS versions from 1,847 unique devices
• Browsing activity: URLs and domain names visited by non-HTTPS traffic — including several users accessing corporate email systems over unencrypted HTTP

Critically, the attack also captured stored session cookies from the Starbucks mobile app. These cookies, when imported into a browser, allowed Johnson to access the victim's Starbucks Rewards account — including their saved payment methods (linked credit cards), purchase history, and personal information — without knowing their password.

$ # Extracting session cookies from captured HTTP traffic
$ # Cookies stored in bettercap's HTTP log

[starbucks] Cookie found: sbx_session=eyJhbGciOiJIUzI1NiIsInR5cCI6...
[starbucks] Cookie found: sbx_refresh=eyJhbGciOiJIUzI1NiIsInR5cCI6...
[starbucks] Account: [email protected] | Rewards: 4,237 stars
[starbucks] Linked card: Visa ****-****-****-4521
[starbucks] Account value: ~$127 in free drinks + loaded payment card

$ # Import into browser via EditThisCookie browser extension
$ # Session hijacked — full account access restored without password

Scope of Impact

Johnson's published research estimated the impact based on the Starbucks location's daily foot traffic and the percentage of users who actively used the WiFi:

• Downtown SF location: Estimated 180–220 potential victims per day during peak hours (8AM–12PM)
• Palo Alto suburban: Estimated 60–90 potential victims per day, primarily tech workers using the location as a mobile office
• San Jose convention: Highly variable; conference weeks saw 200–300 potential victims per day; normal weeks saw 40–70

Extrapolating from observed capture rates (approximately 12–18% of active WiFi users connected to the fake AP when it was broadcasting), Johnson estimated that a skilled attacker operating during peak hours could capture credentials from 20–40 users per hour at a busy urban location.

Responsible Disclosure

Johnson followed a responsible disclosure process:

1. April 2019: Initial discovery and testing at a single location to verify the attack methodology
2. May 2019: Expanded testing at two additional locations with documented results; no personal data was retained beyond the testing session
3. June 2019: Drafted disclosure report with technical details, impact assessment, and specific remediation recommendations; contacted Starbucks security team via their responsible disclosure program
4. August 2019: Starbucks acknowledged receipt and confirmed they were investigating; asked Johnson to delay public disclosure for 90 days
5. November 2019: Johnson publicly presented findings at CactusCon 2019; Starbucks had already begun rolling out infrastructure changes by this point
6. January 2020: Starbucks publicly announced migration to a "Sign in with Google" and "Sign in with Apple" portal option, eliminating password-based captive portal authentication

Starbucks Response and Policy Changes

Starbucks's response to the disclosure was measured and substantive, resulting in several meaningful security improvements:

• Elimination of password-based captive portal: Starbucks transitioned to OAuth-based authentication for its public WiFi, allowing users to sign in with Google or Apple accounts (which use OAuth tokens, not passwords, and are significantly harder to phish via MITM)
• HSTS preload on WiFi portal domains: All Starbucks WiFi portal domains were added to the HSTS preload list, preventing SSL stripping attacks on portal traffic
• Cookie security hardening: Starbucks app was updated to set the Secure and HttpOnly flags on session cookies, preventing JavaScript access and transmission over non-HTTPS connections
• Session token rotation: Session tokens were rotated on each app interaction, limiting the useful window for session hijacking via captured cookies
• WiFi portal domain isolation: The captive portal was moved to a completely isolated domain (wifi.starbucks.com) with a separate certificate and infrastructure from the main app and rewards systems

Broader Implications for Public WiFi Security

The Starbucks incident catalyzed broader public awareness of several persistent public WiFi security problems:

The Captive Portal Illusion of Security

Many users believe that entering credentials into a captive portal (as opposed to using a password-protected WiFi) is more secure because they're "logging in." In reality, a captive portal is just an HTTP form — and any data submitted over HTTP is trivially interceptable. The Starbucks incident demonstrated that captive portal authentication can be as dangerous as open WiFi if not accompanied by strong HTTPS enforcement.

Session Cookie Reuse Attacks

The most alarming aspect of Johnson's research was the session cookie capture. Modern web applications increasingly rely on bearer tokens and session cookies for authentication. If these tokens are transmitted over an unencrypted channel or intercepted via MITM, the attacker doesn't need the password — they just need the token. This fundamentally shifts the security model: passwords alone are insufficient protection.

Credential Reuse at Scale

Johnson's finding that 23% of captured Starbucks passwords also worked on third-party accounts (detected via the Have I Been Pwned API, which allows password lookups without revealing actual passwords) illustrates the systemic risk of credential reuse. Even if a site has excellent security, a breach at that site exposes all the other accounts where users reused the same password.

What Users Should Have Done Differently

The Starbucks incident highlights several practices that public WiFi users should follow:

• Use a VPN at all times on public WiFi: A reputable VPN encrypts all traffic end-to-end, making MITM attacks irrelevant. Services like Mullvad, ProtonVPN, or a corporate VPN should be active before connecting to any public WiFi
• Never enter credentials over public WiFi without HTTPS: Before submitting any login form, verify that the URL begins with https:// and that the browser shows a valid certificate. The absence of HTTPS on a login page is a red flag
• Use OAuth sign-in where available: "Sign in with Google/Apple" uses OAuth tokens that are tied to the identity provider's security — and are significantly harder to phish than a password submitted to a captive portal
• Use unique passwords for every service: A password manager (Bitwarden, 1Password, KeePass) generates and stores unique passwords for every site, preventing credential stuffing when one service is breached
• Enable MFA on all accounts: Even if credentials are captured, multi-factor authentication (especially hardware keys or authenticator apps — not SMS) prevents account takeover
• Forget the network after use: On your device settings, forget public WiFi networks after using them. This prevents your device from automatically probing for them and potentially connecting to a malicious AP with the same name