Debian-Installer: SHA1 Problem

[tobo]

Kann man nicht eine Passwortverwaltung programmieren, die zwar clientseitig eine Passworteingabe erfordert, dieses jedoch nie dem Webserver mitteilt?

Wie sollte sowas funktionieren? Die Authentifizierung erfolgt ja zwingend durch den Server. Dabei spielt es eigentlich wohl keine große Rolle, ob da ein Passwort, ein gehashtes Passwort oder ein gehashtes (Passwort + Salt) an den Server übermittelt wird. Das alles fungiert für den Server dann als Passwort. Und wenn das im Klartext gelesen werden kann, dann liegen die Zugangsdaten offen. Aber eben auch nur von diesem einen Account. Serverseitig wird das Passwort ja nicht gespeichert, sondern nur überprüft. Dort liegen nur die Hashes (bestenfalls verschlüsselt, gegen Bruteforce- und Wörterbuchattacken), die generiert wurden aus Übertragung und zufälligem Salt (gegen Rainbow Tables).

[wanne]

@dufty2 . schorsch_76, MSfree:
Hier nochmal ein weniger offensichtliches Hashverfahren.
Das alte crypt ferfahren, ass früher in der /etc/shadow verwendet wurde. (Bzw. bis heute bei einigen Distributionen wie cirros wird.)

Code: Alles auswählen

echo "Passwör" | openssl passwd -salt "42" -stdin
42MgZCCmg5uOA
echo "PasswC6r" | openssl passwd -salt "42" -stdin
42MgZCCmg5uOA

Jetzt versucht mal ein Passwort zu dem Hash zu finden:
42CoB2PYGETbk
(Darauf verwette ich nicht so viel, da crypt maximal 8-Zeichen Passwörter zulässt. Und das kann man dann auch brutforcen.)

[schorsch_76]

Du lieferst hier keine Quellen für deine Behauptungen: Ich habe hier Bruce Schneier zitiert. Falls du einen anderen Kryptologen hast, der sagt, das es in Ordnung ist SHA1 für Passwörter zu verwenden, dann zeig uns bitte die Quelle.

Heise zu shattered
https://www.heise.de/security/artikel/W ... 34341.html
https://www.heise.de/security/meldung/T ... 33589.html

Nach dem jetzt von Marc Stevens und Kollegen vorgestellten Angriff auf SHA-1 kann man dieses Hash-Verfahren endgültig beerdigen. Wer es jetzt noch einsetzt, handelt grob fahrlässig. Der Nachfolger steht auch schon fest: In allen praktischen Belangen kann und sollte man stattdessen SHA256 oder SHA512 verwenden. Diese beiden SHA-2-Varianten gelten als ausreichend sicher, dass sie auch langfristig die Unterscheidbarkeit verschiedener Dokumente garantieren können. Auf jeden Fall ist eine SHA-2-Kollision eine würdige Herausforderung für Marc Stevens, der auch bereits am Todesstoß für MD5 beteiligt war.

Da haben wir auf der einen Seite Schneier und Heise die sagen das SHA1 tot ist.
Auf der anderen Seite haben wir bisher nur deine Aussage aber keine Quellen gelesen das SHA1 immer noch gut ist.

https://www.heise.de/security/artikel/K ... kelseite=2
Die Richtlinien für Crypto in der IT von Heise sagt:

Für das Speichern von Passwörtern sollte man keine Hash-Funktionen direkt verwenden, sondern stattdessen Verfahren wie PBKDF2, bcrypt oder scrypt einsetzen. Die sind absichtlich so konzipiert, dass ein Passwort-Test möglichst viel Ressourcen benötigt. Sie erreichen dies unter anderem, indem sie viele Iterationen über Hash-Operationen durchführen. Auch für das Erzeugen von geheimen (AES-)Schlüsseln aus Passwörtern sind diese PBKDF2, bcrypt und scrypt das Mittel der Wahl.

Wenn man SHA1 für Passwörter verwendet, macht man schon eine Fehler.

[breakthewall]

Da haben wir auf der einen Seite Schneier und Heise die sagen das SHA1 tot ist.
Auf der anderen Seite haben wir bisher nur deine Aussage aber keine Quellen gelesen das SHA1 immer noch gut ist.

Das wird auch aus validen und nachvollziehbaren Gründen gesagt. Und wer mal geschichtlich nachgeforscht hat der weiß, dass gerade Umstellungen auf andere kryptografische Verfahren, mitunter immense Zeiträume beanspruchen. Nicht zuletzt aufgrund fahrlässiger Hersteller und Ewiggestrigen, auf die alle anderen angewiesen sind. Will man also warten bis SHA1 in jeder Hinsicht gänzlich gebrochen ist, oder will man klug sein und steigt frühzeitig um? Und genau darum wird Druck gemacht, dass hier nicht gewartet und mit etwas gearbeitet wird, nur weil es je nach Anwendung gerade noch so in Ordnung ist. Ein Auto fährt bspw. auch im fast durchgerosteten Zustand von A nach B. Die entscheidende Frage ist, ob man dabei sein will wenn die Achse bricht.

Wenn man SHA1 für Passwörter verwendet, macht man schon eine Fehler.

Es hängt zwar in der Tat davon ab, wie ein Hashverfahren genutzt wird, was jedoch nicht notwendigerweise bedeutet, dass man dies auch tun sollte. Es kann nicht zielführend sein bei Hashverfahren erst abwägen zu müssen, was nun für welchen Anwendungsfall noch sicher ist. Daher müssen MD5 und SHA1 weg, schon aus Prinzip. Mit allen anderen Hashverfahren, kann man hingegen noch nichts falsch machen.

[wanne]

Du hast offesichtlcih auch nicht kapiert was PBKDF2 ist. PBKDF2 praktisch ausschließlich in Kombination mit SHA-1 genutzt. Es ist also absolut kein Widerspruch zu SHA-1.

Du lieferst hier keine Quellen für deine Behauptungen: Ich habe hier Bruce Schneier zitiert. Falls du einen anderen Kryptologen hast, der sagt, das es in Ordnung ist SHA1 für Passwörter zu verwenden, dann zeig uns bitte die Quelle.

Ich kann sogar Bibel zitieren:
Psalm 102:28:

[…]shal [] secure […]

Das ist mindestens so aussagekräftig wie deine Zitate.

Zitieren ist nett aber total nutzlos, wenn man den Inhalt nicht versteht.
Hier noch ein paar links, die nicht durch große Namen sondern durch Inhalt glänzen:
http://stackoverflow.com/questions/2772 ... rd-storage

Sonst setz dich ernsthaft erstmal in ne Vorlesung zu Kryptografie und Diskreter Mathematik. Dann kannst du aus irgend welchen Kryptologen reden. Davor versuch es bitte erstmal mit Lehrbüchern. Die snd in einer Srprache geschrieben die du auch verstehst.

Kein Kryptologe wird btw. irgend wie darüber schreiben was nicht ist. – Warum auch. Du wirst keine Wissenschaftlichen Artikel über das nicht bekannt sein von irgend was finden.
Und Lehrbücher und ähnliches kommen halt nicht alle 5 Minuten heraus.
Hier zu MD5, der ja schon viel länger gerbrochen ist:
https://books.google.de/books?id=5TkLDg ... &q&f=false
Ansonsten der Golem Artikel zum Angriff, der wie immer etwas fundierter und mit mehr Hintergrund als das von Heise:
https://www.golem.de/news/kollissionsan ... 26355.html

Welche Auswirkungen ein Kollisionsangriff hat, ist in vielen Fällen nur mit einer genaueren Analyse feststellbar. So gibt es kryptographische Konstruktionen, in denen Kollisionen keine Rolle spielen und nur sogenannte Preimage-Angriffe vermieden werden müssen. Bei einem Preimage-Angriff kann ein Angreifer für einen bestehenden Hash eine gültige Eingabe finden. Preimage-Angriffe sind bislang für SHA-1 und selbst für MD5 unrealistisch.

Aber ich nehme an das interessiert dich nicht im geringsten. Du hast irgend welchen Bullshit verzapft und willst das jetzt irgend wie belegen.

[schwedenmann]

Hallo

@wanne
Komisch in Golem steht im Prinzip als Abstract gesehen,dasselbe wie in heise,da ist Inhaltlich und in der Bewertung kein Unterschied. Warum du jetzt heise verreißt und deine anderen links "rühmst" entzieht sich meiner Erkenntnis.

Golem und Konsorten kochen auch nur mit Wasser und wo was veröffentlicht ist, sdagt abioslut ncihts über den Inhalt aus, gilt natürlich auch für heise, wie auch für andere Fachrichtungen (außer Aluhutseiten, die sind soweiso unten durch - allein schon rein methodisch und vom Wissenshorizont).

das Entscheidende ist doch wohl, das ein und 2 unterschiedliche Dateien ein und denselben SHA-1 hash haben können, was jetzt bewiesen wurde.

mfg
schwedenmann

[wanne]

Warum du jetzt heise verreißt

Das war nicht so gemeint. Ich lese heise oft und gerne. (Auch öfter als Golem.) Aber ich glaube die beiden Seiten haben schon ein bisschen eine andere Ausrichtung:
Heise ist die typische News-Seite: Immer der versuch möglichst schnell zu veröffentlichen und zumindest für den Technikberecih ziemlich allumfassend. Keine Technik-News, die nicht auf heise erscheint.
Dafür haben sie dann auch gerne mal einen Fehler drin (den sie dann im Gegensatz zu vielen anderen News Seiten nach Hinweis typischerweise ziemlich schnell korrigieren.)
Golems Artikel sind meisten etwas länger und Detaillierter und definitiv meist besser recherchiert. Dafür sind sie dann meist nicht so schnell. Und vor allem habe ich schon das gefühl das es da nicht vorkommt, dass jemand, der eigentlich eher weniger Ahnung vom Theman hat darüber schreibt. Guck dir mal die News-Show an. Da merkst du dass da einige zwar durchaus gut recherchieren können. (Sonst könnten sie keine vernünftigen Artikel abliefern.) Aber Fachlich oft recht wenig Ahnung haben. Dafür fehlen gewisse Ereignisse dann vollständig.
Ist ein bisschen wie der Unterschied zwischen einer Tageszeitung und einer Wochenzeitung.

[wanne]

Wie sollte sowas funktionieren? Die Authentifizierung erfolgt ja zwingend durch den Server. Dabei spielt es eigentlich wohl keine große Rolle, ob da ein Passwort, ein gehashtes Passwort oder ein gehashtes (Passwort + Salt) an den Server übermittelt wird. Das alles fungiert für den Server dann als Passwort.

Hier wie man das richtig macht: https://en.wikipedia.org/wiki/Digest_ac ... entication
Der trick ist, dass der die URL mit in den Hash einfließt. – Andere URLs ergeben einen anderen Hash. Man kann also nur URLs aufrufen, die man schon gesehen hat. (Replay-Angriffe.) Andere sind weiter geschützt.
Daneben fließt bei Digest Authentication noch ein vom server bestimmter nonce ein. Ändert der den in regelmäßigen Abständen, ist der Mitschnitt nach dieser Zeit vollständig nutzlos.

[tobo]

Hier wie man das richtig macht: https://en.wikipedia.org/wiki/Digest_ac ... entication
Der trick ist, dass der die URL mit in den Hash einfließt. – Andere URLs ergeben einen anderen Hash. Man kann also nur URLs aufrufen, die man schon gesehen hat. (Replay-Angriffe.) Andere sind weiter geschützt.
Daneben fließt bei Digest Authentication noch ein vom server bestimmter nonce ein. Ändert der den in regelmäßigen Abständen, ist der Mitschnitt nach dieser Zeit vollständig nutzlos.

Ok, liest sich als hätten sich die Jungs da richtig Gedanken gemacht. Das angesprochene Passwort wäre in dem Fall HA1, also der Hash aus Benutzername, Passwort und der Anfrage. Das wäre dann auch die Konstante, die auf dem Server gespeichert ist. Mit dem Rest dann nochmal außenrum einzigartig zusammengebaut und verhasht. Clever! War mir so nicht bewusst - danke für die Nachreichung!

[wanne]

Ok, liest sich als hätten sich die Jungs da richtig Gedanken gemacht.

Solche Konstrukte waren um die Jahrtausendwende halt eigentlich State of the Art. CRAM-MD5 funktioniert ähnlich und ist 2 Jahre vorher spezifiziert worden. EAP (1998) ebenfalls. Windows 2000 hatte mit NTLM ebenfalls etwas ähnliches am Start (Das aber auf schwachen LM-Hashes beruhte). WPA (2003) nutzt ein ähnliches Konstrukt.
Leider ist das dann wider fallen gelassen worden. Nach diversen Sicherheitslücken wurde alles in SSL gesteckt und solcherlei Konstrukt dann als überflüssig erklärt. Prinzipiell ist das natürlich die sauberere Variante. Aber eigentlich widerspricht sich das ja nicht.

[breakthewall]

Wollte nach einer Recherche noch etwas abschließend zum Thema anfügen. So wie es aussieht war die SHA1-Problematik gewissermaßen hausgemacht, zumal der Debian-Installer selbst, erst seit kurzer Zeit SHA256 unterstützt, und lange nichts anderes als MD5 und SHA1 kannte. Habe die Tage daher nochmals ein aktuelles Testing-Image getestet, und siehe da es wird nun SHA256 genutzt. Damit hat sich die Sache wohl erledigt.

[scientific]

Ich hab jetzt wenigstens mal ordentlich zu lesen und super Stichworte zum weiterrecherchieren bekommen.

Wenn das jetzt ein Pferderennen wäre, würd ich auf wanne setzen. Er hat die Außenseitermeinung, die mir jedoch fachlich sehr gut fundiert erscheint.

Lg scientific