Ein historischer Moment

Impressum | Werbung

Geizhals » Forum » Geizhals »

Ein historischer Moment (30 Beiträge, 1071 Mal gelesen)

Top-100 | Fresh-100

Du bist nicht angemeldet. [ Login/Registrieren ]

Wenn jetzt etwas kaputt ist, oder man sich mit leeren Passwörtern einloggen kann, liegt es daran

geizhals_forum=# alter table users drop column pass;
ALTER TABLE

Das Hashen hat übrigens ca. 30 CPU-Stunden gedauert (langsame Hashfunktionen mit vielen Iterationen sind sicherer, wenn sie keine Designfehler aufweisen).

Die trotz großer Sorgfalt und Nüchternheit auftretenden Fehler bitte gleich melden (ich weiß, die Registrierung im Forum funktionierte jetzt ca. 1h lang nicht).

ACTA wird Menschen töten | wikileaks.geizhals.org

„Ich habe den Verdacht, dass sich alle Terrorismen, egal, ob die deutsche RAF, die italienischen Brigate Rosse, die Franzosen, Iren, Spanier oder Araber, in ihrer Menschenverachtung wenig nehmen. Sie werden übertroffen von bestimmten Formen von Staatsterrorismus“ (Helmut Schmidt)

"Ermittlungen in großen Wirtschaftsstrafsachen unterliegen wegen der Berichtspflichten der Ermittler zum Innen- und Justizministerium vollends dem politischen Würgegriff" (N. Haslhofer, ehem. StA)

Die Passwörter sind jetzt endlich verschlüsselt abgelegt? Endlich...

Save the Earth... it's the only planet with chocolate.
Sind Sie dämlich oder tun Sie nur so?

09.06.2012, 18:27 Uhr - Editiert von Ardjan, alte Version: hier

übersetzung plies!
-

---
Auf deutschem Boden darf nie wieder ein Joint ausgehen!

Es dürfte irgend etwas mit Tablettenbenutzung und Haschisch zu tun haben. Wenigstens hat er in der 30-Stunden-Session seinen Angaben nach aber keinen Tropfen Alkohol angerührt.

10.06.2012, 08:53 Uhr - Editiert von Thing, alte Version: hier

Es dürfte irgend etwas mit Tablettenbenutzung und Haschisch zu tun haben.
Wenigstens hat er in der 30-Stunden-Session seinen Angaben nach aber keinen
Tropfen Alkohol angerührt.

LOL

Grüße,
Geri

Wir schützen jetzt unsere User zusätzlich vor dem Bedrohungsszenario ihrer Fahrlässigkeit (wenn sie ihre Passwörter + Mailadresse auch woanders verwenden) kombiniert mit dem Szenario eines a) gehackten Datenbankservers oder b) GH-Mitarbeiters, der die Forum-Datenbank (oder Teile davon) leakt.

Einzelne Passwörter sind technisch gesehen nun nicht besser geschützt, da ein Angreifer sie nach wie vor durch einen gehackten Forum-Webserver erhalten kann (oder ein GH-Mitarbeiter ohne Hack) indem er einen Login provoziert (oder eine Seite wie "reaktivieren Sie Ihren account" baut) und sie im Klartext abfängt (möglich wenn man den Code am gehackten Webserver manipulieren kann) und das aus unserer Sicht das schwächste Glied in der Kette ist (abgesehen natürlich von jeweils schwächer geschützten Servern / Datenbanken bei denen die User auch die selben credentials verwendet haben).

Ein kompletter Datenbank-Dump von einem gehackten Forum-Webserver aus war auch bisher nicht möglich, da die Passwörter mit column permissions geschützt waren (kein User auf dem Forum-Webserver durfte darauf zugreifen, ein Angreifer hätte sie allenfalls auf dem Webserver selbst brute-forcen können, oder eben den "richtigen" Server hacken müssen).

Oder anders ausgedrückt: wir haben einen sehr hypothetischen Sicherheitsgewinn durch eine "state of the art"- (bzw. nicht-)Speicherung der (nunmehr sehr aufwändig gehashten) Passwörter, realistischere Schwachstellen gibt es nach wie vor, allen voran die Mehrfachverwendung der Logindaten durch die User.

danke für die übersetzung

da muss ich meinen datenbank-dump voll brute-forcen, damit ich mein credential mit column permissions richtig server hacken kann....
aber wahrscheinlich bin ich nicht state of the art......

ich liebe deutsche erklärungen

datenbank-dump

Datenbankstuhlgang.

brute-forcen

Brachialgewalt anwenden.

credential

Anrede.

column permissions

Säulenerlaubnis.

deutsche erklärungen

Das Problem dabei ist, dass manche deutschsprachige Fachbegriffe gängig und verständlich sind, andere aber kaum, irgendwo muss man dann die Grenze ziehen damit man noch verstanden wird und der Leser nicht rätseln muss, was jetzt mit den selten verwendeten und weniger eindeutigen Alternativen "erschöpfende Suche" oder "Durchprobieren" in dem Kontext gemeint ist (für "brute-force" gibt es eigentlich keine gängige Übersetzung).

Völlig oT, nur aus Interesse:

langsame Hashfunktionen mit vielen Iterationen sind sicherer, wenn sie keine Designfehler aufweisen

Hast Du dazu eine Quelle?
Meiner Ansicht nach reicht eine beliebige Funktion mit
- gutem Avalanche-Effekt
- Ergebnis konstanter Breite.

Jede beliebige aus der SHA-2-Familie sollte es also tun... Oder stehe ich wo auf der Leitung?

12.06.2012, 07:40 Uhr - Editiert von kombipaket, alte Version: hier

Meiner Ansicht nach reicht eine beliebige Funktion mit
- gutem Avalanche-Effekt
- Ergebnis konstanter Breite.

Die Funktion sollte (neben den anderen wichtigen Kriterien) langsam genug sein, damit sie nicht in absehbarer Zeit mit genug Ressourcen geknackt werden kann. SHA-2 ist schon mal ziemlich flott. Unsere Variante schafft auf einer flotten CPU gerade mal 3 hashes/Sekunde, d.h. sie ist ca. 1 Mio. x langsamer als MD5 und gerade noch praktikabel um beim Login verwendbar zu sein. Außerdem kann man mit der Zeit (und schnelleren CPUs) die Iterationen raufsetzen, die neu gespeicherten Passwörter sind dann sicherer (bzw. das hashing langsamer).

Reines Hashing oder gleich was "Richtiges" wie bcrypt oder scrypt?

bcrypt

Durch mehrfaches Hashen kann man auch die Berechnung von Rainbow Tables erschweren bzw. praktisch verunmoeglichen - ein Angreifer muesste ja fuer jede Anzahl an durchgefuehrten Iterationen eine entsprechende Table errechnen. Ein Salt ist zwar die einfachere und gaengigere Loesung hierfuer, aber es spricht ja auch nichts dagegen, diese beiden Verfahren zu kombinieren.

Ausgehend davon, dass jeder Hash gesalzen werden soll - würde ich das als ausreichend erachen

.

So aus dem Bauch raus halte ich mehrfaches Hashen sogar für gefährlich:

Jeder Hash ist ja eine Abbildung von varchar nach varchar, wobei ja Kollisionen entstehen können und eben der Avalanche-Effekt eintritt. Das birgt 2 Gefahren:

Bei mehrfachem Hashen können natürlich mehrfach Kollisionen eintreten. Das würde bedeuten, dass mehrfaches Hashen die Unsicherheit erhöht. Jede Kollision erlaubt ja eine zusätzliche "Einlogmöglichkeit".

Auch beim Avalanche-Effekt sehe ich Gefahren. Es könnte ja ideal sein, wenn bei N Bits N/2 Bits geändert werden, wenn ein Bit sich ändert. Dieser Effekt könnte sich durch mehrfaches Hashen aufheben.

Ich bin daher schwer unsicher, ob mehrfaches Hashen gegenüber einfachem Hashen nicht ähnliche Effekte bringen kann wie 2faches ROT13 gegenüber einfachem

14.06.2012, 06:56 Uhr - Editiert von kombipaket, alte Version: hier

Du hast recht, dass die Urbildmenge fuer jeden Durchgang ab der zweiten Runde der Hashfunktion wesentlich kleiner (naemlich gleich der Bildmenge) als beim ersten Mal ist. Fuer gefaehrlich halte ich das aber trotzdem nicht, da ja die Zahl der Runden ebenfalls vorgegeben ist: du muesstest also eine Kollision errechnen, die nicht _irgendeiner_ der Zwischenergebnisse der n Hashrunden entspricht, sondern eine Kollision nach _genau_ n Hashrunden - bzw. tritt eine Kolission mit dem Endergebnis (alle anderen sind fuer den Login ja nicht relevant) der Hashrunden nur genau dann auf, wenn eine Kolission genau in der selben, n. Runde der beiden unterschiedlichen Eingabewerte auftritt. Das Risiko halte ich fuer ziemlich gering

Da der Aufwand mit n Iterationen linear steigt, kann man mit ein paar tausend Runden eine Brute Force-Attacke durchaus in die Laenge ziehen, ohne dass man selbst davon gebissen wird.

Brute Force gegen einen ausreichend großen Hash aus der SHA2-Familie (zB SHA-512) halte ich für sowieso obsolet.

Aber genau gegen dieses obsolete Bruteforcen gibt es nun mehr Runden, die das Bruteforcen vereinfachen? Es passen dann ja mehr Kennworte.... Und den Avalanche-Effekt ignorierst auch

.

Wie auch immer: Ich halte es nicht für gefährlich - sondern nur für sinnlosen Energie- und Zeitverbrauch, aber man müsste es sich echt mal näher ansehen

Schau, angenommen, der (bereits gesalzene) Eingangswert in die Funktion zum Hashen wird (innerhalb dieser Funktion) fuenf mal mit SHA-1 gehasht (welcher Hash konkret verwendet wird undwie oft ist fuer dieses Beispiel egal, es geht hier ja nur um's Prinzip). Dann kannst du in einer Art Schreibtischtest die folgenden internen Zustaende beobachten:

start: x = "trustno1"
Durchlauf 0: x = 71317a745116bf614c38aad75f43f1d8bf2b2350
Durchlauf 1: x = bf86d3a979181f06e5866b2fb68912ef065bade4
Durchlauf 2: x = ea6687d19ce34f8778840dc8246d33571467b132
Durchlauf 3: x = 3646f18d4f70abb1c026733b57d00183b2eef493
Durchlauf 4: x = ba673812f8bddd06b35a04d9bb1091e8a6ea173f
return: ba673812f8bddd06b35a04d9bb1091e8a6ea173f

Fuer eine Kollision brauchst du also einen Eingabewert, der, wenn er fuenf Mal SHA1-gehasht wird, ba673812f8bddd06b35a04d9bb1091e8a6ea173f ergibt. Es bringt dir rein gar nichts, wenn du eine Kollision fuer irgendeinen der zwischenzeitlich berechneten Hashes gefunden hast - wenn du einen solchen in die validierende Funktion einfuetterst (z. B. fuer eine Kollision mit x aus Durchlauf 3) kriegst du am Ende erst wieder einen anderen Wert heraus als du brauchst, weil dein Eingabewert die ganzen fuenf statt nur ein Mal gehasht wurde.

Das mehrfache Hashen schuetzt dich einfach davor, dass - sollte es eine entsprechende Entdeckung zum Errechnen von Kollisionen geben, die statt ~2^160 nur noch (Hausnummer) ~2^50 Versuche braucht, und das im Bereich des Machbaren liegt - man immer noch eine gewisse linear steigende Komplexitaet als Puffer "vorgeschaltet" hat.

Wenn du auf einem Supercomputer zwei Wochen brauchst, um eine Kollision fuer einen beliebigen SHA-1-Hash zu berechnen, Dein Angriffsziel hasht aber statt ein Mal tausend Mal (und du kennst die Anzahl der Runden auch - das muss nicht unbedingt der Fall sein, wenn die gehashten Passwoerter leaken, und dann steigt der Aufwand fuer den Angreifer nochmal), brauchst du ploetzlich zweitausend Wochen zur Bewaeltigung dieser Aufgabe. Man erkauft sich damit also ein bisschen Luft im Falle eines erfolgreichen Angriffs auf den Hash.

Fuer eine Kollision brauchst du also einen Eingabewert, der, wenn er fuenf Mal SHA1-gehasht wird, ba673812f8bddd06b35a04d9bb1091e8a6ea173f ergibt.

Genau!

Es bringt dir rein gar nichts, wenn du eine Kollision fuer irgendeinen der zwischenzeitlich berechneten Hashes gefunden hast

Genau - der interessiert mach aber nicht.

Angenommen, ich hätte eine SHA-Funktion als Hash.
Im Idealfall erzeugt ein Kennwort einen eindeutigen Hash.
Real werden es durchschnittlich 1komma000Irgendwas Kennworte GH-Üblicher Länge (also unter 32 Zeichen) sein.

Wenn wir jetzt 2x Hashen, gibt es _mehr_ "richtige" Kennworte, bei 3x Hashen noch mehr, ... Brute-Forcen wird dadurch [etwas] simpler. Was wurde dadurch aber gewonnen? IMHO nix.

fuer das, das ihr ohnehin meint das es nur theoretisch möglich ist das euch die hashes gfladdert werden, tut ihr euch aber dann doch viel an

Wir befürchten eh dass das wesentlich größere Problem - dass die User ihre credentials mehrfach verwenden - bei diesen Diskussionen über die Speicherung von Passwörtern (und im übrigen auch über die Passwortstärke - die bei vernünftiger Speicherung / aufwändigem Hashing nicht mehr so wichtig ist) untergeht.

ALTER TABLE

Fahr raus zum Ikea und hol einen Neuen

--------------------------------------------------------------------------------
Gott fragte die Steine: Wollt ihr RC-Helis fliegen?
Und die Steine antworteten: NEIN!!! Dafür sind wir nicht hart genug......

alter table users

Es gab einen Geizhals-Stammtisch der Ü40.

drop column pass

Viele kamen mit Ihrem Pass (wahrscheinlich um das Alter zu bestätigen)

Das Hashen hat übrigens ca. 30 CPU-Stunden gedauert

30 Stunden saß man gemeinsam am Pot.

langsame Hashfunktionen mit vielen Iterationen sind sicherer, wenn sie keine
Designfehler aufweisen).

Langsam wurden dann die Leute irritiert und sahen komische Farben.

Die trotz großer Sorgfalt und Nüchternheit auftretenden Fehler bitte gleich
melden

Bei der Heimreise sind manche, trotz großer Sorgfalt und im fast nüchternen Zustand, in den falschen Zug gestiegen. Sollte noch jemand nicht zu Hause sein, soll er sich melden!

Ja, so ein Stammtisch kann schon anstrengend sein.

Zitat von \\ H //: wenn i Probleme will kauf ich online und zahl per Vorkasse
Quelle: http://forum.geizhals.at/t591666,5002602.html#5002602

Lange nicht mehr so gelacht.
Danke!

ueber den kann ich auch noch immer lachen :D
.___.
{o,o}
/)__)
-"-"-

*rofl*

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung