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. Schwarz Dienstleistung KG, Raum Neckarsulm
  2. DRÄXLMAIER Group, Vilsbiburg bei Landshut
  3. Continental AG, Regensburg
  4. ITEOS, Stuttgart

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. (reduzierte Überstände, Restposten & Co.)
  2. täglich neue Deals bei Alternate.de


Haben wir etwas übersehen?

E-Mail an news@golem.de


Generationenübergreifend arbeiten: Bloß nicht streiten
Generationenübergreifend arbeiten
Bloß nicht streiten

Passen Generation Silberlocke und Generation Social Media in ein IT-Team? Ganz klar: ja! Wenn sie ihr Wissen teilen, kommt am Ende sogar Besseres heraus. Entscheidend ist die gleiche Wertschätzung beider Altersgruppen und keine Konflikte in den altersgemischten Teams.
Von Peter Ilg

  1. Frauen in der Technik Von wegen keine Vorbilder!
  2. Arbeit Warum anderswo mehr Frauen IT-Berufe ergreifen
  3. Arbeit Was IT-Recruiting von der Bundesliga lernen kann

Login-Dienste: Wer von der Klarnamenpflicht profitieren könnte
Login-Dienste
Wer von der Klarnamenpflicht profitieren könnte

Immer wieder bringen Politiker einen Klarnamenzwang oder eine Identifizierungspflicht für Nutzer im Internet ins Spiel. Doch welche Anbieter könnten von dieser Pflicht am ehesten einen Vorteil erzielen?
Eine Analyse von Friedhelm Greis

  1. Europäische Netzpolitik Die Rückkehr des Axel Voss
  2. Mitgliederentscheid Netzpolitikerin Esken wird SPD-Chefin
  3. Nach schwerer Krankheit FDP-Netzpolitiker Jimmy Schulz gestorben

Videostreaming: Was an Prime Video und Netflix nervt
Videostreaming
Was an Prime Video und Netflix nervt

Eine ständig anders sortierte Watchlist, ein automatisch startender Stream oder fehlende Markierungen für Aboinhalte: Oft sind es nur Kleinigkeiten, die den Spaß am Streaming vermiesen - eine Hassliste.
Ein IMHO von Ingo Pakalski

  1. Dispatch Open-Source-Krisenmanagement à la Netflix
  2. Videostreaming Netflix integriert Top-10-Listen für Filme und TV-Serien
  3. WhatsOnFlix Smartphone-App für bessere Verwaltung der Netflix-Inhalte

  1. Raumfahrt: Satelliten docken im Orbit zum Tanken an
    Raumfahrt
    Satelliten docken im Orbit zum Tanken an

    Das US-Rüstungs- und Raumfahrtunternehmen Northrop Grumman hat einen Versorgungssatelliten ins All geschossen und an einen Kommunikationssatelliten angedockt, dem der Treibstoff ausgeht. Er soll Treibstoff für fünf weitere Jahre im Einsatz bekommen.

  2. Geeks der Sterne: Wenn Star-Wars-Nerds sich streiten
    Geeks der Sterne
    Wenn Star-Wars-Nerds sich streiten

    Die jüngste Star-Wars-Trilogie ist mit Der Aufstieg Skywalkers abgeschlossen, auch die Serie The Mandalorian ist durch. Höchste Zeit für die zwei Star-Wars-Beauftragten von Golem.de, sich beim Mittagessen über Baby Yoda, langweilige Prequels und "das wahre Star Wars" zu streiten.

  3. WLAN: Telekom bringt Mesh-Router-Vermietung mit Vor-Ort-Service
    WLAN
    Telekom bringt Mesh-Router-Vermietung mit Vor-Ort-Service

    Drei neue Abonnements bietet die Deutsche Telekom mittlerweile an: Kunden können ein oder zwei Mesh-Knoten zu monatlichen Preisen mieten. Im WLAN-Paket S, M und L sind zudem technische Beratung, eine mobile App und ein 90-Tage-Rückgaberecht enthalten, genauso wie ein Vor-Ort-Service.


  1. 12:28

  2. 12:01

  3. 11:52

  4. 11:46

  5. 11:39

  6. 11:24

  7. 11:10

  8. 10:59