Diskussion:WPA2

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Bitte überarbeiten![Quelltext bearbeiten]

"Umstellung WEP WPA"[Quelltext bearbeiten]

Also der Text hier stimmt so nicht. Hier muss die Box nichts in Software emulieren, da AES extra für den Softwarebetrieb entwickelt wurde, und somit in Software fast die 10-fache Leistung hat wie RC4.

Siehe: http://doc.utwente.nl/57007/1/000000eb.pdf Seite 13

Wobei ich zustimmen würde wäre, dass WEP vielleicht bei diesen Boxen, wo ein Upgrade zu WPA2 nicht möglich ist, in Hardware gegossen wurde, und man Hardware nicht einfach durch Software austauschen kann. Ist ja auch logisch :)

-- Matzeepple 19:24, 4. Mai 2009 (CEST)[Beantworten]

"praktisch unknackbar"[Quelltext bearbeiten]

In der Einleitung des Artikels steht, dass WPA2 praktisch unknackbar sei. Diese Information scheint veraltet.

Es ist nun russischen Sicherheitsexperten gelungen mittels eines BruteForce Angriffes einen WPA2-Schlüssel zu ermitteln. Bisher nahm man an, dass niemand dafür ausreichend Rechenleistung aufbringen könnte. Mit Hilfe einer oder mehrerer nVIDIA-GPUs kann man den Rechenvorgang nun jedoch enorm beschleunigen.

Es geht darum, dass das Verfahren an sich sicher ist. Dass zu kurze Passphrasen anfällig für Bruteforceatacken sind, ist nichts Neues. Das ist aber kein WPA Problem, sondern eins der Benutzer. Ein 63 stelliger PSK in akzeptabler Zeit zu knacken ist sehr unwahrscheinlich. Ich werde jetzt darauf verzeichten vorzurchenen, wie hoch die Wahrscheinlichkeit ist in absehbarer Zeit den richtigen PSK zu raten.....--84.58.183.47 16:13, 8. Feb. 2013 (CET)[Beantworten]

Siehe:

 http://www.mckeay.net/2008/10/10/brute-force-attacks-against-wpawpa2-using-nvidia-cards/
 http://www.hardware-infos.com/news.php?news=2456
Seit heute ist WPA2 "offiziell" gebrochen. Nicht der Key selber, den kann man nicht errechnen, sondern das Sicherheitskonzept des Protokolls. Es wird einfach ein eigener Schlüssel injiziert. --mildmr 18:08, 16. Okt. 2017 (CEST)

Quellenangabe fehlt[Quelltext bearbeiten]

Im Abschnitt "Sicherheit" wird behauptet, der BGH hat WPA2 als Sicherheitsstandard definiert. Bitte Quelle benennen (Datum/Aktenzeichen und/oder Fundstelle der Entscheidung).--94.223.189.145 19:32, 16. Dez. 2010 (CET)[Beantworten]

Reduktion der Sendeleistung sinnvoll?[Quelltext bearbeiten]

Das reduzieren der Senderleistung bringt keine zusätzliche Sicherheit, ein Angreiffer wird immer einen stärkeren Sender besitzen. Das einzige was erzielt wird ist eine verringerte Leistung für die eigenen Geräte. Falke666 12:33, 18. Jul 2006 (CEST)

Ja, aber hat der Angreifer auch einen stärkeren Empfänger? Bei einem gezielten Angriff ist natürlich die Verwendung einer Richtantenne möglich - ein relativ unkomplizioertes Zusatzelement. Trotzdem ist das nicht umbedingt ausreichend, um einen Angriff von ausserhalb der Grundstücksgrenzen zu ermöglichen.
Eine reduzierte Sendeleistung kann aber die gafhr verringern, dass "Gelegenheitsangreifern" die Gelegenheit überhaupt erst wahrnehmen. --Klaws 16:16, 11. Feb. 2011 (CET)[Beantworten]
Eine Reduktion des SNR außerhalb der Nutzfläche unter ein für Angriffe nutzbares Maß zu bringen, ist für sich genommen schon eine Sicherheitsmaßnahme, hat aber weder mit WPA noch mit der hier eingesetzten Kryptographie etwas zu tun, und hat somit hier auch nichts verloren. Abseits davon kann der SNR auch auf Entfernung mit einer Antenne mit Gewinn, z.B. einer Parabolantenne (Gewinn > 24 dBi bei 2,4 GHz, > 30 dBi bei 5 GHz), wieder auf ein nutzbares Niveau angehoben werden, ist mithin also nur Scheinsicherheit, da niemals bekannt ist, welches technische Equipment ein Angreifer einsetzen wird. Wer mit CUDA oder FPGAs Brute Force Angriffe fährt, wird sich von einem zu schwachen Signal kaum stören lassen. Jedenfalls wird niemand die Sendeleistung soweit reduzieren können, dass im Nutzbereich genügend SNR-Marge verbleibt, um die eigenen Geräte ordentlich zu versorgen, während außerhalb der Nutzfläche kein Abhören mehr möglich wäre. Welche Sender oder Sendeverstärker Angreifer benutzen, spielt gar keine Rolle, da alle relevanten Angriffe "offline" erfolgen müssen, also anhand mitgeschnittenen Traffics, und somit im wesentlichen der Empfang des Signals von Außerhalb eine Rolle spielt. Da hier der SNR wesentlich ist, der per Definition durch Verstärker nur schlechter statt besser wird, sind wir wieder zurück bei einer Antenne mit Gewinn. 79.255.25.174 13:23, 21. Jun. 2014 (CEST)[Beantworten]

so dass faktisch keinerlei praktischer Nutzen vorhanden ist, da die Netzwerke auch für den normalen Benutzer sichtbar sind.

Ganz so stimmt das ja nicht, weil man muss ja erstmal die SSID herausfinden, bevor man sich einloggen kann. Ichdertom 23:25, 9. Apr. 2007 (CEST)[Beantworten]

Normalerweise braucht man nur zu warten bis sich jemand einloggt oder ein "Reassociate" macht, dann hat man die (E)SSID. Das ist gar kein Hindernis. Raten muss man da gar nicht.

Außerdem, sollte jemand eingeloggt sein, kann man diesen "Deauthentifizieren" und damit den Namen mitsniffen.

Die SSID wird ja trotzdem übertragen. Es wird nur nutzlos ein Flag gesetzt dass den PC "bittet" sie nicht anzuzeigen in der Liste. --95.88.103.178 14:04, 23. Jul. 2014 (CEST)[Beantworten]

Wieviel MIPS für WPA2/AES[Quelltext bearbeiten]

"Eine einfache Umstellung wie von WEP auf WPA durch ein Firmware-Update ist nicht bei jedem Gerät möglich. Zum Teil ist die Hardware zu langsam, um die AES-Verschlüsselung in Software zu emulieren. Abhilfe schaffen dann nur neue Endgeräte mit Spezialhardware für AES."

Wieviele MIPS sollte ein Router ungefähr haben. Würde mich hier etwas interessieren? ~ Gruß

Mir ist an diesem Satz nochwas aufgefallen: sinngemäß steht dort, dass nicht jedes Gerät durch ein Firmware-Update auf WPA umgestellt werden kann, da die Hardware für AES zu langsam ist. Allerdings nutzt doch nur WPA2 AES, oder? Ich vermute mal, dass es WPA2 heißen sollte... --92.230.26.229 01:53, 12. Feb. 2009 (CET)[Beantworten]

bzgl. WLAN-Passwort unter Linux[Quelltext bearbeiten]

Jedoch können Sonderzeichen im Passwort Probleme unter alternativen Betriebssystemen, wie z.B. Linux, bereiten.

Ich halte das für ein Gerücht. Ist Linux auf einigermassen neuestem Stand, ist das überhaupt kein Problem. Entweder sollte dieser Satz also gelöscht werden, oder man gibt EXAKT an, auf welches Linux bzw. welchen Kernel sich man hier bezieht! (oder welche Zeichenkodierung!)

Habe das mal etwas entschärft. --Thornard, Diskussion, 15:18, 6. Aug. 2007 (CEST)[Beantworten]
Okay, Neulinge auf diesem Gebiet hätte das wahrscheinlich abgeschreckt.
Kann es sein dass die Zeichen !"#$%&'()*+,-./:;<=>?@[\]^_`{|}~ aus dem ersten ASCII Standard (ANSI X3.4-1968) verwendet werden können? Diese sollten doch ohne weiteres eingesetzt werden können, da sie ja auch in vielen Programmiersprachen als Basis dienen. Daher kenne ich eigentlich auch nur das Problem dass das Zeichen für einen Zeilenumbruch anderst kodiert wird, unter den verschiedenen Betriebssystemen. Das würde dann die Probleme mit ä, ü, ö und auch § erklären.

Sollte man Security through obscurity ernsthaft empfhelen?[Quelltext bearbeiten]

Die Tipps für die Erhöhung der Sicherheit scheinen mir fast vollständig gegen Kerckhoffs’ Prinzip zu verstoßen. Manche davon sehe ich als fragwürdig an, und manche gar als völlig nutzlos. Dies zu be- oder widerlegen würde wohl hier den Rahmen sprengen.

Natürlich kann es nicht schaden, diese zusätzlichen Maßnahmen zu ergreifen, aber ich befürchte, dass diese Tipps den Eindruck machen können, dass man mit geringer Sendeleistung, einer ungewöhnlichen IP-Adresse und einer sinnfreien SSID auch nur annhähernd die Sicherheit eines sicheren Passwortes bekommen könnte. Andererseits ist doch die kryptografische Sicherheit von AES so hoch, dass ein sicheres Passwort allein ausreichen sollte, womit man sich den Ärger der anderen "Sicherheitsmaßnahmen" komplett sparen kann.

Das sollte meiner Meinung nach definitiv unter "Weniger geeignete Maßnahmen". Genauso wie "Wlan-Geräte abschalten"; auch die Empfehlung eine Firewall zwischen drahtlosem und kabelgebundenen Netzwerkteilen einzusetzen macht für mich keinen Sinn da es nur IT-Spezialisten anspricht. --Phips.A 14:57, 26. Feb. 2008 (CET)[Beantworten]

Kompatibilität WPA/WPA2[Quelltext bearbeiten]

"WPA2 und WPA können einzeln eingesetzt, sofern WPA2 vom Access Point unterstützt wird, sowie nur bei wenigen speziellen Access Points gemeinsam verwendet werden." ---- stimmt wohl so nicht mehr ganz!? meine nullachtfuffzehn fritzbox kann auch schon beide gleichzeitig (mit halbwegs neues firmware)... Gruß R

WEP mit Authentifizierung[Quelltext bearbeiten]

Auch die im WEP integrierte Authentifizierung stellt kein nennenswertes Hindernis für Angreifer dar.

WEP mit Authentifizierung ist noch schlimmer als ohne. Bei diesem Verfahren kriegt man das Passwort sogar geschenkt und kann sich den Zeitaufwand der Datenanalyse ganz ersparen. FreeBSD hat den Code für "Shared Key" zeitweise sogar ganz entfernt. Deswegen war es mir aufgefallen.

Heißt das offiziell WPA2 oder ist das einfach nur eine Abkürzung? Wenn es offiziell so heißt, kann's bleiben. Ansonsten würd ich sagen, auf Wi-Fi Protected Access 2 verschieben. --Xephƃsɯ 17:11, 6. Nov. 2008 (CET)[Beantworten]

Wieviel Leistung und Durchsatz frisst die Verschlüsselung?[Quelltext bearbeiten]

Könnten die Damen und Herren Hochverschlüsselungsapologeten einmal sagen, wieviel Leistung das braucht? Rechenleistung, Datendurchsatz. 50 % ? Ganz zu schweigen von den nervenaufreibenden Inkompatibilitäten, die einen beim Versuch, legal in ein WPA2-Netz zu kommen, gelegentlich hoffnungslos und endgültig verzweifeln lassen. Ich denke da an eine fleißige Journalistin, die aus der T-Mobile-Lounge in Barcelona (mit dem richtigen Schlüssel und allen Segnungen des Hauses!) stundenlang versucht hat, ihren Bericht abzusetzen, mich dann verzweifelt beim vereinbarten Abendessen anrief, und ich ihr empfahl, sich einen Ethernet-Stecker aus einem Laptop im Pressezentrum herauszuziehen und über Draht zu gehen. Man kann Verschlüsselung auch übertreiben. Fritz Jörn 22:32, 24. Jun. 2009 (CEST)––[Beantworten]

Der Verbrauch von Rechenleistung und Datendurchsatz ist vernachlässigbar, mit den häufigen Problemen bei der Herstellung der verschlüsselten Verbindung hat das nichts zu tun. Diese Probleme sind meist auf unter den Stationen schlecht abgestimmte Hardware/Firmware zurückzuführen. Natürlich ist eine Kabelverbindung vorzuziehen, wenn möglich. --91.32.76.59 00:11, 9. Dez. 2009 (CET)[Beantworten]

Im Artikel ist von TKIP die Rede, ohne den Begriff zu verlinken oder diese Abkürzung zu erklären - vielleicht könnte man dazu einen Satz schreiben (kenne mich selbst nicht damit aus ...). chamecko 20:26, 10. Nov. 2009 (CET)[Beantworten]

Artikel unter Computerbild-Niveau[Quelltext bearbeiten]

Im Artikel wird fröhlich die WPA-Personal-Passphrase mit dem PSK (Pre Shared Key) verwechselt und durcheinandergeworfen. Das passiert aber auch einigen WLAN-Herstellern, sie unterstützen die Eingabe eines PSKs schlicht nicht (Beispiel Zyxel).

Fast niemand im privaten Bereich verwendet einen Pre Shared Key, sondern eine Passphrase, aus der die Geräte dann zusammen mit der ESSID den PSK generieren. Diese Generierung reduziert den Schlüsselraum effektiv um mehr als die Hälfte der möglichen 256 Bit. Auf diesem Designfehler basieren sämtliche Angriffe gegen WPA/WPA2. Über kurz oder lang werden sämtliche Passphrases egal welcher Länge als geknackt gelten.

Wer sich also vor diesen Angriffen schützen will, verwendet die Passphrase nicht, sondern gibt den 32 Byte langen PSK direkt ein (64 (!) hexadezimale Ziffern) oder verwendet WPA Enterprise mit Zertifikaten.

Die Passphrase ist im Standard übrigens genau aus diesem Grund auf 63 Zeichen begrenzt worden, damit Geräte diese vom PSK bereits bei der Eingabe unterscheiden können. (nicht signierter Beitrag von 92.224.142.163 (Diskussion | Beiträge) 06:04, 30. Dez. 2009 (CET)) [Beantworten]

Lemma sollte verschoben werden[Quelltext bearbeiten]

Hallo, aus Gründen besserer Konsistenz sollte das Lemma von WPA2 auf Wi-Fi Protected Access 2 verschoben werden. (analog Wi-Fi Protected Access für WPA). Gruß --87.150.242.213 17:32, 30. Dez. 2009 (CET)[Beantworten]

Mitlesen des Datenstroms bei Bekanntheit des PSK[Quelltext bearbeiten]

Ich hab mich jetzt ausführlich mit dem Thema beschäftigt und soweit ich das verstanden haben kann man sofern man Kenntniss über den PSK hat einen 3-way Handshake sowie die nachfolgende Kommunikation mit dem AP mitschneiden und den während des Handshakes ausgehandelten Schlüssel zurückberechnen um damit die gesamte Kommunikation entschlüsseln. Ich habe das selbst noch nicht ausprobiert, jedoch erscheint es für mich Schlüssig. Auf Verfahren wie den Diffie-Hellman-Schlüsselaustausch wurde beim Spezifizieren bewusst verzichtet. Sofern das wirklich stimmt, finde ich sollte in diesem Artikel darauf hingewiesen werden, dass ein mit WPA2 gesichertes Netzwerk nur solange sicher ist, wie alle Netzwerkteilnehmer Vertrauenwürdig sind und kein Angreifer im besitzt des PSK ist. --109.193.70.34 15:00, 25. Sep. 2011 (CEST)[Beantworten]

Du sprichst mir aus der Seele. Genau das hab ich auch gedacht. Diffie-Hellman-Schlüsselaustausch implementieren und ein verlorener PSK sorgt nicht mehr dafür, dass ein Angreifer alle Daten entschlüsseln klann, die er vorher mitgeschnitten hat. Im Moment ist wohl die einzige Möglichkeit sich vor dieser Gefahr zu schützen, der Einsatz eines RASIUS Servers und Cient Zertifikaten.... wobei man da auch wieder achtgeben muss, damit man kein EAP verwendet... weil das ist ja auch wiederum in wenigen Stunden knackbar... (nicht signierter Beitrag von 84.58.183.47 (Diskussion) 16:13, 8. Feb. 2013 (CET))[Beantworten]

Sicherheitsmaßnahmen - SSID?[Quelltext bearbeiten]

Ist es nicht so, dass der Session-Key(?) bei WPA2-PSK sich aus PSK und SSID zusammensetzt, also eine Änderung der SSID Angriffe mittels Rainbow-Tables erschwert? --2A01:198:70A:FEFE:225:22FF:FE67:F10B 13:37, 22. Sep. 2012 (CEST)[Beantworten]

der englische artikel sagt "The PTK is generated by concatenating the following attributes: PMK, AP nonce (ANonce), STA nonce (SNonce), AP MAC address, and STA MAC address. The product is then put through PBKDF2-SHA1 as the cryptographic hash function." die SSID spielt also gar nicht mit rein und rainbow-tables einzusetzen ist auch sinnlos, weil beide parteien eine einmalige zufallszahl (nonce) waehlen. --Mario d 18:50, 8. Feb. 2013 (CET)[Beantworten]

Sicherheitsmaßnahmen[Quelltext bearbeiten]

"Dieser sollte die maximale Schlüssellänge von 63 Zeichen nutzen.", diese Empfehlung für die Passphrase (der PSK wird davon abgeleitet) ist doppelt und dreifach hirnrissig.

Da es sich um eine Passphrase handelt, aus der der PSK abgeleitet wird, spielt die Länge dieser Passphrase nur für Brute-Force-Angriffe auf die Passphrase selbst eine Rolle. Um die Kompatibilität zu erhöhen, beschränkt man sich hier auf a-z, A-Z und 0-9, also 62 Möglichkeiten je Stelle. Bei 12 Stellen ergeben sich grob 3,2 x 1021 Möglichkeiten, also wären im Mittel 1,6 x 1021 Angriffe nötig. Bei einer hypothetischen Angriffsdauer von 1ns je Versuch wären das immer noch 50.000 Jahre. Mit anderen Worten, die notwendige "absolute" Sicherheit ist bei einem zufällig gewählten Schlüssel nach obigen Kriterien mit einer Schlüssellänge von 12 bis 16 Zeichen bereits vollständig erreicht und Brute-Force-Angriffe wären keine Option mehr. Bei 22 Zeichen wäre die technisch mögliche Entropie sowie schon überschritten und bei längeren Passphrasen tritt somit gar keine Erhöhung der Sicherheit mehr auf.

Was spricht nun dagegen, eine 63 Zeichen lange Passphrase (> 10112 Möglichkeiten) zu verwenden? Da der PSK aus der Passphrase abgeleitet wird, und "nur" 128 Bit lang ist, mithin also 1038 Möglichkeiten erlaubt, überschreitet eine 63 Zeichen lange Passphrase bei weitem die durch die Schlüssellänge möglich Entropie. Das wäre auch nicht weiter schlimm, allerdings reduziert die Nutzung einer so langen Passphrase deutlisch den Komfort beim Verbinden eines Gerätes, so dass schnell auf unsichere Verfahren wie WPS, am Gerät angebrachte QI-Codes oder NFC-Tags zurückgegriffen wird.

Mit anderen Worten: eine Passphrase ist bei einer komfortablen Länge, die man manuell bequem eingeben kann, bereits mehr als sicher genug, ab einer bestimmten Länge wird die Sicherheit in der Praxis aufgrund der 128-Bit-Beschränkung auch nicht mehr weiter erhöht, und bei zu langen Schlüsseln wird die Eingabe desselben so unpraktisch, dass wieder Verbindungsverfahren zum Einsatz kommen, die die Sicherheit beträchtlich reduzieren. Ein völlig ausreichender 12-Zeichen-Schlüssel kann bequem von einem Zettel oder Bildschirm abgelesen und in das Mobilgerät eingegeben werden. WPS-PIN und WPS-Push-Button dagegen sind unsicher, da sie entweder die notwendige Schlüssellänge für eine erfolgreiche Verbindung deutlich herabsetzen, oder lediglich einen kurzen Moment des physischen Zugriffs benötigen, um eine Verbindung herzustellen. Gleiches gilt für QI-Codes oder NFC-Tags. (nicht signierter Beitrag von 79.255.25.174 (Diskussion) 13:23, 21. Jun. 2014 (CEST))[Beantworten]

Der WPS Push Button macht gar nichts unsicher weil diese kurze Pin dann nur für wenige Minuten nutzbar ist. --95.88.103.178 14:07, 23. Jul. 2014 (CEST)[Beantworten]

Wasserzeichen im Bild[Quelltext bearbeiten]

Ich bin relativ neu, aber ich finde, dass das Wasserzeichen im Bild der Weltkarte Schleichwerbung ist und so etwas nich in einen Wikipediaartikel passt. Ich will es jetzt nicht einfach rauslöchen, aber vielleicht gibt es ja eine Alternative. Die Karte ist zudem von 2007. NathanScheufele (Diskussion) 17:44, 2. Feb. 2015 (CET)[Beantworten]

Einleitung verständlicher?[Quelltext bearbeiten]

Ob es möglich wäre, die Einleitung zumindest am Beginn allgemeinverständlicher zu formulieren? "Implementierung" und die Berufung auf IEEE 802.11a, b, g, n (...) ist nicht gerade laienverständlich. Da WPA 2 aber gerade auch von Laien eingesetzt wird/werden sollte, müsste das doch auch anders formuliert werden können, oder? --Superbass (Diskussion) 17:35, 8. Feb. 2016 (CET)[Beantworten]

Link auf Beschreibung des 4-Wege-Handshakes[Quelltext bearbeiten]

Es wäre nett wenn sich die folgende Beschreibung des 4-Wege-Handshakes hier an geeigneter Stelle verlinken ließe.
https://en.wikipedia.org/wiki/IEEE_802.11i-2004#The_four-way_handshake
Auch in der englischen Wikipedia hatte ich die Beschreibung nicht gleich auf Anhieb gefunden. Eine geeignete Verlinkung spart einfach Zeit.
Vielen Dank. 109.91.245.60 16:18, 17. Okt. 2017 (CEST)[Beantworten]

Abschnitt Sicherheit hoffnungslos veraltet?[Quelltext bearbeiten]

Auch wenn der abschnitt sicherheit im dritten satz ausdrücklich auf 2006 hinweist, sind die davorstehenden zwei sätze m. e. im jahr 2021 nur noch irreführend. Entweder entspricht WPA2 nicht mehr den "strengen anforderungen" oder besagte anforderungen sind nach heutigen maszstäben nicht mehr als "streng" zu betrachten. Ich kenne mich mit der materie nicht im detail aus, halte aber eine aktualisierung für überfällig. Zooloo (Diskussion) 15:37, 22. Okt. 2021 (CEST)[Beantworten]

Ich will nichts behaupten, weil ich gerade keine Belege zur Hand habe, aber bei WPA2 hängt die Sicherheit sehr von den schlüssellängen ab. 64 Bit soll inzwischen in ein paar Minuten mit einem Standardrechner zu knacken sein, 128 Bit (16 Zeichen) galten vor 2-3 Jahren noch als sicher, und erlaubt sind ja eh bis zu 63 Zeichen. Da die Spezifikationen wohl noch sicher sein dürften, ist also noch genügend Spielraum vorhanden. Ich gehe davon aus, dass die Informationen zwar alt, aber nicht zwingend veraltet sein müssen. --H7 (Mid am Nämbercher redn!) 11:33, 26. Okt. 2021 (CEST)[Beantworten]
Der ganze Artikel müsste mal aktualisiert werden. Insbesondere da in WPA2-Netzen der Schlüssel symmetrisch für alle Verbindungen genutzt wird, sollte es nirgendwo außer vllt in privaten Netzen mehr eingesetzt werden, wobei selbst da WPA3 zu empfehlen ist sofern verfügbar. --BlauerBaum (Diskussion) 00:37, 11. Nov. 2021 (CET)[Beantworten]