What Is PEAP Authentication? How PEAP Secures Your WiFi

Was ist PEAP-Authentifizierung? Wie PEAP Ihr WiFi sichert. Ein Purple Enterprise WiFi Intelligence Briefing. Willkommen. Wenn Sie für die Netzwerksicherheit in einer Hotelgruppe, einem Einzelhandelsunternehmen, einem Stadion oder einer Organisation des öffentlichen Sektors verantwortlich sind, ist dieses Briefing genau das Richtige für Sie. In den nächsten zehn Minuten werden wir uns mit der PEAP-Authentifizierung befassen – was sie eigentlich ist, wie sie unter der Haube funktioniert, wo sie in Ihre Sicherheitsarchitektur passt und, was besonders wichtig ist, wann sie die richtige Wahl ist und wann Sie sich nach etwas Stärkerem umsehen sollten. Lassen Sie uns direkt einsteigen. Abschnitt eins: Kontext und warum dies genau jetzt wichtig ist. Die meisten Enterprise-WiFi-Bereitstellungen basieren heute immer noch auf einem von zwei Authentifizierungsmodellen. Sie haben entweder einen Pre-Shared Key – ein einziges Passwort, das im gesamten Unternehmen geteilt wird – oder Sie nutzen 802.1X, den IEEE-Standard für portbasierte Netzwerkzugriffskontrolle. PEAP gehört eindeutig in das 802.1X-Lager und ist die mit Abstand am weitesten verbreitete EAP-Methode in Unternehmens- und institutionellen Umgebungen weltweit. Der Grund, warum PEAP so dominant wurde, ist einfach: Es hat ein echtes betriebliches Problem gelöst. Vor PEAP bedeutete die Bereitstellung einer zertifikatsbasierten WiFi-Authentifizierung, dass Client-Zertifikate für jedes Gerät ausgestellt werden mussten – für jeden Laptop, jedes Telefon, jedes Tablet. Für ein Unternehmen mit fünfhundert Mitarbeitern und einer BYOD-Richtlinie ist das ein PKI-Bereitstellungsaufwand, für den die meisten IT-Teams schlichtweg weder das Budget noch die Zeit hatten. PEAP bot einen Mittelweg: starke serverseitige Authentifizierung über TLS mit Benutzername und Passwort auf der Client-Seite. Keine Client-Zertifikate erforderlich. Dieser Kompromiss machte PEAP in den 2000er und 2010er Jahren zum De-facto-Standard für die WiFi-Authentifizierung in Unternehmen, und es ist auch heute noch extrem weit verbreitet. Die Architektur – und ihre Grenzen – zu verstehen, ist für jeden, der im Jahr 2024 und darüber hinaus Infrastrukturentscheidungen trifft, unerlässlich. Abschnitt zwei: Technischer Deep-Dive. Lassen Sie uns genau durchgehen, was passiert, wenn sich ein Gerät über PEAP authentifiziert. Der Prozess besteht aus zwei verschiedenen Phasen, und das Verständnis beider Phasen ist entscheidend. Die drei Akteure bei diesem Austausch sind: der Supplicant – das ist das Client-Gerät, sei es ein Laptop, ein Smartphone oder ein IoT-Terminal; der Authenticator – in der Regel der Wireless Access Point oder der Wireless LAN Controller; und der Authentifizierungsserver – fast immer ein RADIUS-Server, wie Microsoft NPS, FreeRADIUS oder ein in der Cloud gehosteter RADIUS-Dienst. Phase eins ist der Aufbau des TLS-Tunnels. Wenn der Supplicant versucht, eine Verbindung herzustellen, gewährt der Authenticator nicht sofort Zugriff. Stattdessen initiiert er einen EAP-Austausch über das lokale Netzwerk – dies ist EAPOL, EAP over LAN. Der Authenticator leitet dies an den RADIUS-Server weiter, der dem Client sein serverseitiges TLS-Zertifikat präsentiert. Der Client validiert dieses Zertifikat anhand seines Speichers für vertrauenswürdige Zertifikate. Wenn die Validierung erfolgreich ist, wird ein TLS-Tunnel zwischen dem Client und dem RADIUS-Server aufgebaut. Dieser Tunnel ist verschlüsselt – in modernen Bereitstellungen typischerweise mit TLS 1.2 oder 1.3. Phase zwei ist die innere Authentifizierung. Innerhalb dieses verschlüsselten Tunnels werden die eigentlichen Anmeldedaten ausgetauscht. Bei der am häufigsten verwendeten Bereitstellung – PEAP-MSCHAPv2 – sendet der Client einen Benutzernamen und ein Passwort über das Microsoft Challenge Handshake Authentication Protocol Version 2. Der RADIUS-Server validiert diese Anmeldedaten mit seinem Identitätsspeicher, bei dem es sich um Active Directory, LDAP oder einen Cloud-Identitätsanbieter handeln kann. Wenn die Anmeldedaten korrekt sind, sendet der RADIUS-Server eine Access-Accept-Nachricht über den Authentifikator zurück, und dem Client wird der Netzwerkzugriff gewährt. Das entscheidende Sicherheitsmerkmal hierbei ist, dass der MSCHAPv2-Austausch innerhalb des TLS-Tunnels stattfindet. Ein Angreifer, der den drahtlosen Kanal passiv überwacht, kann die übertragenen Anmeldedaten nicht sehen. Das ist das zentrale Wertversprechen von PEAP. Wo liegen nun die Schwachstellen von PEAP-MSCHAPv2? Es gibt zwei wesentliche Probleme, die jeder sicherheitsbewusste Architekt verstehen muss. Erstens: Die Validierung des Serverzertifikats. PEAP erfordert nur, dass der Server ein Zertifikat vorlegt – der Client muss keines vorlegen. Dies schafft einen gut dokumentierten Angriffsvektor. Wenn ein Client-Gerät so falsch konfiguriert ist, dass es jedes Zertifikat akzeptiert – oder Zertifikate von jeder beliebigen Zertifizierungsstelle (CA) – kann ein Angreifer einen betrügerischen Access Point einrichten, ein gefälschtes Zertifikat vorlegen und den MSCHAPv2-Handshake abfangen. Tools wie hostapd-wpe haben diesen Angriff extrem einfach gemacht. Die Gegenmaßnahme ist eine strenge Konfiguration des Supplicants: Erzwingen Sie die Validierung des Serverzertifikats, pinnen Sie die erwartete CA und geben Sie den Common Name des Servers an. Dies ist in jeder professionellen Bereitstellung nicht verhandelbar. Zweitens: MSCHAPv2 ist ein älteres Protokoll mit bekannten Schwachstellen. Die Untersuchungen von Moxie Marlinspike aus dem Jahr 2012 haben gezeigt, dass MSCHAPv2-Challenge-Response-Paare mit ausreichender Rechenleistung offline geknackt werden können. Wenn ein Angreifer den inneren Authentifizierungsaustausch abfängt – beispielsweise durch den oben beschriebenen Angriff über einen gefälschten AP –, kann er versuchen, das Klartext-Passwort offline wiederherzustellen. Die Stärke Ihrer Passwortrichtlinie wirkt sich daher direkt auf Ihr Risiko aus. Lange, komplexe und zufällig generierte Passwörter reduzieren dieses Risiko erheblich. Vergleichen Sie dies mit EAP-TLS, bei dem sowohl der Server als auch der Client Zertifikate vorlegen. Es gibt keine Passwörter, die gestohlen werden können. Die Angriffsfläche wird drastisch reduziert. Der Kompromiss liegt in der betrieblichen Komplexität: Sie benötigen eine PKI, müssen Client-Zertifikate ausstellen und verwalten sowie einen Mechanismus haben, um diese auf jedem Gerät zu verteilen. Für Organisationen mit einer ausgereiften MDM-Bereitstellung und einer gut verwalteten PKI ist EAP-TLS der Goldstandard. Für alle anderen bleibt PEAP-MSCHAPv2 mit einer strengen Konfiguration eine vertretbare und praktische Wahl. Abschnitt drei: Empfehlungen für die Implementierung und Fallstricke. Hier sind die praktischen Richtlinien für die Bereitstellung. Dies sind die Punkte, die eine sichere PEAP-Bereitstellung von einer anfälligen unterscheiden. Nummer eins: Erzwingen Sie die Serverzertifikatsvalidierung auf jedem Supplicant. Dies ist das wichtigste Konfigurationselement überhaupt. Unter Windows ist dies das Kontrollkästchen "Serverzertifikat überprüfen" im WLAN-Netzwerkprofil. Unter iOS und Android ist es das Feld für das CA-Zertifikat in der EAP-Konfiguration. Wenn dies nicht konfiguriert ist, ist Ihre PEAP-Bereitstellung anfällig für Angriffe durch Rogue APs, unabhängig davon, wie gut alles andere eingerichtet ist. Nummer zwei: Bereitstellung über MDM oder GPO, nicht über manuelle Konfiguration. Die manuelle Konfiguration durch Endbenutzer ist unzuverlässig. Benutzer klicken sich durch Zertifikatswarnungen. Sie konfigurieren das CA-Feld falsch. Verteilen Sie Ihre WLAN-Profile über Microsoft Intune, Jamf oder Gruppenrichtlinien. Dies gewährleistet eine konsistente, richtlinienkonforme Supplicant-Konfiguration in Ihrer gesamten Umgebung. Nummer drei: Verwenden Sie mindestens TLS 1.2 auf Ihrem RADIUS-Server. Deaktivieren Sie TLS 1.0 und 1.1. Die meisten modernen RADIUS-Implementierungen unterstützen dies, aber es lohnt sich, dies zu überprüfen – insbesondere bei älteren On-Premises-Bereitstellungen. Nummer vier: Integrieren Sie Ihren Identity Provider. PEAP-MSCHAPv2 authentifiziert sich gegenüber einem Anmeldeinformationsspeicher. Dieser Speicher sollte Ihr maßgeblicher Identity Provider sein – Active Directory, Azure AD über die NPS-Erweiterung oder ein Cloud-RADIUS-Dienst mit LDAP-Integration. Das bedeutet: Wenn ein Mitarbeiter das Unternehmen verlässt, entzieht die Deaktivierung seines Kontos sofort seinen WiFi-Zugang. Keine gemeinsamen Geheimnisse, die rotiert werden müssen, keine manuelle Deaktivierung. Nummer fünf: Betrachten Sie Ihr Gastnetzwerk separat. PEAP ist eine Authentifizierungsmethode für Unternehmen. Für das Gast-WiFi – bei dem Sie Besucher, Kunden oder Veranstaltungsteilnehmer an Bord holen – benötigen Sie einen anderen Ansatz. Plattformen wie Purple bieten eine speziell entwickelte Gast-WiFi-Ebene, die die Captive Portal-Authentifizierung, Datenerfassung und Analysen übernimmt, ohne dass eine RADIUS-Infrastruktur auf der Gast-SSID erforderlich ist. Belassen Sie Ihre Unternehmens-SSID auf 802.1X mit PEAP und Ihre Gast-SSID auf einem separaten, isolierten Netzwerk mit entsprechendem Onboarding. Nummer sechs: Planen Sie die Zertifikatsrotation. Das Zertifikat Ihres RADIUS-Servers wird ablaufen. Wenn dies geschieht, schlägt die Authentifizierung bei jedem Client fehl, der dieses Zertifikat gepinnt hat, bis das neue Zertifikat verteilt ist. Planen Sie die Zertifikatserneuerung fest in Ihren Betriebskalender ein – mindestens 90 Tage vor dem Ablaufdatum – und testen Sie den Rotationsprozess in einer Staging-Umgebung, bevor Sie ihn in der Produktion einführen. Die häufigsten Fehlerszenarien, die ich in der Praxis sehe, sind: Die Zertifikatsvalidierung wird nicht erzwungen, was zu einer Anfälligkeit für Rogue APs führt; RADIUS-Serverzertifikate laufen ohne Vorwarnung ab, was zu flächendeckenden Authentifizierungsfehlern führt; und die innere MSCHAPv2-Authentifizierung ist ungeschützt, weil der RADIUS-Server aus dem falschen Netzwerksegment erreichbar ist. Alle drei Szenarien lassen sich mit der richtigen Planung vermeiden. Abschnitt vier: Schnelle Fragen und Antworten. Kann PEAP mit Cloud-Identitätsanbietern wie Azure AD verwendet werden? Ja. Die NPS-Erweiterung von Microsoft für Azure AD MFA ermöglicht es Ihnen, die PEAP-Authentifizierung über Azure AD zu proxyen, was eine Multi-Faktor-Authentifizierung für Ihr WiFi ermöglicht. Alternativ können Cloud-RADIUS-Dienste wie Cisco ISE, Aruba ClearPass oder JumpCloud RADIUS direkt in Azure AD oder Okta integriert werden. Ist PEAP konform mit PCI DSS? PEAP-MSCHAPv2 kann in PCI DSS-Umgebungen verwendet werden, aber Sie müssen sicherstellen, dass die Serverzertifikatsvalidierung erzwungen wird, TLS 1.2 oder höher verwendet wird und der RADIUS-Server ordnungsgemäß segmentiert ist. PCI DSS 4.0 verschärft die Anforderungen an Netzwerkzugriffskontrollen — überprüfen Sie die relevanten Anforderungen mit Ihrem QSA. Sollte ich von PEAP auf EAP-TLS migrieren? Wenn Sie über ein ausgereiftes MDM-Deployment und die betriebliche Kapazität zur Verwaltung einer PKI verfügen, ja — EAP-TLS ist die sicherere Wahl. Wenn Sie eine gemischte Umgebung mit persönlichen Geräten, älterer Hardware oder begrenzter MDM-Abdeckung verwalten, bleibt PEAP-MSCHAPv2 mit strenger Konfiguration weiterhin angemessen. Dies ist eine risikobasierte Entscheidung, keine binäre. Wie verhält es sich mit WPA3-Enterprise? WPA3-Enterprise schreibt für Hochsicherheitsumgebungen den 192-Bit-Sicherheitsmodus vor, unterstützt aber weiterhin EAP-Methoden einschließlich PEAP. WPA3 verbessert die Verschlüsselung über die Luft, ändert jedoch nicht den EAP-Authentifizierungsaustausch selbst. Abschnitt fünf: Zusammenfassung und nächste Schritte. Zusammenfassend lässt sich sagen: PEAP ist ein zweiphasiges Authentifizierungsprotokoll, das interne Anmeldedaten — in der Regel MSCHAPv2 — in einen TLS-Tunnel verpackt. Es ist die am weitesten verbreitete 802.1X EAP-Methode, da sie Client-Zertifikate überflüssig macht und dennoch eine starke Server-Authentifizierung bietet. Die Hauptschwachstelle sind Angriffe über gefälschte Access Points (Rogue APs), die durch falsch konfigurierte Supplicants ermöglicht werden, die das Serverzertifikat nicht validieren. Minimieren Sie dieses Risiko durch MDM-erzwungene Wireless-Profile, CA-Pinning und Servernamen-Validierung. Für die meisten Enterprise-WiFi-Deployments — Unternehmensbüros, Back-of-House-Netzwerke in Hotels, Netzwerke für Einzelhandelsmitarbeiter — ist PEAP-MSCHAPv2 mit der richtigen Konfiguration eine solide, vertretbare Wahl. Für Hochsicherheitsumgebungen, regulierte Branchen oder Organisationen mit einer ausgereiften PKI-Infrastruktur bietet EAP-TLS eine deutlich stärkere Sicherheit und sollte die Zielarchitektur sein. Wenn Sie neben Ihrem Unternehmensnetzwerk auch ein Gäste-WiFi betreiben — was auf die meisten von Ihnen zutrifft —, denken Sie daran, dass PEAP nicht das richtige Tool für das Onboarding von Gästen ist. Nutzen Sie Plattformen wie Purple, die eine speziell entwickelte Gäste-WiFi-Authentifizierung mit Analysen, Datenerfassung und Marketingintegration bieten, sodass Ihr Gäste- und Unternehmenstraffic ordnungsgemäß getrennt bleibt und Ihre Compliance-Richtlinien eingehalten werden. Für weitere Informationen lesen Sie die Leitfäden von Purple zur RADIUS-Serverarchitektur und zur Enterprise-WiFi-Authentifizierung. Die Links finden Sie in den Shownotes. Vielen Dank fürs Zuhören. Dies war ein Purple Enterprise WiFi Intelligence Briefing.