Abo
  1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Password Hashing Competition…

Weitere Anforderung: Sichere Authentifizierung

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Weitere Anforderung: Sichere Authentifizierung

    Autor: RipClaw 27.07.15 - 08:38

    Ein Problem mit Passwörtern die als Hash abgelegt werden ist das für den Vergleich das Passwort im Klartext übermittel werden muss.

    Sichere Authentifizierungsverfahren wie z.B. CRAM-MD5 verlangen hingegen das das Passwort entweder im Klartext oder nur als einfacher Hash abgelegt wird, der aber dummerweise wieder relativ schnell berechnet werden kann.

    Bisher kenne ich nur ein Verfahren (SCRAM-SHA256) bei dem das Passwort als sicherer Hash abgelegt werden kann und gleichzeitig das Passwort nicht im Klartext übermittelt werden muss.

  2. Re: Weitere Anforderung: Sichere Authentifizierung

    Autor: Lala Satalin Deviluke 27.07.15 - 08:49

    Wenn man vor der Übertragung hasht und dann vergleicht, dann hat man das Problem, dass man den Hash abfangen kann und sich direkt mit dem Hash einloggen kann.

    Es ist und bleibt für einen Login essentiell das über HTTPS zu machen.

    Grüße vom Planeten Deviluke!

  3. Re: Weitere Anforderung: Sichere Authentifizierung

    Autor: fapo 27.07.15 - 08:59

    Was Spricht dagegen wenn der Client aus dem eingegebenen pw einen hash bildet, diesen auf den Server Überträgt dort kommt ein bissle salz und pfeffer dazu und wird nochmal gehasht?

  4. Re: Weitere Anforderung: Sichere Authentifizierung

    Autor: Lala Satalin Deviluke 27.07.15 - 09:07

    Weil man dann Hashes abfangen kann und sich mit denen einloggen kann...

    Grüße vom Planeten Deviluke!

  5. Re: Weitere Anforderung: Sichere Authentifizierung

    Autor: wirry 27.07.15 - 09:11

    Ändert nichts - wenn die Übertragen abgefangen wird kann der Angreifer dann einfach den Hash schicken.

    Eventuell eine Art 2 Faktor Authentisierung: ein Code kommt per SMS, der Benutzer gibt diesen in das Loginform ein und das Passwort wird zusammen mit dem Code gehasht.

    Allerdings muesste dieser Prozess dann umkehrbar sein, sonst kann man auf dem Server nicht vergleichen - oder aber man verzichtet auf Salting im Server.

    HTTPS ist dann wohl doch die einfachere Lösung.

  6. Re: Weitere Anforderung: Sichere Authentifizierung

    Autor: lear 27.07.15 - 09:15

    fapo schrieb:
    --------------------------------------------------------------------------------
    > Was Spricht dagegen wenn der Client aus dem eingegebenen pw einen hash
    > bildet, diesen auf den Server Überträgt dort kommt ein bissle salz und
    > pfeffer dazu und wird nochmal gehasht?

    Nichts - aber auch nicht viel dafür.

    Sofern die Übertragung nicht gesichert ist, ist es erstmal egal, ob Du "1234" oder "e7df7cd2ca07f4f1ab415d457a6e1c13" abfängst um Dich damit in Zukunft einzuloggen.

    Bestenfalls könnte man noch mit inter-service Sicherheit argumentieren (ich verwende "1234" überall, aber wg. der untersch. lokalen Hashes, hilft "e7df7cd2ca07f4f1ab415d457a6e1c13" nur bei einem Account) - nur nutzt das wenig, wenn Du die Kommunikation länger abhören kannst (und *verlangt*, daß jeder Dienst lokal unterschiedliche Hashfunktionen und/oder *lokale*! Salts verwendet)

    In der Hinsicht, täte es dann ("nur") das, was die ganzen Passwortdienste tun: mit einem masterpassword, individuelle accountpasswords zu verwalten.

  7. Re: Weitere Anforderung: Sichere Authentifizierung

    Autor: minecrawlerx 27.07.15 - 09:17

    Nicht vergessen, dass Otto-Norm ein Passwort für viele Seiten verwendet. Das Hashen des Passwortes auf dem Client ermöglicht zumindest, dass die User-Passwort Kombi nicht direkt vorliegt. Ich hashe auf meinen Seiten deshalb grundsätzlich im Client zuerst, und dann auf dem Server nochmal. Das dauert zwar ein bisschen länger, ist aber ein Service, der mir wichtig ist.
    Klar verwende ich auch HTTP über TLS. Aber es ist nur eine Frage der Zeit, bis auch hier eine Angriffsmöglichkeit gefunden wird.

    Wenn ihr mit den Juwelen eurer Kunden hantiert, dann tragt ihr die ja auch nicht in nem Sack, den ihr über die Schulter werft, herum.

  8. Re: Weitere Anforderung: Sichere Authentifizierung

    Autor: Schläfer 27.07.15 - 09:18

    Ansonsten wird aber das Passwort im Klartext abgefangen, dass ist doch noch schlechter. Wenn man vor dem Übertragen hasht hat wenigstens keiner das Passwort, auch wenn er sich trotzdem noch einloggen kann. Und wird nochmal nach dem Übertragen der Hash gebildet (wie gewöhnlich), hat man auch kein Problem, wenn die Datenbank erbeutet wird.
    Wäre vielleicht auch nicht verkehrt bei HTTPS nur einen Hash zu übertragen, damit der Server nicht das Passwort im Klartext bekommt.

  9. Re: Weitere Anforderung: Sichere Authentifizierung

    Autor: Yogu 27.07.15 - 09:28

    Lala Satalin Deviluke schrieb:
    --------------------------------------------------------------------------------
    > Es ist und bleibt für einen Login essentiell das über HTTPS zu machen.

    Vollkommen richtig, und zwar völlig unabhängig von dieser Thematik hier: Denn ohne HTTPS könnte der Angreifer einfach eine Login-Maske an den Benutzer schicken, die das Passwort im Klartext direkt zu ihm schickt. Denn HTTPS garantiert auch die Integrität der Webseite.

    Zurück zum Thema: Es gibt eine Authentifizierung, bei der das Passwort nicht im Klartext übertragen werden muss, und die gegen Replay-Attacken geschützt ist, und sie ist sogar im HTTP-Standard spezifiziert: Digest Authentication. Funktioniert leider nicht mit bcrypt, aber die Idee sollte man ja auf andere Hash-Funktionen übertragen können.

  10. Re: Weitere Anforderung: Sichere Authentifizierung

    Autor: Anonymer Nutzer 27.07.15 - 10:04

    RipClaw schrieb:
    --------------------------------------------------------------------------------
    > Bisher kenne ich nur ein Verfahren (SCRAM-SHA256) bei dem das Passwort als
    > sicherer Hash abgelegt werden kann und gleichzeitig das Passwort nicht im
    > Klartext übermittelt werden muss.

    Das stimmt nur bedingt. Der "StoredKey" steht in der Datenbank. Mit ihm alleine kann man nichts anfangen. Hört man jedoch eine erfolgreiche Authentifizierung mit, kann man den "ClientKey" berechnen, der vom Client für Authentifzierungen verwendet wird, ohne das Passwort des Benutzers im Klartext kennen zu müssen. Es ist insofern eine Verbesserung gegenüber anderen Verfahren, als dass zwei Probleme auftreten müssen, aber trotzdem nicht wirklich sicher. Das einzig wirklich sichere Verfahren für passwortbasierte Authentifizierung ist SRP. Es muss kein Passwort oder Passwort-Äquivalent in der Datenbank gespeichert werden. Während der Authentifizierung werden keine Daten übertragen, die zu einer unerlaubten Authentifizierung geeignet wären, selbst wenn die Authentifizierungsdaten der Datenbank bekannt sind. Die einzige Methode, diese Authentifzierung zu umgehen ist Brute Force auf das Passwort.

    Die Diskussion über sicherer Passwortverfahren ist aber mehr als müßig. Zum einen sind Passwörter meistens extrem schlecht gewählt. Zum zweiten verraten Benutzer ihre Passwörter sowieso gerne. Außerdem tippen viele Benutzer ihre Passwörter überall ein, wo sie nur können und machen sich keine Gedanken darüber, ob das Gerät nun sicher ist oder nicht. Zusätzlich bieten schon viele Hersteller von Mobiltelefonbetriebssystemen an, Passwörter zu synchronisieren. Damit werden diese dann so und so wieder im Klartext irgendwo gespeichert.

    Die sicherste Methode wäre, bei Webseiten (z.B. auch Webmails) zusätzlich Zwei-Faktor-Authentifzierung zu verwenden. Mittlerweile ist das recht leicht zu implementieren. Bei Clientanwendungen, wie z.B. einem E-Mail-Client wäre es sinnvoll, die Authentifizierung einmal zu erledigen und dann ein Schlüsselpaar zu erzeugen, das nur für diesen Client gültig ist und fortan zur Authentifzierung verwendet wird.

  11. Re: Weitere Anforderung: Sichere Authentifizierung

    Autor: RipClaw 27.07.15 - 10:25

    Schläfer schrieb:
    --------------------------------------------------------------------------------
    > Ansonsten wird aber das Passwort im Klartext abgefangen, dass ist doch noch
    > schlechter. Wenn man vor dem Übertragen hasht hat wenigstens keiner das
    > Passwort, auch wenn er sich trotzdem noch einloggen kann. Und wird nochmal
    > nach dem Übertragen der Hash gebildet (wie gewöhnlich), hat man auch kein
    > Problem, wenn die Datenbank erbeutet wird.
    > Wäre vielleicht auch nicht verkehrt bei HTTPS nur einen Hash zu übertragen,
    > damit der Server nicht das Passwort im Klartext bekommt.

    Nur müsste der Server dem Client dann auch mitteilen welchen Hash er schicken soll. Es gibt immerhin mehr als ein Verfahren.

    Zudem sind ungesalzene Hashes über Rainbowtables relativ einfach zu brechen.

  12. Re: Weitere Anforderung: Sichere Authentifizierung

    Autor: theonlyone 27.07.15 - 10:31

    bjs schrieb:
    --------------------------------------------------------------------------------
    > Die sicherste Methode wäre, bei Webseiten (z.B. auch Webmails) zusätzlich
    > Zwei-Faktor-Authentifzierung zu verwenden. Mittlerweile ist das recht
    > leicht zu implementieren. Bei Clientanwendungen, wie z.B. einem
    > E-Mail-Client wäre es sinnvoll, die Authentifizierung einmal zu erledigen
    > und dann ein Schlüsselpaar zu erzeugen, das nur für diesen Client gültig
    > ist und fortan zur Authentifzierung verwendet wird.

    Das Anmelden mit SMS Code (oder sonstige Authentifikator) ist ja schon ziemlich verbreitet.

    Macht gerade bei Email Services Sinn, erst recht wenn dieses Email Konto praktisch als Anlaufpunkt für sonstige Passwörter gilt. Gibt ja Leute die speichern ihre Passwörter einfach direkt im Email Konto ab (als Mail an sich selbst etc. pp.).

    Das funktioniert auch sehr gut und ist für solche Services eine ziemlich gute Lösung.

  13. Re: Weitere Anforderung: Sichere Authentifizierung

    Autor: rngcntr 27.07.15 - 10:38

    Wo liegt denn zum Beispiel das Problem wenn zur Authentifizierung der Server dem Client einen zufälligen String schickt und dann der Client diesen zusammen mit seinem PW-Hash nochmal hasht und das Ergebnis an den Server zurück schickt? Diese Lösung stellt nicht den Anspruch perfekt zu sein aber sollte doch zumindest bei unsicherem Übertragungskanal nicht trivial zu attackieren sein, da ein Angreifer keinerlei Möglichkeit hat mit den übertragenen Daten etwas über das Passwort herauszufinden beziehungsweise sich danach selbst beim Server einloggen zu können.

  14. Re: Weitere Anforderung: Sichere Authentifizierung

    Autor: Anonymer Nutzer 27.07.15 - 10:41

    rngcntr schrieb:
    --------------------------------------------------------------------------------
    > Wo liegt denn zum Beispiel das Problem wenn zur Authentifizierung der
    > Server dem Client einen zufälligen String schickt und dann der Client
    > diesen zusammen mit seinem PW-Hash nochmal hasht und das Ergebnis an den
    > Server zurück schickt? Diese Lösung stellt nicht den Anspruch perfekt zu
    > sein aber sollte doch zumindest bei unsicherem Übertragungskanal nicht
    > trivial zu attackieren sein, da ein Angreifer keinerlei Möglichkeit hat mit
    > den übertragenen Daten etwas über das Passwort herauszufinden
    > beziehungsweise sich danach selbst beim Server einloggen zu können.
    Das Problem ist, dass das Passwort bzw. ein Äquivalent des Passwortes am Server im Klartext gespeichert werden muss.

  15. Re: Weitere Anforderung: Sichere Authentifizierung

    Autor: rngcntr 27.07.15 - 11:10

    bjs schrieb:
    --------------------------------------------------------------------------------
    > Das Problem ist, dass das Passwort bzw. ein Äquivalent des Passwortes am
    > Server im Klartext gespeichert werden muss.

    Aber wozu? Der Server braucht doch nicht mehr als den Hash des Passworts. Meinst du das mit einem Äquivalent?

  16. Re: Weitere Anforderung: Sichere Authentifizierung

    Autor: robinx999 27.07.15 - 11:22

    Macht natürlich sinn und gibt es teilweise ja auch wenn man Passwort + Domain hashed. So kann sich ein Angreifer zwar auf der Seite einloggen kann es aber nicht ohne Großen aufwand bei anderen Seiten verwenden. So etwas gibt es aber auch schon länger z.B.: http://crypto.stanford.edu/PwdHash/

  17. Re: Weitere Anforderung: Sichere Authentifizierung

    Autor: Marc2 27.07.15 - 11:55

    aber ein serverdatendieb macht den wörterbuchangriff bei srp doch in der gleichen zeit wie üblich, oder?

  18. Re: Weitere Anforderung: Sichere Authentifizierung

    Autor: minecrawlerx 27.07.15 - 12:37

    Klar, es ist nicht neu. Und es ist eigentlich kein echter Mehraufwand, zumal man die Funktion zum Hashen ein Mal schreibt und dann überall wiederverwertet. Trotzdem wird auf den aller aller meisten Seiten einfach das Plain Passwort übertragen.
    Ich kenne sogar Seiten, die dir dein Plain Passwort danach nochmal per Mail schicken, nicht, dass man es vergisst. Eigentlich sehr traurig...

  19. Re: Weitere Anforderung: Sichere Authentifizierung

    Autor: rngcntr 27.07.15 - 13:21

    minecrawlerx schrieb:
    --------------------------------------------------------------------------------
    > Klar, es ist nicht neu. Und es ist eigentlich kein echter Mehraufwand,
    > zumal man die Funktion zum Hashen ein Mal schreibt und dann überall
    > wiederverwertet. Trotzdem wird auf den aller aller meisten Seiten einfach
    > das Plain Passwort übertragen.
    > Ich kenne sogar Seiten, die dir dein Plain Passwort danach nochmal per Mail
    > schicken, nicht, dass man es vergisst. Eigentlich sehr traurig...
    Ich hab mir kürzlich vorgenommen, dass jede dieser Seiten die mir das Passwort per Mail schickt sofort eine E-Mail mit einer Beschwerde zurück bekommt.

  20. Challenge-Response

    Autor: minnime 27.07.15 - 13:45

    Das Zauberwort heißt Challenge-Response. Das Verfahren wurde von einigen bereits angesprochen. Der Server speichert einen (ggf. gesalteten) Passworthash in der Datenbank. Bei der Authentifizierung schickt der Server einen Zufallswert (Challenge) und ggf. den Salt an den Client, der Client erzeugt aus dem Passwort und dem Salt den Passworthash, so wie er auch in der Serverdatenbank liegt. Daraus wird mit der Challenge noch ein Hash (Response) erzeugt und an den Server geschickt. Der Server muss ebenfalls den Passworthash in der Datenbank mit der Challenge verquicken und das Ergebnis mit der erhaltenen Response vergleichen.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. ruhlamat GmbH, Marksuhl
  2. PIA Automation Holding GmbH, Bad Neustadt an der Saale, Amberg
  3. VDE Verband der Elektrotechnik Elektronik Informationstechnik e. V., Frankfurt am Main
  4. Techniker Krankenkasse, Hamburg

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 4,99€
  2. 2,19€
  3. 1,72€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Ryzen 3900X/3700X im Test: AMDs 7-nm-CPUs lassen Intel hinter sich
Ryzen 3900X/3700X im Test
AMDs 7-nm-CPUs lassen Intel hinter sich

Das beste Prozessor-Design seit dem Athlon 64: Mit den Ryzen 3000 alias Matisse bringt AMD sehr leistungsstarke und Energie-effiziente CPUs zu niedrigen Preisen in den Handel. Obendrein laufen die auch auf zwei Jahre alten sowie günstigen Platinen mit schnellem DDR4-Speicher.
Ein Test von Marc Sauter

  1. Ryzen 3000 BIOS-Updates schalten PCIe Gen4 für ältere Boards frei
  2. Mehr Performance Windows 10 v1903 hat besseren Ryzen-Scheduler
  3. Picasso für Sockel AM4 AMD verlötet Ryzen 3400G für flottere iGPU

Forschung: Mehr Elektronen sollen Photovoltaik effizienter machen
Forschung
Mehr Elektronen sollen Photovoltaik effizienter machen

Zwei dünne Schichten auf einer Silizium-Solarzelle könnten ihre Effizienz erhöhen. Grünes und blaues Licht kann darin gleich zwei Elektronen statt nur eines freisetzen.
Von Frank Wunderlich-Pfeiffer

  1. ISS Tierbeobachtungssystem Icarus startet
  2. Sun To Liquid Solaranlage erzeugt Kerosin aus Sonnenlicht, Wasser und CO2
  3. Shell Ocean Discovery X Prize X-Prize für unbemannte Systeme zur Meereskartierung vergeben

LEDs: Schlimmes Flimmern
LEDs
Schlimmes Flimmern

LED-Licht zu Hause oder im Auto leuchtet nur selten völlig konstant. Je nach Frequenz und Intensität kann das Flimmern der Leuchtmittel problematisch sein, für manche Menschen sogar gesundheitsschädlich.
Von Wolfgang Messer

  1. Wissenschaft Schadet LED-Licht unseren Augen?
  2. Straßenbeleuchtung Detroit kämpft mit LED-Ausfällen und der Hersteller schweigt
  3. ULED Ubiquitis Netzwerkleuchten bieten Wechselstromversorgung

  1. Streaming: Netflix' Kundenwachstum geht zurück
    Streaming
    Netflix' Kundenwachstum geht zurück

    Netflix hat im zweiten Quartal die eigenen Erwartungen verfehlt. Auch der Gewinn fiel niedriger aus als im Vorjahresquartal.

  2. Coradia iLint: Alstoms Brennstoffzellenzüge bewähren sich
    Coradia iLint
    Alstoms Brennstoffzellenzüge bewähren sich

    Zwei Züge, 100.000 Kilometer, keine Probleme: Nach zehn Monaten regulärem Einsatz in Niedersachsen ist das französische Unternehmen Alstom zufrieden mit seinen Brennstoffzellenzügen.

  3. Matternet: Schweizer Post pausiert Drohnenlieferungen nach Absturz
    Matternet
    Schweizer Post pausiert Drohnenlieferungen nach Absturz

    Blutkonserven oder Gewebeproben müssen unter Umständen schnell zu ihrem Bestimmungsort gebracht werden. Die Schweizer Post setzt für solche Transporte Drohnen ein. Doch nach vielen problemlosen Flüge ist ein Copter abgestürzt. Das Drohnenprogramm wurde daraufhin vorerst gestoppt.


  1. 23:00

  2. 19:06

  3. 16:52

  4. 15:49

  5. 14:30

  6. 14:10

  7. 13:40

  8. 13:00