• Hallo liebe Userinnen und User,

    nach bereits längeren Planungen und Vorbereitungen sind wir nun von vBulletin auf Xenforo umgestiegen. Die Umstellung musste leider aufgrund der Serverprobleme der letzten Tage notgedrungen vorverlegt werden. Das neue Forum ist soweit voll funktionsfähig, allerdings sind noch nicht alle der gewohnten Funktionen vorhanden. Nach Möglichkeit werden wir sie in den nächsten Wochen nachrüsten. Dafür sollte es nun einige der Probleme lösen, die wir in den letzten Tagen, Wochen und Monaten hatten. Auch der Server ist nun potenter als bei unserem alten Hoster, wodurch wir nun langfristig den Tank mit Bytes vollgetankt haben.

    Anfangs mag die neue Boardsoftware etwas ungewohnt sein, aber man findet sich recht schnell ein. Wir wissen, dass ihr alle Gewohnheitstiere seid, aber gebt dem neuen Board eine Chance.
    Sollte etwas der neuen oder auch gewohnten Funktionen unklar sein, könnt ihr den "Wo issn da der Button zu"-Thread im Feedback nutzen. Bugs meldet ihr bitte im Bugtracker, es wird sicher welche geben die uns noch nicht aufgefallen sind. Ich werde das dann versuchen, halbwegs im Startbeitrag übersichtlich zu halten, was an Arbeit noch aussteht.

    Neu ist, dass die Boardsoftware deutlich besser für Mobiltelefone und diverse Endgeräte geeignet ist und nun auch im mobilen Style alle Funktionen verfügbar sind. Am Desktop findet ihr oben rechts sowohl den Umschalter zwischen hellem und dunklem Style. Am Handy ist der Hell-/Dunkelschalter am Ende der Seite. Damit sollte zukünftig jeder sein Board so konfigurieren können, wie es ihm am liebsten ist.


    Die restlichen Funktionen sollten eigentlich soweit wie gewohnt funktionieren. Einfach mal ein wenig damit spielen oder bei Unklarheiten im Thread nachfragen. Viel Spaß im ngb 2.0.

Bestandsdatenauskunft mit Passwortherausgabe verabschiedet

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
@KaPiTN: Nein, was ich dir damit sagen will, dass es völlig normal ist, und auch kein Sicherheitsrisiko, wenn der Salt der Username ist. SELBST WENN ES EINE ZUFALLSZAHL WÄRE, ist er trotzdem im Klartext gespeichert (was one übrigens falsch dargestellt hat - ein nicht gespeicherter Salt funktioniert ausschließlich als Account-Sperrmechanismus).

Wir stehen beide auf der selben Seite: Das Gesetz ist Unsinn, weil nicht funktionsfähig. Die technischen Details sind da nebensächlich.
 

rexcolo

Opfer

Registriert
16 Sep. 2017
Beiträge
158
@KaPiTN: Nur, wenn die Admins die gleichen Passwörter verwenden würden, was mehr die Qualität des Admins infrage stellt als die der Anwendung.

Wie gesagt, natürlich kannst du Rainbow Tables mit dem Salt "Admin" erstellen - wenn der Salt aber dann "Administrator" ist, sind sie wieder nutzlos (oder wenn die Passwörter halbwegs gut sind, weil da reden wir sehr schnell von mehreren hundert Terabyte pro RT).

Es gibt nicht nur Salt, sondern auch Pepper! :)
http://blog.kablamo.org/2013/12/18/authen-passphrase/

Allerdings bringt's gar nichts, den Usernamen zu nehmen, wenn man auch einfach eine zusätzliche Spalte in der DB mit nem random Salt anlegen kann.

@KaPiTN: Nein, was ich dir damit sagen will, dass es völlig normal ist, und auch kein Sicherheitsrisiko, wenn der Salt der Username ist.

Dämlich ist es trotzdem, weil ein random salt mehr Sicherheit beim selben Aufwand bietet.

Wie naiv zu denken, wenn irgendwo jemand als Username 'admin' benutzt, er auch auch ein Administrator von irgend einem Netzwerk zu sein hätte.

Und wie naiv zu denken, dass Leute mit dem Benutzernamen admin automatisch kompetent sein müssen. Ich kenne genügend Leute mit viel zu viel Zugriff und viel zu wenig Kompetenz.
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
@rexcolo: Wenn ich von Salt rede, kannst du mir zwar mit Pepper reingrätschen (kenn ich natürlich, bin ja nicht erst seit gestern in der IT), das hat aber an der Stelle genauso wenig Nutzen, denn der muss ja mit rausgegeben werden. Und während reines Salting mit Usernamen als Salt auch bei gleichen Passwörtern immer unterschiedliche Hashes produziert, würde reines Peppering (ohne Salt) in diesem Fall zu lauter gleichen Hashes führen. An der Stelle erklärt der Blog das Prinzip des Peppers nämlich FALSCH. Natürlich kann man das so machen, ist aber nicht mehr wirklich Peppering.

Und ja, natürlich ist ein random salt eine minimale Verbesserung des Problems, ändert aber immer noch nix am Problem, egal ob von Red- oder Blue-Seite betrachtet.
 

rexcolo

Opfer

Registriert
16 Sep. 2017
Beiträge
158
@rexcolo: Wenn ich von Salt rede, kannst du mir zwar mit Pepper reingrätschen (kenn ich natürlich, bin ja nicht erst seit gestern in der IT), das hat aber an der Stelle genauso wenig Nutzen, denn der muss ja mit rausgegeben werden.
Je nach Art des Peppers: nein, muss nicht zwangsweise rausgegeben werden.

Und während reines Salting mit Usernamen als Salt auch bei gleichen Passwörtern immer unterschiedliche Hashes produziert, würde reines Peppering (ohne Salt) in diesem Fall zu lauter gleichen Hashes führen
Deswegen ist es ja ein zweiter Salt, den man Pepper nennt.

An der Stelle erklärt der Blog das Prinzip des Peppers nämlich FALSCH. Natürlich kann man das so machen, ist aber nicht mehr wirklich Peppering.
Achso, OK. Du scheinst das ja dann richtig missverstanden zu haben.

Und ja, natürlich ist ein random salt eine minimale Verbesserung des Problems, ändert aber immer noch nix am Problem, egal ob von Red- oder Blue-Seite betrachtet.
Es ist eine minimale Verbesserung des Problems, ändert aber nichts am Problem? Du widersprichst dir selbst innerhalb eines einzigen Satzes.

Regierung doof, Hashes, DSGVO, haha /thread

Ich kenne genügend Leute mit viel zu viel Zugriff und viel zu wenig Kompetenz.
q.e.d.
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
@rexcolo: Nein, hab ich nicht.

Klassischerweise ist der Pepper ein String, der im Quellcode oder einer Config-Datei hinterlegt wird, und damit nur zur Laufzeit im Arbeitsspeicher der Anwendung vorhanden ist. Wird die Datenbank gedumpt, sorgt der Pepper dafür, dass trotz der bekannten Salts und der bekannten Hashes die Kennwörter nur sehr viel schwerer gebrochen werden können.

Natürlich KANN man einen Pepper über eine zweite Datenbank abbilden, damit ist er aber de facto nur ein zweiter Salt, und der Zugriff auf die Datenbank zur Laufzeit ist das nächste Problem, denn wenn ich als Angreifer eine Datenbank dumpen kann, kann ich üblicherweise auch die zweite dumpen, damit hast du also nicht wirklich viel gewonnen. Deshalb ja Config-Datei, die dumpt man nämlich nicht, sondern liest sie beim Start ein bzw. bekommt bei solchen Dingen die Werte via Umgebungsvariable rein, weil die Anwendung selbst nichtmal Zugriff auf die Konfigdatei hat, damit tut sich ein Angreifer sehr schwer.

So, und jetzt noch der Punkt mit Peppering mit randomisierten Daten. Kann man machen. Skaliert nur scheiße. Grund: Statt einen Hash zu rechnen, muss ich (bei den genannten 8bit-Peppers) 256 Hashes rechnen und jeden einzelnen vergleichen. Das ist DUMM. So richtig haarsträubend dumm, weil mit jedem weiteren Nutzer dein Aufwand exponentiell ansteigt. Serverseitig, wohlgemerkt. Was das zusätzlich Traffic auf eine Datenbank bedeutet, ist nicht ohne. Woher ich das weiß? Sagen wir, ich hab in meiner aktuellen Arbeit eine etwas größere Replikationsstruktur rumstehen, wir reden hier vom oberen dreistelligen Bereich, und wenn der ein oder andere Kollege eine etwas interessantere Datenbankabfrage startet, kreischt das Monitoring, dass die Slaves hinterher hinken. DUMME Idee.

Ziel eines Hashes ist üblicherweise, die Berechnung für legitime Parteien so schnell und einfach wie möglich zu machen, und einen Angriff darauf trotzdem so komplex wie irgend möglich zu gestalten. Daher ist es bedeutend sinnvoller, einfach nur nen besseren Algorithmus zu nehmen. bcrypt zum Beispiel wird extrem schnell sehr rechenintensiv, weil zum eigentlichen Hashing ein Kostenfaktor kommt, der die Anzahl der Iterationen festlegt. Warum ist das besser als 256 einfache Rechnungen? Weil die WAITs geringer ausfallen - ich schubse die Funktion und die Parameter einmal in die CPU, und dann rechnet die, ich bekomme ein Ergebnis, das ich mit einer Datenbankabfrage abfrühstücke. Bei der Methode mit randomisierten Peppers sind das 256 Pushes mit den entsprechenden Random-Peppers (das sind damit auch 256 waits, mit der du den Serveradmins viel Freude machst), plus 256 Abfragen an die Datenbank, die auch immer ganz toll sind. Oder, alternativ, was konzeptionell z. B. bei LDAP gar nicht mehr funktioniert, erst den Hash aus der DB lutschen, und dann mit for i in 256; do if RESULT = HASH; then LOGIN=OK; break; done in der Anwendung drüberiterieren. Scheißidee. Ach, und natürlich kannst du die Berechnung abbrechen, wenn einmal OK zurück kommt - das ist aber noch rechenintensiver, weil mit noch mehr Wartezeit verbunden, weil das dann definitiv sequentiell abgearbeitet werden muss und nichtmal Parallelisierung zulässt.
Der einzige Punkt, bei dem die Random-Pepper-Methode theoretisch besser ist als die mit statischem Pepper ist folgendes Szenario:
Ist die Verschmelzungsmethode von Pepper, Salt und Passwort bekannt, die Methode selbst eine Verschachtelung aus Hashingfunktionen, und es liegen Hash, Salt UND das Passwort im Klartext vor, lässt sich mit vergleichsweise geringem Aufwand eine BruteForce-Attacke schreiben, welche den Pepper zum Ziel hat. Ein Beispiel wäre z. B. "md5(PEPPER+md5(SALT+md5(PASS)))". Ist der Pepper erraten, kann die BruteForce-Attacke zweistufig gefahren werden, nämlich indem eine Rainbow-Table für die unbekannte Komponente erstellt wird (d. h. mit dem Ziel X=md5(PASS)), während nur noch Hashes für die unbekannten Komponenten erbrütet werden, was durch den Wegfall der äußeren Hashfunktionen einfacher ist. Caveat: Funktioniert nur mit annehmbarem Aufwand, wenn der Pepper schwach ist. Ergo: NIE.

Ja, ich kenne Peppering. Ziemlich gut sogar, und nicht erst seit gestern. Und da ich auch schon die ein oder anderen Algorithmen/Hashes mit der Brechstange bearbeitet habe, kann ich da denke ich auch etwas mitreden.
 

Steeve

Vereinsheimer
Barkeeper

Registriert
15 Juli 2013
Beiträge
41.121
Sry mein Spam, aber ich verstehe nur Bahnhof. Ich muss auch noch Zusatzqualifikationen machen. FISI alleine ist gar nichts. Oder einfach Verständnis gewinnen für IT? Aber ich finde gut, dass hier im ngb endlich Mal offenbart wird, worauf es ankommt. Sry, aber diese ganze Verschlüsselung und Sicherheit und DSGVO und was auch immer, habe ich null Plan von oder besser gesagt kein Interesse. Ich lese nur deinen Text Metal und sehe Hyroglyphen. Egal weitermachen... Finde ja gut wenn wir uns Mal über IT unterhalten. Sonst halten sich hier ja viele zurück an Board.
 

BurnerR

Bot #0384479

Registriert
20 Juli 2013
Beiträge
5.504
Naja, das war hier jetzt viel "wer hat den längeren" gelabere.
Hashes müssen rausgegeben werden -> bedingt ok. Wieso 'bedingt': Du hast keine Kontrolle darüber ob der Anbieter auch wirklich sichere Verfahren für die Hashes verwendet.

Du selber kannst einen Passwort-Safe nutzen, starke Passwörter und für jeden Service ein anderes, dann ist dir das Thema 'Hashes rausgeben müssen' weitesgehend egal. Ist so auch üblich in der IT. Jenseits der IT, nicht wirklich.

Worum es in dem Artikel geht so lese ich es zumindest: Das Gesetz, wann diese Hashes (und anderes natürlich) rausgegeben werden müssen wurde *eingeschränkt*.
Kann vielleicht noch eine zweite Person den Artikel lesen und dann sprechen wir darüber anstatt über 20 jahre alte Hash-Themen?
 

rexcolo

Opfer

Registriert
16 Sep. 2017
Beiträge
158
Skaliert nur scheiße. Grund: Statt einen Hash zu rechnen, muss ich (bei den genannten 8bit-Peppers) 256 Hashes rechnen und jeden einzelnen vergleichen. Das ist DUMM. So richtig haarsträubend dumm, weil mit jedem weiteren Nutzer dein Aufwand exponentiell ansteigt. Serverseitig, wohlgemerkt.

Das lässt sich anderweitig lösen. Der Punkt ist aber: Der Pepper muss nicht herausgegeben werden. Und genau darum ging es doch?
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
@rexcolo: Das kommt auf die Auslegung des Gesetzestextes an. Und die legt meistens dann die Gerichtsbarkeit fest, die vermutlich nach Intention des Gesetzgebers argumentieren wird, dass alles herausgegeben werden muss, was zur Authentifizierung notwendig ist, also Algorithmen, Verbau, Salts und Peppers. Egal wie, das Gesetz gehört weg. Oder aber explizit bei allem angewendet, was zur Sicherung der Gesetzgeberdaten genutzt wird, damit sie schön erstmal selbst in die Scheiße langen, und zwar so richtig.
 

Steeve

Vereinsheimer
Barkeeper

Registriert
15 Juli 2013
Beiträge
41.121
Pepper, Salts höre ich das erste Mal, aber kein Problem, bin ja noch Geselle, finde aber spannend hier eure Beiträge zu lesen.
 

Steeve

Vereinsheimer
Barkeeper

Registriert
15 Juli 2013
Beiträge
41.121
Ah ok, ist tatsächlich Lerninhalt der IHK Fisi, aber das sagt mir nur ich bin nicht ausgebildet?
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
@Pleitgengeier: Ja und nein.

Schwer zu merken - ja. Definitiv. Leicht zu knacken? Das unterschreib ich dir nicht.

Wenn du auf Correct Battery Horse Stable anspielst: Das ist ein mieses Kennwort. Grund: Die Methode ist bekannt, und es ist wesentlich leichter, alle bekannten Wörter 3-6x hintereinander zu hängen, als ein 32-Zeichen-Kauderwelsch aus allen printbaren Zeichen zu erbrüten. Um genau zu sein lasse ich grundsätzlich, wenn ich sowas brechen will, die Wörterbücher erstmal ran, noch bevor ich die weakpass_2a auspacke. Ca. 10-20% der Kennwörter sind direkt aus dem Wörterbuch oder haben nur kleine Abweichungen (wie ne Zahl hintendran).

Um die Rechnung mal kurz aufzumachen:
Der englische Wortschatz umfasst ca. 1 Mio Wörter, davon sind 20-40k im allgemeinen Sprachgebrauch. Bei vier Worten macht das also grade mal bis zu 10^24 Kombinationen, beim allgemeinen Sprachgebrauch sogar nur ca. 10^17. Mit 32 Zeichen Kauderwelsch komme ich auf 10^64. Bereits mit 12 Zeichen erreiche ich ein Schutzniveau, das identisch ist mit dem maximalen Bereich der englischen Sprache.
 
Zuletzt bearbeitet:

one

Querulant

Registriert
21 Juli 2013
Beiträge
5.839
Ort
ja
Also genau so, wie man es NICHT macht :T
Schwer zu merken, leicht zu knacken

Leicht zu knacken eben nicht, denn du hast gar keinen Ansatzpunkt. Scheinbar alle Zeichen, Länge unbekannt bzw. >=8. Das passt schon so.

Schwer zu merken ist so ne Sache. Manche Leute können sich die komischsten Sachen merken. Dem Prinzip widerspricht es aber, da haste recht. Wobei eben nicht jedes Prinzip auch für jeden wichtig sein muss. Wenn ich mir Pi auf 100 Nachkommastellen merken kann, dann machen mir wild zusammengewürfelte Passwörter wahrscheinlich auch recht wenig Probleme.
 

BurnerR

Bot #0384479

Registriert
20 Juli 2013
Beiträge
5.504
Kauderwelsch ist schwerer zu merken, generell. Alles andere ist Schneeflocken-Gerede.

Zu den 8 Zeichen: Grad nochmal kurz nachgeschlagen / recherchiert: https://blog.codinghorror.com/speed-hashing/
SHA-1 ohne zusätzliche 'rounds' wurde bis vor kurzem noch beim Firefox-Safe verwendet. Der Artikel ist von 2012 da wird MD5 8 Zeichen mit etwas über 1 Jahr angegeben und SHA1 ca. 3 mal langsamer, also so 3-5 Jahre für *ALLE* Kombination, also mehr so 1,5-2,5 Jahre im Mitte. Vor 8 Jahren, wohlgemerkt, heute dürfte das eher im Bereich von Monaten oder Wochen liegen.
Fazit: 8 Zeichen im Allgemeinen sind zu wenig, auch wenn Symbole verwendet werden. Natürlich kann man heute oft die 'difficulty' einstellen des Hashverfahren, aber im häufigsten Fall hat man eher keinen Einfluss oder gar keine Kenntniss davon, welcher Algo da jetzt wie genau eingesetzt wird.
 

Steeve

Vereinsheimer
Barkeeper

Registriert
15 Juli 2013
Beiträge
41.121
Keine Ahnung ich denke auch dass da ein Passwortknacker keine Chance hat.

Hier

+Geraldriva66

schaffst du nicht.
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
@Steev: Vorsicht, gerade solche Passwörter sind eine Falle.

Gewisse Tools in der Richtung arbeiten grundsätzlich gerne so, dass sie bekanntere Wörter bzw. oft zusammen vorkommene Kombinationen mit "Anhängseln" zusätzlich betrachten.

Dein Passwort würde also bei einer Namensliste mit ".{0,2}$NAME.{0,4}" direkt mit angegriffen werden.

Und Geralt von Riva ist ja durchaus ein nicht unbekannter Name, nech?
 
Oben