Amazon: Sicherheitslücke bei einigen Passwörtern

Beim Versandhausriesen Amazon wurde eine schwerwiegende Sicherheitslücke entdeckt: Diese erlaubt ein Einloggen auf die Seite, auch wenn man ein falsches Passwort eingibt, die Lücke tritt aber nur unter bestimmten Umständen auf. mehr... Amazon, Logo, Versandhandel Bildquelle: Amazon Amazon, Logo, Versandhandel Amazon, Logo, Versandhandel Amazon

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben
 
Betrifft mich nicht... 9-stelliges Passwort, wenn ich nur 8 Stellen eingebe, bekomme ich eine Fehlermeldung. Auch wenn ich mehr als die 9 Stellen eingebe, kann ich mich nicht einloggen. Und ich bin seit 2007 Kunde und habe seitdem mein PW dort...
 
Bin seit Ende '99 dort und habe ein 14-stelliges Kennwort. Geht bei mir auch nicht.
 
@Niclas: 14 Stellen... seit 99 dort... Niclas... hmmm... niclasniclas99 ;D
 
@dodnet: Mist ! Wie konntest Du das nur so schnell erraten ? :D Und ich dachte das wäre sicherer als "password123456"
 
@Niclas: Habe ein 2007 stelliges kennwort und bin seit 12 dort
 
Bei mir (8-stellig) auch kein Problem. Sobald ich was dranhänge, lässt mich das System nicht rein.
 
geht noch nichts über "123" wie man jetzt wieder sieht
 
Das ein längeres Passwort, dass auf die gleiche Art beginnt akzeptiert wird ist wohl eher kein Problem. Wenn die effektive Sicherheit aber auf 8 Zeichen schrumpft....
 
Ich bin seit 1999 Kunde und nutze derzeit ein 15stelliges Passwort, und der Fehler betrifft mich nicht.
 
Verstehe echt nicht, dass Amazon kein Token für die Konten anbietet, nicht mal optional. Das würde solche Geschichten doch deutlich entschärfen...
 
@Vollbluthonk: Weil dann viel zu viele Vollhonks ihre Token versemmeln würden und Amazon damit nur Ärger hätte!
 
Das ist wohl noch ein Überbleibsel aus alten Unix-Zeiten als Amazon noch DES-Crypt genutzt hat. Da wurden immer nur die ersten 8 Zeichen des Passworts für die Hashgenerierung gelesen. Basierend auf 56bit Verschlüsselung, wird der Schlüssel aus den unteren 7 Bit des 8-stelligen Passworts generiert, noch ein 12stelliges Salt draufgehauen und fertig ist der Hash. Die gleiche Sicherheits-Problematik gabs vor 15 Jahren schon bei diversen Unix-Funktionen wie SSH, htaccess usw, die alle auf DES-Crypt zurückgegriffen haben.

Inzwischen sollten aber alle mit MD5 oder besseren Hashes laufen. Die Länge des Passworts spielt bei den heise-Tests dann logischerweise keine Rolle. Es ist nur relevant wann das letzte Mal ein neues Passwort gesetzt wurde. Wenn die letzte Passwort-Änderung 10 Jahre zurück liegt, liegen die Passwort-Hashes eben auch nur im alten Hash-Format vor und werden auch nach alter DES-Methode mit den ersten 8 Zeichen geprüft. Erst wenn der User ein neues Passwort generiert, werden neuere Crypt-Methoden verwendet, die alle Zeichen berücksichtigen.
 
@Trashy: Gute Erklärung. Habs getestet, nach PW-Änderung ist das Problem (siehe o9) nun auch beseitigt.
 
@Trashy: Ergänzend sei noch gesagt: Bei JEDER Website, die einen HASH für das Password verwendet, kann man durch Eingabe einer ANDEREN Zeichenkette Zugriff auf ein Konto Erlangen. Das nennt sich dann Kollision. So besonders ist das nicht. (Ein "Hash" kann vereinfacht betrachtet als Quersumme einer Zahl betrachtet warden. Speichert die Seite dann eben nur "5", sind mögliche Gültige Passwörter: 5, 41, 32, 11111 usw...) (Hashs sind natürlich sehr viel Komplexer.) Das Paradoxe ist aber leider: Je Kollisionsfreiher ein Hash ist, desto unsicherer ist er gegen Rainbow-Table-Attacken. Viele Kollisionen dagegen sind unsicher bei Bruteforce versuchen.
Aus diesen Gründen sind auch Passwörter wie "!"§%&$&(/)=/()ODFG" völlig unnötig, da kein Angreifer versuchen wird, das Password zu finden - sondern die erstmögliche Kollision. Und das "könnte" - wenns dumm läuft - "ABC" sein.
 
@dognose: Du verkennst die Lage etwas. Die Chance ist schon arg gering, ein anderes Passwort zu finden, das zufällig den gleichen Hash hat. Es macht keinen nennenswerten Unterschied, ob man versucht das richtige Passwort oder einen Kollisionshash zu finden - da bei vernünftigen Salting beides nur via Bruteforcing möglich ist. Rainbow-Tables bringen heutzutage null, weil jeder vernünftige Admin die Hashes salted, d.h., dass jedes Passwort einen eigenen Salt besitzt aus dessen Kombination dann erst der Hash entsteht. Es existiert schlicht kein Rainbow-Table, der diese Werte enthält. Selbst wenn der Hash dann gleich ist, kommt man mit dessen Passwort dank des Salts trotzdem nicht durch die Loginroutine, damit sind Rainbow-Tables völlig sinnlos. Wer will, kann das ganze auch noch peppern, d.h. eine fixe Zeichenkette zusätzlich vor der Hasherzeugung dranhängen, die nicht in der Datenbank gespeichert ist, aber für alle Passwörter auf dem Server gilt. Selbst wenn einem Angreifer jetzt die Datenbank zB durch einen SQL-Exploit samt verschlüsselten Hashes (inkl Salts) in die Finger fallen sollte und er sich über die Salts versucht neue Rainbow-Tables zu erzeugen (pro Passwort Millionen Einträge!), kann er ohne den passenden Pepper-String die Loginroutine dennoch nicht umgehen, weil die Passwörter aus seinem erzeugten Rainbow-Table wieder nicht zum Pepper-Key passen. Und darüber hinaus kann die Loginroutine noch zig andere Cryptoverfahren nutzen, die der Angreifer in der Regel nicht kennt. Klar existieren dann rein theoretisch immer noch Kollisions-Hashes, aber die kriegt man dann eben höchstens via Brutforcing raus. Ein guter Admin riegelt die Loginroutine dann aber sowieso nach 3 Falscheingaben gegen Bruteforcing für 5 Min für den Zielaccount ab.. dann braucht der Angreifer Jahr(zehnte)e fürs Knacken eines einzelnen Passworts - zumindest insofern der User was sinnvolleres als "ABC" hat - und genau aus dem Grund macht "!§%&$&(/)=/()ODFG" als Passwort auch deutlich mehr Sinn als "ABC" - den "ABC" findet man per Bruteforcing noch recht schnell. :P
 
@Trashy: In Zeiten, in denen große Unternehmen passwörter sogar im KLARTEXT speichern, würde ich mich nicht darauf verlassen, dass jene Admins überhaupt einmal was von Pepper oder Salt gehört haben. Rainbow Tables machen - auch bei Salt und Pepper - Sinn. Zwar nicht, wenn man ein einzelnes Passwort knacken will, doch wenn man z.b. einen Datensatz mit 5 Mio User-Daten in die Finger bekommt, dann baut man sich die entsprechenden Rainbow Tables auf, um alle Passwörter in vernünftiger Zeit "knacken" zu können. Der Vorteil von Rainbow-Tables liegt schließlich in einem "Kompromiss" aus Speicherplatz und Rechenzeit.
 
@dognose: Was bitte nützt dir ein Rainbow-Table, wenn jedes PW einen eigenen Salt hat? Du kannst den Rainbow-Table nur ohne Salt oder mit einem(!) bestimmten Salt (in dem Fall dann Pepper) erzeugen. Wenn aber jedes PW in der Datenbank seinen eigenen Salt hat, dann brauchst du auch für jedes PW einen eigenen Rainbow-Table - da ist nichts mit "alle Passwörter in vernünftiger Zeit knacken". Der Sinn von Salts ist es ja gerade, die reinen MD5-Rainbow-Tables wirkungslos zu machen. Wie schon oben gesagt - du kannst zwar zufällig einen identischen Hash im Rainbow-Table finden, aber das dazugehörige Passwort wird trotzdem nicht beim Login funktionieren, weil es nicht zum Salt in der DB passt. Und wenn noch ein unbekannter ein Pepperkey beim Login dazukommt, bleibt außer Bruteforcing nichts übrig. Siehe http://de.wikipedia.org/wiki/Rainbow_Table => Gegenmaßnahmen
 
Also ich kanns bestätigen. Ich hab ein 8 Zeichen langes PW (seit Anfang 2000er Jahre), habs eben eingegeben und ab dem 9. Zeichen einfach mal auf der Tastatur rumgeklimpert -> Enter -> eingeloggt -.-
 
das Problem mit den 8 Zeichen hatte auch der Ultra-VNC-Viewer in alten Versionen.
Kommentar abgeben Netiquette beachten!

Jetzt als Amazon Blitzangebot

Ab 00:00 Uhr Kaspersky Internet Security 2017 + Kaspersky Internet Security für 1 Android Gerät - [Online Code]
Kaspersky Internet Security 2017 + Kaspersky Internet Security für 1 Android Gerät - [Online Code]
Original Amazon-Preis
27,99
Im Preisvergleich ab
23,00
Blitzangebot-Preis
22,29
Ersparnis zu Amazon 20% oder 5,70

Amazons Aktienkurs in Euro

Amazons Aktienkurs -1 Jahr
Zeitraum: 1 Jahr

Kindle Oasis im Preis-Check