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. AOK Niedersachsen, Hannover
  2. idw -Informationsdienst Wissenschaft, Bayreuth, Bochum, Clausthal
  3. Statistisches Bundesamt, Wiesbaden
  4. Hochschule Furtwangen, Furtwangen

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. (u. a. Samsung 860 QVO 1 TB für 99,90€, Samsung 860 QVO 2 TB für 199,99€, Samsung Protable...
  2. (reduzierte Überstände, Restposten & Co.)
  3. täglich neue Deals bei Alternate.de


Haben wir etwas übersehen?

E-Mail an news@golem.de


Coronakrise: Hardware-Industrie auf dem Weg der Besserung
Coronakrise
Hardware-Industrie auf dem Weg der Besserung

Fast alle Fabriken für Hardware laufen wieder - trotz verlängertem Chinese New Year. Bei Launches und Lieferengpässen sieht es anders aus.
Ein Bericht von Marc Sauter

  1. Kaufberatung (2020) Die richtige CPU und Grafikkarte
  2. SSDs Intel arbeitet an 144-Schicht-Speicher und 5-Bit-Zellen

Asus Zephyrus G14 im Test: Ryzen-Renoir-Revolution!
Asus Zephyrus G14 im Test
Ryzen-Renoir-Revolution!

Dank acht CPU-Kernen bei nur 35 Watt schlägt Asus' Ryzen-basiertes 14-Zoll-Spiele-Notebook jegliche Konkurrenz.
Ein Test von Marc Sauter

  1. Intel MKL Matlab R2020a läuft auf Ryzen drastisch schneller
  2. DFI GHF51 Ryzen-Platine ist so klein wie Raspberry Pi
  3. Ryzen Mobile 4000 Das kann AMDs Renoir

Star Trek - Der Film: Immer Ärger mit Roddenberry
Star Trek - Der Film
Immer Ärger mit Roddenberry

Verworfene Drehbücher, unzufriedene Paramount-Chefs und ein zögerlicher Spock: Dass der erste Star-Trek-Film vor 40 Jahren schließlich doch in die Kinos kam, grenzt an ein Wunder. Dass er schön aussieht, noch mehr.
Von Peter Osteried

  1. Machine Learning Fan überarbeitet Star Trek Voyager in 4K
  2. Star Trek - Picard Hasenpizza mit Jean-Luc
  3. Star Trek Voyager Starke Frauen und schwache Gegner