Passwörter versenden, ohne die Sicherheit zu kompromittieren

[sia]

Wie viele Zeichen würdet ihr denn als Minimum empfehlen?

Maximum gibt es ja nicht, in unserer Passwortrichtlinie wird empfohlen (!), einen Satz zu nutzen mit eingestreuter Zahl.

Also beispielsweise WasFür1PferdStapeltBatterien?

Das hier darf natürlich auch in keinem Artikel über Passwörter fehlen:

 

[dexter]

Keine Ahnung, wie alt die Tabelle is:

You do not have permission to view link please Anmelden or Registrieren

nehme ich mal den Einwand bei den 12 Zeichen zurück. Wenn ich das richtig interpretiere wäre 12 Buchstaben Klein- und Grossschreibung aktuell sicher.

 

[sia]

You do not have permission to view link please Anmelden or Registrieren

abgesehen davon, dass die meisten Dienste gar kein Brute Force zulassen. Maßnahmen dagegen sind ja schon sehr, sehr einfach umzusetzen. Jeder Dienst, der das nicht tut, handelt meiner Meinung nach grob fahrlässig.

Für die Windows-Anmeldung oder das Mailpasswort ist das denke ich recht sicher. Sobald damit natürlich wichtige Daten verschlüsselt werden, sollte man längere Passwörter nutzen – dafür gibt es ja dann einen Passwortmanager.

Der sollte natürlich auch ein sicheres Masterpasswort haben, aber bei KeePassX kann man bspw. die Anzahl der "Runden", die das Passwort gehasht wird, einstellen. Damit schaffen selbst Supercomputer nur wenige hundert Variationen pro Sekunde. Auch ein Keyfile ist sinnvoll, damit man die Datenbank sicher synchronisieren kann (bspw. auf Netzlaufwerken oder in der Klaut).

 

[alter_Bekannter]

Für die Realität würde ich sagen 8 Zeichen.

Laut meiner Erfahrung machen die meisten bots weniger als 100 Versuche.

Die einfachste Vriante wäre jede IP nach jedem Versuch einfach 5 Sekunden warten zu lassen. Dann gehen nur noch 12 Versuche pro IP und minute. Selbst mit einem enormen Botnetz wäre dann kaum was zu machen.

 

[dexter]

Der sollte natürlich auch ein sicheres Masterpasswort haben, aber bei KeePassX kann man bspw. die Anzahl der "Runden", die das Passwort gehasht wird, einstellen. Damit schaffen selbst Supercomputer nur wenige hundert Variationen pro Sekunde.

Versteh ich nich. Zumindest nicht in Gänze. Wenn das tatsächlich so ist, dann mache ich eben 1000+x Kopien vom File, die ich einzeln zu brechen versuche.

Für die Realität würde ich sagen 8 Zeichen.

Mag sein, würde ich aber nicht empfehlen, denn das heisst, dass man ständig überlegen muss, ob das jetzt "Realität" ist oder komplexer, wie bspw. ein keepassfile. Wenn Du einem Dau erklärst, dass 8 Zeichen für Facebook reichen, dann nimmt der überall 8...

 

[alter_Bekannter]

Leider gibts überall dumme Einschränkungen.

Sonst würde ich sagen benutz: einen unsinnigen Satz.

Scheitert leider an all den Schwachmaten die die Passwortlänge auf 16 Zeichen beschränken oder Sonderzeichen etc fordern. Die komplexen System richten in dem Bereich wie so oft mehr Schaden an als sie nutzen. Da liegt halt das Problem wenn man Deppen ran lässt die glauben das kompliziert automatisch gut ist.

 

[BurnerR]

Ich mach das immer so, weil mir richtige Wörter auch nicht gefallen - wenn ich nicht sowieso KeePassX benutze:
Im ngb finde ich stets gute Antworten auf meine Fragen
-> IngbfisgAamF
12 Zeichen.

Disclaimer: Natürlich verwende ich dieses Passwort nicht

 

[bevoller]

Viel schlimmer: Seit ich KeePass nutze, kann ich mir Passwörter nur noch schlecht merken.

You do not have permission to view link please Anmelden or Registrieren

Diese Einmal-Passwortgeschichten mit Ablaufdatum sind super, danke. Ich denke, so ein Dienst auf meinem Server in Kombination mit einem lokalen Passwortmanager ist die beste Idee. Die Links dazu kann ich dann entweder per Mail oder per internem Chat verschicken – sehr gut. Warum ich darauf nicht selbst gekommen bin!

Das ist generell zu empfehlen, schon allein aus Haftungsgründen. Wenn du Zugangdaten vergibst, kennen mindestens zwei Leute diese. Du und der Empfänger. Baut irgendjemand unter diesem Account (des Empfängers) Mist, gibt es zwei Leute, die tatverdächtig sind. Gilt ein Passwort nur bis nach der ersten Anmeldung und muss zwingend vom Benutzer geändert werden, bist du aus dem Schneider.

 

[sia]

Ich mach das immer so, weil mir richtige Wörter auch nicht gefallen - wenn ich nicht sowieso KeePassX benutze:
Im ngb finde ich stets gute Antworten auf meine Fragen
-> IngbfisgAamF
12 Zeichen.

Warum nicht ngbBeantwortetSogarDummeTrolls?
Leichter zu merken, schnell getippt und schwer zu knacken.

Versteh ich nich. Zumindest nicht in Gänze. Wenn das tatsächlich so ist, dann mache ich eben 1000+x Kopien vom File, die ich einzeln zu brechen versuche.

Nein, so einfach ist das nicht.

Es gibt Passwortderivatfunktionen, beispielsweise

You do not have permission to view link please Anmelden or Registrieren

, die ein Passwort X mal verändern und damit dann die Datenbank verschlüsseln.

Bei KeePassX ist das ein "einfaches" SHA256. Aus dem Passwort "hunter2" wird mit SHA256 folgendes:
[src=bf]46a9d5bde718bf366178313019f04a753bad00685d38e3ec81c8628f35dfcb1b[/src]

Wenn man das dann noch mal durch SHA256 jagt – für Fans von Pseudocode: [kw]sha256(sha256("hunter2"))[/kw] –, kommt das hier dabei raus:
[src=bf]c582378787d85f3282850d50859077206abbd0ac87cbc569ee9d31a5d42800ca[/src]

Und wenn man das 1000 mal macht, erhöht man den Rechenaufwand um das Tausendfache (logischerweise) – das ist auch nicht parallelisierbar, da man ja immer das Ergebnis des vorherigen Laufs benötigt. Auch Rainbow Tables bringen hier ungefähr gar nichts, weil diese ebenfalls die tausendfache Zeit zum Berechnen benötigen würden und weil die Anzahl der "Rounds" (also der Durchläufe durch SHA256) bei jeder Datenbank anders ist (bzw. sein sollte, am Besten nimmt man irgendeine krumme Zahl).

Die Zahl der Durchläufe steht dann soweit ich weiß unverschlüsselt in der Datenbank, ähnlich wie bei einem Salt. Nur dass man eben zusätzlich zur Anzahl der Runden bei KeePassX einen Salt (das Keyfile!) benutzen kann. Und spätestens dann steigt der Rechenaufwand ins Unermessliche.

Hoffe, das ist so einigermaßen verständlich, falls nicht, beantworte ich auch gerne Detailfragen. Ich finde sowas immer sehr schwer zu erklären

 

[alter_Bekannter]

Der Vorgang ist trotzdem Unfug/Schlangenöl weil er den Aufwand symmetrisch erhöht.

 

[dexter]

Und wenn man das 1000 mal macht, erhöht man den Rechenaufwand um das Tausendfache (logischerweise) – das ist auch nicht parallelisierbar, da man ja immer das Ergebnis des vorherigen Laufs benötigt.

Ääh, ich such natürlich nicht in allen Kopien nach der selben Zeichenfolge. Kopie 1: Axxxx, Kopie 2: Bxxxxx usw.

Die Zahl der Durchläufe steht dann soweit ich weiß unverschlüsselt in der Datenbank,

Die zahl der Verhaschung/Versaltung? Die interessiert mich nicht, "ich" kippe ein echtes Passwort in die Eingabemaske.

P.s. Damit wir nich aneinander vorbeireden: ich rede von einem Szenario ohne Extra-Keyfile, also reine einzige keepass-db mit Pass.

 

[sia]

Der Vorgang ist trotzdem Unfug/Schlangenöl weil er den Aufwand symmetrisch erhöht.

Erkläre bitte ausführlicher, was du damit meinst. PBKDF2 ist also Unfug? Oder meinst du das mehrfache Hashen?

Kaskadierte Hashfunktionen begrenzen die verfügbare Rechenleistung, wirken also einer Brute-Force-Attacke entgegen. Was ist an dieser Aussage falsch?

Ääh, ich such natürlich nicht in allen Kopien nach der selben Zeichenfolge. Kopie 1: Axxxx, Kopie 2: Bxxxxx usw.

Zeichenfolge = Passwort? Auch wenn du in tausend Kopien parallel suchst, benötigst du noch die tausendfache Rechenleistung zur Berechnung EINES Hashes.

Die zahl der Verhaschung/Versaltung? Die interessiert mich nicht, "ich" kippe ein echtes Passwort in die Eingabemaske.

Ja, und die Eingabemaske berechnet den Hash eben tausendmal verschachtelt. Das kann man auch nicht einfach umgehen, da die Rechenleistung begrenzt ist.

Selbstverständlich gilt das nicht bei unbegrenzter Rechenleistung. Aber wer hat die schon? Gott?

EDIT: Und inwiefern ist ein Audit der Hashfunktion von KeePassX das Thema dieses Threads?

Passwörter versenden, ohne die Sicherheit zu kompromittieren

 

[dexter]

EDIT: Und inwiefern ist ein Audit der Hashfunktion von KeePassX das Thema dieses Threads?

Es ging um Details nicht um Audits, schon vergessen?

Hoffe, das ist so einigermaßen verständlich, falls nicht, beantworte ich auch gerne Detailfragen.

Im Übrigen bin ich der Meinung, dass Details zur Verschlüsselung (etc.) von Keepass zwar ein Subthema ist, aber hier bestens reinpasst.

Auch wenn du in tausend Kopien parallel suchst, benötigst du noch die tausendfache Rechenleistung zur Berechnung EINES Hashes.

Das ist mir soweit klar, wenn ich tausend Rechner oder Kerne oder Threads oder CPUs hinstelle, dass ich da auch mehr Leistung brauche. Ich vermute aber, dass man durch eine solche "Verteilung" mehr Zeit und Kraft durch Synergieeffkte gewinnt, als wenn man einen Supercomputer Jahrelang an einem File rumknabbern lässt.

Schön, dass Du das mit dem Audit erwähnst, da sind grad Leute dran mit Plan, müssen wir also hier nicht ausdiskutieren.

 

[virtus]

Für die Realität würde ich sagen 8 Zeichen.

Da muss man Offline und Online-Systeme unterscheiden. Bei einem Online-System sind Bruteforce-Angriffe normalerweise kaum möglich. Da bringt der Superrechner des Angreifers kaum etwas, wenn er die Anfragen erst mal über's Internet an den Host schickt, dieser eine Antwort generiert und anschließend doch heraus kommt, dass das Passwort falsch ist. Die Kommunikation bremst massiv aus. Zumal die meisten Online-Systeme sowieso Beschränkungen aktiviert haben - mal abgesehen von der iCloud bei TheFappening. Gerade bei Facebook muss man sagen, dass diese sehr gut gegen Online-Angriffe aufgestellt sind. Bei Logins von ungewöhnlichen Standorten aus, reagiert Facebook sogar mit zusätzlichen Maßnahmen, was die Rechenpower von Bot-Netzen quasi aushebelt.
Bei Offline-Systemen sieht das schon wieder anders aus, da kann man nahezu das Potential des angreifenden Systems voll ausnutzen und hier lassen sich Angriffe auch vernünftig parallelisieren.


Hashfunktionen sind im Allgemeinen nicht das Mittel der Wahl um Passwörter zu verschlüsseln.

Spoiler

Zunächst einmal ist mit Verschlüsselung ein bidirektionales Verfahren gemeint. Einen Klartext kann man mit einem Schlüssel in einen Code umwandeln und mit dem richtigen, nicht notwendigerweise gleichen Schlüssel kann man diesen Code wiederum in den ursprünglichen Klartext überführen. Der Code ohne Schlüssel sollte dabei keine Rückschlüsse - abgesehen von der Länge - auf den Klartext zulassen.
Beim Hashing muss die Bidirektionalität nicht gegeben sein. Es wird nicht vorgeschrieben, ob der sog. Hash Rückschlüsse auf den ursprünglichen Wert zulassen darf oder nicht.
Man unterteilt Hashfunktionen in der Regel danach, ob es schwer ist eine Kollision zu finden oder ob es ein one-way-Verfahren ist.

Kollision: hash(a) = hash(b) für a ≠ b
One-Way: Es existiert kein unhash() so dass unhash(hash(a)) = a

Eine sehr einfache Hashfunktion:

[src=text]
cut_hash(String value) {
// falls Eingabelänge > 17
if(string_len(value) > 17) {
// gib Zeichen von Pos 0 bis 16 zurück
return value[0..16];
}
// sonst
else {
// gib alle Zeichen zurück
return value;
}
}

# Beispiele
cut_hash("Hallo"); // Rückgabe: "Hallo"
cut_hash("Hallo, ich heiße Peter."); // Rückgabe: "Hallo, ich heiße "
cut_hash("Hallo, ich heiße Petra."); // Rückgabe: "Hallo, ich heiße "
cut_hash("Hallo, ich heiße Hanswurst."); // Rückgabe: "Hallo, ich heiße "
[/src]

Für Eingaben mit einer Länge von maximal 17 Zeichen ist die Hash-Funktion kollisionsresistent, denn es existieren keine zwei Zeichenketten der Länge <= 17, so dass die Zeichenketten unterschiedlich, aber die Hashes gleich sind. Das sollte durch die Definition der Funktion offensichtlich sein.
Für Eingaben der Länge > 17 handelt es sich um eine one-way-Funktion. Das sieht man am besten an den Beispielen 2 bis 4.

Hashing ist in der Regel in Richtung Geschwindigkeit optimiert. Das Generieren eines Hashes sollte folglich also schnell ablaufen. Im Zusammenhang mit kryptografischer Sicherheit verfolgt man genau das gegenteilige Ziel, nämlich möglichst zeitaufwändige Verfahren.
Statt sha256(wert)[SUP]1000[/SUP] zu berechnen, wäre es sinnvoller Verfahren einzusetzen, die schon bei einmaliger Ausführung einen "enormen" Zeitaufwand benötigen.



Grobe Fehler sind möglich.

 

[mathmos]

Die letzten Beiträge haben nicht wirklich zum eigentlichen Thema des Threads gepasst. Ich habe diese daher in eine neuen Thread ausgelagert.