Abo
  1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › PHP 5.5: Sichere…

SHA1 unsicher?

Anzeige
  1. Thema

Neues Thema Ansicht wechseln


  1. SHA1 unsicher?

    Autor: ww 13.09.12 - 12:40

    Für MD5 wurden tatsächlich Möglichkeiten gefunden, um Kollisionen zu erzeugen. Für SHA1 ist mir das allerdings nicht bekannt. Hab ich da was verpasst?

    Außerdem sind Kollisionsattacken lediglich ein theoretischer Angriffsvektor. Der Aufwand eine Kollision zu erzeugen ist gigantisch.

    Einzig Wörterbuchangriffe sind mit nicht-kryptographischen Hash-Funktionen möglich. Denen kann man mit einem dicken Salt leicht aus dem Wege gehen.

    Klar ist eine kryptographishe Hashfunktion vorzuziehen, aber SHA1 als "unsicher" zu bezeichnen finde ich nicht sonderlich gut recherchiert.

    Außerdem nennt man bei Kryptographischen Hashfunktionen den Schlüssel "Schlüssel" und nicht "Salt".

    Belehrt mich bitte eines Besseren.



    2 mal bearbeitet, zuletzt am 13.09.12 12:51 durch ww.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  2. Re: SHA1 unsicher?

    Autor: crash 13.09.12 - 12:51

    http://www.php.net/manual/en/faq.passwords.php#faq.passwords.fasthash

    Benutzer wird von Ihnen ignoriert. Anzeigen

  3. Re: SHA1 unsicher?

    Autor: ww 13.09.12 - 12:54

    "Hashing algorithms such as MD5, SHA1 and SHA256 are designed to be very fast and efficient. With modern techniques and computer equipment, it has become trivial to "brute force" the output of these algorithms, in order to determine the original input. "

    Das ist einfach nicht korrekt.
    Man kann mit Wörterbüchern Bruteforceattacken starten.
    Wenn das Passwort nicht im Wörterbuch vorhanden ist, ist es unmöglich. Das ist immer so, wenn es gesalzen ist. Dann bleibt nur die Kollision und die ist theoretisch.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  4. Re: SHA1 unsicher?

    Autor: dabbes 13.09.12 - 12:55

    Wenn es hilft die Masse an DAU Programmierern dazu zu bewegen statt md5 etwas anderes zu benutzen, dann kann man von mir aus SHA1 als Ausgeburt der Hölle bezeichnen ;-)

    Benutzer wird von Ihnen ignoriert. Anzeigen

  5. Re: SHA1 unsicher?

    Autor: dabbes 13.09.12 - 12:56

    Ja MIT salt, aber ohne stimmt es schon.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  6. Re: SHA1 unsicher?

    Autor: ww 13.09.12 - 12:58

    dabbes schrieb:
    --------------------------------------------------------------------------------
    > Wenn es hilft die Masse an DAU Programmierern dazu zu bewegen statt md5
    > etwas anderes zu benutzen, dann kann man von mir aus SHA1 als Ausgeburt der
    > Hölle bezeichnen ;-)


    Wo liegt das Problem bei MD5. Doch wohl nur in der Tatsache dass man es auch ohne Salz benutzen kann. Benutzt man es mit Salz ist es genauso gut oder schlecht wie Bcrypt.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  7. Re: SHA1 unsicher?

    Autor: droptable 13.09.12 - 13:00

    Sobald der Salt aber bekannt ist, isses kein großes Ding mehr.
    http://hashcat.net/oclhashcat-plus/#performance

    Zudem ist bcrypt nicht unbedingt "sicherer", sondern langsamer.
    Und eben da liegt der Hase im Pfeffer ;)

    Benutzer wird von Ihnen ignoriert. Anzeigen

  8. Re: SHA1 unsicher?

    Autor: EqPO 13.09.12 - 13:22

    Coder-DAUs speichern im Klartext, damit sie es dem Benutzer zusenden könne. ;)
    Fortgeschrittene hashen es, Profis salzen es. :)

    Benutzer wird von Ihnen ignoriert. Anzeigen

  9. Re: SHA1 unsicher?

    Autor: blizzy 13.09.12 - 13:49

    http://en.wikipedia.org/wiki/Key_stretching

    Benutzer wird von Ihnen ignoriert. Anzeigen

  10. Re: SHA1 unsicher?

    Autor: slashwalker 13.09.12 - 14:59

    blizzy schrieb:
    --------------------------------------------------------------------------------
    > en.wikipedia.org


    So in etwa mach ich das immer wenn es um wirklich kritische Passwörter geht:

    private string function getHash(String pass, String salt){

    var key=hash(trim(arguments.pass) & trim(arguments.salt),"SHA-512");
    for (x=1;x lt 65536;x++){
    key=hash(key & arguments.salt,"SHA-512");
    }
    return key;
    }

    Benutzer wird von Ihnen ignoriert. Anzeigen

  11. Re: SHA1 unsicher?

    Autor: laZee 13.09.12 - 15:23

    ww schrieb:
    --------------------------------------------------------------------------------
    > "Hashing algorithms such as MD5, SHA1 and SHA256 are designed to be very
    > fast and efficient. With modern techniques and computer equipment, it has
    > become trivial to "brute force" the output of these algorithms, in order to
    > determine the original input. "
    >
    > Das ist einfach nicht korrekt.

    Ohne Salt ist das korrekt. "Trivial" ist Ansichtssache.

    > Man kann mit Wörterbüchern Bruteforceattacken starten.

    Na entweder Wörterbuch ODER Brute-Force-Attacke würde ich sagen. Bruteforce geht immer. Wird nur sehr ineffizient, wenn das Salt sehr groß ist.

    > Wenn das Passwort nicht im Wörterbuch vorhanden ist, ist es unmöglich. Das
    > ist immer so, wenn es gesalzen ist. Dann bleibt nur die Kollision und die
    > ist theoretisch.

    Unmöglich würde ich bei sowas einfach nicht in den Mund nehmen ;). Brute-Force geht immer. Auch bei gesalzenen Hashes. Es wird nur sehr viel schwieriger / aufwändiger.

    Im Zweifel erfindest du sowas wie "SETI" und lässt die ganze Welt deine Brutforceattacken fahren :)

    Benutzer wird von Ihnen ignoriert. Anzeigen

  12. Re: SHA1 unsicher?

    Autor: laZee 13.09.12 - 15:24

    > Coder-DAUs speichern im Klartext, damit sie es dem Benutzer zusenden könne.
    > ;)
    > Fortgeschrittene hashen es, Profis salzen es. :)

    Es gibt Szenarien, in denen du Klartext BRAUCHST. Also nicht sofort mit DAU gleichsetzen :). Aber in 99% der Fälle stimmt das schon ;)

    Benutzer wird von Ihnen ignoriert. Anzeigen

  13. Re: SHA1 unsicher?

    Autor: blizzy 13.09.12 - 15:27

    > Es gibt Szenarien, in denen du Klartext BRAUCHST.

    Zum Beispiel?

    Benutzer wird von Ihnen ignoriert. Anzeigen

  14. Re: SHA1 unsicher?

    Autor: slashwalker 13.09.12 - 15:32

    laZee schrieb:
    --------------------------------------------------------------------------------
    > > Coder-DAUs speichern im Klartext, damit sie es dem Benutzer zusenden
    > könne.
    > > ;)
    > > Fortgeschrittene hashen es, Profis salzen es. :)
    >
    > Es gibt Szenarien, in denen du Klartext BRAUCHST. Also nicht sofort mit DAU
    > gleichsetzen :). Aber in 99% der Fälle stimmt das schon ;)

    In solchen fällen nehme ich etwas in der Art:
    private string function setPass(String pass){
    var str=rot13(arguments.pass);
    return tobase64(str);
    }
    private string function getPass(String pass){
    var str= tostring(tobinary(arguments.pass));
    return rot13(str);
    }
    Auch unsicher, klar aber immer noch besser als Klartext in die DB zu schreiben.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  15. Re: SHA1 unsicher?

    Autor: laZee 13.09.12 - 15:35

    droptable schrieb:
    --------------------------------------------------------------------------------
    > Sobald der Salt aber bekannt ist, isses kein großes Ding mehr.
    > hashcat.net#performance

    (((((8^26) / 4085) / 60) / 60) / 24) / 365 = 2,34607015 × 10^12

    ... Jahre. Bei bcrypt und dem schnellsten, aufgeführten Setup. Nehmen wir an du clusterst das auf 100000 Maschinen:

    ((((((8^26) / 4085) / 60) / 60) / 24) / 365) / 100 000 = 23 460 701,5

    Nur noch 23 460 701 Jahre bis du deinen Rainbowtable / die Lösung hast. Für EINEN Hash. Das nennst du "kein großes Ding" ;)?

    > Zudem ist bcrypt nicht unbedingt "sicherer", sondern langsamer.
    > Und eben da liegt der Hase im Pfeffer ;)

    Fast sämtliche Krypto-Algorithmen basieren auf Aufwand, also auf Geschwindigkeit. Also ist langsamer = sicherer, weil Bruteforce damit langsamer ist. Und das ist nunmal die finale Waffe wenn alles andere nicht geht.

    Ergo: langsamer = sicherer.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  16. Re: SHA1 unsicher?

    Autor: blizzy 13.09.12 - 15:37

    > Auch unsicher, klar aber immer noch besser als Klartext in die DB zu
    > schreiben.

    Nicht wirklich. Base64 erkennt man schon direkt. Und daß Du ROT13 verwendet hast, kann man über eine Häufigkeitsanalyse herausfinden.

    Vermutlich gibt es irgendwo in Hackerkreisen auch schon eine Art Checkliste, welche "simplen" Verschleierungstricks abgeprüft werden, um schon mal die einfachsten Programme auszuhebeln.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  17. Re: SHA1 unsicher?

    Autor: slashwalker 13.09.12 - 15:43

    blizzy schrieb:
    --------------------------------------------------------------------------------
    > > Auch unsicher, klar aber immer noch besser als Klartext in die DB zu
    > > schreiben.
    >
    > Nicht wirklich. Base64 erkennt man schon direkt. Und daß Du ROT13 verwendet
    > hast, kann man über eine Häufigkeitsanalyse herausfinden.
    >
    > Vermutlich gibt es irgendwo in Hackerkreisen auch schon eine Art
    > Checkliste, welche "simplen" Verschleierungstricks abgeprüft werden, um
    > schon mal die einfachsten Programme auszuhebeln.


    Das ist ja auch nur für die 1% der Fälle in denen man selbst das PW irgendwo wieder als Klartext benötigt.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  18. Re: SHA1 unsicher?

    Autor: laZee 13.09.12 - 15:49

    CRAM - Challenge-Response Authentication

    bspw.
    http://en.wikipedia.org/wiki/CRAM-MD5

    Benutzer wird von Ihnen ignoriert. Anzeigen

  19. Re: SHA1 unsicher?

    Autor: c3rl 13.09.12 - 17:13

    slashwalker schrieb:
    --------------------------------------------------------------------------------
    > blizzy schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > en.wikipedia.org
    >
    > So in etwa mach ich das immer wenn es um wirklich kritische Passwörter
    > geht:
    >
    > private string function getHash(String pass, String salt){
    >
    > var key=hash(trim(arguments.pass) & trim(arguments.salt),"SHA-512");
    > for (x=1;x lt 65536;x++){
    > key=hash(key & arguments.salt,"SHA-512");
    > }
    > return key;
    > }

    Ouch. Das ist aber sehr gefährlich! Mit der Verundung erzeugt zu einen parteiischen Datenstrom, in dem vor allem Nullen vorkommen. Das macht das Cracken enorm leichter. Nimm XOR statt AND und gut is, häng den Salt einfach an oder machs gleich einfach richtig und verwend PBKDF2:
    http://pastebin.com/5KynURz3



    1 mal bearbeitet, zuletzt am 13.09.12 17:13 durch c3rl.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  20. Re: SHA1 unsicher?

    Autor: slashwalker 17.09.12 - 14:10

    c3rl schrieb:
    --------------------------------------------------------------------------------
    > slashwalker schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > blizzy schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > en.wikipedia.org
    > >
    > >
    > > So in etwa mach ich das immer wenn es um wirklich kritische Passwörter
    > > geht:
    > >
    > > private string function getHash(String pass, String salt){
    > >
    > > var key=hash(trim(arguments.pass) & trim(arguments.salt),"SHA-512");
    > > for (x=1;x lt 65536;x++){
    > > key=hash(key & arguments.salt,"SHA-512");
    > > }
    > > return key;
    > > }
    >
    > Ouch. Das ist aber sehr gefährlich! Mit der Verundung erzeugt zu einen
    > parteiischen Datenstrom, in dem vor allem Nullen vorkommen. Das macht das
    > Cracken enorm leichter. Nimm XOR statt AND und gut is, häng den Salt
    > einfach an oder machs gleich einfach richtig und verwend PBKDF2:
    > pastebin.com


    Hä bitte? Wo verwendet das Script AND?

    > var key=hash(trim(arguments.pass) & trim(arguments.salt),"SHA-512");
    erzeugt einen SHA-512 hash aus Passwort+Salt

    > for (x=1;x lt 65536;x++){
    > key=hash(key & arguments.salt,"SHA-512");
    > }
    Schleife von 1-65536 in der jedes Mal ein Hash aus vorherigem Hash+Salt erzeugt wird. Und das willst du "leicht crackbar" nennen?

    Ich vermute du hast dich verlesen.

    Benutzer wird von Ihnen ignoriert. Anzeigen

Neues Thema Ansicht wechseln


Entschuldigung, nur registrierte Benutzer dürfen in diesem Forum schreiben. Klicken Sie hier um sich einzuloggen


Anzeige
  1. Junior PLM Development Ingenieur (m/w)
    MBtech Group GmbH & Co. KGaA, Großraum Stuttgart
  2. Scrum Master Application Integration (m/w)
    Media-Saturn IT-Services GmbH, Ingolstadt
  3. Software-Entwickler/in MES (Manufacturing Execution Systems)
    Robert Bosch GmbH, Crailsheim
  4. Linux-Administrator (m/w) mit Schwerpunkt Automation
    BG-Phoenics GmbH, München

Detailsuche



Spiele-Angebote
  1. GRATIS: The Witcher 2 für Xbox One
  2. VORBESTELLBAR: Tom Clancy's: The Division [PC Code - Uplay]
    54,45€ - Release 8. März
  3. Xbox One 1 TB Tom Clancy’s The Division Bundle
    399,99€

Weitere Angebote



Haben wir etwas übersehen?

E-Mail an news@golem.de


Asteroidenbergbau: Verblendet vom Platinrausch
Asteroidenbergbau
Verblendet vom Platinrausch
  1. Raumfahrt SpaceX und Orbital bauen Triebwerke für das US-Militär
  2. Dream Chaser Mini-Shuttle darf zur ISS fliegen
  3. Raumfahrt Raumsonde Dawn findet Wasser auf Zwergplaneten Ceres

Künstliche Intelligenz: Alpha Go spielt wie ein Japaner
Künstliche Intelligenz
Alpha Go spielt wie ein Japaner
  1. Nachruf KI-Pionier Marvin Minsky mit 88 Jahren gestorben
  2. CNTK Microsoft gibt Deep-Learning-Toolkit frei
  3. OpenAI Elon Musk unterstützt Forschung an gemeinnütziger KI

Tails 2.0 angeschaut: Die Linux-Distribution zum sicheren Surfen neu aufgelegt
Tails 2.0 angeschaut
Die Linux-Distribution zum sicheren Surfen neu aufgelegt

  1. Daybreak Game Company: Zombiespiel H1Z1 wird aufgeteilt
    Daybreak Game Company
    Zombiespiel H1Z1 wird aufgeteilt

    Noch gibt es nur ein H1Z1, ab Mitte Februar sind es zwei: Das Entwicklerstudio Daybreak Game Company will dann ein Überlebens- und ein Actionspiel anbieten. Die Community hat es offenbar so gewollt.

  2. Twitter: Neue Sortierung der Timeline kommt
    Twitter
    Neue Sortierung der Timeline kommt

    Twitter folgt bei der Sortierung der Timeline wohl dem großen Konkurrenten Facebook: Bereits in den kommenden Tagen soll die Timeline nicht mehr grundsätzlich chronologisch sortiert werden - sondern zumindest auf Wunsch auch so, wie Algorithmen es richtig finden.

  3. Error 53: Unautorisierte Ersatzteile sperren iPhone
    Error 53
    Unautorisierte Ersatzteile sperren iPhone

    Eine ältere Fehlermeldung von Apple sorgt für neue Diskussionen: Ab iOS 9 sorgen unautorisierte Komponenten - etwa für den Touch-ID-Fingerabdrucksensor - in einem iPhone für die Fehlermeldung "Error 53". Der Hersteller verteidigt dieses Vorgehen.


  1. 14:45

  2. 13:25

  3. 12:43

  4. 11:52

  5. 11:28

  6. 09:01

  7. 21:49

  8. 16:04