längerer Schlüssel

[Wendelin Uez]

Wieso soll eigentlich ein langer Schlüssel sicherer sein als ein kurzer?

Der Angreifer weiß ja nicht, welche Schlüssellänge verwendet wurde, und für
brute force Attacken, bei denen er die kürzeren schneller durch hat,
funktionieren ja auch nur, wenn die Prüfzeiten null sind, d.h. bei falschem
Schlüssel keine Mindestwartezeit bis zum nächsten Ausprobieren gegeben ist
oder paralle Attacken gefahren werden können - das wäre dann aber ein Manko
des Servers, nicht des Algorithmus'.

[Juergen Ilse]

Wendelin Uez <wu...@online.de> wrote:
> Wieso soll eigentlich ein langer Schlüssel sicherer sein als ein kurzer?

Sofern man die Schluessellaenge kennt, ist das so, weil es bei einem kurzen
Schluessel weitaus weniger Moegloichkeiten gibt und damit "brute force" zum
knacken deutlich erfolgversprechender wird.

> Der Angreifer weiß ja nicht, welche Schlüssellänge verwendet wurde, und für
> brute force Attacken, bei denen er die kürzeren schneller durch hat,
> funktionieren ja auch nur, wenn die Prüfzeiten null sind, d.h. bei falschem
> Schlüssel keine Mindestwartezeit bis zum nächsten Ausprobieren gegeben ist
> oder paralle Attacken gefahren werden können - das wäre dann aber ein Manko
> des Servers, nicht des Algorithmus'.

Wenn der Angreifer keine Moeglichkeit hat, an die Informtion der veerwen-
deten Schluessellaenge zu gelangen, waere ein kurzer Schluessel in der Tat
nicht weniger sicher als ein langer (sofern der Angreifer nicht bei den
kurzen Schluessellaengen sein brute force Attacke beginnt. was ja durch-
aus nicht so unwahrsscheinlich waere, da er von den kurzen SSchluesseln
viel mehr in begrenzter Zeit testen koennte).

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Christian Treffler]

Wendelin Uez schrieb:

> brute force Attacken, bei denen er die kürzeren schneller durch hat,

> funktionieren ja auch nur, wenn die Prüfzeiten null sind, [...]

> das wäre dann aber ein Manko
> des Servers, nicht des Algorithmus'.

Nun werden aber oft Login-Daten durch Einbrüche in Datenbanken entwendet
und dann auf den Rechnern der Einbrecher einer Brute-Force-Attacke
unterzogen. Der Server des Dienste-Anbieters ist dann außen vor und
Prüfzeiten sind nahe null.

CU,
Christian

[Marcel Mueller]

Am 16.07.21 um 14:06 schrieb Wendelin Uez:

> Wieso soll eigentlich ein langer Schlüssel sicherer sein als ein kurzer?

Aus demselben Grund aus dem ein 1 Zeichen langes Passwort nicht dadurch
sicherer wird, dass es auch 100 Zeichen haben /könnte/.

> Der Angreifer weiß ja nicht, welche Schlüssellänge verwendet wurde, und
> für brute force Attacken, bei denen er die kürzeren schneller durch hat,
> funktionieren ja auch nur, wenn die Prüfzeiten null sind, d.h. bei
> falschem Schlüssel keine Mindestwartezeit bis zum nächsten Ausprobieren
> gegeben ist oder paralle Attacken gefahren werden können - das wäre dann
> aber ein Manko des Servers, nicht des Algorithmus'.

Wenn man die Prüfrate oder die Anzahl limitiert ist vieles sicher.
Selbst die 4-stellige EC-Pin ist durch das Limit auf 3 Versuche kaum
sinnvoll zu knacken. Wenn man nur die Rate begrenzen kann, muss man sich
schon deutlich mehr Mühe mit dem Schlüssel geben. Und wenn das eben auch
nicht geht, weil man sich mit dem Public Key in aller Ruhe ins
Hinterkämmerchen setzen kann, dann zählt die Länge noch erheblich mehr.
Sie muss so groß sein, das auf absehbare Zeit damit kein wirtschaftlich
profitabler Angriff möglich ist. Falls Wirtschaftlichkeit keine Rolle
spielt, weil die andere Seite unbegrenzte Mittel hat (Spionage), dann
hat man nur noch die Zeit auf seiner Seite. Es muss also lange genug
dauern, um den Schlüssel zu knacken. Zusammen mit Perfect Forward
Security ist das durchaus noch ein scharfes Schwert. Aber es schützt
natürlich trotzdem nicht immer, denn es gibt Myriaden von potentiellen
Seitenkanalattacken und natürlich die Schwachstelle Mensch.


Marcel

[Juergen Ilse]

Hallo,

Marcel Mueller <news.5...@spamgourmet.org> wrote:
> Am 16.07.21 um 14:06 schrieb Wendelin Uez:
>> Wieso soll eigentlich ein langer Schlüssel sicherer sein als ein kurzer?
>
> Aus demselben Grund aus dem ein 1 Zeichen langes Passwort nicht dadurch
> sicherer wird, dass es auch 100 Zeichen haben /könnte/.

... und das kann tatsaechlich sicherersein, weil sehr viele Angreifer bei
"bute force" Attacken "1 Zeichen Passworte" auslassen wuerden, weil sie
die (wegen fehlender Sicherheit" fuer unmoeglich halten ...
So lange keinerlei Hinweis daauf besteht, wie kurz oder lang das Passwort
sein kann, kann man mit einem "1 Zeichen Passwwort" tatsaechlich u.U.
noch einigermassen gut da stehen ...
;-)

>> Der Angreifer weiß ja nicht, welche Schlüssellänge verwendet wurde, und
>> für brute force Attacken, bei denen er die kürzeren schneller durch hat,
>> funktionieren ja auch nur, wenn die Prüfzeiten null sind, d.h. bei
>> falschem Schlüssel keine Mindestwartezeit bis zum nächsten Ausprobieren
>> gegeben ist oder paralle Attacken gefahren werden können - das wäre dann
>> aber ein Manko des Servers, nicht des Algorithmus'.
>
> Wenn man die Prüfrate oder die Anzahl limitiert ist vieles sicher.
> Selbst die 4-stellige EC-Pin ist durch das Limit auf 3 Versuche kaum
> sinnvoll zu knacken. Wenn man nur die Rate begrenzen kann, muss man sich
> schon deutlich mehr Mühe mit dem Schlüssel geben. Und wenn das eben auch
> nicht geht, weil man sich mit dem Public Key in aller Ruhe ins
> Hinterkämmerchen setzen kann, dann zählt die Länge noch erheblich mehr.

Wenn du keinerlei Hinweis auf die Laenge hast, bei welchen Schluesseln
wuerdeest du eine brute Force Attacke beginnen? Wenn du als Angreifer
pauschal sagen wuerdest "Schluessellaengen bis 1024 probiere ich gar nicht
erst aus, weil die wegen der Unsicherheit bestimmt niemand nutzt", haette
man bei dir als Angreifer mit einem kurzen Schluessel evt. einen deutlichen
Vorteil ...
Das ist nun kein Plaedoyer fuer kurrze Schluessel, sondern ein Hinweis,
dass ein kurzer Schluesseel oder ein kurzes Passwort nicht bei jedem
moeglichen denkbaren Angreifer gleich unsicher sein muss.

Tscchuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Marcel Mueller]

Am 17.07.21 um 22:41 schrieb Juergen Ilse:

> Marcel Mueller <news.5...@spamgourmet.org> wrote:
>> Am 16.07.21 um 14:06 schrieb Wendelin Uez:
>>> Wieso soll eigentlich ein langer Schlüssel sicherer sein als ein kurzer?
>>
>> Aus demselben Grund aus dem ein 1 Zeichen langes Passwort nicht dadurch
>> sicherer wird, dass es auch 100 Zeichen haben /könnte/.
>
> ... und das kann tatsaechlich sicherersein, weil sehr viele Angreifer bei
> "bute force" Attacken "1 Zeichen Passworte" auslassen wuerden, weil sie
> die (wegen fehlender Sicherheit" fuer unmoeglich halten ...

Damit spart man nichts an Zeit.

> So lange keinerlei Hinweis daauf besteht, wie kurz oder lang das Passwort
> sein kann, kann man mit einem "1 Zeichen Passwwort" tatsaechlich u.U.
> noch einigermassen gut da stehen ...

Sorry, aber das ist Unsinn.

>> Wenn man die Prüfrate oder die Anzahl limitiert ist vieles sicher.
>> Selbst die 4-stellige EC-Pin ist durch das Limit auf 3 Versuche kaum
>> sinnvoll zu knacken. Wenn man nur die Rate begrenzen kann, muss man sich
>> schon deutlich mehr Mühe mit dem Schlüssel geben. Und wenn das eben auch
>> nicht geht, weil man sich mit dem Public Key in aller Ruhe ins
>> Hinterkämmerchen setzen kann, dann zählt die Länge noch erheblich mehr.
>
> Wenn du keinerlei Hinweis auf die Laenge hast, bei welchen Schluesseln
> wuerdeest du eine brute Force Attacke beginnen?

Bei den einfachsten natürlich. Geringster Aufwand bei erstaunlicher
Trefferquote. Wie war das noch Gleich? "12345" ist der Favorit?
Aufgrund des exponentiell steigenden Aufwands sind die jeweils kürzeren
Lösungen jeweils nur ein verschwindend geringer Anteil der nächst
größeren Variante.

> Wenn du als Angreifer
> pauschal sagen wuerdest "Schluessellaengen bis 1024 probiere ich gar nicht
> erst aus, weil die wegen der Unsicherheit bestimmt niemand nutzt", haette
> man bei dir als Angreifer mit einem kurzen Schluessel evt. einen deutlichen
> Vorteil ...

Hätte, falls, im Sinne von wenn.

> Das ist nun kein Plaedoyer fuer kurrze Schluessel, sondern ein Hinweis,
> dass ein kurzer Schluesseel oder ein kurzes Passwort nicht bei jedem
> moeglichen denkbaren Angreifer gleich unsicher sein muss.

Nein, komplette Deppen bekommen das dann nicht raus.


Marcel

[Wendelin Uez]

> Nun werden aber oft Login-Daten durch Einbrüche in Datenbanken entwendet
> und dann auf den Rechnern der Einbrecher einer Brute-Force-Attacke
> unterzogen. Der Server des Dienste-Anbieters ist dann außen vor und
> Prüfzeiten sind nahe null.

Versteh ich nicht - die Brute-Force-Passwörter können doch nur am
antwortenden Objekt getstet werden und nicht unabhängig davon. Ob ein
Passwort funktioniert oder nicht wird doch nur durch die Antwort des Servers
bestimmt, oder nicht?

[Thomas Hochstein]

Wendelin Uez schrieb:

> > Nun werden aber oft Login-Daten durch Einbrüche in Datenbanken entwendet
> > und dann auf den Rechnern der Einbrecher einer Brute-Force-Attacke
> > unterzogen. Der Server des Dienste-Anbieters ist dann außen vor und
> > Prüfzeiten sind nahe null.
>
> Versteh ich nicht

Offenbar.

> - die Brute-Force-Passwörter können doch nur am
> antwortenden Objekt getstet werden und nicht unabhängig davon.

Passworte können "verlorengehen", d.h. durch Einbrüche entwendet
werden. (Und das passiert regelmäßig.) Damit man sich dann nicht
direkt damit anmelden kann, werden Passworte - hoffentlich - nicht im
Klartext, sondern als Hash gespeichert, also einer Transformation
unterworfen, die nicht umkehrbar ist. Wenn man sich anmeldet, prüft
das System nicht, ob man das Passwort eingibt, dass es in der
Datenbank gespeichert hat, sondern ob man ein Passwort eingibt, dessen
Hash dem entspricht, der in der Datenbank gespeichert wurde. Dieses
Prinzip ist uralt.

Zwar lässt sich aus einem Hash nicht das Klartext-Passwort erzeugen,
aber man kann natürlich so lange Klartest-Passworte hashen, bis man
den Klartext gefunden hat, der den Hash erzeugt, der in der geklauten
Datenbank steht (brute force). Dann kann man sich mit den entwendeten
Logindaten anmelden.

> Ob ein
> Passwort funktioniert oder nicht wird doch nur durch die Antwort des Servers
> bestimmt, oder nicht?

Wenn man das richtige Passwort bereits ermittelt hat, braucht man es
nicht mehr am lebenden Objekt zu testen.

-thh

[Thomas Hochstein]

Wendelin Uez schrieb:

> Der Angreifer weiß ja nicht, welche Schlüssellänge verwendet wurde, und für
> brute force Attacken, bei denen er die kürzeren schneller durch hat,
> funktionieren ja auch nur, wenn die Prüfzeiten null sind, d.h. bei falschem
> Schlüssel keine Mindestwartezeit bis zum nächsten Ausprobieren gegeben ist
> oder paralle Attacken gefahren werden können - das wäre dann aber ein Manko
> des Servers, nicht des Algorithmus'.

Natürlich kann man Mindestwartezeiten erzwingen oder den Zugang sogar
nach mehreren Fehlversuchen - für eine bestimmte Zeit oder endgültig -
sperren; so sind ja bspw. die Onlinebanking-Zugänge und ec-Karten
gesichert. Das hat allerdings den Nachteil, dass man auf diese Weise
sehr leicht legitime Nutzer aussperren kann.

Ich bin mir nicht sicher, wie groß die Begeisterung wäre, wenn man
Mails erst dann wieder abholen kann, wenn der Brute-Force-Angreifer
mit seinen Versuchen durch ist (und dann die Wartezeit abgelaufen ist)
oder wenn man auf sein Postfach immer nur mit einem Thread
gleichzeitig zugreifen kann, weil parallele Anmeldungen ja doof sind.

-thh

[Stefan Claas]

On Sunday, July 18, 2021 at 11:45:02 AM UTC+2, Thomas Hochstein wrote:
> Wendelin Uez schrieb:
> > > Nun werden aber oft Login-Daten durch Einbrüche in Datenbanken entwendet
> > > und dann auf den Rechnern der Einbrecher einer Brute-Force-Attacke
> > > unterzogen. Der Server des Dienste-Anbieters ist dann außen vor und
> > > Prüfzeiten sind nahe null.
> >
> > Versteh ich nicht
> Offenbar.
> > - die Brute-Force-Passwörter können doch nur am
> > antwortenden Objekt getstet werden und nicht unabhängig davon.
> Passworte können "verlorengehen", d.h. durch Einbrüche entwendet
> werden. (Und das passiert regelmäßig.) Damit man sich dann nicht
> direkt damit anmelden kann, werden Passworte - hoffentlich - nicht im
> Klartext, sondern als Hash gespeichert, also einer Transformation
> unterworfen, die nicht umkehrbar ist. Wenn man sich anmeldet, prüft
> das System nicht, ob man das Passwort eingibt, dass es in der
> Datenbank gespeichert hat, sondern ob man ein Passwort eingibt, dessen
> Hash dem entspricht, der in der Datenbank gespeichert wurde. Dieses
> Prinzip ist uralt.
>
> Zwar lässt sich aus einem Hash nicht das Klartext-Passwort erzeugen,
> aber man kann natürlich so lange Klartest-Passworte hashen, bis man
> den Klartext gefunden hat, der den Hash erzeugt, der in der geklauten
> Datenbank steht (brute force). Dann kann man sich mit den entwendeten
> Logindaten anmelden.

Das BKA z.B. macht das über Europol und nutzt dazu einen hashcat GPU cluster.
Also brauchen die IMHO nur ganz legal Zugriff auf Server Datenbanken.

Grüße
Stefan

[Juergen Ilse]

Ein "offline testen" der Passworte setzt voraus, dass der Angreifer an die
"verschluesselten Passworte" auf dem Server herangekommen ist (z.B. durch
andere Sicherheitsluecken auf dem Server). Ht der Angreifer diese Daten
*nicht* zur Vefuegung, ist auch diese Art von "offline testen" der Passworte
nicht moeglich.

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Arno Welzel]

Wendelin Uez:

> Wieso soll eigentlich ein langer Schlüssel sicherer sein als ein kurzer?

Weil es länger dauert, sie auszuprobieren.

> Der Angreifer weiß ja nicht, welche Schlüssellänge verwendet wurde, und für
> brute force Attacken, bei denen er die kürzeren schneller durch hat,
> funktionieren ja auch nur, wenn die Prüfzeiten null sind, d.h. bei falschem

Nein, sie funktionieren auch, wenn die Prüfzeiten nicht null sind,
solange man unbgrenzt viele Versuche hat.


--
Arno Welzel
https://arnowelzel.de

[Arno Welzel]

Wendelin Uez:

Es gibt auch Schlüssel, die nicht für den Login bei einem Server benutzt
werden.

[Wendelin Uez]

>> Der Angreifer weiß ja nicht, welche Schlüssellänge verwendet wurde, und
>> für
>> brute force Attacken, bei denen er die kürzeren schneller durch hat,
>> funktionieren ja auch nur, wenn die Prüfzeiten null sind, d.h. bei
>> falschem
>> Schlüssel keine Mindestwartezeit bis zum nächsten Ausprobieren gegeben
>> ist
>> oder paralle Attacken gefahren werden können - das wäre dann aber ein
>> Manko
>> des Servers, nicht des Algorithmus'.
>
> Natürlich kann man Mindestwartezeiten erzwingen oder den Zugang sogar
> nach mehreren Fehlversuchen - für eine bestimmte Zeit oder endgültig -
> sperren; so sind ja bspw. die Onlinebanking-Zugänge und ec-Karten
> gesichert. Das hat allerdings den Nachteil, dass man auf diese Weise
> sehr leicht legitime Nutzer aussperren kann.

Auf was ich hinaus will: Einem Angreifer nützt doch seine ganze Rechenpower
nichts, solange er ein Passwort nicht am zugehörigen Server testen kann -
selbst wenn er den gespeicherten Hash-Wert erbeutet kann er nichts damit
anfangen, wenn er nicht weiß, an welchem Server er ihn einsetzen kann.

Man kann ein Passwort nicht im leeren Raum knacken, man braucht immer den
zugehörigen Server dazu.

Und eine brute force Attacke an einem bestimmten Server, die alle denkbaren
Schlüssel durchprobiert, kann doch nur dann erfolgreich sein, wenn der
Server sorgloserweise tausende Login-Versuche anstandslos sofort beantwortet
und bei Fehlern keine Konsequenzen zieht.

Ich kann mir nicht helfen, aber die Verwendung langer und komplizierter
Schlüssel ist doch überflüssig, wenn der Server, wie z.B. bei der Fritz!Box,
auf einen falschen Schlüssel mit (dazu noch) ansteigender Wartezeit
reagiert. Das ist doch wie bei den Bankkarten mit nur vier oder fünf Zahlen,
da ist nach drei Fehleingaben Schluß, und brute force Attacken können erst
gar nicht stattfinden.

Was für mich bedeutet, lange und komplizierte Passwörter sind genau nur dort
nötig, wo die Server schlampern, und eigentlich nur der Versuch, dies dem
User anzulasten.

Oder gibt es etwas, was ich übersehen habe?

> Ich bin mir nicht sicher, wie groß die Begeisterung wäre, wenn man
> Mails erst dann wieder abholen kann, wenn der Brute-Force-Angreifer
> mit seinen Versuchen durch ist (und dann die Wartezeit abgelaufen ist)
> oder wenn man auf sein Postfach immer nur mit einem Thread
> gleichzeitig zugreifen kann, weil parallele Anmeldungen ja doof sind.

Die parallelen Anmeldungen müssen ja nicht in derselben Sekunde erfolgen,
manuelles Login verträgt durchaus Wartezeiten von 1..10 Sekunden, und damit
sind brute force Attacken hinfällig.

[Arno Welzel]

Wendelin Uez:

[...]

> Auf was ich hinaus will: Einem Angreifer nützt doch seine ganze Rechenpower
> nichts, solange er ein Passwort nicht am zugehörigen Server testen kann -
> selbst wenn er den gespeicherten Hash-Wert erbeutet kann er nichts damit
> anfangen, wenn er nicht weiß, an welchem Server er ihn einsetzen kann.
>
> Man kann ein Passwort nicht im leeren Raum knacken, man braucht immer den
> zugehörigen Server dazu.

Nein, die Kenntnis, wo das Passwort benutzt wird, reicht, wenn man den
Hash dazu kennt. Dann probiert man so lange, bis man den selben Hash
erhält und kann sich dann mit dem Passwort an dem Server anmelden, wo es
verwendet wird.

> Oder gibt es etwas, was ich übersehen habe?

Dass der Angreifer weiß, welcher Server das Passwort akzeptiert, nachdem
er offline ein Passwort zu dem kopierten Hash erzeugen konnte.

[Wendelin Uez]

> Nein, die Kenntnis, wo das Passwort benutzt wird, reicht, wenn man den
> Hash dazu kennt. Dann probiert man so lange, bis man den selben Hash
> erhält und kann sich dann mit dem Passwort an dem Server anmelden, wo es
> verwendet wird.
>
>> Oder gibt es etwas, was ich übersehen habe?
>
> Dass der Angreifer weiß, welcher Server das Passwort akzeptiert, nachdem
> er offline ein Passwort zu dem kopierten Hash erzeugen konnte.

Ja, das ist hatte ich jetzt nicht im Fokus.

Der Normalo kommt eben mit Passworten primär im Zusammenhang mit Accounts
und Login in Verbindung. Und da wird ihm - meiner Ansicht nach
fälschlicherweise - geraten, möglichst lange und komplizierte Passwörter zu
verwenden und damit ihm die Verantwortung für die Sicherheit seines Accounts
zugesprochen, während es tatsächlich hauptsächlich ein Problem der
Serverantwortzeit ist und die Länge des Passworts lediglich von
untergeordneter Wichtgkeit.

[Helmut Waitzmann]

"Wendelin Uez" <wu...@online.de>:

Es wird ihm zu Recht geraten, ein langes Passwort zu verwenden. 
Schau folgendes Szenario an:  Angenommen, du hast ein kurzes
Passwort gewählt, weil der Server, bei dem du es verwendest, nur 3
Versuche erlaubt, ehe er dich für (relativ) lange Zeit an weiteren
Einlogg‐Versuchen hindert.  Weiter sei angenommen, dass ich auf
irgendeine Weise an den Hashwert deines Passworts herangekommen
bin.  Dann kann ich auf meinem Rechner (oder besser einem
leistungsfähigeren anderen) mittels brute force ein Passwort suchen,
das denselben Hashwert wie dein Passwort hat.  (Das muss
strenggenommen nicht einmal dasselbe Passwort wie deines sein; es
genügt, dass es denselben Hashwert hat.)  Dieses Suchen geht auf dem
von mir dafür verwendeten Rechner schnell, und der Server, auf dem
du dein Passwort verwendest, ist dabei nicht beteiligt.

Erst dann, wenn ich ein passendes Passwort gefunden habe, logge ich
mich am Server ein; und dazu brauche ich genau einen Versuch, denn
ich weiß ja, dass mein von mir gefundenes Passwort denselben
Hashwert wie deines liefert, also vom Server akzeptiert werden wird.

=> Wenn Brute‐Force‐Angriffe auf bekannte Hashwerte von Passwörtern
möglich sind, helfen lange Serverantwortzeiten genau gar nichts.

[Helmut Waitzmann]

Helmut Waitzmann <nn.th...@xoxy.net>:

>Angenommen, du hast ein kurzes Passwort gewählt, weil der Server,
>bei dem du es verwendest, nur 3 Versuche erlaubt, ehe er dich für
>(relativ) lange Zeit an weiteren Einlogg‐Versuchen hindert. 

Der Satz ist schief gegangen.  Richtig muss er wie folgt heißen:


Angenommen, du hast ein kurzes Passwort gewählt, weil dir der
Server, bei dem du es verwendest, nach 3 Einlogg‐Versuchen mit dem
falschen Passwort erst nach (relativ) langer Zeit weitere Versuche
erlaubt. 

[Wendelin Uez]

> Weiter sei angenommen, dass ich auf irgendeine Weise an den Hashwert
> deines Passworts herangekommen bin. Dann kann ich auf meinem Rechner (oder
> besser einem leistungsfähigeren anderen) mittels brute force ein Passwort
> suchen, das denselben Hashwert wie dein Passwort hat. (Das muss
> strenggenommen nicht einmal dasselbe Passwort wie deines sein; es genügt,
> dass es denselben Hashwert hat.) Dieses Suchen geht auf dem von mir dafür
> verwendeten Rechner schnell, und der Server, auf dem du dein Passwort
> verwendest, ist dabei nicht beteiligt.

Das setzt aber voraus, daß der Algorithmus zur Berechnung des Hashwerts
bekannt ist. Es gibt sicher publizierte Algorithmen dafür, aber ich würde
doch annehmen, daß die Server-Programmierer da ein bißchen Abwechslung
hinein bringen. Und Algorithmus-Änderungen dürften anders als
brute-force-Passwortprobiererei schwieriger durchzuprobieren sein. Die Menge
der potentiellen Passörter kann man relativ leicht abarbeiten, weil man die
zu testenden Paßwörter problemlos generieren kann - es ist ja nur eine Frage
der Quantität,.Aber Algorithmen, deren Konstrujtionsregeln man ja nicht
kennt (bei Paßwörtern kennt man sie), dürften deutlich schwerer
durchzuprobieren sein.

Ansonsten, selbst wenn ich den Algorithmus kenne und alle denkbaren
Paßwörter durchprobieren kann, ist der Hashwert ja normalerweise unabhängig
von der Paßwortlänge, was wiederum bedeutet, daß der Hashcode eines langen
Paßworts auch identisch sein kann mit dem eines kürzeren.

[Marc Haber]

"Wendelin Uez" <wu...@online.de> wrote:
>> Weiter sei angenommen, dass ich auf irgendeine Weise an den Hashwert
>> deines Passworts herangekommen bin. Dann kann ich auf meinem Rechner (oder
>> besser einem leistungsfähigeren anderen) mittels brute force ein Passwort
>> suchen, das denselben Hashwert wie dein Passwort hat. (Das muss
>> strenggenommen nicht einmal dasselbe Passwort wie deines sein; es genügt,
>> dass es denselben Hashwert hat.) Dieses Suchen geht auf dem von mir dafür
>> verwendeten Rechner schnell, und der Server, auf dem du dein Passwort
>> verwendest, ist dabei nicht beteiligt.
>
>Das setzt aber voraus, daß der Algorithmus zur Berechnung des Hashwerts
>bekannt ist. Es gibt sicher publizierte Algorithmen dafür, aber ich würde
>doch annehmen, daß die Server-Programmierer da ein bißchen Abwechslung
>hinein bringen.

"Don't roll your own crypto."
"Security by obscurity doesnt work"

Es gibt sogar Library-Routinen zum Hashen von Passworten.

Außerdem sind sehr viele Server-Applikationen Open Source, da nimmt
man im Zweifel einfach den Originalcode.

Weißt Du was ein gesalzener Hash ist?

--
-------------------------------------- !! 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

[Stephan Seitz]

Marc Haber <mh+usene...@zugschl.us> wrote:
> Weißt Du was ein gesalzener Hash ist?

Die Frage ist doch, ob man immer an einem Hash erkennen kann, mit
welchem Algorithmus er erstellt wurde.

Unter Linux kannst du verschiedene Algorithmen für die Paßwörter in
/etc/shadow wählen.

Stephan

--
| Stephan Seitz E-Mail: stse+...@rootsland.net |
| If your life was a horse, you'd have to shoot it. |

[Helmut Waitzmann]

"Wendelin Uez" <wu...@online.de>:

>> Weiter sei angenommen, dass ich auf irgendeine Weise an den
>> Hashwert deines Passworts herangekommen bin. Dann kann ich auf
>> meinem Rechner (oder besser einem leistungsfähigeren anderen)
>> mittels brute force ein Passwort suchen, das denselben Hashwert
>> wie dein Passwort hat. (Das muss strenggenommen nicht einmal
>> dasselbe Passwort wie deines sein; es genügt, dass es denselben
>> Hashwert hat.) Dieses Suchen geht auf dem von mir dafür
>> verwendeten Rechner schnell, und der Server, auf dem du dein
>> Passwort verwendest, ist dabei nicht beteiligt.
>
>Das setzt aber voraus, daß der Algorithmus zur Berechnung des
>Hashwerts bekannt ist.

Ja, genau, und das ist in der Regel der Fall:

>Es gibt sicher publizierte Algorithmen dafür, aber ich würde doch
>annehmen, daß die Server-Programmierer da ein bißchen Abwechslung
>hinein bringen.

Das eher nicht:  An Hash‐Algorithmen werden – damit sie ihren Zweck
erfüllen – bestimmte mathematische Anforderungen gestellt.  Da
erfindet man nicht mal so einfach einen neuen.  Eine dieser
Anforderungen wäre beispielsweise, dass Rückwärtsrechnen, also aus
einem gegebenen Hashwert das Original (häufig eigentlich: eines von
mehreren Originalen) zu berechnen, nicht möglich ist – sonst
bräuchte man ja im Fall des bekannten Hashwertes eines gesuchten
Passworts keine Brute‐Force‐Methode, sondern könnte einfach ein zum
Hashwert passendes Passwort berechnen.  Siehe auch das
Wikipedia‐Lemma «Hashfunktion»
(<https://de.wikipedia.org/wiki/Hashfunktion#top>), dort besonders
<https://de.wikipedia.org/wiki/Hashfunktion#Kriterien> und
<https://de.wikipedia.org/wiki/Hashfunktion#Kryptologie>, sowie das
Lemma «Kryptographische Hashfunktion»
(<https://de.wikipedia.org/wiki/Kryptographische_Hashfunktion#top>).

>Und Algorithmus-Änderungen dürften anders als
>brute-force-Passwortprobiererei schwieriger durchzuprobieren sein.

Das mag einerseits sein; andererseits könnte es sein, dass ein
geänderter Algorithmus im Gegensatz zum Original angreifbar ist,
weil er eine der Anforderungen nicht mehr erfüllt.

>Die Menge der potentiellen Passörter kann man relativ leicht
>abarbeiten, weil man die zu testenden Paßwörter problemlos

>generieren kann - es ist ja nur eine Frage der Quantität.

Genau: nur eine Frage der Quantität.  Deswegen ist es ja so wichtig,
die Länge der Passwörter so groß zu wählen, dass die riesige Anzahl
möglicher Passwörter die Brute‐Force‐Methode vereitelt.

>Aber Algorithmen, deren Konstrujtionsregeln man ja nicht kennt (bei
>Paßwörtern kennt man sie), dürften deutlich schwerer
>durchzuprobieren sein.
>
>Ansonsten, selbst wenn ich den Algorithmus kenne und alle denkbaren
>Paßwörter durchprobieren kann, ist der Hashwert ja normalerweise
>unabhängig von der Paßwortlänge, was wiederum bedeutet, daß der
>Hashcode eines langen Paßworts auch identisch sein kann mit dem
>eines kürzeren.

Genau.  Trotzdem sind kurze Passwörter keine so gute Idee:


Wenn ich als Angreifer irgendwo her erfahre, dass du ein kurzes
Passwort verwendest, dann probiere ich bei der Brute‐Force‐Methode
(zuerst) kurze Passwörter aus.  Wenn ich als Angreifer irgendwo her
erfahre, dass du ein langes Passwort verwendest, dann probiere ich
bei der Brute‐Force‐Methode (zuerst) lange Passwörter aus.

Ein Beispiel soll zeigen, warum lange Passwörter besser sind:  Nimm
um des einfachen Rechnens willen an, Passwörter dürften nur aus
Folgen der Ziffern von 0 bis 9 bestehen, und es dürften maximal 4
Ziffern sein.  Dann gibt es zu jeder Passwortlänge eine genau
bestimmte Anzahl von Passwörtern:

Passwortlänge | Anzahl | Beispiele
--------------+--------+-----------------------------
1 | 10 | 0, 1, 2, 3, 4, 5, 6, 7, 8, 9
2 | 100 | 00, 01, …, 10, 11, …, 98, 99
3 | 1000 | 000, 001, …, 998, 999
4 | 10000 | 0000, 0001, …, 9998, 9999

Die Anzahl der Passwörter bestehend aus mindestens 1 und höchstens 3
Ziffern ist demnach 1110.  Die Anzahl der Passwörter bestehend aus 4
Ziffern ist 10000.

Ein Passwort welcher Länge wirst du also wählen, wenn du es einem
Brute‐Force‐Angriff möglichst schwer machen willst?

Wenn der Angreifer nicht weiß, ob du lange oder kurze Passwörter
bevorzugst, ist er nach spätestens 11110 Hashwertberechnungen am
Ziel.

Falls der Angreifer irgendwo her erfahren hat, dass du ein möglichst
langes Passwort wählst, muss er immer noch bis zu 10000 Hashwerte
berechnen, ehe er ein passendes Passwort gefunden hat.  Das sind
etwa 90 % der Passwörter des Falls, wo der Angreifer nichts über
dich weiß.

Wenn er hingegen weiß, dass du kürzere Passwörter bevorzugst, wird
er der Reihe nach die Passwörter der Längen 1, 2 und 3 probieren und
ist bei spätestens 1110 Versuchen am Ziel.  Das sind etwa 10 % der
Passwörter des Falls, wo er nichts über dich weiß, und etwa 11 % der
Passwörter des Falls, wo er weiß, dass du ein möglichst langes
Passwort wählst.

=> Willst du ein möglichst sicheres Passwort, nimm eines mit der
maximal erlaubten Anzahl an Zeichen, dann verlierst du im Fall, dass
der Angreifer irgendwo her erfährt, wie lang dein Passwort ist, am
wenigsten (im Beispiel: etwa 10 %).

[Marc Haber]

Stephan Seitz <stse+...@rootsland.net> wrote:
>Marc Haber <mh+usene...@zugschl.us> wrote:
>> Weißt Du was ein gesalzener Hash ist?
>
>Die Frage ist doch, ob man immer an einem Hash erkennen kann, mit
>welchem Algorithmus er erstellt wurde.
>
>Unter Linux kannst du verschiedene Algorithmen für die Paßwörter in
>/etc/shadow wählen.

Und man kann an dem Hash erkennen welcher Algorithmus verwendet wurde.
Und das ist auch gut so.

Grüße
Marc

[Wendelin Uez]

>>Die Frage ist doch, ob man immer an einem Hash erkennen kann, mit
>>welchem Algorithmus er erstellt wurde.
>>
>>Unter Linux kannst du verschiedene Algorithmen für die Paßwörter in
>>/etc/shadow wählen.
>
> Und man kann an dem Hash erkennen welcher Algorithmus verwendet wurde.
> Und das ist auch gut so.

Na, dann sag uns mal, welcher Algorithmus den Hashwert 7159087415687568
produzierte?

[Marc Haber]

Ein völlig unzureichender, da viel zu kurz.

Wir reden hier übrigens von Hashes für Passwörter, und dafür gibt es
einen Standard, man 5 crypt.

Du weißt was ein gesalzener Hash ist?

[Stephan Seitz]

Marc Haber <mh+usene...@zugschl.us> wrote:

> "Wendelin Uez" <wu...@online.de> wrote:
>>Na, dann sag uns mal, welcher Algorithmus den Hashwert 7159087415687568
>>produzierte?
> Ein völlig unzureichender, da viel zu kurz.

Das war jetzt nicht wirklich die Antwort auf die Frage, aber solche
Hashes habe ich schon häufiger in Datenbanken gesehen. Es gibt also
Anwendungen, die solche Hashes erstellen.

Shade and sweet water!

[Bastian Blank]

Wendelin Uez wrote:
> Na, dann sag uns mal, welcher Algorithmus den Hashwert 7159087415687568
> produzierte?

https://xkcd.com/221/

Bastian
>

[Wendelin Uez]

>>Na, dann sag uns mal, welcher Algorithmus den Hashwert 7159087415687568
>>produzierte?
>
> Ein völlig unzureichender, da viel zu kurz.

Normalerweise ist Heiterkeit produzieren nicht deine Stärke.

> Wir reden hier übrigens von Hashes für Passwörter, und dafür gibt es
> einen Standard, man 5 crypt.

Muß ein weitverbreiteter Standard sein, wenn eine Google-Suche nach "man 5
crypt" (incl. Anführungszeichen) exakt einen einzigen Treffer liefert.

[Stefan Claas]

Ich würde an deiner Stelle lieber nach Argon2 googeln und mal fragen
ob Betreiber, die man so nutzt, selbigen schon einsetzen ...

Grüße
Stefan

[Marc Haber]

Du bist entweder ein Troll oder hast so wenig Grundwissen, dass sich
weitergehende Diskussion auf für mich akzeptablem Niveau erübrigt.

[Wendelin Uez]

> Du bist entweder ein Troll oder hast so wenig Grundwissen, dass sich
> weitergehende Diskussion auf für mich akzeptablem Niveau erübrigt.

Schade, wenn man schon mit wenig Grundwissen über deinem akzeptablen Niveau
liegt.

[Thomas Heuving]

Stephan Seitz schrieb am 30 Jul 2021 09:50:33 GMT:
> Marc Haber <mh+usene...@zugschl.us> wrote:
>> "Wendelin Uez" <wu...@online.de> wrote:
>>>Na, dann sag uns mal, welcher Algorithmus den Hashwert 7159087415687568
>>>produzierte?
>> Ein völlig unzureichender, da viel zu kurz.
>
> Das war jetzt nicht wirklich die Antwort auf die Frage, aber solche
> Hashes habe ich schon häufiger in Datenbanken gesehen. Es gibt also
> Anwendungen, die solche Hashes erstellen.

Aber nicht in /etc/shadow, da wirst du so einen Hashwert nicht
finden, sondern nur welche, an denen man das verwendete Verfahren
erkennen kann.
> man 5 crypt
| FORMAT OF HASHED PASSPHRASES
| All of the hashing methods supported by crypt(3) produce a
| hashed passphrase which consists of four components:
| prefix, options, salt, and hash. The prefix controls which
| hashing method is to be used, and is the appropriate
| string to pass to crypt_gensalt(3) to select that method.

Tschüß
--
Thomas Heuving

[Thomas Heuving]

Mach dich doch nicht so zum Honk. Wer bei "man 5 crypt" nicht auf
die Idee kommt, in der Shell genau diese Zeichenfolge einzugeben und
dann die Manpage von crypt(5) lesen zu können, der sollte wirklich
ganz still sein. Ergo: Du bist ein Troll oder hast aber auch nicht
die geringste Ahnung.

Tschüß
--
Thomas Heuving

[Stephan Seitz]

Thomas Heuving <heu...@gmx.de> wrote:
> Stephan Seitz schrieb am 30 Jul 2021 09:50:33 GMT:
>> Marc Haber <mh+usene...@zugschl.us> wrote:
>>> "Wendelin Uez" <wu...@online.de> wrote:
>>>>Na, dann sag uns mal, welcher Algorithmus den Hashwert 7159087415687568
>>>>produzierte?
>>> Ein völlig unzureichender, da viel zu kurz.
>> Das war jetzt nicht wirklich die Antwort auf die Frage, aber solche
>> Hashes habe ich schon häufiger in Datenbanken gesehen. Es gibt also
>> Anwendungen, die solche Hashes erstellen.
> Aber nicht in /etc/shadow, da wirst du so einen Hashwert nicht
> finden, sondern nur welche, an denen man das verwendete Verfahren
> erkennen kann.

Keiner schrieb, daß der Hash aus /etc/shadow sein müßte. Marc
brabbelte, daß man am Hash den Algorithmus erkennen kann, aber
natürlich kann er nicht liefern.

[Wendelin Uez]

> Mach dich doch nicht so zum Honk. Wer bei "man 5 crypt" nicht auf
> die Idee kommt, in der Shell genau diese Zeichenfolge einzugeben und
> dann die Manpage von crypt(5) lesen zu können, der sollte wirklich
> ganz still sein. Ergo: Du bist ein Troll oder hast aber auch nicht
> die geringste Ahnung.

geht auf einem Windows nur dummerweise schlecht bis gar nicht

[Marc Haber]

Stephan Seitz <stse+...@rootsland.net> wrote:
>Thomas Heuving <heu...@gmx.de> wrote:
>> Stephan Seitz schrieb am 30 Jul 2021 09:50:33 GMT:
>>> Marc Haber <mh+usene...@zugschl.us> wrote:
>>>> "Wendelin Uez" <wu...@online.de> wrote:
>>>>>Na, dann sag uns mal, welcher Algorithmus den Hashwert 7159087415687568
>>>>>produzierte?
>>>> Ein völlig unzureichender, da viel zu kurz.
>>> Das war jetzt nicht wirklich die Antwort auf die Frage, aber solche
>>> Hashes habe ich schon häufiger in Datenbanken gesehen. Es gibt also
>>> Anwendungen, die solche Hashes erstellen.
>> Aber nicht in /etc/shadow, da wirst du so einen Hashwert nicht
>> finden, sondern nur welche, an denen man das verwendete Verfahren
>> erkennen kann.
>
>Keiner schrieb, daß der Hash aus /etc/shadow sein müßte. Marc
>brabbelte, daß man am Hash den Algorithmus erkennen kann, aber
>natürlich kann er nicht liefern.

Was muss ich liefern? Ich schrieb, dass es einen Standard für die
Formatierung (gesalzener) Hashes gibt und verwies auf dessen
Dokumentation.

Freilich gibt es überall Deppen, die der Meinung sind, es besser zu
können als diejenigen, die den Standard definiert haben und die
partout selbst programmieren wollen anstelle einfach die vorhandene
(und dem Stand der Technik entsprechende und sich mit diesem ohne
weiteres Zutun weiterentwickelnde) Library-Routine zu nutzen.

"Don't Roll your own Crypto" müsste in der FAQ dieser Gruppe stehen,
wenn es eine gäbe.

[Stefan Kanthak]

"Marc Haber" <mh+usene...@zugschl.us> schrieb:

> Stephan Seitz <stse+...@rootsland.net> wrote:
>>Thomas Heuving <heu...@gmx.de> wrote:
>>> Stephan Seitz schrieb am 30 Jul 2021 09:50:33 GMT:
>>>> Marc Haber <mh+usene...@zugschl.us> wrote:
>>>>> "Wendelin Uez" <wu...@online.de> wrote:
>>>>>>Na, dann sag uns mal, welcher Algorithmus den Hashwert 7159087415687568
>>>>>>produzierte?
>>>>> Ein völlig unzureichender, da viel zu kurz.
>>>> Das war jetzt nicht wirklich die Antwort auf die Frage, aber solche
>>>> Hashes habe ich schon häufiger in Datenbanken gesehen. Es gibt also
>>>> Anwendungen, die solche Hashes erstellen.
>>> Aber nicht in /etc/shadow, da wirst du so einen Hashwert nicht
>>> finden, sondern nur welche, an denen man das verwendete Verfahren
>>> erkennen kann.
>>
>>Keiner schrieb, daß der Hash aus /etc/shadow sein müßte. Marc
>>brabbelte, daß man am Hash den Algorithmus erkennen kann, aber
>>natürlich kann er nicht liefern.
>
> Was muss ich liefern?

Nichts!
Dein (mit gaaanz kurzem Gedaechtnis gesegneter) Vorposter hat in
<news:im9qhh...@mid.individual.net> auf /etc/shadow hingewiesen
... und jetzt will er's nicht gewesen sein.

wehret den Trollen
Stefan
--
<https://www.duden.de/rechtschreibung/Kanthaken>

[Stephan Seitz]

Stefan Kanthak <postmaster@[127.0.0.1]> wrote:
> Nichts!
> Dein (mit gaaanz kurzem Gedaechtnis gesegneter) Vorposter hat in
> <news:im9qhh...@mid.individual.net> auf /etc/shadow hingewiesen
> ... und jetzt will er's nicht gewesen sein.

Du trollst oder bist blöd.

Wenn du intelligent für Quotingebenen wärest, hättest du gesehen, daß
es gar nicht mehr um /etc/shadow ging.

Marc brabbelte, daß man den Algorithmus am Hash erkennen kann. Jemand
gab ein Hash-Beispiel, wie er in Datenbanken zu finden ist, also wie
irgendwelche Anwendungen in der Wildnis etwas generieren und
speichern, und wollte von Marc den Algorithmus genannt bekommen.

Und wie üblich konnte der nicht liefern.

Aber um das zu erkennen, brauchst du halt Verstand...

[Marc Haber]

Stephan Seitz <stse+...@rootsland.net> wrote:
>Und wie üblich konnte der nicht liefern.

Was muss ich liefern? Ich schrieb, dass es einen Standard für die
Formatierung (gesalzener) Hashes gibt und verwies auf dessen
Dokumentation.

[Arno Welzel]

Wendelin Uez:

>> Weiter sei angenommen, dass ich auf irgendeine Weise an den Hashwert
>> deines Passworts herangekommen bin. Dann kann ich auf meinem Rechner (oder
>> besser einem leistungsfähigeren anderen) mittels brute force ein Passwort
>> suchen, das denselben Hashwert wie dein Passwort hat. (Das muss
>> strenggenommen nicht einmal dasselbe Passwort wie deines sein; es genügt,
>> dass es denselben Hashwert hat.) Dieses Suchen geht auf dem von mir dafür
>> verwendeten Rechner schnell, und der Server, auf dem du dein Passwort
>> verwendest, ist dabei nicht beteiligt.
>
> Das setzt aber voraus, daß der Algorithmus zur Berechnung des Hashwerts
> bekannt ist. Es gibt sicher publizierte Algorithmen dafür, aber ich würde

Das ist in der Regel der Fall.

> doch annehmen, daß die Server-Programmierer da ein bißchen Abwechslung
> hinein bringen. Und Algorithmus-Änderungen dürften anders als

Nein, genau das tun sie nicht. Eigene Algorithmen zu erfinden, ist
zuverlässiger Weg, ein System unsicher zu machen. Genau deshalb gilt es
auch als best practice, für Verschlüsselung und Hashing nur
dokumentierte und geteste Algorithmen einzusetzen.

[...]

> Ansonsten, selbst wenn ich den Algorithmus kenne und alle denkbaren
> Paßwörter durchprobieren kann, ist der Hashwert ja normalerweise unabhängig
> von der Paßwortlänge, was wiederum bedeutet, daß der Hashcode eines langen
> Paßworts auch identisch sein kann mit dem eines kürzeren.

Korrekt. Allerdings geht die Berechnung von Hashwerten für kürzere
Passwörter deutlich schneller und nicht alle langen Passwörter führen zu
den selben Werten, wie kürzere Passwörter.

[Arno Welzel]

Wendelin Uez:

<https://www.tunnelsup.com/hash-analyzer/> sagt, es könnte "LM or MySQL
< version 4.1" sein - aber vermutlich hast Du Dir die Zahl einfach so
ausgedacht.

[Arno Welzel]

Stephan Seitz:

> Stefan Kanthak <postmaster@[127.0.0.1]> wrote:
>> Nichts!
>> Dein (mit gaaanz kurzem Gedaechtnis gesegneter) Vorposter hat in
>> <news:im9qhh...@mid.individual.net> auf /etc/shadow hingewiesen
>> ... und jetzt will er's nicht gewesen sein.
>
> Du trollst oder bist blöd.
>
> Wenn du intelligent für Quotingebenen wärest, hättest du gesehen, daß
> es gar nicht mehr um /etc/shadow ging.
>
> Marc brabbelte, daß man den Algorithmus am Hash erkennen kann. Jemand
> gab ein Hash-Beispiel, wie er in Datenbanken zu finden ist, also wie
> irgendwelche Anwendungen in der Wildnis etwas generieren und
> speichern, und wollte von Marc den Algorithmus genannt bekommen.

Falsch!

Zitat dessen was Marc in <sdpl7j$2gj$1...@news1.tnib.de> schrieb::

| > Unter Linux kannst du verschiedene Algorithmen für die Paßwörter in
| > /etc/shadow wählen.
|
| Und man kann an dem Hash erkennen welcher Algorithmus verwendet wurde.
| Und das ist auch gut so.

D.h. Marc bezog sich ganz klar auf /etc/shadow und dass man DORT(!)
erkennen kann, welcher Algorithmus verwendet wurde.

Aber um das zu erkennen, müsste man Texten schon vollständig folgen und
sich nicht nur einzelne Sätze aus dem Zusammenhang reißen.

[Arno Welzel]

Wendelin Uez:

> Muß ein weitverbreiteter Standard sein, wenn eine Google-Suche nach "man 5 > crypt" (incl. Anführungszeichen) exakt einen einzigen Treffer liefert.

Man merkt, dass keine Ahnung hast, was mit dem Hinweis gemeint ist. Du
sollst das nicht bei Google eingeben. Aber ich helfe Dir dennoch:

<https://manpages.debian.org/unstable/libcrypt-dev/crypt.5.en.html>

[Arno Welzel]

Wendelin Uez:

Dass Du Windows benutzt und dein Wissen darauf beschränkst, ist deine
ganz persönliche Entscheidung.

[Ralph Angenendt]

Well, Stephan Seitz <stse+...@rootsland.net> wrote:
> Stefan Kanthak <postmaster@[127.0.0.1]> wrote:
>> Nichts!
>> Dein (mit gaaanz kurzem Gedaechtnis gesegneter) Vorposter hat in
>> <news:im9qhh...@mid.individual.net> auf /etc/shadow hingewiesen
>> ... und jetzt will er's nicht gewesen sein.
>
> Du trollst oder bist blöd.
>
> Wenn du intelligent für Quotingebenen wärest, hättest du gesehen, daß
> es gar nicht mehr um /etc/shadow ging.

Aha.

| >>>Unter Linux kannst du verschiedene Algorithmen für die Paßwörter in
| >>>/etc/shadow wählen.
| >>
| >> Und man kann an dem Hash erkennen welcher Algorithmus verwendet
| >> wurde.
| >> Und das ist auch gut so.
| >

| >Na, dann sag uns mal, welcher Algorithmus den Hashwert 7159087415687568
| >produzierte?
|
| Ein völlig unzureichender, da viel zu kurz.
|

| Wir reden hier übrigens von Hashes für Passwörter, und dafür gibt es
| einen Standard, man 5 crypt.

Magst du noch mal daran überlegen, ob dein Vorwurf der Dummheit
gerechtfertigt ist oder nicht?

> Marc brabbelte, daß man den Algorithmus am Hash erkennen kann. Jemand
> gab ein Hash-Beispiel, wie er in Datenbanken zu finden ist, also wie
> irgendwelche Anwendungen in der Wildnis etwas generieren und
> speichern, und wollte von Marc den Algorithmus genannt bekommen.
>
> Und wie üblich konnte der nicht liefern.

Aha. Dass das Quatsch ist, kannst du ja oben selber sehen.

> Aber um das zu erkennen, brauchst du halt Verstand...

Ja. Scheint ja bei dir im Übermaß vorhanden.

Ralph
--
Übervaterlandverräter und Mutterkornblumenblau

[Thomas Heuving]

Stephan Seitz schrieb am 2 Aug 2021 10:16:14 GMT:
> Thomas Heuving <heu...@gmx.de> wrote:
>> Stephan Seitz schrieb am 30 Jul 2021 09:50:33 GMT:
>>> Marc Haber <mh+usene...@zugschl.us> wrote:
>>>> "Wendelin Uez" <wu...@online.de> wrote:
>>>>>Na, dann sag uns mal, welcher Algorithmus den Hashwert 7159087415687568
>>>>>produzierte?
>>>> Ein völlig unzureichender, da viel zu kurz.
>>> Das war jetzt nicht wirklich die Antwort auf die Frage, aber solche
>>> Hashes habe ich schon häufiger in Datenbanken gesehen. Es gibt also
>>> Anwendungen, die solche Hashes erstellen.
>> Aber nicht in /etc/shadow, da wirst du so einen Hashwert nicht
>> finden, sondern nur welche, an denen man das verwendete Verfahren
>> erkennen kann.
>
> Keiner schrieb, daß der Hash aus /etc/shadow sein müßte. Marc
> brabbelte, daß man am Hash den Algorithmus erkennen kann, aber
> natürlich kann er nicht liefern.

Marc erwähnte explizit /etc/shadow!

Tschüß
--
Thomas Heuving

[Stephan Seitz]

Arno Welzel <use...@arnowelzel.de> wrote:
> Falsch!
>
> Zitat dessen was Marc in <sdpl7j$2gj$1...@news1.tnib.de> schrieb::

Du zitierst unvollständig. Vor dem Beispiel mit /etc/shadow schrieb
ich nämlich noch:

|Die Frage ist doch, ob man immer an einem Hash erkennen kann, mit
|welchem Algorithmus er erstellt wurde.
|

|Unter Linux kannst du verschiedene Algorithmen für die Paßwörter in
|/etc/shadow wählen.

Ich habe als Beispiel /etc/shadow gewählt. Ich hätte auch htpasswd mit
seinen unterschiedlichen Optionen wählen können.

Da steht dann manchmal der Algorithmus davor (z.B. {SHA}). Aber ich
könnte dir nicht sagen, ob das jetzt auch für den Betrieb nötig ist
oder nur ein Hinweis für einen Beobachter.

> D.h. Marc bezog sich ganz klar auf /etc/shadow und dass man DORT(!)
> erkennen kann, welcher Algorithmus verwendet wurde.

Nein, Marc quotete mich komplett, das heißt, man kann durchaus davon
ausgehen, daß er nicht nur mein Beispiel gemeint hat sondern es war
seine Antwort auf meine allgemeine Frage.

> Aber um das zu erkennen, müsste man Texten schon vollständig folgen und
> sich nicht nur einzelne Sätze aus dem Zusammenhang reißen.

Tja, dann fang doch damit an und quote komplett und nicht nur Teile
aus dem Zusammenhang.

Abgesehen ist das für die Problematik im Thread auch egal. Wenn
irgendwelche Zugangsdaten von (meistens) Webdiensten abhanden kommen,
dann sind das keine Paßwörter aus /etc/shadow sondern irgendwelche
Datenbankinhalte.

Wie dort teilweise Paßwörter gehasht werden, haben wir ja im Thread
auch als Beispiel gehabt.

Shade and sweet water!

[Arno Welzel]

Stephan Seitz:

> Arno Welzel <use...@arnowelzel.de> wrote:
>> Falsch!
>>
>> Zitat dessen was Marc in <sdpl7j$2gj$1...@news1.tnib.de> schrieb::
>
> Du zitierst unvollständig. Vor dem Beispiel mit /etc/shadow schrieb
> ich nämlich noch:
>
> |Die Frage ist doch, ob man immer an einem Hash erkennen kann, mit
> |welchem Algorithmus er erstellt wurde.
> |
> |Unter Linux kannst du verschiedene Algorithmen für die Paßwörter in
> |/etc/shadow wählen.
>
> Ich habe als Beispiel /etc/shadow gewählt. Ich hätte auch htpasswd mit
> seinen unterschiedlichen Optionen wählen können.
>
> Da steht dann manchmal der Algorithmus davor (z.B. {SHA}). Aber ich
> könnte dir nicht sagen, ob das jetzt auch für den Betrieb nötig ist
> oder nur ein Hinweis für einen Beobachter.

Es ist nötig, weil Linux auch selber wissen muss, nach welchem
Algorithmus aus dem eingegebenen Passwort beim Login der Hash erzeugt
werden muss.

>> D.h. Marc bezog sich ganz klar auf /etc/shadow und dass man DORT(!)
>> erkennen kann, welcher Algorithmus verwendet wurde.
>
> Nein, Marc quotete mich komplett, das heißt, man kann durchaus davon
> ausgehen, daß er nicht nur mein Beispiel gemeint hat sondern es war
> seine Antwort auf meine allgemeine Frage.

Ich habe das nicht so verstanden - denn die Aussage, dass man bei
*allen* Hashes sehen kann, wie sie erstellt wurden, wäre kompletter Unsinn.

[Arno Welzel]

Thomas Noll:

> Am Tue, 3 Aug 2021 11:32:53 +0200 schrieb Arno Welzel:
>
>
>> Allerdings geht die Berechnung von Hashwerten für kürzere
>> Passwörter deutlich schneller
>

> Für welches Verfahren und warum?

Für fast alle weil kürzere Passwörter weniger Daten sind, die man in die
Berechnung des Hash einbeziehen muss. Man kann natürlich auch pauschal
jedes Passwort auf eine feste Länge mit Füllzeichen verlängern, damit
die Dauer der Berechnung keinen Rückschluss auf die Passwortlänge gibt.

[Stephan Seitz]

Arno Welzel <use...@arnowelzel.de> wrote:
>> Nein, Marc quotete mich komplett, das heißt, man kann durchaus davon
>> ausgehen, daß er nicht nur mein Beispiel gemeint hat sondern es war
>> seine Antwort auf meine allgemeine Frage.
> Ich habe das nicht so verstanden - denn die Aussage, dass man bei
> *allen* Hashes sehen kann, wie sie erstellt wurden, wäre kompletter Unsinn.

Aber das war ja meine Frage. Hätte er sich nur auf mein Beispiel
bezogen, hätte er meine Frage nicht zu quoten brauchen (bzw. zum
Verständnis her gar nicht dürfen).

[Wendelin Uez]

>> Keiner schrieb, daß der Hash aus /etc/shadow sein müßte. Marc
>> brabbelte, daß man am Hash den Algorithmus erkennen kann, aber
>> natürlich kann er nicht liefern.
>
> Marc erwähnte explizit /etc/shadow!

Nein, das erwähnte er eben nicht, schon gar nicht explizit, jedenfalls nicht
in der Antwort, in der diese Behauptung von ihm gemacht wurde.

Er sprach zuvor zwar von Linux, aber seine freistehende Behauptung ohne
Bezug auf vorheriges, man könne aus dem Hash den Algorithmus erkennen, ist
und war aus der Luft gegriffen, um wieder mal meine Unkenntnis beweisen zu
wollen. :-)

Sich jetzt hinterher auf einen vorangehenden Absatz zu berufen, in dem auf
Linux in einem ganz anderen Zusammenhang hingewiesen wurde, ist zwar ein
mäßig eleganter Rettungsversuch, aber ansonsten nicht statthaft - man sollte
sich so ausdrücken, daß der Gegenüber auch weiß, was man meint, wir
schreiben hier nicht notarielle Verträge.

Und er hat sich so ausgedrückt, daß man den reklamierten Bezug nicht
annehmen musste.

wuez

p.s.: es hätte mich auch gewundert, wenn er den Algorithmus gewusst hätte