News Unsichere Passwort-Abfrage bei Amazon

[LinuxMcBook]

@LinuxMcBook: Nein. Aber wenn du sachlich sein wolltest, hättest du das ja auch selbst rausfinden können.

Waren 14 Zeichen. Also trotzdem begrenzt.
http://www.heise.de/security/artikel/Mit-roher-Gewalt-270318.html

 

[1668mib]

Der Aritkel hat echt eine krasse Relevanz...

 

[Hexxxer76]

Geht bei mir nisch.

Hab es gerade getestet, bei mir geht es nicht.

Bei mir tritt das Problem auch nicht auf.

hier kein probleme

Bei mir geht das auch nicht ..

Das selbe bei mir. Momentan ist alles okay.

 

[Bartonius]

Ich habe ein 8-Zeichen Passwort und bei mir klappt das ganze. Alles, was ich über die 8-Zeichen hinaus eingebe, wird gepflegt ignoriert und ich kann mich einloggen, solange die ersten 8 Zeichen stimmen.

Der Account scheint von 2006 zu sein, zumindest sind in dem Jahr meine ersten Bestellungen gelistet.

 

[riDDi]

Auch interessant: Ich hab grade mal mein Passwort geändert, um es zu testen. Es kam eine Mail, dass mein Passwort zurückgesetzt wurde. Keine Bestätigung erforderlich. Wenn jemand anderes mein Passwort geändert hätte, dann könnte ich rein gar nichts dagegen tun. Das sind Anfängerfehler, die man von einem internationalen Multimilliarden-Dollar-Unternehmen nicht erwarten würde.

 

[Dante2000]

Kann diese Meldung nicht nachvollziehen. Mein Account ist offenbar nicht betroffen.

 

[easy.2ci]

Also ich bin betroffen, halte das aber für keine große Sache. Hab ein 8 stelliges Kennwort und kann da beliebige Zeichen hinten dranhängen und mich trotzdem einloggen.

Laut heise ist das so, wenn das Passwort vor zig Jahren gesetzt wurde und nicht mehr geändert wurde. Dann ist es immernoch mit dem damals unzulänglichen Hash Algorythmus berechnet und seitdem eben nicht mehr angefaßt worden.

Das macht mein PW aber jetzt auch nicht unsicherer.


Werds dennoch ändern, damit ein moderner Algorythmus benutzt wird.

Account besteht seit 2005.

 

[Xport]

Mein Passwort entspricht den meisten gängigen Regeln für "harte" Passworte, und nur mit den ersten 8 Zeichen klappt das nicht. Offenbar geht's nur, wie man hier liest, mit 8-stelligen an die man was anhängt. Das würde bedeuten, dass die Passwort-Abfrage einen Längenabgleich durchführt? So etwas habe ich ja noch nie gehört.

 

[Jesterfox]

Kein Längenabgleich sondern einfach nur eine alte Hashfunktion die nur 8 Zeichen verarbeiten kann zusammen mit einem vorherigen SubString um es abzuschneiden. Wird aber wohl nur noch für richtig alte Passwörter verwendet die seitdem nicht geändert wurden.

 

[WhiteShark]

Du denkst zu kompliziert. Amazon braucht doch die alten Passwörter gar nicht herausfinden.
Sie schreiben einfach neu generierte Passwörter in ihre Datenbank.

Dafür bastelt man sich ein kleines Script welches die Passwörter generiert und diese neuen Passwörter an die Kunden herausschickt. Das Script verschlüsselt das Passwort dann und überschreibt das alte Passwort mit dem neuen Passwort in der Datenbank. Fertig das Problem ist gelöst.

Das wäre aber ein recht unprofessioneller Weg. Ich würde mir da eher denken das es zuvor ein gravierendes Sicherheitsproblem gab und möglicherweise alle Passwörter geknackt worden wären. Nur das würde in meinen Augen solch einen Schritt rechtfertigen.

Professionell löst man sowas recht simpel. Man legt in der Datenbanktabelle ein weiteres Feld an, bspw New_Passwort.
Meldet sich der User jetzt an und sein Feld ist leer, so wird das eingegebene Passwort mit dem alten Passwort verglichen. Ist es korrekt und damit der Login erfolgreich, so wird das Klartextpasswort (hat der User ja eingegeben) mit dem neuen Verfahren gehasht und gepeichertin dem neuen Datenbankfeld.
Schon hat man das Passwort konvertiert.
Der nach der alten Methode erstellte Hash sollte dann natürlich aus der Datenbank entfernt werden (denn dieser ist ja leichter angreifbar).

Der Kunde bekommt davon nichts mit und erfährt nie etwas von der Sicherheitslücke.

auch 8 Zeichen sind doch ganz sicher, wenn man groß, klein und Sonderzeichen verwendet.

Es ist spielt an sich keine Rolle ob man Groß/Kleinschreibung und Sonderzeichen verwendet.
Bei Bruteforce werden erstmal die Standard-Passwort-Listen abgearbeitet. Sind die durch so wird nach und nach jedes erdenkliche Passwort geprüft.
Nach aaaaaa kommt aaaaab, dann aaaaac und so weiter.
Es werden dabei für jede Stelle alle erdenklichen Zeichen ausprobiert. Ob man jetzt irgendwo ein Sonderzeichen hat spielt keine große Rolle, da die Anzahl an möglichen Kombinationen immer gleich ist.
Gehen wir mal von 100 möglichen Zeichen aus. Bei einem sechstelligem Passwort gibt es also 100^6 Kombinationen.
Ein siebenstelliges Passwort hat also hundert mal soviele Kombinationen wie ein sechsstelliges.
Es dauert also 100 mal länger es zu knacken.

 

[1668mib]

@WhiteShark: Wieso eine new_password-Spalte? Lieber eine Spalte, in der die Art des Algorithmus hinterlegt ist...

 

[WielandSchmied]

Also ich habe ein richtig altes Passwort (1999) und trotzdem komm ich nicht mit 8 Zeichen rein (Passwortlänge 10 Zeichen).

 

[Mr.Church]

doesn't work. safe
Dabei habe ich schon ein Konto seit 2000.

 

[WhiteShark]

@WhiteShark: Wieso eine new_password-Spalte? Lieber eine Spalte, in der die Art des Algorithmus hinterlegt ist...

Das wäre ja kontraproduktiv. Dann würden ja die unsicher gehashten Passwörter weiter in der Datenbank stehen. Man will die aber raushaben und das bisherige Passwort mit dem neuen Algorithmus speichern.

 

[1668mib]

@WhiteShark: Und warum sollte das mit einer Spalte, in der das zur Speicherung verwendete Verfahren angegeben wird, nicht gehen? oO

 

[WhiteShark]

Ahh jetzt hats gerade "Klick" gemacht, bin etwas müde^^.

Also man erstellt eine neue Spalte, alle erhalten erstmal den Wert 0 (also altes Verfahren), ausser Neuregistrierungen. Ist es im alten Verfahren, so wird es nach dem alten Verfahren geprüft, neu gehasht und der Wert auf 1 gesetzt.
Jo wäre eine bessere Lösung.

 

[1668mib]

Kann passieren ;-)

 

[Suxxess]

Professionell löst man sowas recht simpel. Man legt in der Datenbanktabelle ein weiteres Feld an, bspw New_Passwort.
Meldet sich der User jetzt an und sein Feld ist leer, so wird das eingegebene Passwort mit dem alten Passwort verglichen. Ist es korrekt und damit der Login erfolgreich, so wird das Klartextpasswort (hat der User ja eingegeben) mit dem neuen Verfahren gehasht und gepeichertin dem neuen Datenbankfeld.
Schon hat man das Passwort konvertiert.
Der nach der alten Methode erstellte Hash sollte dann natürlich aus der Datenbank entfernt werden (denn dieser ist ja leichter angreifbar).

Der Kunde bekommt davon nichts mit und erfährt nie etwas von der Sicherheitslücke.

Guter Einwand, wobei man dafür wohl nicht mal ein zweites Feld bräuchte. Wenn man davon ausgeht, dass man weiß wann die Passwortfunktion intern umgestellt wurde und wann der letzte Zugriff auf den jeweiligen Account stattgefunden hat, dann kann man durchaus das ursprüngliche Passwortfeld beim Login des Nutzers überschreiben.

 

[1668mib]

Ich weiß jetzt nicht ob es einfacher ist, anhand des Datums auf den Algorithmus zu schließen, oder ob eine Spalte mit der Info zum Algorithmus einfacher wäre...

Im Übrigen: Das Umstellen des Passworts kann vielleicht automatisch erfolgen... aber...
Wenn es eines der Problempasswörter ist, dann geht das gar nicht... weil angenommen mein PW ist 1234567890. Ich geb jetzt aber 1234567899 ein.
Das System merkt den Irrtum nicht, weil es nur die ersten 8 Zeichen beachtet... und schwupps hab ich das falsche Passwort drin...

 

[UnitedUniverse]

naja der angreifer muss aber dennoch die ersten 8 zeichen des passwortes kennen, sonst nützt ihm das doch nichts oder stehe ich grade auf dem schlauch und verstehe den artikel nicht?
bei mir jedenfalls ist eine anmeldung nicht möglich wenn ich alles über 8 weg lasse.....