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. CodeCamp:N GmbH, Nürnberg
  2. Dataport, Altenholz bei Kiel
  3. Interhyp Gruppe, München
  4. ilum:e informatik ag, Mainz

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 149,90€ (Bestpreis!)
  2. (u. a. HP 34f Curved Monitor für 389,00€, Acer 32 Zoll Curved Monitor für 222,00€, Seasonic...
  3. (u. a. Star Wars Battlefront 2 für 9,49€, PSN Card 20 Euro für 18,99€)
  4. 769,00€


Haben wir etwas übersehen?

E-Mail an news@golem.de


iPad 7 im Test: Nicht nur für Einsteiger lohnenswert
iPad 7 im Test
Nicht nur für Einsteiger lohnenswert

Auch mit der siebten Version des klassischen iPads richtet sich Apple wieder an Nutzer im Einsteigersegment. Dennoch ist das Tablet sehr leistungsfähig und kommt mit Smart-Keyboard-Unterstützung. Wer ein gutes, lange unterstütztes Tablet sucht, kann sich freuen - ärgerlich sind die Preise fürs Zubehör.
Ein Test von Tobias Költzsch

  1. iPad Einschränkungen für Apples Sidecar-Funktion
  2. Apple Microsoft Office auf neuem iPad nicht mehr kostenlos nutzbar
  3. Tablet Apple bringt die 7. Generation des iPads

Rohstoffe: Lithium aus dem heißen Untergrund
Rohstoffe
Lithium aus dem heißen Untergrund

Liefern Geothermiekraftwerke in Südwestdeutschland bald nicht nur Strom und Wärme, sondern auch einen wichtigen Rohstoff für die Akkus von Smartphones, Tablets und Elektroautos? Das Thermalwasser hat einen so hohen Gehalt an Lithium, dass sich ein Abbau lohnen könnte. Doch es gibt auch Gegner.
Ein Bericht von Werner Pluta

  1. Wasserkraft Strom aus dem Strom
  2. Energie Wie Mikroben Methan mit Windstrom produzieren
  3. Erneuerbare Energien Die Energiewende braucht Wasserstoff

SSD-Kompendium: AHCI, M.2, NVMe, PCIe, Sata, U.2 - ein Überblick
SSD-Kompendium
AHCI, M.2, NVMe, PCIe, Sata, U.2 - ein Überblick

Heutige SSDs gibt es in allerhand Formfaktoren mit diversen Anbindungen und Protokollen, selbst der verwendete Speicher ist längst nicht mehr zwingend NAND-Flash. Wir erläutern die Unterschiede und Gemeinsamkeiten der Solid State Drives.
Von Marc Sauter

  1. PM1733 Samsungs PCIe-Gen4-SSD macht die 8 GByte/s voll
  2. PS5018-E18 Phisons PCIe-Gen4-SSD-Controller liefert 7 GByte/s
  3. Ultrastar SN640 Western Digital bringt SSD mit 31 TByte im E1.L-Ruler-Format

  1. Corsair One: Wakü-Rechner erhalten mehr RAM- und SSD-Kapazität
    Corsair One
    Wakü-Rechner erhalten mehr RAM- und SSD-Kapazität

    Mit dem i182, dem i164 und dem i145 aktualisiert Corsair die One-Serie: Die wassergekühlten Komplett-PCs werden mit doppelt so viel DDR4-Speicher und doppelt so großen SSDs ausgerüstet.

  2. ChromeOS: Google zeigt neues Pixelbook Go und benennt Start von Stadia
    ChromeOS
    Google zeigt neues Pixelbook Go und benennt Start von Stadia

    Das Pixelbook Go ist ein Clamshell-Notebook mit ChromeOS, das eher eine Ergänzung als ein Nachfolger des Ur-Pixelbooks ist. Zumindest kostet es wesentlich weniger. Auch der genaue Starttermin für Stadia steht jetzt fest.

  3. Multiplayer: Microsoft stellt Textfilter für Xbox One vor
    Multiplayer
    Microsoft stellt Textfilter für Xbox One vor

    Vielen potenziellen Onlinespielern ist der Umgangston in den Chats zu rau, dafür stellt Microsoft einen Lösungsansatz vor: Spieler auf der Xbox One sowie auf den Apps für Windows 10 und mobilen Plattformen können Texte künftig filtern lassen.


  1. 17:30

  2. 17:20

  3. 17:12

  4. 17:00

  5. 17:00

  6. 17:00

  7. 16:11

  8. 15:03