1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Passwort-Richtlinien…

Viel wichtiger ist...

  1. Thema

Neues Thema Ansicht wechseln


  1. Viel wichtiger ist...

    Autor: maverick1977 08.04.19 - 12:22

    dass man Bruteforce-Attacken durch Account-Sperrungen verhindert.
    10 falsche Eingaben, Account für 10 Minuten deaktiviert. Somit reduziert man den Erfolg von Bruteforce schon mal ganz gehörig. Und letzten Endes, wenn man Regeln für Passwörter heraus gibt, wird eines direkt deutlich. Das Passwort wird im Klartext analysiert. Und das geht meiner Meinung nach überhaupt nicht. Die Länge des Passwortes kann man auf Client-Seite ermitteln und ne Warnung ausgeben, wenns zu kurz ist. Aber sobald das Passwort auf nem Server landet, hat die Variable gesalzen und gehasht zu werden! Da gibt es überhaupt keine Diskussion.

  2. Re: Viel wichtiger ist...

    Autor: RicoBrassers 08.04.19 - 12:28

    maverick1977 schrieb:
    --------------------------------------------------------------------------------
    > Aber sobald das auf nem Server landet, hat die Variable gesalzen und gehasht zu
    > werden! Da gibt es überhaupt keine Diskussion.

    So sieht es aus!

  3. Re: Viel wichtiger ist...

    Autor: LH 08.04.19 - 12:48

    maverick1977 schrieb:
    --------------------------------------------------------------------------------
    > dass man Bruteforce-Attacken durch Account-Sperrungen verhindert.
    > 10 falsche Eingaben, Account für 10 Minuten deaktiviert.

    Das ist ein Ansatz, der sehr schnell zu Problemen führt. Hat man z.B. einen gekündigten Mitarbeiter, der dass weiß, sperrt er einfach mal alle Kundenkonten mit dieser Methode. Da ist dann schnell die Grenze dieser Methode erreicht.
    Das ist gar nicht so selten, daher werden üblicherweise auch nicht die Konten gesperrt (außer in Ausnahmesituationen), sondern die "Angreifer" werden für das Konto gesperrt.

  4. Re: Viel wichtiger ist...

    Autor: KOTRET 08.04.19 - 13:03

    maverick1977 schrieb:
    --------------------------------------------------------------------------------
    > sobald das Passwort auf nem Server landet, hat die Variable gesalzen und gehasht zu
    > werden! Da gibt es überhaupt keine Diskussion.
    Willst du das Passwort jetzt schon clientseitig hashen oder wie soll das aussehen? Per Request kommt es ja ungesalzen und ungehashed rüber.

  5. Re: Viel wichtiger ist...

    Autor: torrbox 08.04.19 - 13:13

    LH schrieb:
    --------------------------------------------------------------------------------
    > maverick1977 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > dass man Bruteforce-Attacken durch Account-Sperrungen verhindert.
    > > 10 falsche Eingaben, Account für 10 Minuten deaktiviert.
    >
    > Das ist ein Ansatz, der sehr schnell zu Problemen führt. Hat man z.B. einen
    > gekündigten Mitarbeiter, der dass weiß, sperrt er einfach mal alle
    > Kundenkonten mit dieser Methode. Da ist dann schnell die Grenze dieser
    > Methode erreicht.
    > Das ist gar nicht so selten, daher werden üblicherweise auch nicht die
    > Konten gesperrt (außer in Ausnahmesituationen), sondern die "Angreifer"
    > werden für das Konto gesperrt.

    Dann melden sich ausgesperrte Nutzer halt mit Emaillink an.

  6. Re: Viel wichtiger ist...

    Autor: Schrödinger's Katze 08.04.19 - 13:16

    torrbox schrieb:
    --------------------------------------------------------------------------------
    > Dann melden sich ausgesperrte Nutzer halt mit Emaillink an.

    Aber wie, wenn jetzt mein E-Mail-Account gesperrt ist?

  7. Re: Viel wichtiger ist...

    Autor: dabbes 08.04.19 - 13:18

    IP basiertes Sperren reicht schon.
    Die wenigsten werden BF-Attacken über 1000 Server laufen lassen, für ein lumpiges E-Mail-Konto.


    Alternativ könnte man auch einen 2-Faktor anfordern, den man z. B. per Authenticator oder SMS eingeben muss.

  8. Re: Viel wichtiger ist...

    Autor: torrbox 08.04.19 - 13:20

    Schrödinger's Katze schrieb:
    --------------------------------------------------------------------------------
    > torrbox schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Dann melden sich ausgesperrte Nutzer halt mit Emaillink an.
    >
    > Aber wie, wenn jetzt mein E-Mail-Account gesperrt ist?


    Da sind Beschränkungen nutzlos, weil IMAP/POP3 nicht abgesichert werden können. Dafür kann man aber den Loginnamen anders als den Sendernamen machen und schon ist es unmöglich, den Account zu bruteforcen.



    1 mal bearbeitet, zuletzt am 08.04.19 13:21 durch torrbox.

  9. Re: Viel wichtiger ist...

    Autor: senf.dazu 08.04.19 - 13:23

    KOTRET schrieb:
    --------------------------------------------------------------------------------
    > maverick1977 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > sobald das Passwort auf nem Server landet, hat die Variable gesalzen und
    > gehasht zu
    > > werden! Da gibt es überhaupt keine Diskussion.
    > Willst du das Passwort jetzt schon clientseitig hashen oder wie soll das
    > aussehen? Per Request kommt es ja ungesalzen und ungehashed rüber.

    warum eigentlich nicht - wenn bereits ein verschlüsseltes Paßwort über die Strippe geht (und der Server idealerweise den key zum entschlüsseln gar nicht kennt) können auch keine Klartextpaßwörter in falsche Hände geraten .. und vielleicht sind die (verschlüsselten) Paßworte dann sogar automatisch supertoll ..

    Aber ich will ja eigentlich gar keine schlafenden Hunde wecken - ich bin ja eher dafür die Paßworte endlich auf den Müll zu schmeißen und durch Hardwareschlüsselbasierte Dinge wie WebAuth zu ersetzen ..



    2 mal bearbeitet, zuletzt am 08.04.19 13:27 durch senf.dazu.

  10. Re: Viel wichtiger ist...

    Autor: Stebs 08.04.19 - 13:25

    maverick1977 schrieb:
    --------------------------------------------------------------------------------
    > dass man Bruteforce-Attacken durch Account-Sperrungen verhindert.
    > 10 falsche Eingaben, Account für 10 Minuten deaktiviert. Somit reduziert
    > man den Erfolg von Bruteforce schon mal ganz gehörig
    So funktioniert Bruteforce aber nicht, du beschreibst lediglich einen Endanwender der sich seines Passwortes nicht mehr sicher ist und nun verzweifelt ein paar ausprobiert.
    Bruteforce findet mit Hilfe der gestohlenen/gekauften Passwörter-Hashdatei statt, komplett unabhängig vom ursprünglichen Web-Server.

  11. Re: Viel wichtiger ist...

    Autor: torrbox 08.04.19 - 13:25

    senf.dazu schrieb:
    --------------------------------------------------------------------------------
    > KOTRET schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > maverick1977 schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > sobald das Passwort auf nem Server landet, hat die Variable gesalzen
    > und
    > > gehasht zu
    > > > werden! Da gibt es überhaupt keine Diskussion.
    > > Willst du das Passwort jetzt schon clientseitig hashen oder wie soll das
    > > aussehen? Per Request kommt es ja ungesalzen und ungehashed rüber.
    >
    > warum eigentlich nicht - wenn bereits ein verschlüsseltes Paßwort über die
    > Strippe geht (und der Server idealerweise den key zum entschlüsseln gar
    > nicht kennt) können auch keine Klartextpaßwörter in falsche Hände geraten
    > ..

    Wenn ein Angreifer deine Webseite modifizieren und damit Passwörter abgreifen kann, kann er auch das clientseitige Hashing manipulieren (sodass das Passwort im Klartext gesendet wird).



    1 mal bearbeitet, zuletzt am 08.04.19 13:26 durch torrbox.

  12. Re: Viel wichtiger ist...

    Autor: torrbox 08.04.19 - 13:28

    Stebs schrieb:
    --------------------------------------------------------------------------------
    > maverick1977 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > dass man Bruteforce-Attacken durch Account-Sperrungen verhindert.
    > > 10 falsche Eingaben, Account für 10 Minuten deaktiviert. Somit reduziert
    > > man den Erfolg von Bruteforce schon mal ganz gehörig
    > So funktioniert Bruteforce aber nicht, du beschreibst lediglich einen
    > Endanwender der sich seines Passwortes nicht mehr sicher ist und nun
    > verzweifelt ein paar ausprobiert.
    > Bruteforce findet mit Hilfe der gestohlenen/gekauften Passwörter-Hashdatei
    > statt, komplett unabhängig vom ursprünglichen Web-Server.

    Geklaute Daten sind nutzlos, da die Nutzer ihre Passwörter ändern müssen.

  13. Re: Viel wichtiger ist...

    Autor: Stebs 08.04.19 - 13:37

    torrbox schrieb:
    --------------------------------------------------------------------------------
    > Geklaute Daten sind nutzlos, da die Nutzer ihre Passwörter ändern müssen.
    Das gilt für den betroffenen Webserver nur ab dem Zeitpunkt, wo der Einbruch bemerkt, oder genauer, vom Webseitenbetreiber reagiert wird.

    Da die meisten Leute nur ein Passwort für alle/viele Dienste benutzen, sind die die Daten auch danach sehr wohl wertvoll. Nach Bruteforce hat man z.B. 70% gültige Email/Passwort Paare und kann die bei x-beliebigen Webdiensten ausprobieren.

  14. Re: Viel wichtiger ist...

    Autor: senf.dazu 09.04.19 - 13:43

    Was uns dazu bringt das der Server das cleintseitige "Hashing" nicht beeinflussen darf .. sprich der key dazu ist Eigentum des Clients. Und schon wären wir wieder beim Paßwortmanager (im Browser oder als extra Software) mit einem Paßwort für alles - oder eben gleich einem richtigen Hardware-Key mit ggf. sicherer Paßwort/Pin/Biometrie-Unlocking a la WebAuth. Kann auch durchaus gleich im Handy oder dem Rechner verbaut sein ..

  15. Re: Viel wichtiger ist...

    Autor: robinx999 12.04.19 - 13:25

    senf.dazu schrieb:
    --------------------------------------------------------------------------------
    > KOTRET schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > maverick1977 schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > sobald das Passwort auf nem Server landet, hat die Variable gesalzen
    > und
    > > gehasht zu
    > > > werden! Da gibt es überhaupt keine Diskussion.
    > > Willst du das Passwort jetzt schon clientseitig hashen oder wie soll das
    > > aussehen? Per Request kommt es ja ungesalzen und ungehashed rüber.
    >
    > warum eigentlich nicht - wenn bereits ein verschlüsseltes Paßwort über die
    > Strippe geht (und der Server idealerweise den key zum entschlüsseln gar
    > nicht kennt) können auch keine Klartextpaßwörter in falsche Hände geraten
    > .. und vielleicht sind die (verschlüsselten) Paßworte dann sogar
    > automatisch supertoll ..
    >
    Die Idee gab es so ja schon mal hat sich aber bei kaum jemandem durchgesetzt. Die sah im Prinzip so aus der Nutzer verwendet ein Passwort (hoffentlich ein sicheres) und verwendet dieses praktisch überall, der Browser bzw. ein passendes Addon hängt die Website hinten an dem Passwort an und hasht dieses dann mit irgendeinem Algorithmus

    Also Beispiel mein Passwort ist "Geheim" (ja nicht sicher ist aber nur ein Beispiel)
    Dann wird z.B.: mein Passwort so gebildet "Geheimgolem.de"
    Wenn ich das jetzt mit sha256 hashe ist das Passwort:
    37405f49ddcdbe775b23a5cd9fc8044becddb15cc3f823ea5c52875187efff16
    Benutze ich das Passwort jetzt auf amazon.de so wird es zu
    d50924dcbe6b21e1bfed07c6d60332447459386a11dfeee548b26dbd0a75c4fd

    echo -n Geheimgolem.de|sha256sum
    37405f49ddcdbe775b23a5cd9fc8044becddb15cc3f823ea5c52875187efff16 -

    echo -n Geheimamazon.de|sha256sum
    d50924dcbe6b21e1bfed07c6d60332447459386a11dfeee548b26dbd0a75c4fd -

    Wenn das System bekannt ist könnte man es natürlich zumindest bei schwachen Passwörtern immer noch Bruteforcen, bei guten Passwörtern wäre so ein System recht sicher nur muss man natürlich auch Mechanismen sinnvoll einbauen was genau genutzt wird (Insbesondere bei Subdomains und dem Nutzer Möglichkeiten geben Passwörter einzugeben wenn sich Domains ändern), wobei da dies extra geschehen muss würde es sogar gegen Phishing Angriffe helfen, da die Domain eine andere ist. Nur wirklich nutzen tut so etwas keiner und es erschwert natürlich auch mangels Passender Plugins die Nutzung von nicht Nutzer Browsern

  1. Thema

Neues Thema Ansicht wechseln


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

Stellenmarkt
  1. Wirecard Issuing Technologies GmbH, Aschheim/München
  2. ITERGO Informationstechnologie GmbH, Düsseldorf
  3. Berliner Verkehrsbetriebe (BVG), Berlin
  4. Hays AG, Raum Hannover

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 555,55€ (zzgl. Versandkosten)


Haben wir etwas übersehen?

E-Mail an news@golem.de


HR-Analytics: Weshalb Mitarbeiter kündigen
HR-Analytics
Weshalb Mitarbeiter kündigen

HR-Analytics soll vorhersagbare und damit wertvollere Informationen liefern als reine Zahlen aus dem Controlling. Diese junge Disziplin im Personalwesen hat großes Potenzial, weil sie Personaler in die Lage versetzt, zu agieren, statt zu reagieren.
Ein Bericht von Peter Ilg

  1. Frauen in der IT Ist Logik von Natur aus Männersache?
  2. IT-Jobs Gibt es den Fachkräftemangel wirklich?
  3. Arbeit im Amt Wichtig ist ein Talent zum Zeittotschlagen

Neuer Streamingdienst von Disney: Disney+ ist stark bei Filmen und schwach bei Serien
Neuer Streamingdienst von Disney
Disney+ ist stark bei Filmen und schwach bei Serien

Das Hollywoodstudio Disney ist in den Markt für Videostreamingabos eingestiegen. In den USA hat es beim Start von Disney+ technische Probleme gegeben. Mit Blick auf inhaltliche Vielfalt kann der Dienst weder mit Netflix noch mit Amazon Prime Video mithalten.
Von Ingo Pakalski

  1. Disney+ Disney korrigiert falsches Seitenverhältnis bei den Simpsons
  2. Videostreaming im Abo Disney+ hat 10 Millionen Abonnenten
  3. Disney+ Disney bringt seinen Streaming-Dienst auf Fire-TV-Geräte

Google Stadia im Test: Stadia ist (noch) kein Spiele-PC- oder Konsolenkiller
Google Stadia im Test
Stadia ist (noch) kein Spiele-PC- oder Konsolenkiller

Tschüss, Downloads, Datenträger und Installationsroutinen: Mit Google Stadia können wir einfach losspielen. Beim Test hat das unter Echtweltbedingungen schon ziemlich gut geklappt - trotz der teils enormen Datenmengen und vielen fehlenden Funktionen.
Von Peter Steinlechner

  1. Google Stadia Assassin's Creed Odyssey bis Samurai Showdown zum Start
  2. Nest Wifi Googles Mesh-Router priorisiert Stadia
  3. Spielestreaming Google stiftet Verwirrung über Start von Stadia

  1. Valve: Half-Life schickt Alyx in City 17
    Valve
    Half-Life schickt Alyx in City 17

    Zwischen dem ersten und dem zweiten Half-Life sind Spieler im Vollpreisspiel Half-Life Alyx als Widerstandskämpferin unterwegs - laut Valve mit jedem PC-basierten Virtual-Reality-Headset.

  2. Mobilfunk: Trump will Apple als Ausrüster für 5G in den USA
    Mobilfunk
    Trump will Apple als Ausrüster für 5G in den USA

    Apple soll laut US-Präsident Trump den nationalen Notstand für die Telekommunikation beenden und 5G-Ausrüster werden. Der iPhone-Hersteller hat darauf bisher nicht reagiert.

  3. Lime: E-Scooter-Anbieter stellt Kunden Bußgelder in Rechnung
    Lime
    E-Scooter-Anbieter stellt Kunden Bußgelder in Rechnung

    Mit dem E-Scooter bei Rot über die Ampel fahren kostet zwischen 60 und 180 Euro. Das und mehr müssen die Kunden von Lime künftig selbst bezahlen.


  1. 20:02

  2. 18:40

  3. 18:04

  4. 17:07

  5. 16:47

  6. 16:28

  7. 16:02

  8. 15:04