Discussion:
Sicherheit von Passwörtern
(zu alt für eine Antwort)
Louis Noser
2022-05-12 17:32:06 UTC
Permalink
Hallo

Weil wohl bei den meisten Login-Seiten bei drei oder vier Fehlversuchen
der Zugriff eine Zeit lang blockiert ist/sein sollte, sollten relativ
einfache Passwörter doch kein Problem sein.

Oder wo ist hier mein Denkfehler?

Hier
https://www.nzz.ch/technologie/was-ist-ein-gutes-passwort-zwei-tipps-fuer-mehr-sicherheit-ld.1682123?utm_source=pocket-newtab-global-de-DE

steht u.a.

"Die genaue Dauer hängt zwar davon ab, mit welchem Algorithmus das
Passwort verschlüsselt ist und mit wie viel Rechenleistung der Angreifer
anrückt."

1. Ist das unklar formuliert oder weshalb ist oder soll ein Passwort
verschlüsselt sein? (Gut, der Anbieter, auf den man zugreifen möchte,
muss das Passwort ja ablegen. Und das wird schlüsselt sein. Auf die
Verschlüsselungsstärke habe ich als Client aber keinen Einfluss. Und das
Thema des obigen Artikels ist die Sicherheit von Anwender-Passworten.)

2. Bei den meisten Login-Seiten wird der Zugriff wohl bei drei oder vier
Fehlversuchen eine Zeit lang verunmöglicht. Warum soll ein 6- oder
8-stelliges Passwort dann ein Problem sein? Um schlussendlich Zugriff
auf den gewünschten Web-Inhalt zu bekommen, bedarf es ja wohl
abermillionen Versuche, oder nicht? Und weil bei 3 Fehlversuchen Schluss
ist, sollten doch auch relativ einfache Passwörter kein Problem sein.

Vielen Dank.

Grüsse
Louis
Wendelin Uez
2022-05-12 18:05:28 UTC
Permalink
Post by Louis Noser
Weil wohl bei den meisten Login-Seiten bei drei oder vier Fehlversuchen
der Zugriff eine Zeit lang blockiert ist/sein sollte, sollten relativ
einfache Passwörter doch kein Problem sein.
Sie sind kein technisches Problem, falls gewollt können Passwörter auch
einstellig sein :-)

Bei sog. brute-force-Angriffen, bei denen Passwortkombinationen einfach
durchprobiert werden, sind die kurzen Kombinationen halt weit früher durcht
als längere, das ist das ganze Geheimnis. Deshalb bestehen die meisten
Formulare auf einer gewissen Mindestlänge. Welche das sein soll kann aber
jedes selber festlegen.

Ansonsten werden Passwörte nicht verschlüsselt, sondern "gehasht" - das
eingegebene Passwort wird zu einer Art Quersumme umgerechnet, und nur diese
"Quersumme" wird weitergereicht und gespeichert. Der gewissenhafte Betreiber
bekommt also das eigentliche Passwort gar nicht zu sehen, es reicht, wenn er
ein mathematisch errechnetes Abbild davon bekommt und dieses verarbeitet
bzw. prüft. Es muß nur sichergestellt sein, daß möglichst nicht mehrere
Passwörter ein- und dieselbe Abbildung ergeben - warum, das sieht man daran,
was wäre, wenn im Extremfall alle Passwörter dieselbe Abbildung ergeben
würden.
Louis Noser
2022-05-12 18:18:19 UTC
Permalink
Post by Wendelin Uez
Bei sog. brute-force-Angriffen, bei denen Passwortkombinationen einfach
durchprobiert werden, ...
Bei einer Login-Seite, die den Zugriff nach 4 Fehlversuchen für zB. 15
Minuten sperrt, ist das Durchprobieren aber doch sehr mühsam und vor
allem zeitraubend, also eher nicht zielführend. Oder ist das falsch?

Grüsse
Louis
Andreas Kohlbach
2022-05-12 18:31:59 UTC
Permalink
Post by Louis Noser
Post by Wendelin Uez
Bei sog. brute-force-Angriffen, bei denen Passwortkombinationen einfach
durchprobiert werden, ...
Bei einer Login-Seite, die den Zugriff nach 4 Fehlversuchen für zB. 15
Minuten sperrt, ist das Durchprobieren aber doch sehr mühsam und vor
allem zeitraubend, also eher nicht zielführend. Oder ist das falsch?
Wenn sich das automatisieren lässt, *und* man schwache Passwörter hat,
kann das für den Angreifer zum Erfolg führen.
--
Andreas
Juergen Ilse
2022-05-13 00:31:01 UTC
Permalink
Post by Louis Noser
Post by Wendelin Uez
Bei sog. brute-force-Angriffen, bei denen Passwortkombinationen einfach
durchprobiert werden, ...
Bei einer Login-Seite, die den Zugriff nach 4 Fehlversuchen für zB. 15
Minuten sperrt, ist das Durchprobieren aber doch sehr mühsam und vor
allem zeitraubend, also eher nicht zielführend. Oder ist das falsch?
Es besteht die Moeglichkeit, dass jemand durch irgend eine Sicherheitsluecke
an die gehaschten Passworte kommt (Download der Passwort Datei mit den ge-
hashten Passworte). In dem Fall ist die Programmierung der Passwort-Abfrage
der Webseite voellig wurcht, dass das Passwort "offline" gecracked wird.

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)
Wendelin Uez
2022-05-13 11:20:41 UTC
Permalink
Post by Louis Noser
Bei einer Login-Seite, die den Zugriff nach 4 Fehlversuchen für zB. 15
Minuten sperrt, ist das Durchprobieren aber doch sehr mühsam und vor allem
zeitraubend, also eher nicht zielführend. Oder ist das falsch?
Das Problem ist, daß eine Login-Seite von vielen anderen IP-Nummern
gleichzeitig aufgerufen werden kann, hinter denen alle derselbe Angreifer
stecen kannt. Wenn er also genügend Verbindungen aufbauen kann ist so eine
Zeitlimitierung relativ nutzlos, ide Loginseite kennt ja nur die IP-Nummer
als Unterscheidungsmerkmal der Anfragen.
Marcel Logen
2022-05-13 11:57:06 UTC
Permalink
Post by Wendelin Uez
Post by Louis Noser
Bei einer Login-Seite, die den Zugriff nach 4 Fehlversuchen für zB. 15
Minuten sperrt, ist das Durchprobieren aber doch sehr mühsam und vor
allem zeitraubend, also eher nicht zielführend. Oder ist das falsch?
Das Problem ist, daß eine Login-Seite von vielen anderen IP-Nummern
gleichzeitig aufgerufen werden kann, hinter denen alle derselbe
Angreifer stecen kannt. Wenn er also genügend Verbindungen aufbauen
kann ist so eine Zeitlimitierung relativ nutzlos, ide Loginseite kennt
ja nur die IP-Nummer als Unterscheidungsmerkmal der Anfragen.
Nein, auch den Benutzernamen.

Marcel gfr9 (540521)
--
╭─╮ ╭──────╮ ╭──╮ ╭──╮ ╭────╮ ╭─╮
╯ ╰───╮ ╰──╮ ╰─╯ ╰─╯ │ │ ╭─╯ ╭───╮ │ ╰────────
╭───╯ ╭─╮ ╰───╮ ╰──╯ ╰──╮ ╭──╯ ╰─╯
╰──────╯ ╰───────────────────╯ ╰─╯ 41fd49
Wendelin Uez
2022-05-13 15:04:45 UTC
Permalink
Post by Marcel Logen
Post by Wendelin Uez
Das Problem ist, daß eine Login-Seite von vielen anderen IP-Nummern
gleichzeitig aufgerufen werden kann, hinter denen alle derselbe Angreifer
stecen kannt. Wenn er also genügend Verbindungen aufbauen kann ist so eine
Zeitlimitierung relativ nutzlos, ide Loginseite kennt ja nur die IP-Nummer
als Unterscheidungsmerkmal der Anfragen.
Nein, auch den Benutzernamen.
Ja, das stimmt. Aber dann hätte der Server wesentlich mehr Aufwand, z.B.
sich alle Loginversuche mit Zeitstempel der letzten x Minuten zu merken, da
ist es eben einfacher, der Benutzer muß sich ein längeres Passwort merken.
Arno Welzel
2022-05-15 13:07:37 UTC
Permalink
Post by Wendelin Uez
Post by Marcel Logen
Post by Wendelin Uez
Das Problem ist, daß eine Login-Seite von vielen anderen IP-Nummern
gleichzeitig aufgerufen werden kann, hinter denen alle derselbe Angreifer
stecen kannt. Wenn er also genügend Verbindungen aufbauen kann ist so eine
Zeitlimitierung relativ nutzlos, ide Loginseite kennt ja nur die IP-Nummer
als Unterscheidungsmerkmal der Anfragen.
Nein, auch den Benutzernamen.
Ja, das stimmt. Aber dann hätte der Server wesentlich mehr Aufwand, z.B.
sich alle Loginversuche mit Zeitstempel der letzten x Minuten zu merken, da
ist es eben einfacher, der Benutzer muß sich ein längeres Passwort merken.
Nein, der Aufwand ist trivial. Es wird einfach beim Benutzerkonto X
vermerkt, wann der letzte fehlerhafte Login-Versuch war und wie häufig
Fehler aufgetreten sind. Ist die Zahl der fehlerhafte Login-Versuche
z.B. über 3 wird ein Login erst wieder erlaubt, wenn der letzte Versuch
länger als 15 Minuten her ist.
--
Arno Welzel
https://arnowelzel.de
Marc Stibane
2022-09-19 09:14:46 UTC
Permalink
Post by Arno Welzel
Post by Wendelin Uez
Post by Marcel Logen
Post by Wendelin Uez
Das Problem ist, daß eine Login-Seite von vielen anderen IP-Nummern
gleichzeitig aufgerufen werden kann, hinter denen alle derselbe
Angreifer stecen kannt. Wenn er also genügend Verbindungen aufbauen
kann ist so eine Zeitlimitierung relativ nutzlos, ide Loginseite
kennt ja nur die IP-Nummer als Unterscheidungsmerkmal der Anfragen.
Nein, auch den Benutzernamen.
Ja, das stimmt. Aber dann hätte der Server wesentlich mehr Aufwand,
z.B. sich alle Loginversuche mit Zeitstempel der letzten x Minuten zu
merken, da ist es eben einfacher, der Benutzer muß sich ein längeres
Passwort merken.
Nein, der Aufwand ist trivial. Es wird einfach beim Benutzerkonto X
vermerkt, wann der letzte fehlerhafte Login-Versuch war und wie häufig
Fehler aufgetreten sind. Ist die Zahl der fehlerhafte Login-Versuche
z.B. über 3 wird ein Login erst wieder erlaubt, wenn der letzte Versuch
länger als 15 Minuten her ist.
Prima. Der Angreifer macht also per Script alle 12 Minuten einen Login-
Versuch und der rechtmäßige User kommt nie wieder rein.
Da braucht man nicht mal mehr einen DDoS...
--
In a world without walls and fences,
who needs windows and gates?
Arno Welzel
2022-09-19 12:34:35 UTC
Permalink
Post by Marc Stibane
Post by Arno Welzel
Post by Wendelin Uez
Post by Marcel Logen
Post by Wendelin Uez
Das Problem ist, daß eine Login-Seite von vielen anderen IP-Nummern
gleichzeitig aufgerufen werden kann, hinter denen alle derselbe
Angreifer stecen kannt. Wenn er also genügend Verbindungen aufbauen
kann ist so eine Zeitlimitierung relativ nutzlos, ide Loginseite
kennt ja nur die IP-Nummer als Unterscheidungsmerkmal der Anfragen.
Nein, auch den Benutzernamen.
Ja, das stimmt. Aber dann hätte der Server wesentlich mehr Aufwand,
z.B. sich alle Loginversuche mit Zeitstempel der letzten x Minuten zu
merken, da ist es eben einfacher, der Benutzer muß sich ein längeres
Passwort merken.
Nein, der Aufwand ist trivial. Es wird einfach beim Benutzerkonto X
vermerkt, wann der letzte fehlerhafte Login-Versuch war und wie häufig
Fehler aufgetreten sind. Ist die Zahl der fehlerhafte Login-Versuche
z.B. über 3 wird ein Login erst wieder erlaubt, wenn der letzte Versuch
länger als 15 Minuten her ist.
Prima. Der Angreifer macht also per Script alle 12 Minuten einen Login-
Versuch und der rechtmäßige User kommt nie wieder rein.
Korrekt.
Post by Marc Stibane
Da braucht man nicht mal mehr einen DDoS...
Und was soll das dem Angreifer bringen? Der schafft so pro Tag nur 120
Versuche.

Alternativ kann man den Login noch mit einem 2. Faktor absichern.
--
Arno Welzel
https://arnowelzel.de
Marc Stibane
2022-09-22 06:21:53 UTC
Permalink
Post by Arno Welzel
Post by Marc Stibane
Post by Arno Welzel
Nein, der Aufwand ist trivial. Es wird einfach beim Benutzerkonto X
vermerkt, wann der letzte fehlerhafte Login-Versuch war und wie
häufig Fehler aufgetreten sind. Ist die Zahl der fehlerhafte
Login-Versuche z.B. über 3 wird ein Login erst wieder erlaubt, wenn
der letzte Versuch länger als 15 Minuten her ist.
Prima. Der Angreifer macht also per Script alle 12 Minuten einen
Login- Versuch und der rechtmäßige User kommt nie wieder rein.
Korrekt.
Und was soll das dem Angreifer bringen? Der schafft so pro Tag nur 120
Versuche.
Klar, der Angreifer kommt nicht rein. Der rechtmäßige User aber auch
nicht, solange der Angreifer das Script (oder cronjob) laufen lässt.
Dadurch wird der Nutzen des Accounts ggf. stark dezimiert.
Post by Arno Welzel
Alternativ kann man den Login noch mit einem 2. Faktor absichern.
Mit manueller Bestätigung (SMS/Push-Notification empfangen und one-time-
key eintippen) kann man auch den User bombardieren.
Gerade neulich war zu lesen, dass ein Mitarbeiter von Uber dutzende
solcher Bestätigungsanfragen bekommen hat obwohl er sich gar nicht
einloggen wollte, und dann hat ihn der Angreifer angerufen und sich als
Uber-HelpDesk ausgegeben und ihn veranlasst, einer Anfrage zuzustimmen.
Social engineering.

Was wirklich hilft, ist z.B. FIDO2, Passkeys, ...
--
In a world without walls and fences,
who needs windows and gates?
Andreas Borutta
2022-09-22 08:09:19 UTC
Permalink
Post by Marc Stibane
Was wirklich hilft, ist z.B. FIDO2, Passkeys, ...
Wie bewertet ihr das Verfahren in macOS Ventura (mit M1 Hardware)?

https://www.wired.co.uk/article/apple-passkeys-password-iphone-mac-ios16-ventura

Andreas
--
http://fahrradzukunft.de
Beate Goebel
2022-09-22 08:44:19 UTC
Permalink
Marc Stibane schrieb am 22 Sep 2022
Post by Marc Stibane
Was wirklich hilft, ist z.B. FIDO2, Passkeys, ...
Vor allem die gerade gehackten Versionen davon...

Beate
--
„Ich finde es schräg, wenn Menschen mit fünfstelligem Monatseinkommen
anderen erklären, wie man spart“ [Kevin Kühnert]
Marc Stibane
2022-09-22 21:35:32 UTC
Permalink
Post by Beate Goebel
Marc Stibane schrieb am 22 Sep 2022
Post by Marc Stibane
Was wirklich hilft, ist z.B. FIDO2, Passkeys, ...
Vor allem die gerade gehackten Versionen davon...
Link?
--
In a world without walls and fences,
who needs windows and gates?
Beate Goebel
2022-09-23 07:13:07 UTC
Permalink
Marc Stibane schrieb am 22 Sep 2022
Post by Beate Goebel
Marc Stibane schrieb am 22 Sep 2022
Post by Marc Stibane
Was wirklich hilft, ist z.B. FIDO2, Passkeys, ...
Vor allem die gerade gehackten Versionen davon...
Link?
https://www.heise.de/news/Lastpass-Angreifer-hatten-vier-Tage-Zugriff-keine-Gefahr-fuer-Kundendaten-7267758.html

Beate
--
"Wenn ihr diese Verschwörungslügen glaubt, dann schadet ihr auch euch
selbst und unterstützt Geschäftemacher, die unseren Planeten
ausplündern." [Michael Blume, zeit.de 23.02.21]
Peter J. Holzer
2022-09-24 12:37:13 UTC
Permalink
Post by Beate Goebel
Marc Stibane schrieb am 22 Sep 2022
Post by Beate Goebel
Marc Stibane schrieb am 22 Sep 2022
Post by Marc Stibane
Was wirklich hilft, ist z.B. FIDO2, Passkeys, ...
Vor allem die gerade gehackten Versionen davon...
Link?
https://www.heise.de/news/Lastpass-Angreifer-hatten-vier-Tage-Zugriff-keine-Gefahr-fuer-Kundendaten-7267758.html
Falscher Link?

Ich sehe da keinen Zusammenhang.

hp
Marc Stibane
2022-09-25 13:05:09 UTC
Permalink
Post by Peter J. Holzer
Post by Beate Goebel
Marc Stibane schrieb am 22 Sep 2022
Post by Beate Goebel
Marc Stibane schrieb am 22 Sep 2022
Post by Marc Stibane
Was wirklich hilft, ist z.B. FIDO2, Passkeys, ...
Vor allem die gerade gehackten Versionen davon...
Link?
<https://www.heise.de/news/Lastpass-Angreifer-hatten-vier-Tage-Zugriff-keine-Gefahr-fuer-Kundendaten-7267758.html>
Falscher Link?
Ich sehe da keinen Zusammenhang.
Ich auch nicht.
--
In a world without walls and fences,
who needs windows and gates?
Arno Welzel
2022-09-26 11:48:10 UTC
Permalink
Post by Beate Goebel
Marc Stibane schrieb am 22 Sep 2022
Post by Beate Goebel
Marc Stibane schrieb am 22 Sep 2022
Post by Marc Stibane
Was wirklich hilft, ist z.B. FIDO2, Passkeys, ...
Vor allem die gerade gehackten Versionen davon...
Link?
https://www.heise.de/news/Lastpass-Angreifer-hatten-vier-Tage-Zugriff-keine-Gefahr-fuer-Kundendaten-7267758.html
Was hat das mit FIDO2 und Passkeys zu tun?
--
Arno Welzel
https://arnowelzel.de
Beate Goebel
2022-09-26 12:47:34 UTC
Permalink
Arno Welzel schrieb am 26 Sep 2022
Post by Arno Welzel
Post by Beate Goebel
https://www.heise.de/news/Lastpass-Angreifer-hatten-vier-Tage-Zugr
iff-keine-Gefahr-fuer-Kundendaten-7267758.html
Was hat das mit FIDO2 und Passkeys zu tun?
Zu blöde für Analogien? Hint: Was ist Lastpass?

Beate
--
"Das Weib wird fast nie vom objektiven, rein menschlichen Standpunkt,
als selbstständiges Glied der menschlichen Gesellschaft beurtheilt
(...), sondern nur in seinem Verhältniß zum Mann"
[Franziska Essenther 1871]
Jakob YANAGIBASHI
2022-09-26 14:11:44 UTC
Permalink
Post by Beate Goebel
Zu blöde für Analogien? Hint: Was ist Lastpass?
Ein propietärer Passwort-Manager. (Der nicht gehackt wurde, sondern
lediglich das Unternehmen, das ihn veröffentlicht.) Während FIDO2 und
Passkeys technologische Standards sind, ähnlich wie SSH- oder
PGP-Schlüssel. Die auch nicht gehackt wurden. Die Analogie besteht jetzt,
weil alles drei noch sicher ist?

Grüße

Jakob
Arno Welzel
2022-10-05 06:38:24 UTC
Permalink
Post by Beate Goebel
Arno Welzel schrieb am 26 Sep 2022
Post by Arno Welzel
Post by Beate Goebel
https://www.heise.de/news/Lastpass-Angreifer-hatten-vier-Tage-Zugr
iff-keine-Gefahr-fuer-Kundendaten-7267758.html
Was hat das mit FIDO2 und Passkeys zu tun?
Zu blöde für Analogien? Hint: Was ist Lastpass?
Welche Analogie? Was genau ist bei FIDO2 das Problem?
--
Arno Welzel
https://arnowelzel.de
Arno Welzel
2022-09-22 11:45:26 UTC
Permalink
Post by Marc Stibane
Post by Arno Welzel
Post by Marc Stibane
Post by Arno Welzel
Nein, der Aufwand ist trivial. Es wird einfach beim Benutzerkonto X
vermerkt, wann der letzte fehlerhafte Login-Versuch war und wie
häufig Fehler aufgetreten sind. Ist die Zahl der fehlerhafte
Login-Versuche z.B. über 3 wird ein Login erst wieder erlaubt, wenn
der letzte Versuch länger als 15 Minuten her ist.
Prima. Der Angreifer macht also per Script alle 12 Minuten einen
Login- Versuch und der rechtmäßige User kommt nie wieder rein.
Korrekt.
Und was soll das dem Angreifer bringen? Der schafft so pro Tag nur 120
Versuche.
Klar, der Angreifer kommt nicht rein. Der rechtmäßige User aber auch
nicht, solange der Angreifer das Script (oder cronjob) laufen lässt.
Dadurch wird der Nutzen des Accounts ggf. stark dezimiert.
Ja, ist so. Und?
Post by Marc Stibane
Post by Arno Welzel
Alternativ kann man den Login noch mit einem 2. Faktor absichern.
Mit manueller Bestätigung (SMS/Push-Notification empfangen und one-time-
key eintippen) kann man auch den User bombardieren.
Wo schrieb ich von SMS?
Post by Marc Stibane
Was wirklich hilft, ist z.B. FIDO2, Passkeys, ...
Eben.
--
Arno Welzel
https://arnowelzel.de
Andreas Kohlbach
2022-09-19 19:44:53 UTC
Permalink
Post by Marc Stibane
Post by Arno Welzel
Post by Wendelin Uez
Ja, das stimmt. Aber dann hätte der Server wesentlich mehr Aufwand,
z.B. sich alle Loginversuche mit Zeitstempel der letzten x Minuten zu
merken, da ist es eben einfacher, der Benutzer muß sich ein längeres
Passwort merken.
Nein, der Aufwand ist trivial. Es wird einfach beim Benutzerkonto X
vermerkt, wann der letzte fehlerhafte Login-Versuch war und wie häufig
Fehler aufgetreten sind. Ist die Zahl der fehlerhafte Login-Versuche
z.B. über 3 wird ein Login erst wieder erlaubt, wenn der letzte Versuch
länger als 15 Minuten her ist.
Prima. Der Angreifer macht also per Script alle 12 Minuten einen Login-
Versuch und der rechtmäßige User kommt nie wieder rein.
Da braucht man nicht mal mehr einen DDoS...
Dinge wie Fail2Ban blockieren nach einer vorbestimmten Anzahl von
Versuchen die ausgehende IP. Wenn sich der rechtmäßige User nicht auch
von dieser einloggt, hat er mit dem Bann keine Probleme.
--
Andreas
Ruediger Lahl
2022-09-22 07:15:29 UTC
Permalink
Post by Andreas Kohlbach
Post by Marc Stibane
Post by Arno Welzel
Post by Wendelin Uez
Ja, das stimmt. Aber dann hätte der Server wesentlich mehr Aufwand,
z.B. sich alle Loginversuche mit Zeitstempel der letzten x Minuten zu
merken, da ist es eben einfacher, der Benutzer muß sich ein längeres
Passwort merken.
Nein, der Aufwand ist trivial. Es wird einfach beim Benutzerkonto X
vermerkt, wann der letzte fehlerhafte Login-Versuch war und wie häufig
Fehler aufgetreten sind. Ist die Zahl der fehlerhafte Login-Versuche
z.B. über 3 wird ein Login erst wieder erlaubt, wenn der letzte Versuch
länger als 15 Minuten her ist.
Prima. Der Angreifer macht also per Script alle 12 Minuten einen Login-
Versuch und der rechtmäßige User kommt nie wieder rein.
Da braucht man nicht mal mehr einen DDoS...
Dinge wie Fail2Ban blockieren nach einer vorbestimmten Anzahl von
Versuchen die ausgehende IP.
Die "eingehende" IP.
Post by Andreas Kohlbach
Wenn sich der rechtmäßige User nicht auch
von dieser einloggt, hat er mit dem Bann keine Probleme.
Eben und höchst unwahrscheinlich. Und wahrscheinlich kann man in der
Sperre auch festlegen, dass lokale IPs nie geblockt werden.
--
bis denne
Andreas Kohlbach
2022-09-22 13:45:50 UTC
Permalink
Post by Ruediger Lahl
Post by Andreas Kohlbach
Post by Marc Stibane
Prima. Der Angreifer macht also per Script alle 12 Minuten einen Login-
Versuch und der rechtmäßige User kommt nie wieder rein.
Da braucht man nicht mal mehr einen DDoS...
Dinge wie Fail2Ban blockieren nach einer vorbestimmten Anzahl von
Versuchen die ausgehende IP.
Die "eingehende" IP.
Oops, ja.
Post by Ruediger Lahl
Post by Andreas Kohlbach
Wenn sich der rechtmäßige User nicht auch
von dieser einloggt, hat er mit dem Bann keine Probleme.
Eben und höchst unwahrscheinlich. Und wahrscheinlich kann man in der
Sperre auch festlegen, dass lokale IPs nie geblockt werden.
Lokal wie in Intranet (private range)? 192.168... oder 10...?

Ich habe eine iptables Zeile, die an einem Rechner in der DMZ die Zahl
der Einlogversuche über SSH limitieren soll:

iptables -I INPUT -p tcp --dport 22 -i ppp0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP

ppp0 ist hier alles von "außen", wlan0 alles von "innen".

Sonst würde iptables auch eine Adressen-Range anzugeben erlauben.
--
Andreas
Louis Noser
2022-05-14 05:27:51 UTC
Permalink
Post by Marcel Logen
...ide Loginseite kennt
ja nur die IP-Nummer als Unterscheidungsmerkmal der Anfragen.
Nein, auch den Benutzernamen.
Da wäre auch noch die MAC-Adresse.

Grüsse
Louis
Juergen Ilse
2022-05-14 11:14:02 UTC
Permalink
Hallo,
Post by Louis Noser
Post by Marcel Logen
...ide Loginseite kennt
ja nur die IP-Nummer als Unterscheidungsmerkmal der Anfragen.
Nein, auch den Benutzernamen.
Da wäre auch noch die MAC-Adresse.
Die MAC-Adresse bekommt der Server i.d.R. nicht mit, denn die ist ausserhalb
des lokalen Netzes nicht nur bedeutungslos sondern auch normalerweise *nicht*
sichtbar.

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)
Louis Noser
2022-05-14 11:44:52 UTC
Permalink
Post by Juergen Ilse
Post by Louis Noser
Da wäre auch noch die MAC-Adresse.
Die MAC-Adresse bekommt der Server i.d.R. nicht mit, denn die ist ausserhalb
des lokalen Netzes nicht nur bedeutungslos sondern auch normalerweise *nicht*
sichtbar.
Manchmal werden Gratis-WLANs an öffentlichen Orten zur breiten Benutzung
angeboten, die jedoch teilweise zeitlich beschränkt sind (nach zB. einer
Stunde Nutzung ist das Netz eine Stunde lang gesperrt). Bei einem
bestimmten solchen zeitlich beschränkten WLAN musste ich nach einer
Stunde nur die MAC-Adresse meines Rechners (ich nehme an, das ist jene
der Netzwerkkarte) ändern und die Gegenseite liess mich wieder ins WLAN.

Grüsse
Louis
Thomas Klix
2022-05-14 12:24:25 UTC
Permalink
Post by Louis Noser
Post by Juergen Ilse
Post by Louis Noser
Da wäre auch noch die MAC-Adresse.
Die MAC-Adresse bekommt der Server i.d.R. nicht mit, denn die ist ausserhalb
des lokalen Netzes nicht nur bedeutungslos sondern auch normalerweise *nicht*
sichtbar.
Manchmal werden Gratis-WLANs an öffentlichen Orten zur breiten Benutzung
angeboten, die jedoch teilweise zeitlich beschränkt sind (nach zB. einer
Stunde Nutzung ist das Netz eine Stunde lang gesperrt). Bei einem
bestimmten solchen zeitlich beschränkten WLAN musste ich nach einer
Stunde nur die MAC-Adresse meines Rechners (ich nehme an, das ist jene
der Netzwerkkarte) ändern und die Gegenseite liess mich wieder ins WLAN.
Dann ist dieses WLAN aber eben dein *lokales* Netz - und innerhalb dessen
ist deine MAC-Adresse sowohl sichtbar als auch bedeutungsvoll.

Thomas
Marc Haber
2022-05-15 06:55:32 UTC
Permalink
Post by Louis Noser
Post by Juergen Ilse
Post by Louis Noser
Da wäre auch noch die MAC-Adresse.
Die MAC-Adresse bekommt der Server i.d.R. nicht mit, denn die ist ausserhalb
des lokalen Netzes nicht nur bedeutungslos sondern auch normalerweise *nicht*
sichtbar.
Manchmal werden Gratis-WLANs an öffentlichen Orten zur breiten Benutzung
angeboten, die jedoch teilweise zeitlich beschränkt sind (nach zB. einer
Stunde Nutzung ist das Netz eine Stunde lang gesperrt). Bei einem
bestimmten solchen zeitlich beschränkten WLAN musste ich nach einer
Stunde nur die MAC-Adresse meines Rechners (ich nehme an, das ist jene
der Netzwerkkarte) ändern und die Gegenseite liess mich wieder ins WLAN.
Das ist kein Widerspruch zu Juergens Erklärung.
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Arno Welzel
2022-05-15 13:06:05 UTC
Permalink
Post by Wendelin Uez
Post by Louis Noser
Bei einer Login-Seite, die den Zugriff nach 4 Fehlversuchen für zB. 15
Minuten sperrt, ist das Durchprobieren aber doch sehr mühsam und vor allem
zeitraubend, also eher nicht zielführend. Oder ist das falsch?
Das Problem ist, daß eine Login-Seite von vielen anderen IP-Nummern
gleichzeitig aufgerufen werden kann, hinter denen alle derselbe Angreifer
stecen kannt. Wenn er also genügend Verbindungen aufbauen kann ist so eine
Zeitlimitierung relativ nutzlos, ide Loginseite kennt ja nur die IP-Nummer
als Unterscheidungsmerkmal der Anfragen.
Ein halbwegs sinnvoller Mechanismus sperrt natürlich das betroffene
Benutzerkonto an sich für Login-Versuche insgesanmt und nicht nicht nur
die IP-Adresse von der aus der Login versucht wurde.
--
Arno Welzel
https://arnowelzel.de
Wendelin Uez
2022-05-16 16:46:23 UTC
Permalink
ja, auch wieder wahr :-)
Marc Stibane
2022-09-19 09:14:46 UTC
Permalink
Post by Arno Welzel
Post by Wendelin Uez
Post by Louis Noser
Bei einer Login-Seite, die den Zugriff nach 4 Fehlversuchen für zB.
15 Minuten sperrt, ist das Durchprobieren aber doch sehr mühsam und
vor allem zeitraubend, also eher nicht zielführend. Oder ist das
falsch?
Das Problem ist, daß eine Login-Seite von vielen anderen IP-Nummern
gleichzeitig aufgerufen werden kann, hinter denen alle derselbe
Angreifer stecen kannt. Wenn er also genügend Verbindungen aufbauen
kann ist so eine Zeitlimitierung relativ nutzlos, ide Loginseite
kennt ja nur die IP-Nummer als Unterscheidungsmerkmal der Anfragen.
Ein halbwegs sinnvoller Mechanismus sperrt natürlich das betroffene
Benutzerkonto an sich für Login-Versuche insgesanmt und nicht nicht nur
die IP-Adresse von der aus der Login versucht wurde.
Ein halbwegs sinnvoller Mechanismus sperrt nicht den rechtmäßigen User
für immer aus.
--
In a world without walls and fences,
who needs windows and gates?
Lawnick, Michael
2022-09-19 09:28:01 UTC
Permalink
Post by Marc Stibane
Post by Arno Welzel
Post by Wendelin Uez
Post by Louis Noser
Bei einer Login-Seite, die den Zugriff nach 4 Fehlversuchen für zB.
15 Minuten sperrt, ist das Durchprobieren aber doch sehr mühsam und
vor allem zeitraubend, also eher nicht zielführend. Oder ist das
falsch?
Das Problem ist, daß eine Login-Seite von vielen anderen IP-Nummern
gleichzeitig aufgerufen werden kann, hinter denen alle derselbe
Angreifer stecen kannt. Wenn er also genügend Verbindungen aufbauen
kann ist so eine Zeitlimitierung relativ nutzlos, ide Loginseite
kennt ja nur die IP-Nummer als Unterscheidungsmerkmal der Anfragen.
Ein halbwegs sinnvoller Mechanismus sperrt natürlich das betroffene
Benutzerkonto an sich für Login-Versuche insgesanmt und nicht nicht nur
die IP-Adresse von der aus der Login versucht wurde.
Ein halbwegs sinnvoller Mechanismus sperrt nicht den rechtmäßigen User
für immer aus.
Und der halbwegs sinnvolle Mechanismus erkennt den rechtmäßigen User wie?
--
Gruß,
Michael
Marc Stibane
2022-09-19 09:45:44 UTC
Permalink
Post by Lawnick, Michael
Post by Marc Stibane
Post by Arno Welzel
Ein halbwegs sinnvoller Mechanismus sperrt natürlich das betroffene
Benutzerkonto an sich für Login-Versuche insgesanmt und nicht nicht
nur die IP-Adresse von der aus der Login versucht wurde.
Ein halbwegs sinnvoller Mechanismus sperrt nicht den rechtmäßigen
User für immer aus.
Und der halbwegs sinnvolle Mechanismus erkennt den rechtmäßigen User wie?
Völlig richtig - genau das ist das Problem. Für den kleinen Krauter ist
das kaum zu bewerkstelligen.
Deswegen existieren Dienste die DDoS-Protection anbieten.

Hmm, ich könnte mir noch einen versteckten Zugang über zusätzliche
Login-Credentials vorstellen, die der User natürlich geheimhalten muss.
Statt als Bob meldet er sich als Alice an, und landet trotzdem im
Bob-Account. Der Angreifer bombardiert die Vordertür, der User geht zur
Hintertür rein.
--
In a world without walls and fences,
who needs windows and gates?
Lawnick, Michael
2022-09-19 10:03:29 UTC
Permalink
Post by Marc Stibane
Post by Lawnick, Michael
Post by Marc Stibane
Post by Arno Welzel
Ein halbwegs sinnvoller Mechanismus sperrt natürlich das betroffene
Benutzerkonto an sich für Login-Versuche insgesanmt und nicht nicht
nur die IP-Adresse von der aus der Login versucht wurde.
Ein halbwegs sinnvoller Mechanismus sperrt nicht den rechtmäßigen
User für immer aus.
Und der halbwegs sinnvolle Mechanismus erkennt den rechtmäßigen User wie?
Völlig richtig - genau das ist das Problem. Für den kleinen Krauter ist
das kaum zu bewerkstelligen.
Deswegen existieren Dienste die DDoS-Protection anbieten.
Hmm, ich könnte mir noch einen versteckten Zugang über zusätzliche
Login-Credentials vorstellen, die der User natürlich geheimhalten muss.
Statt als Bob meldet er sich als Alice an, und landet trotzdem im
Bob-Account. Der Angreifer bombardiert die Vordertür, der User geht zur
Hintertür rein.
Merkst du es schon? Das hebt das Problem nur auf den nächsten aber
identischen Level. Das hat nichts mit Krauter oder sonstigem zu tun, es
ist halt *der* Nebeneffekt der Abwehr unbefugter Loginversuche durch
Rate-Limit.
Fügst du einen Mechanismus hinzu, der geheim ist, kannst du gleich
ausschließlich den nehmen. Geheime Mechanismen sind aber der Tod
funktionierender Sicherheit.
Ist der Mechanismus nicht geheim, so unterliegt er den gleichen
Bedingungen wie der offizielle. Gehe zurück auf Los, ziehe keine DM
400,- ein.
--
Gruß,
Michael
Marc Stibane
2022-09-19 11:32:00 UTC
Permalink
Post by Lawnick, Michael
Post by Marc Stibane
Post by Lawnick, Michael
Post by Marc Stibane
Ein halbwegs sinnvoller Mechanismus sperrt nicht den rechtmäßigen
User für immer aus.
Und der halbwegs sinnvolle Mechanismus erkennt den rechtmäßigen User wie?
Völlig richtig - genau das ist das Problem. Für den kleinen Krauter
ist das kaum zu bewerkstelligen.
Deswegen existieren Dienste die DDoS-Protection anbieten.
Merkst du es schon? Das hebt das Problem nur auf den nächsten aber
identischen Level. Das hat nichts mit Krauter oder sonstigem zu tun, es
ist halt *der* Nebeneffekt der Abwehr unbefugter Loginversuche durch
Rate-Limit.
DDoS-Protection ist ja gerade kein Rate-Limit, sondern soll die Über-
forderung eines einzelnen Login-Servers durch massives Bombardement (so
dass der legitime User nicht mehr durchkommt) verhindern.
Ein Rate-Limit kann ein Angreifer mit wenig Aufwand triggern, dafür
hilft das nicht.
Post by Lawnick, Michael
Post by Marc Stibane
Hmm, ich könnte mir noch einen versteckten Zugang über zusätzliche
Login-Credentials vorstellen, die der User natürlich geheimhalten
muss. Statt als Bob meldet er sich als Alice an, und landet trotzdem
im Bob-Account. Der Angreifer bombardiert die Vordertür, der User
geht zur Hintertür rein.
Fügst du einen Mechanismus hinzu, der geheim ist, kannst du gleich
ausschließlich den nehmen.
Nein. Erstens ist nicht der Mechanismus selber geheim, sondern nur die
Login-Credentials. Wenn der Username des Opfers dem Angreifer bekannt
ist, kann er entweder einen Brute-Force-Angriff fahren (wenn der Server
unbegrenzt Login-Versuche zulässt) oder den User selber aussperren (wenn
der Server die Login-Versuche limitiert). Der User kann sich in beiden
Fällen nicht mit seinen normalen Credentials anmelden.
Aber mangels Kenntnis der alternativen Credentials kann der Angreifer
den Login des Users damit nicht verhindern.
Post by Lawnick, Michael
Geheime Mechanismen sind aber der Tod funktionierender Sicherheit.
Nur ein zweiter Satz Login-Credentials. Exakt dieselbe Sicherheit wie
beim ersten.
Post by Lawnick, Michael
Ist der Mechanismus nicht geheim, so unterliegt er den gleichen
Bedingungen wie der offizielle. Gehe zurück auf Los, ziehe keine DM
400,- ein.
Nein. Dem Angreifer ist der zweite Satz nicht bekannt, u.a. weil der
User ja im Normalfall seine Haupt-Credentials nimmt.

Bei SIM-Karten gibt es auch außer der PIN noch den PUK, mit dem man die
Karte wieder freischalten kann wenn sie nach dreimaliger Falscheingabe
der PIN gesperrt wurde.
--
In a world without walls and fences,
who needs windows and gates?
Lawnick, Michael
2022-09-19 12:41:44 UTC
Permalink
Post by Marc Stibane
Post by Lawnick, Michael
Post by Marc Stibane
Post by Lawnick, Michael
Post by Marc Stibane
Ein halbwegs sinnvoller Mechanismus sperrt nicht den rechtmäßigen
User für immer aus.
Und der halbwegs sinnvolle Mechanismus erkennt den rechtmäßigen User wie?
Völlig richtig - genau das ist das Problem. Für den kleinen Krauter
ist das kaum zu bewerkstelligen.
Deswegen existieren Dienste die DDoS-Protection anbieten.
Merkst du es schon? Das hebt das Problem nur auf den nächsten aber
identischen Level. Das hat nichts mit Krauter oder sonstigem zu tun, es
ist halt *der* Nebeneffekt der Abwehr unbefugter Loginversuche durch
Rate-Limit.
DDoS-Protection ist ja gerade kein Rate-Limit, sondern soll die Über-
forderung eines einzelnen Login-Servers durch massives Bombardement (so
dass der legitime User nicht mehr durchkommt) verhindern.
Ein Rate-Limit kann ein Angreifer mit wenig Aufwand triggern, dafür
hilft das nicht.
Post by Lawnick, Michael
Post by Marc Stibane
Hmm, ich könnte mir noch einen versteckten Zugang über zusätzliche
Login-Credentials vorstellen, die der User natürlich geheimhalten
muss. Statt als Bob meldet er sich als Alice an, und landet trotzdem
im Bob-Account. Der Angreifer bombardiert die Vordertür, der User
geht zur Hintertür rein.
Fügst du einen Mechanismus hinzu, der geheim ist, kannst du gleich
ausschließlich den nehmen.
Nein. Erstens ist nicht der Mechanismus selber geheim, sondern nur die
Login-Credentials. Wenn der Username des Opfers dem Angreifer bekannt
ist, kann er entweder einen Brute-Force-Angriff fahren (wenn der Server
unbegrenzt Login-Versuche zulässt) oder den User selber aussperren (wenn
der Server die Login-Versuche limitiert). Der User kann sich in beiden
Fällen nicht mit seinen normalen Credentials anmelden.
Aber mangels Kenntnis der alternativen Credentials kann der Angreifer
den Login des Users damit nicht verhindern.
Post by Lawnick, Michael
Geheime Mechanismen sind aber der Tod funktionierender Sicherheit.
Nur ein zweiter Satz Login-Credentials. Exakt dieselbe Sicherheit wie
beim ersten.
Post by Lawnick, Michael
Ist der Mechanismus nicht geheim, so unterliegt er den gleichen
Bedingungen wie der offizielle. Gehe zurück auf Los, ziehe keine DM
400,- ein.
Nein. Dem Angreifer ist der zweite Satz nicht bekannt, u.a. weil der
User ja im Normalfall seine Haupt-Credentials nimmt.
Bei SIM-Karten gibt es auch außer der PIN noch den PUK, mit dem man die
Karte wieder freischalten kann wenn sie nach dreimaliger Falscheingabe
der PIN gesperrt wurde.
Ich stelle fest, dass du das elementare Problem nicht verstehen willst.

EOD
--
Gruß,
Michael
Christian Garbs
2022-09-22 20:22:33 UTC
Permalink
Mahlzeit!

Marc Stibane <***@arcor.de> wrote:

[…]
Post by Marc Stibane
Nein. Erstens ist nicht der Mechanismus selber geheim, sondern nur die
Login-Credentials. Wenn der Username des Opfers dem Angreifer bekannt
ist, kann er entweder einen Brute-Force-Angriff fahren (wenn der Server
unbegrenzt Login-Versuche zulässt) oder den User selber aussperren (wenn
der Server die Login-Versuche limitiert). Der User kann sich in beiden
Fällen nicht mit seinen normalen Credentials anmelden.
Aber mangels Kenntnis der alternativen Credentials kann der Angreifer
den Login des Users damit nicht verhindern.
Warum kann sich der Angreifer die Erst-Credentials ergaunern,
die Zweit-Credentials aber nicht?
Post by Marc Stibane
Nur ein zweiter Satz Login-Credentials. Exakt dieselbe Sicherheit wie
beim ersten.
Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
Viele Menschen sehnen sich nach der Unsterblichkeit und wissen nicht,
was sie an einem Sonntagnachmittag machen sollen!
Marc Stibane
2022-09-25 13:05:08 UTC
Permalink
Post by Christian Garbs
Post by Marc Stibane
Nein. Erstens ist nicht der Mechanismus selber geheim, sondern nur
die Login-Credentials. Wenn der Username des Opfers dem Angreifer
bekannt ist, kann er entweder einen Brute-Force-Angriff fahren (wenn
der Server unbegrenzt Login-Versuche zulässt) oder den User selber
aussperren (wenn der Server die Login-Versuche limitiert). Der User
kann sich in beiden Fällen nicht mit seinen normalen Credentials
anmelden.
Aber mangels Kenntnis der alternativen Credentials kann der Angreifer
den Login des Users damit nicht verhindern.
Warum kann sich der Angreifer die Erst-Credentials ergaunern,
die Zweit-Credentials aber nicht?
Weil z.B. der User die Erst-Credentials in einem Internet-Café verwendet
hat. Oder mit seinem Handy in einem public WLAN war. Oder...

Die Zweit-Credentials nimmt man nur zuhause.
Post by Christian Garbs
Post by Marc Stibane
Nur ein zweiter Satz Login-Credentials. Exakt dieselbe Sicherheit wie
beim ersten.
Der Unterschied ist die Frequenz und der Ort der Verwendung.
--
In a world without walls and fences,
who needs windows and gates?
Andreas Kohlbach
2022-05-12 18:29:00 UTC
Permalink
Post by Wendelin Uez
Post by Louis Noser
Weil wohl bei den meisten Login-Seiten bei drei oder vier
Fehlversuchen der Zugriff eine Zeit lang blockiert ist/sein sollte,
sollten relativ einfache Passwörter doch kein Problem sein.
Sie sind kein technisches Problem, falls gewollt können Passwörter
auch einstellig sein :-)
Bei sog. brute-force-Angriffen, bei denen Passwortkombinationen
einfach durchprobiert werden, sind die kurzen Kombinationen halt weit
früher durcht als längere, das ist das ganze Geheimnis. Deshalb
bestehen die meisten Formulare auf einer gewissen Mindestlänge. Welche
das sein soll kann aber jedes selber festlegen.
Zudem erlauben viele Systeme nur eine bestimmte Anzahl an Versuchen. Gab
es zu viele Fehlversuche, muss man, je nach System, X Stunden warten oder
sich auf andere Art authentifizieren. Oder bekommt, wie bei Banken, eine
neue PIN zugesandt.
--
Andreas
Laurenz Trossel
2022-05-14 08:50:09 UTC
Permalink
Der gewissenhafte Betreiber bekommt also das eigentliche Passwort gar
nicht zu sehen, es reicht, wenn er ein mathematisch errechnetes Abbild
davon bekommt
Wenn der gewissenhafte Betreiber das Passwort als gesalzenen Hash
speichert, muss der Client es bei den üblichen Verfahren im Klartext
übertragen.
Juergen Ilse
2022-05-14 11:16:48 UTC
Permalink
Hallo,
Post by Laurenz Trossel
Der gewissenhafte Betreiber bekommt also das eigentliche Passwort gar
nicht zu sehen, es reicht, wenn er ein mathematisch errechnetes Abbild
davon bekommt
Wenn der gewissenhafte Betreiber das Passwort als gesalzenen Hash
speichert, muss der Client es bei den üblichen Verfahren im Klartext
übertragen.
Deswegen wird es ja dann i.d.R. das Passwort ueber eine verschluesselte
Verbindung uebertragen, i.a. HTTPS ...

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)
Laurenz Trossel
2022-05-14 13:10:13 UTC
Permalink
Post by Juergen Ilse
Deswegen wird es ja dann i.d.R. das Passwort ueber eine verschluesselte
Verbindung uebertragen, i.a. HTTPS ...
Für die Verbindung zwischen Client und erstem Server ist das selbstverständlich.
Ich hielt es nicht für extra erwähnenswert.

Ob das Passwort auf dem Weg zum endgültigen Endpunkt weiterhin
verschlüsselt wird und ob TCP oder Unix-Sockets verwendet werden, kann man
von aussen nicht sehen.
Post by Juergen Ilse
Der gewissenhafte Betreiber bekommt also das eigentliche Passwort gar
nicht zu sehen
Juergen Ilse
2022-05-14 22:21:26 UTC
Permalink
Post by Laurenz Trossel
Post by Juergen Ilse
Deswegen wird es ja dann i.d.R. das Passwort ueber eine verschluesselte
Verbindung uebertragen, i.a. HTTPS ...
Für die Verbindung zwischen Client und erstem Server ist das selbstverständlich.
Ich hielt es nicht für extra erwähnenswert.
Ob das Passwort auf dem Weg zum endgültigen Endpunkt weiterhin
verschlüsselt wird und ob TCP oder Unix-Sockets verwendet werden, kann man
von aussen nicht sehen.
Idealerweise ist bei einem Anbieter, derweiss was er tut, auch diese
Verbindung vertrauenswuerddig (beide Server stehen im selben vertrauens-
wuerdigeen Netz oder die Server kommunizieren ueber eine verschluessselte
Verbindung, z.B. HTTPS oder VPN oder ...

Gegen unsinnige und angreifbare Implementierung der Infrastruktur auf
Serverseite ist man nicht gefeit. Das giltvoellig unabhaengig davon, ob
das Passwort im Klartext uebertragen wird oder ob es auf Serverseite im
Klartexxt gespeichert ist. Ersteres waere mit dann im Zweifelsfall sogar
noch lieber ...
Post by Laurenz Trossel
Post by Juergen Ilse
Der gewissenhafte Betreiber bekommt also das eigentliche Passwort gar
nicht zu sehen
Ein *gewissenhafter* und *kompetenter* Betreiber wird kein Passwort ueber
nicht unverschluesselt ueber nicht vetrauenswuerdige Verbindungen ueber-
tragen. Gegen nicht gewissenhhafte oder inkompetente Server-Betreiber hilft
hoechstens, dessen Server nicht zu benutzenn.

Ja, ich weiss, i.a. weiss man nicht sicher, ob der Serverbetreiber gewissen-
haft und Kompetent ist. Ein gewisser Unsicherheitsfaktor besteht da (leider)
immer (voellig unabhaengig von der fuer den Nutzer sicchtbaren Teil der
Implementierung).

Tschuess,
Juergen Ilse (***@useenet-verwaltung.de)
Arno Welzel
2022-05-15 13:09:16 UTC
Permalink
Post by Laurenz Trossel
Der gewissenhafte Betreiber bekommt also das eigentliche Passwort gar
nicht zu sehen, es reicht, wenn er ein mathematisch errechnetes Abbild
davon bekommt
Wenn der gewissenhafte Betreiber das Passwort als gesalzenen Hash
speichert, muss der Client es bei den üblichen Verfahren im Klartext
übertragen.
Der Betreiber sieht es dennoch nicht, der es in der Anwendung direkt
beim Login-Versuch nur im RAM gehasht wird und irgends gespeichert wird.
Wenn der Betreiber etwas einbaut, das unverschlüsselte Passwort explizit
irgendwo hin auszuleiten, bevor es gehasht wird, handelt er grob fahrlässig.
--
Arno Welzel
https://arnowelzel.de
Thomas Hochstein
2022-05-12 18:32:12 UTC
Permalink
Post by Louis Noser
"Die genaue Dauer hängt zwar davon ab, mit welchem Algorithmus das
Passwort verschlüsselt ist und mit wie viel Rechenleistung der Angreifer
anrückt."
1. Ist das unklar formuliert oder weshalb ist oder soll ein Passwort
verschlüsselt sein? (Gut, der Anbieter, auf den man zugreifen möchte,
muss das Passwort ja ablegen. Und das wird schlüsselt sein. Auf die
Verschlüsselungsstärke habe ich als Client aber keinen Einfluss. Und das
Thema des obigen Artikels ist die Sicherheit von Anwender-Passworten.)
Wenn dem Anbieter die Passwort-Datenbank abhandenkommt, ist es schon nett,
wenn die Passworte da nicht im Klartext drinstehen.
Post by Louis Noser
2. Bei den meisten Login-Seiten wird der Zugriff wohl bei drei oder vier
Fehlversuchen eine Zeit lang verunmöglicht. Warum soll ein 6- oder
8-stelliges Passwort dann ein Problem sein? Um schlussendlich Zugriff
auf den gewünschten Web-Inhalt zu bekommen, bedarf es ja wohl
abermillionen Versuche, oder nicht? Und weil bei 3 Fehlversuchen Schluss
ist, sollten doch auch relativ einfache Passwörter kein Problem sein.
Wenn dem Anbieter die Passwort-Datenbank abhandenkommt, kann man sehr,
sehr schnell durchprobieren, welches Passwort zum Hash (dem
"verschlüsselten" Passwort) passt. Je simpler das Passwort ist, desto
schneller kann es "entschlüsselt" werden. Wenn der Anbieter bis dahin noch
nicht gemerkt hat, dass ihm die Passwort-Datenbank abhandengekommen ist,
ist das dann doof. Ist das Passwort komplex, dauert es sehr lange, es zu
"entschlüsseln". Bis dahin _hat_ der Anbieter dann meist gemerkt, dass er
ein Problem hat.

Für Innentäter gilt das alles mutatis mutandis.
Marc Haber
2022-05-12 19:12:14 UTC
Permalink
Post by Thomas Hochstein
Wenn dem Anbieter die Passwort-Datenbank abhandenkommt, kann man sehr,
sehr schnell durchprobieren, welches Passwort zum Hash (dem
"verschlüsselten" Passwort) passt.
Deswegen nimmt man auch gerne Hash-Algorihmen, deren Berechnung einige
Zeit dauern. Das treibt den Aufwand für das Errechnen der eigentlichen
Passworte in die Höhe.

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Heiko Rost
2022-05-12 19:03:49 UTC
Permalink
Post by Louis Noser
Hier
https://www.nzz.ch/technologie/was-ist-ein-gutes-passwort-zwei-tipps-fuer-mehr-sicherheit-ld.1682123?utm_source=pocket-newtab-global-de-DE
steht u.a.
"Die genaue Dauer hängt zwar davon ab, mit welchem Algorithmus das
Passwort verschlüsselt ist und mit wie viel Rechenleistung der Angreifer
anrückt."
1. Ist das unklar formuliert oder weshalb ist oder soll ein Passwort
verschlüsselt sein? (Gut, der Anbieter, auf den man zugreifen möchte,
muss das Passwort ja ablegen. Und das wird schlüsselt sein. Auf die
Verschlüsselungsstärke habe ich als Client aber keinen Einfluss. Und das
Thema des obigen Artikels ist die Sicherheit von Anwender-Passworten.)
In dem Artikel wird von Entschlüsselung des Passwortes geschrieben.
Deshalb dürfte der Fall gemeint sein, daß ein Angreifer irgendwie
Zugriff auf die Datenbank mit den Zugangsdaten hatte (genau deshalb
sollte verschlüsselte Speicherung auf Serverseite Standard sein). Und
mit Verschlüsselungen ist in dem Fall gemeint, daß man aus den
verschlüsselten Daten nicht einfach auf das Original schließen kan. Man
muß also alle möglichen Kennworte nehmen, die nach dem auf dem Server
benutzten Verfahren verschlüsseln und nachschauen, ob das Ergebnis
irgendwo in der Datenbank zu finden ist. Das dauert dann um so länger,
je länger das benutzte Passwort ist (darauf hast Du als Nutzer Einfluß)
und wie komplex die Verschlüsselung ist (das kann nur der Betreiber
beeinflussen).

Wobei Verschlüsselung eigentlich der falsche Begriff ist, weil das Ziel
ist, daß eben nicht entschlüsselt werden kann, Der korrekte Ausdruck
Hash <https://de.wikipedia.org/wiki/Kryptographische_Hashfunktion> wäre
für die meisten Leser aber wahrscheinlich noch verwirrender,
Post by Louis Noser
2. Bei den meisten Login-Seiten wird der Zugriff wohl bei drei oder vier
Fehlversuchen eine Zeit lang verunmöglicht. Warum soll ein 6- oder
8-stelliges Passwort dann ein Problem sein? Um schlussendlich Zugriff
auf den gewünschten Web-Inhalt zu bekommen, bedarf es ja wohl
abermillionen Versuche, oder nicht? Und weil bei 3 Fehlversuchen Schluss
ist, sollten doch auch relativ einfache Passwörter kein Problem sein.
Wenn Du davon ausgehst, daß ein Angreifer ausschließlich durch Brute
Force <https://de.wikipedia.org/wiki/Brute-Force-Methode> in das System
kommt, kann man das so sehen. Wobei das allerdings nur bei
Komplettsperrung des Zugangs und Freischaltung auf irgendeinem anderen
Weg als Online genutzt werden sollte. Bei Deinem Bankkonto funktioniert
das, da bekommst Du ein Schreiben Deiner Bank und eine neue EC-Karte.
Bei einem Anbieter, der Dich nur Online kennt, wird das schon
problematisch.

Außerden gibt es eben noch weitere Angriffsszenarien, gegen die man auch
Schutz braucht (sicher fehlt da noch einiges):

- Irgendein technischer Fehler, durch den ein gesichertes System doch
nicht so sicher ist wie gewünscht
- Jemand mit administrativen Rechten verläßt die Firma unfreiwillig und
nimmt die Datenbank mit
- Jemand mit administrativen Rechten ist nicht so sorgsam mit
seinen Zugangsdaten wie erhofft.
- Man läßt versehentlich sein Backup frei zugänglich im Netz liegen

Gruß Heiko
--
Der Wille, gesund zu werden, ist stärker als der Wille, gesund zu bleiben.
Gerhard Kocher
Arno Welzel
2022-05-15 13:04:28 UTC
Permalink
Post by Louis Noser
Hallo
Weil wohl bei den meisten Login-Seiten bei drei oder vier Fehlversuchen
der Zugriff eine Zeit lang blockiert ist/sein sollte, sollten relativ
einfache Passwörter doch kein Problem sein.
Oder wo ist hier mein Denkfehler?
Der Denkfehler ist, dass es nicht um Login-Formulare geht.
Post by Louis Noser
https://www.nzz.ch/technologie/was-ist-ein-gutes-passwort-zwei-tipps-fuer-mehr-sicherheit-ld.1682123?utm_source=pocket-newtab-global-de-DE
steht u.a.
"Die genaue Dauer hängt zwar davon ab, mit welchem Algorithmus das
Passwort verschlüsselt ist und mit wie viel Rechenleistung der Angreifer
anrückt."
Das gilt nicht für das Passwort, sondern den Hash-Wert dazu in der
Anwendung.
Post by Louis Noser
1. Ist das unklar formuliert oder weshalb ist oder soll ein Passwort
verschlüsselt sein? (Gut, der Anbieter, auf den man zugreifen möchte,
Die NZZ ist halt auch kein Fachmagazin.

Es geht um den Hash-Wert des Passworts. Das ist eine Prüfsumme, die auf
Basis das Passworts gebildet wird. Und um *diesen* Algorithmus geht es.
Früher wurde MD5 benutzt, mittlerweile verwendet man andere Verfahren,
wiel MD5 knackbar geworden ist.

Beispiel:

Passwort "Test"

MD5-Hash-Wert dazu: 0cbc6611f5540bd0809a388dc95a615b
SHA1-Hash-Wert dazu: 640ab2bae07bedc4c163f679a746f7ab7fb5d1fa

Passwort "PferdwagenMandarinenSchnitzel"

MD5-Hash-Wert dazu: e30ac3e298ff552ad8f8c7544b52c029
SHA1-Hash-Wert dazu: 7addfe74fa593818d56826d8afbab41630b18d2e

Wenn nun ein Angreifer z.B. die Benutzerdatenbank des Anbieters kopiert
hat, sieht er keine Passwörter, sondern nur die Hash-Werte. Um daraus
auf das Passwort zu kommen, müsste er alle möglichen Passwörter
durchprobieren, bis eines davon den passenden Wert ergibt.

Wenn der Angreifer weiß, dass das Passwort maximal 8 Zeichen lang ist
muss er "nur" etwa 90^8 verschiedene Wörter durchprobieren, wenn z.B. 90
verschiedene Zeichen möglich sind (z.B. a-z, A-Z, alle Ziffern und
diverse Sonderzeichen).

Das ist zwar rechnerisch sehr viel - aber wenn mehrere Millionen oder
gar Milliarden Varianten pro Sekunde berechnet werden können, auch nicht
unlösbar.

Ist dagegen das Passwort doppelt so lang, steigt der Aufwand enorm an.
Jedes weitere Zeichen führt zu einer 90-fach längeren Zeit, da ja mit
jedem weiteren Zeichen wieder 90 Mal mehr Kombinationen dazu kommen, die
geprüft werden müssen.
Post by Louis Noser
2. Bei den meisten Login-Seiten wird der Zugriff wohl bei drei oder vier
Fehlversuchen eine Zeit lang verunmöglicht. Warum soll ein 6- oder
8-stelliges Passwort dann ein Problem sein? Um schlussendlich Zugriff
auf den gewünschten Web-Inhalt zu bekommen, bedarf es ja wohl
abermillionen Versuche, oder nicht? Und weil bei 3 Fehlversuchen Schluss
ist, sollten doch auch relativ einfache Passwörter kein Problem sein.
Siehe oben - es geht *nicht* um das Login-Formular, sondern die Frage,
wie sicher ein Passwort ist, wenn ein Angreifer an die Passwort-Hashes
kommt und dann in Ruhe durchprobieren kann, bis er ein Passwort gefunden
hat, was den richtigen Hash ergibt. Damit kann er sich dann einfach
anmelden.
--
Arno Welzel
https://arnowelzel.de
Louis Noser
2022-05-15 14:26:17 UTC
Permalink
Post by Arno Welzel
Der Denkfehler ist, dass es nicht um Login-Formulare geht.
Als Nutzer muss man also damit rechnen, dass es grundsätzlich jedem
Anbieter passieren kann, dass seine Passwort- bzw. Hash-Wert-Datenbank
in falsche Hände gerät. Deshalb also soll man möglichst lange und
komplizierte Passworte wählen. Würde der Angreifer das Passwort über das
Login-Formular zu knacken versuchen, wären wohl auch einfachere
Passworte ausreichend.

Grüsse
Louis
Arno Welzel
2022-05-15 16:43:34 UTC
Permalink
Post by Louis Noser
Post by Arno Welzel
Der Denkfehler ist, dass es nicht um Login-Formulare geht.
Als Nutzer muss man also damit rechnen, dass es grundsätzlich jedem
Anbieter passieren kann, dass seine Passwort- bzw. Hash-Wert-Datenbank
in falsche Hände gerät. Deshalb also soll man möglichst lange und
Korrekt.

Eine Garantie dafür, dass Daten niemals in falsche Hände geraten gibt es
nicht. Und angesichts der Vorfälle der letzten Jahre wo millionenfach
Benutzerdaten im Netz gelandet sind, würde ich grundsätzlich davon
ausgehen, dass sowas passieren kann.
Post by Louis Noser
komplizierte Passworte wählen. Würde der Angreifer das Passwort über das
Login-Formular zu knacken versuchen, wären wohl auch einfachere
Passworte ausreichend.
Genau das tut aber kein Angreifer, weil Login-Formular in der Regel
nicht tausende Versuche für das selbe Benutzerkonto in Kurzer Zeit
zulassen, auch nicht von mehreren IP-Adressen aus.

"Kompliziert" bedeutet bei Passwörter vor allem *lang*. Ein Passwort wie
"A!#8&ygY-" mag zwar "kompliziert" aussehen, hat aber auch nur 9
Zeichen. Auch die Nutzung echter Wörter sollte man vermeiden, weil sowas
mit Wörterbüchern durchprobiert wird. Also besser Fantasiebegriffe und
das mit ein paar Sonderzeichen kombiniert wie "bluna3SchlintaLo" o.Ä.
--
Arno Welzel
https://arnowelzel.de
Marc Stibane
2022-09-15 23:10:41 UTC
Permalink
Post by Arno Welzel
"Kompliziert" bedeutet bei Passwörter vor allem *lang*. Ein Passwort wie
"A!#8&ygY-" mag zwar "kompliziert" aussehen, hat aber auch nur 9
Zeichen. Auch die Nutzung echter Wörter sollte man vermeiden, weil sowas
mit Wörterbüchern durchprobiert wird. Also besser Fantasiebegriffe und
das mit ein paar Sonderzeichen kombiniert wie "bluna3SchlintaLo" o.Ä.
"Tr0ub4dor&3" vs "correct horse battery staple"

www.xkcd.com/936
--
In a world without walls and fences,
who needs windows and gates?
Stefan Claas
2022-09-16 11:13:59 UTC
Permalink
Post by Arno Welzel
"Kompliziert" bedeutet bei Passwörter vor allem *lang*. Ein Passwort wie
"A!#8&ygY-" mag zwar "kompliziert" aussehen, hat aber auch nur 9
Zeichen. Auch die Nutzung echter Wörter sollte man vermeiden, weil sowas
mit Wörterbüchern durchprobiert wird. Also besser Fantasiebegriffe und
das mit ein paar Sonderzeichen kombiniert wie "bluna3SchlintaLo" o.Ä.
Dafür hat man vor Jahren key derivation functions erfunden, die kurze Passwörter
und dazu ein salt in lange hex Schlüssel, als Passwort genutzt, verwenden, welche
es dann auch erlauben bei z.B. wie Google heimische Zeichensätze als Passwort zu nutzen.

Europol und BKA haben dadurch z. B. es schwieriger, Passwort-Datenbanken zu knacken,
weil Argon2id bei denen noch nicht in hashcash und deren GPU Cluster genutzt wird.

Daher wohl nur eine Erfolgsrate von ca. 40 Prozent, der geknackten Passwörter.

Argon2id findet man auch unter Linux Derivaten.

Grüße
Stefan
Stefan Claas
2022-09-16 12:39:23 UTC
Permalink
Europol und BKA haben dadurch z. B. es schwieriger, Passwort-Datenbanken zu knacken,
weil Argon2id bei denen noch nicht in hashcash und deren GPU Cluster genutzt wird.
Korrektur, hashcat und nicht hashcash, was für andere Sachen sinnvoll ist.

https://hashcat.net/hashcat/

Grüße
Stefan
Loading...