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. Schaeffler Technologies AG & Co. KG, Nürnberg
  2. Schwarz Dienstleistung KG, Raum Neckarsulm
  3. Blume 2000 new media ag, Hamburg
  4. WEGMANN automotive GmbH, Veitshöchheim bei Würzburg

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. täglich neue Deals bei Alternate.de
  2. (u. a. Roccat Kain 122 Aimo für 53,99€, Roccat Kain 200 Aimo für 74,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

Geforce Now im Test: Nvidia nutzt einzigartige CPU und GPU
Geforce Now im Test
Nvidia nutzt einzigartige CPU und GPU

Wer mit Nvidias Geforce Now spielt, bekommt laut Performance Overlay eine RTX 2060c oder RTX 2080c, tatsächlich aber werden eine Tesla RTX T10 als Grafikkarte und ein Intel CC150 als Prozessor verwendet. Die Performance ist auf die jeweiligen Spiele abgestimmt, vor allem mit Raytracing.
Ein Test von Marc Sauter

  1. Cloud Gaming Activision Blizzard zieht Spiele von Geforce Now zurück
  2. Nvidia-Spiele-Streaming Geforce Now kostet 5,49 Euro pro Monat
  3. Geforce Now Nvidias Cloud-Gaming-Dienst kommt noch 2019 für Android

Mythic Quest: Spielentwickler im Schniedelstress
Mythic Quest
Spielentwickler im Schniedelstress

Zweideutige Zweckentfremdung von Ingame-Extras, dazu Ärger mit Hackern und Onlinenazis: Die Apple-TV-Serie Mythic Quest bietet einen interessanten, allerdings nur stellenweise humorvollen Einblick in die Spielebrache.
Eine Rezension von Peter Steinlechner

  1. Apple TV TVOS 13 mit Mehrbenutzer-Option erschienen

  1. Halbleiterfertigung: Samsung verdreifacht EUV-Kapazität
    Halbleiterfertigung
    Samsung verdreifacht EUV-Kapazität

    Die Fab V1 im südkoreanischen Hwaseong ist fertig: Samsung Foundry nimmt dort die Produktion von Chips mit 7-nm-EUV-Technik und feiner auf, bis Ende 2020 soll die dreifache Fertigungskapazität verfügbar sein.

  2. Agon AG353UCG: AOC baut 200-Hz-Monitor im Kinoformat und mit HDR1000
    Agon AG353UCG
    AOC baut 200-Hz-Monitor im Kinoformat und mit HDR1000

    Der Gaming-Monitor AOC Agon AG353UCG ist zumindest auf dem Papier gut ausgestattet: Er hat ein 200-Hz-Panel, unterstützt HDR mit 1.000 cd/m² und kommt im gestreckten 21:9-Format. Das alles ist aber nicht ganz preiswert.

  3. Entwicklertagung: Sony und Facebook sagen Teilnahme an GDC 2020 ab
    Entwicklertagung
    Sony und Facebook sagen Teilnahme an GDC 2020 ab

    GDC 2020 Mit Neuigkeiten zur Playstation 5 ist auf der Entwicklerkonferenz GDC 2020 nicht zu rechnen: Sony hat wegen des Coronavirus ebenso wie Facebook mit seiner Tochter Oculus abgesagt.


  1. 11:55

  2. 11:40

  3. 11:12

  4. 10:25

  5. 09:30

  6. 09:16

  7. 08:55

  8. 07:54