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. Burger King Deutschland GmbH, Hannover
  2. über duerenhoff GmbH, Nürnberg
  3. Stadtverwaltung Eisenach, Eisenach
  4. DRÄXLMAIER Group, Vilsbiburg bei Landshut

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. (-79%) 21,00€
  2. 12,49€
  3. 3,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Nitropad im Test: Ein sicherer Laptop, der im Alltag kaum nervt
Nitropad im Test
Ein sicherer Laptop, der im Alltag kaum nervt

Das Nitropad schützt vor Bios-Rootkits oder Evil-Maid-Angriffen. Dazu setzt es auf die freie Firmware Coreboot, die mit einem Nitrokey überprüft wird. Das ist im Alltag erstaunlich einfach, nur Updates werden etwas aufwendiger.
Ein Praxistest von Moritz Tremmel und Sebastian Grüner

  1. Nitropad X230 Nitrokey veröffentlicht abgesicherten Laptop
  2. LVFS Coreboot-Updates sollen nutzerfreundlich werden
  3. Linux-Laptop System 76 verkauft zwei Laptops mit Coreboot

Alphakanal: Gimp verrät Geheimnisse in Bildern
Alphakanal
Gimp verrät Geheimnisse in Bildern

Wer in Gimp in einem Bild mit Transparenz Bildbereiche löscht, der macht sie nur durchsichtig. Dieses wenig intuitive Verhalten kann dazu führen, dass Nutzer ungewollt Geheimnisse preisgeben.


    Unitymedia: Upgrade beim Kabelstandard, Downgrade bei Fritz OS
    Unitymedia
    Upgrade beim Kabelstandard, Downgrade bei Fritz OS

    Der Kabelnetzbetreiber Unitymedia stellt sein Netz derzeit auf Docsis 3.1 um. Für Kunden kann das viel Arbeit beim Austausch ihrer Fritzbox bedeuten, wie ein Fallbeispiel zeigt.
    Von Günther Born

    1. Hessen Vodafone bietet 1 GBit/s in 70 Städten und kleineren Orten
    2. Technetix Docsis 4.0 mit 10G im Kabelnetz wird Wirklichkeit
    3. Docsis 3.1 Magenta Telekom bringt Gigabit im Kabelnetz

    1. Elenion Technologies: Nokia übernimmt US-Experten für Siliziumphotonik
      Elenion Technologies
      Nokia übernimmt US-Experten für Siliziumphotonik

      Nokia kauft ein New Yorker Unternehmen, das im Bereich Siliziumphotonik aktiv ist. Die Produkte sind für 5G-, Cloud- und Rechenzentrumsnetzwerke einsetzbar, es geht um die tiefere Integration bei der Umwandlung von Licht zu elektrischen Signalen.

    2. Spielestreaming: Google Stadia funktioniert auch mit Smartphones von Samsung
      Spielestreaming
      Google Stadia funktioniert auch mit Smartphones von Samsung

      Der Spielestreamingdienst Stadia von Google unterstützt künftig auch einige Smartphones von Razer und Asus, vor allem aber viele neuere Geräte von Samsung - inklusive der gerade erst vorgestellten Galaxy-S20-Reihe.

    3. EU-Kommission: Zehn Datenräume für die digitale Zukunft Europas
      EU-Kommission
      Zehn Datenräume für die digitale Zukunft Europas

      Die EU-Kommission unter Ursula von der Leyen will mit einer neuen Digitalstrategie europäische Daten besser nutzbar machen. Wie die vollmundigen Ankündigungen konkret umgesetzt werden, ist aber noch offen.


    1. 19:08

    2. 17:21

    3. 16:54

    4. 16:07

    5. 15:43

    6. 15:23

    7. 15:00

    8. 14:45