• Hallo liebe Userinnen und User,

    nach bereits längeren Planungen und Vorbereitungen sind wir nun von vBulletin auf Xenforo umgestiegen. Die Umstellung musste leider aufgrund der Serverprobleme der letzten Tage notgedrungen vorverlegt werden. Das neue Forum ist soweit voll funktionsfähig, allerdings sind noch nicht alle der gewohnten Funktionen vorhanden. Nach Möglichkeit werden wir sie in den nächsten Wochen nachrüsten. Dafür sollte es nun einige der Probleme lösen, die wir in den letzten Tagen, Wochen und Monaten hatten. Auch der Server ist nun potenter als bei unserem alten Hoster, wodurch wir nun langfristig den Tank mit Bytes vollgetankt haben.

    Anfangs mag die neue Boardsoftware etwas ungewohnt sein, aber man findet sich recht schnell ein. Wir wissen, dass ihr alle Gewohnheitstiere seid, aber gebt dem neuen Board eine Chance.
    Sollte etwas der neuen oder auch gewohnten Funktionen unklar sein, könnt ihr den "Wo issn da der Button zu"-Thread im Feedback nutzen. Bugs meldet ihr bitte im Bugtracker, es wird sicher welche geben die uns noch nicht aufgefallen sind. Ich werde das dann versuchen, halbwegs im Startbeitrag übersichtlich zu halten, was an Arbeit noch aussteht.

    Neu ist, dass die Boardsoftware deutlich besser für Mobiltelefone und diverse Endgeräte geeignet ist und nun auch im mobilen Style alle Funktionen verfügbar sind. Am Desktop findet ihr oben rechts sowohl den Umschalter zwischen hellem und dunklem Style. Am Handy ist der Hell-/Dunkelschalter am Ende der Seite. Damit sollte zukünftig jeder sein Board so konfigurieren können, wie es ihm am liebsten ist.


    Die restlichen Funktionen sollten eigentlich soweit wie gewohnt funktionieren. Einfach mal ein wenig damit spielen oder bei Unklarheiten im Thread nachfragen. Viel Spaß im ngb 2.0.

Warum ist die Passwortlänge oft begrenzt?

Rakshasa

Mitglied

Registriert
24 Juli 2013
Beiträge
176
Ort
ADL
Ahoi,

bei vielen Seiten (z.B. eBay, PayPal, ...) ist mir aufgefallen, dass die Länge des Passworts begrenzt ist (20 Zeichen).
Kann mir jemand erklären, warum das so ist? Mir fällt kein technischer Grund dafür ein, warum Passwörter nicht wenigstens 50 oder 100 Zeichen lang sein dürften - oder gibt es da einen?
Oder ist das eine Art Hintertür für die NSA, um Passwörter notfalls knackbar zu halten?

:confused:
 
Zuletzt bearbeitet:

keksautomat

Neu angemeldet

Registriert
15 Juli 2013
Beiträge
471
Du weißt ja nicht, mit welcher Datenbank "da hinter" gearbeitet wird. Kann mir schon vorstellen, dass es "doof" ist aus einem varchar(20) ein varchar(255) zu machen - ohne alte Daten zu gefährden. Und im/exportieren mit so gewaltigen Daten ist mit Sicherheit auch nicht witzig.

Anders kann ichs mir nicht erklären.
 

Kugelfisch

Nerd

Registriert
12 Juli 2013
Beiträge
2.342
Ort
Im Ozean
keksautomat, dieses Argument würde implizieren, dass Passwörter im Klartext gespeichert werden. Das wäre allerdings ohnehin problematisch. Kommt ein Hash-Verfahren zum Einsatz, wird durch die Hash-Funktion jede beliebige Eingabe auf eine Ausgabe fixer Länge abgebildet, demnach ist die Länge der Eingabe für die Speicherung irrelevant (schliesslich ist z.B. ein MD5-Password-Hash ebenso lang wie der MD5-Hash eines DVD-Images, 128 Bit; das gilt auch für Passwort-geeignete Hash-Algorithmen). Ich schätze, die vergleichsweise engen Grenzen sind historisch gewachsen und viele Website-Betreiber erwarten schlich nicht, dass ein Benutzer ein längeres Passwort verwenden möchte.

Eine gezielte Erleichterung für Geheimdienste ist meines Erachtens wenig wahrscheinlich. Einerseits lässt sich auch ein gutes 20-Zeichen-Passwort online nicht in akzeptabler Zeit erraten, andererseits wäre es für den Anbieter, der mit einem Geheimdienst kooperieren muss oder möchte, wesentlich einfacher, die Autorisierung über das Passwort schlicht zu umgehen und die gewünschten Daten direkt aus der Datenbank auszulesen.
 

Mr_J

Neu angemeldet

Registriert
14 Juli 2013
Beiträge
991
Wobei 20 Zeichen auch schon teilweise Luxus sind, ich hatte da schon Konsorten wo die Grenze um die 10 Zeichen lag und sowas geht mal garnicht.

MfG
Mr. J
 

kuromi

KU ♪ RO ♪ MI ♪ (shy)

Registriert
14 Juli 2013
Beiträge
13.113
Ort
ngb
Ich sag nur ICQ.
Oder haben die es inzwischen endlich mal geschafft das zu ändern?
 

p3Eq

zu nichts zu gebrauchen

Registriert
15 Juli 2013
Beiträge
358
Wäre es nicht auch denkbar, dass man bei Verwendung von hashfunktionen Kollisionen vermeiden will? Wäre ja möglich, dass jemand bei der verwendeten Funktion eine Schwachstelle entdeckt, die eine Kollision von nicht vorhersehbaren lange erzeugt und man durch eine entsprechende Begrenzung dieser Problematik entgegen wirken will. Ist aber auch nur eine Idee, normalerweise dürfte man, sofern man eine Kollision findet, wohl kaum nur für Menschen lesbare Zeichen dabei erhalten...
 

Rakshasa

Mitglied

Registriert
24 Juli 2013
Beiträge
176
Ort
ADL
  • Thread Starter Thread Starter
  • #8
Danke für eure Meinungen; ich bin ja schon froh, wenn die Webseitenbetreiber die Eingabe des Passworts beim Login begrenzen! Denn wenn das Passwort bei der Einrichtung kommentarlos nach 20 Zeichen abgeschnitten wird, aber beim späteren Login länger sein darf, wird es für den User düster.

Das Problem hatte ich gerade bei meinem Hoster - und ich wundere mich, warum mein Passwort auch über Copy & Paste nicht funktioniert... :m :rolleyes:
 

accC

gesperrt

Registriert
14 Juli 2013
Beiträge
5.250
Wäre es nicht auch denkbar, dass man bei Verwendung von hashfunktionen Kollisionen vermeiden will?
Jein. Hashfunktionen können prinzipiell technisch bedingt keine Kollisionen vermeiden. Wenn du 256bit Input hast, aber als Output bspw nur 64bit, dann muss es logischerweise Kollisionen geben. [Du hast 256bit viele Inputmöglichkeiten, aber nur 64bit viele Outputmöglichkeiten.] Hashfunktionen versuchen lediglich das Auffinden einer solcher Kollisonen schwer zu machen. Laus sollte keinenfalls den gleichen Hash wie Maus haben, auch wenn "nur" ein Buchstabe ausgetauscht wurde.

Wäre ja möglich, dass jemand bei der verwendeten Funktion eine Schwachstelle entdeckt, die eine Kollision von nicht vorhersehbaren lange erzeugt und man durch eine entsprechende Begrenzung dieser Problematik entgegen wirken will.
Du verstehst da etwas falsch. Eine Kollision bedeutet, dass die Hashfunktion f(x) -> y für zwei verschiedene Eingaben x1, x2 mit x1 != x2 ein gemeinsamen Hash erzeugt, also f(x1) = f(x2)
Die Länge von x1, x2 sowie f(x1), f(x2) spielt dabei erst mal keine Rolle.
 

Tourgott

für immer™

Registriert
14 Juli 2013
Beiträge
640
Mich nervt eher, dass es tatsächlich noch Anbieter gibt, die keine Sonderzeichen erlauben.
 

p3Eq

zu nichts zu gebrauchen

Registriert
15 Juli 2013
Beiträge
358
@accC: Dein erstes Zitat ist falsch von mir formuliert gewesen. Sollte heißen: ..., dass man die Verwendung der Kollisionen von Hashfunktionen vermeiden will.
Was ein Hash ist, ist mir durchaus bekannt.

Die Problematik, die ich angesprochen habe, ist eher folgende: Angenommen ich habe eine Hashfunktion h, die den Wert 2 auf 281 abildet. Nun finde ich eine Schwachstelle in der Hashfunktion, mit der es mir gelingt, eine Kollision zu finden, sodass h(x) = 281 ist, wobei x meine Kollision ist.
Die Kollision ist möglicherweise (je nachdem, was für eine Schwachstelle man gefunden hat und um was für einen Algorithmus es geht) aber deutlich länger als ein normales Kennwort es wäre.
Dann würde man einer solchen Problematik entgehen, indem man die Länge des Kennworts beim Login auf beispielsweise 20 Zeichen begrenzt, auch wenn ich es für unwahrscheinlich halte, dass so ein Angriff in der Praxis überhaupt stattfinden könnte (da die Kollision vermutlich nicht von Menschen lesbar sein wird, sondern auch Steuerzeichen usw enthalten kann).
 

alter_Bekannter

N.A.C.J.A.C.

Registriert
14 Juli 2013
Beiträge
4.829
Ort
Midgard
Aufgrund Langfristiger Erfahrungswerte würde ich sagen das es in den meisten Fällen durchaus an daran liegt das nicht mit Hashfunktionen
gearbeitet wird, wer das jetzt bedenklich findet hat vollkommen recht.

Ich denke der Fisch ist da etwas zu optimistisch und unterschätzt die Inkompetenz anderer.

Ich möchte daher an dieser Stelle anmerken das ich es durchaus schon gesehen habe das jemand Passwörter zum vergleichen an den Client sendet
und in einer solchen Welt halte ich nichts für unmöglich, es soll sich jetzt mal jeder selber ausmalen auf wie vielen Ebenen die beschriebene
Vorgehensweise unfassbar dumm ist. Ich kann nur sagen beim lesen des enstprechenden Codes hat man Live bemerkt wie man langsam aber
sicher verblödet, ungefähr so wie beim Fernsehen.
 

Pleitgengeier

offizielles GEZ-Haustier

Registriert
14 Juli 2013
Beiträge
7.378
Ort
127.0.0.1
Mich nervt eher, dass es tatsächlich noch Anbieter gibt, die keine Sonderzeichen erlauben.
Mich nervt eher, dass es genug seiten gibt, die vorschreiben dass PWs aus Sonderzeichen, Groß-, Kleinbuchstaben und Ziffern bestehen müssen.

Ein Bruteforce-Angriff auf ein zB 25stelliges Passwort aus Text (zumal der Angreifer ja gar nicht wissen kann ob Sonderzeichen enthalten sind) dauert wesentlich länger als ein Angriff auf ein 10stelliges, zufallsgeneriertes Passwort aus Sonderzeichen, Groß/kleinbuhstaben und zahlen.
Und bitte noch die Schwierigkeit bedenken, dass man sich das ganze noch merken können muss...
 

Registriert
14 Juli 2013
Beiträge
715
Sagen wir so, ich wusste schon vorher von diesem Irrtum, aber ich versteh nicht ganz was diese Entropie bedeutet bzw. wie man auf diese Werte kommt.
Vielleicht könnte jemand nettes mir dies bitte erklären, interessiert mich jedenfalls sehr.
Genauso warum man 2^ irgendwas nimmt, wieso 2?
Vielleicht steh ich gerade auch auf dem Schlauch weil es so spät ist, aber ich versteh es gerade net wirklich :D
 

Mr_J

Neu angemeldet

Registriert
14 Juli 2013
Beiträge
991
Man nimmt die 2 deshalb weil Computersysteme letzten Ende immer binär arbeiten und somit die meisten Begrifflichkeiten gerne mit Zweipotenzen geschrieben werden.

MfG
Mr. J
 

p3Eq

zu nichts zu gebrauchen

Registriert
15 Juli 2013
Beiträge
358
Ist einfach eine Konvention mit der zwei als Basis. Als "zu rechenaufwändig" (also auch für Cluster von Geheimdiensten) gilt übrigens 2^80, allerdings nur mittelfristig lange. Empfohlen wird 128 bit Sicherheit, bzw 256, falls man sich gegen Quantencomputer auch absichern möchte.
 

bevoller

Neu angemeldet

Registriert
4 Aug. 2013
Beiträge
1.481
Die Problematik, die ich angesprochen habe, ist eher folgende: Angenommen ich habe eine Hashfunktion h, die den Wert 2 auf 281 abildet. Nun finde ich eine Schwachstelle in der Hashfunktion, mit der es mir gelingt, eine Kollision zu finden, sodass h(x) = 281 ist, wobei x meine Kollision ist.
Die Kollision ist möglicherweise (je nachdem, was für eine Schwachstelle man gefunden hat und um was für einen Algorithmus es geht) aber deutlich länger als ein normales Kennwort es wäre.
Dann würde man einer solchen Problematik entgehen, indem man die Länge des Kennworts beim Login auf beispielsweise 20 Zeichen begrenzt, auch wenn ich es für unwahrscheinlich halte, dass so ein Angriff in der Praxis überhaupt stattfinden könnte (da die Kollision vermutlich nicht von Menschen lesbar sein wird, sondern auch Steuerzeichen usw enthalten kann).
Dann unterliegst du meiner Ansicht nach immer noch dem Irrtum, dass die Länge des Hashwertes von der Passwortlänge abhängig ist.
Übrigens... Wenn ein längeres Passwort zwangsläufig einen längern Hash erzeugen würde, dann wäre die Wahrscheinlichkeit einer Hashkollision doch geringer. Denn 30 identische Zeichen in einer bestimmten Reihenfolge zu treffen, dürfte unwahrscheinlicher sein, als nur 20 identische Zeichen in der richtigen Reihenfolge.

Sagen wir so, ich wusste schon vorher von diesem Irrtum, aber ich versteh nicht ganz was diese Entropie bedeutet bzw. wie man auf diese Werte kommt.
Kann dir hier so ac hoc wohl keiner gut verständlich beantworten. Gibt aber hier und hier schicke Lektüre dazu.
Wenn alle Stricke reißen, hilft vielleicht der liebe Onkel Harald weiter. http://www.youtube.com/watch?v=4VS0LR5iIMU Schau ich mir gleich auf jeden Fall mal an. Ist ja meist recht interessant, was der so erzählt.

Interessant ist die Thematik allemal. Denn angeblich ist der komplett ausgeschriebene Satz (bzw. sinnvolle Wörter) als Passwort ja leichter zu merken und sicherer (das Wesentliche mal unterstrichen ;)).
Umgekehrt ist es aber so, dass Satzzeichen unterschiedlich häufig benutzt werden. In der deutschen Sprache liegt z.B. (soweit ich weiß) das "e" auf Platz 1. Jepp - und die restlichen Platzierungen kann man sich selbst anschauen. Klick

Die Verteilung im Text sollte sich auch maschinell herausfinden lassen. Insofern würde ich vermuten, dass ein deutscher Satz als Passwort eher ungünstig ist, weil man an der Häufigkeit der Buchstaben im Satz Rückschlüsse auf die Satzzeichen ziehen kann. Außerdem müssten zumindest die einzelnen Wörter ja einen Sinn ergeben. Hier vermute ich allerdings stark, dass die Maschine bei einer Deutung dem Menschen unterlegen ist.

Die Entropie müsste außerdem geringer sein, denn: "Bei einer kleinen Entropie enthält der Informationstext Redundanzen oder statistische Regelmäßigkeiten." Das ist übrigens auch im Beispiellink von Mr_J der Fall. Bis auf das "c" kommen dort alle Buchstaben mehrfach vor.

Mein Ansatz, warum so eine Passwortkombination trotzdem sicherer ist:
Die Zahl der verwendeten Zeichen ist wesentlich höher (11:25 ohne Leerzeichen). Und jedes verwendete Zeichen kann entweder richtig oder falsch sein.
Probiere ich ein Passwort aus, habe ich also bei dem längeren Passwort häufiger die Chance, daneben zu liegen und ein falsches Zeichen einzugeben => höhere Entropie. Das deckt sich dann auch wieder mit: "Noch einfacher formuliert, ist die Entropie die durchschnittliche Anzahl von Entscheidungen (bits), die benötigt werden, um ein Zeichen aus einer Zeichenmenge zu identifizieren oder zu isolieren."

So - und jetzt warte ich mal auf eine Erklärung von Mr_J. Ganz explitzit erläutern und vorrechnen lassen wir uns das dann von Kugelfisch. ;)
 
Oben