hashlib.new(string), Welche Hashfuncs gibts noch???

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Benutzeravatar
akis.kapo
User
Beiträge: 127
Registriert: Freitag 1. September 2006, 12:58

Hi all,

ihr kennt bestimmt alle hashlib.* functionen .md5(), .sha*(), ...usw

In der docs.python.org... libref zu hashlib steh auch ein Beispiel mit ripemd160:

Code: Alles auswählen

>>> h = hashlib.new('ripemd160')
>>> h.update(b"Nobody inspects the spammish repetition")
>>> h.hexdigest()
'cc4a5ce1b3df48aec5d22d1f16b894a0b894eccc'
Offenbar gibst du .new() einen String mit dem Namen des Hashes und dann legt er des Objekt an.

Aber welche Hashes gibt es sonst noch?
Kann man die sich nicht irgendwie in Python anzeigen lassen per dir() und oder sonstwie?

Da steht ja dran "Using new() with an algorithm provided by OpenSSL",
ja aber woher weiss ich welches OpenSSL integriert ist, welche Version
und wieviele Algorithmen da genau unterstützt sind? Muss ich mir jetzt
paralell die OpenSSL docs aus der history durchlesen?

Ich nutze Python 3.1.2 für Windoof (und 2.6.2 für cygwin),
die sind beide relativ alt. Dagegen gabs bei OpenSSL in letzter
Zeit einige grössere Releases, wo Algorithmen hinzugekommen sind.

Nochmal die Frage: Wieso kann ich nicht oder wie kann ich mit Pyhton-Mitteln gucken,
welche Hashalgorithmen genau in hashlib.new() unterstützt werden???

Wie immer many thanks in advance!! :-*
Benutzeravatar
Hyperion
Moderator
Beiträge: 7478
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

akis.kapo hat geschrieben: Da steht ja dran "Using new() with an algorithm provided by OpenSSL",
Also in der Doku zu 2.7 steht die Beschreibung, wie man an die Algos kommt direkt unter der von new(). Vermutlich hast Du nur in die der 3.1er Reihe geguckt. Dort steht das lustigerweise nicht mehr.

Allerdings gibt es dieses Attribut "algorithms" bei mir nicht (Python 2.6.5).

Dennoch steht in der Doku (sowohl in der 2.7er als auch in der 3.1er) zu hashlib ganz oben folgendes:
Doku hat geschrieben: Included are the FIPS secure hash algorithms SHA1, SHA224, SHA256, SHA384, and SHA512 (defined in FIPS 180-2) as well as RSA’s MD5 algorithm (defined in Internet RFC 1321)
Ich denke das sagt es doch aus :-)
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
Benutzeravatar
akis.kapo
User
Beiträge: 127
Registriert: Freitag 1. September 2006, 12:58

Achso... hmm, das ist mir nie aufgefallen (wie denn auch, in meiner Python-Version gibts des nicht...).

Ja ok ich hab das jetzt mitgenommen, danke für den Hinweis!

Allerdings bin ich jetzt trotzdem sehr enttäuscht, ich werde doch nicht die Python Version wechseln deswegen, die sollen das einfach wieder includen... :(
Benutzeravatar
Hyperion
Moderator
Beiträge: 7478
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

akis.kapo hat geschrieben: Allerdings bin ich jetzt trotzdem sehr enttäuscht, ich werde doch nicht die Python Version wechseln deswegen, die sollen das einfach wieder includen... :(
Ich nehme schon an, dass die Entwickler einen trifftigen Grund dafür hatten - im Endeffekt stehen die Algos ja in der Doku. Welchen Mehrwert hat dann also ein Attribut, in welchem sie gespeichert sind?
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
Benutzeravatar
akis.kapo
User
Beiträge: 127
Registriert: Freitag 1. September 2006, 12:58

Du hast es nicht ganz erfasst, "ripemd160" ist nicht in der Doku drin! Und viele andere auch nicht, die man mit .new(<md-name>) erstellen kann!

Guck mal genauer hin.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

akis.kapo hat geschrieben:Dagegen gabs bei OpenSSL in letzter
Zeit einige grössere Releases, wo Algorithmen hinzugekommen sind.
Ich glaube nicht dass in der 0.9.8-Serie und resp. 1.0-Serie in den "Buchstabenreleases" neue Algerithmen dazugekommen sind. So kannst du schauen gegen welche OpenSSL-Version dein Python gelinkt ist und schon weißt du welche Algorithmen unterstützt werden ;)

Wobei, ich vermute mal dass man das auch nicht so generell sagen kann, vermutlich hängt das auch davon ab, welche Algorithmen beim kompilieren von OpenSSL ausgewählt wurden.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
fk
User
Beiträge: 7
Registriert: Freitag 7. November 2008, 14:54

Bzgl. des algorithms-Attribut: Da wurde nichts entfernt, das ist einfach neu in Python 2.7. 3.1 ist aber älter als 2.7; da gab's das noch nicht. In 3.2 gibt es algorithms dann auch (wieder).
Benutzeravatar
Hyperion
Moderator
Beiträge: 7478
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

*patsch* Nun habe ich das auch richtig erkannt. Ich hatte das "new in version 2.7" auf den gesamten Rest bezogen... :oops:
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Mein openssl 1.0.0a kann laut "openssl dgst -help" folgendes: md4, md5, mdc2, ripemd160, sha, sha1, sha224, sha256, sha384, sha512 und whirepool. Die gehen auch alle in Python 2.6 und Python 2.7. Will man noch mehr Hashing-Algorithmen haben, fällt mir noch bouncycastle für Java ein, welches zusätzlich zu den erwähnten noch md2, ripemd128, ripemd256, ripemd320, tiger und gost3411 unterstützt. Das ist IMHO sowieso die goto-Bibliothek, wenn es um Kryptografie geht.

Von gost hatte ich bis eben noch nie gehört. Offenbar ist das ein Algorithmus aus der Soviet Union (kalter Krieg und so). OpenSSL kann den angeblich auch, aber dann wohl nicht per Kommandozeilen-Client. Neugierig geworden, glaube ich aus dem Sourcecode zu lesen, dass der Name gost94 sein müsste, doch das will auch nicht funktionieren. Egal...

Stefan
Benutzeravatar
microkernel
User
Beiträge: 271
Registriert: Mittwoch 10. Juni 2009, 17:27
Wohnort: Frankfurt
Kontaktdaten:

ich habe mal jetzt so ganz nebenbei eine Frage welche nur halbwegs etwas mit diesem Thema zu tun hat (ich wollte aber nicht extra ein neuen thread erstellen):
Was ist zurzeit der beste Hashalgo. um Passwörter in einer Datenbank zu speichern (gehasht natürlich ;))? Ich glaube mal gehört zu haben das man md5 Hashsummen rekonstruieren kann... bin mir aber nicht sicher :s
ms4py
User
Beiträge: 1178
Registriert: Montag 19. Januar 2009, 09:37

Also, Rekonstruieren geht bei den modernen Hash-Alg. gar nicht (durch einen Algorithmus, mit DictionaryAttacks/BruteForce natürlich schon).
Bei MD5 kann man AFAIR einen zweiten Byte-String konstruieren, der den selben Hash-Wert erzeugt. Dies allerdings nur, wenn der Hash-Wert bestimmte Voraussetzungen erfüllt und das ist vermutlich sehr selten.
SHA1 ist IMO sicher genug, für mehr Sicherheit brauchst du einfach einen Algorithmus, der einen längeren Hash-Wert erzeugt.

Ach BTW: Um Dictionary-Attacks vorzubeugen, solltest du einen Salt verwenden.
http://de.wikipedia.org/wiki/Salt_%28Kryptologie%29
„Lieber von den Richtigen kritisiert als von den Falschen gelobt werden.“
Gerhard Kocher

http://ms4py.org/
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Salt wird IMHO überbewertet. Ausreichend zufällige Salt-Werte verbessern zwar Kennworte derart, dass man nicht einfach fertige Tabellen zum Vergleichen benutzen kann, aber wenn ich's richtig messe, schafft mein Computer etwa 380.000 MD5- Digests (SHA1 ist nur minimal langsamer) pro Sekunde pro Prozessor und wenn ich z.B. 50.000.000 Kennworte aus einem Wörterbuch prüfen möchte, dauert das gerade mal 132 Sekunden, also rund zwei Minuten. Da ist es dann egal, ob ich ein Salt benutze oder nicht, brute force ist schnell genug. Selbst eine Milliarde Kennwörter kann ich dann mit einem Dual-Quadcore-System in knapp 6 Minuten durchprobieren.

Die Entropie (ist das das richtige Wort), die in einem typischen 6 Zeichen langen Kennwort aus dem Zeichenvorrat a-z, A-Z, 0-9 und 10 typischen Sonderzeichen steckt, ist 139314069504. Das sind also 139 Milliarden mögliche Wörter und in 14 Stunden durchprobierbar. Bei 8 Zeichen gibt es schon 722204136308736 Kombinationen, da rechnet der Computer dann 3000 Tage. Aber man könnte sich ja 100 Rechner bei Amazon mieten...

Je länger, desto besser also.

Ansonsten gilt: MD5 kann man zu Kollisionen führen, d.h. man findet mit vertretbarem Aufwand (weniger als Brute Force) einen weiteren Text, der den gleichen MD5-Wert hat, was man z.B. nutzen kann, um mit RSA-MD5 gesicherte Zertifikate zu fälschen. Bei SHA1 sieht es hier noch besser aus, doch auch hier wurde schon mal gewarnt. RSA-SHA1 ist dennoch noch immer die Kombination für Signaturen von Zertifikaten. Als kryptografisch sicher gelten AFAIK die SHA2-Varianten und man sollte sie mittelfristig nutzen. Bis 2012 soll ein neuer Algorithmus als SHA3 benannt werden, auf den man dann langfristig umsteigen kann.

Stefan

PS: Was auch hilft ist, immer wieder (z.B. 1000 mal) die Hashfunktion anzuwenden. Das muss derjenige, der per Bruteforce durchprobieren will, natürlich ebenfalls machen und da kann man ihm gleich mal einen Faktor 1000 als Bremse mitgeben. Wenn jedoch alle 18 Monate die Rechner doppelt so leistunsfähig werden, ist das nach 15 Jahren auch kein Thema mehr.
BlackJack

@sma: Die 132 Sekunden stimmen doch nur wenn Du kein Salt hast und eben nur die 50 Mio. Wörter direkt prüfen musst, oder!? Bei einem zwei Zeichen-Salt wobei jedes Zeichen in a..z liegt, kommt man schon auf einen Tag. Ist natürlich immer noch problemlos machbar.
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Das "Salz" ist ja im Klartext lesbar, wenn ich also ein Kennwort unter Kenntnis von <salz>$<glibberisch> knacken will, wobei <glibberisch> einem hash(<kennwort>+<salz>) entspricht, muss ich das selbe Salz bei meinem brute-force-Ausprobieren aller Kombinationen auch nur anwenden. Ich kann's ja aus meinem zu erratenden Kennwort-String ableiten. Es macht eben nicht das Kennwort länger, sondern schützt nur gegen fertig berechnete Tabellen.

Stefan
ms4py
User
Beiträge: 1178
Registriert: Montag 19. Januar 2009, 09:37

"Ophcrack" braucht für ein 8-stelliges Passwort ca. 5 Sekunden. Irgendwie ein *kleiner* Unterschied zu den 3000 Tagen...

Also ich würde ja sagen BruteForce ist deutlich unwirtschaftlicher als RainbowTables und deshalb lohnt sich ein Salt auf jeden Fall!
„Lieber von den Richtigen kritisiert als von den Falschen gelobt werden.“
Gerhard Kocher

http://ms4py.org/
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Mir ging es nicht darum, dass es ohne "Salz" schneller geht, sondern das es mit Salz nicht schwerer ist als ohne. Brute Force ist auf heutigen Rechnern schon verdammt schnell und ein einfacher MD5 ist damit ungenügend, um ein Kennwort zu schützen, egal ob mit oder ohne Salz.

Stefan
Darii
User
Beiträge: 1177
Registriert: Donnerstag 29. November 2007, 17:02

Da hilft nur, das Salz zu verstreuen. Dann muss das vor Verwendung zusammengefegt werden.
Benutzeravatar
Defnull
User
Beiträge: 778
Registriert: Donnerstag 18. Juni 2009, 22:09
Wohnort: Göttingen
Kontaktdaten:

Ein Salt soll Rainbow-Table Angriffe (Komprimierte Tabellen bekannter Klartext<->md5 Paare) verhindern. Gegen BruteForce hilft ein (öffentlicher) Salt natürlich nicht. Ist der Salt allerdings unbekannt (Hacker bekommt Zugriff auf die DB, aber nicht auf die Scripte) ist er auch da ein großer Vorteil.

BruteForce funktioniert wiederum nur bei schwachen Passwörtern. Wenn du 380.000 Passwörter pro Sekunde schaffst, sind das bei einem 8 stelligen Passwort mit Buchstaben, Zahlen und Sonderzeichen schon etwa 60 Jahre. Selbst auf Grafikkarten dauert das etwas.
Bottle: Micro Web Framework + Development Blog
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Defnull hat geschrieben:etwa 60 Jahre.
Also ich kam auf 3000 Tage (bei 8 CPUs). Das sind etwas über 8 Jahre. Allerdings bin ich mir sicher, dass es bei spezieller Hardware deutlich schneller geht. Zudem kommt, dass im Schnitt ja nicht alle sondern nur die Hälfte aller Kombinationen probiert werden müssen.

Bei Amazon kann ich schon heute einen Rechner mit 8 virtuellen Kernen anmieten, die vielleicht doppelt so schnell sind, wie mein PC. Schon bin ich bei 2 Jahren oder 750 Tagen. Mit 75 dieser Maschinen dauert es dann 10 Tage und kostet etwa $12240. Hm... noch ein bisschen teuer für ein Kennwort ;)

Das Salt zu verstecken, es also zu einem shared secret zu machen, ist kein gutes Sicherheitskonzept, da es einfach nur "security by obscurity" ist.

Stefan
Benutzeravatar
mkesper
User
Beiträge: 919
Registriert: Montag 20. November 2006, 15:48
Wohnort: formerly known as mkallas
Kontaktdaten:

Das ist alles für umsonst, wenn die Passwörter vom Benutzer eingegeben und nicht auf Sicherheit geprüft werden:
http://www.zdnet.de/news/wirtschaft_sic ... 6495-1.htm
Antworten