Passwort zu lang

[ddserv]

Ich benutze für gewähnlich MD5-Hashes in Hex als Passwörter. => 32 zeichen.
Das Debianforum sagt mir allerdings dass mein Passwort zu lange ist.

Könnte man das nicht auf 256 oder so erhöhen wie das sonst bei den meisten Textfeldern üblich ist? Ich meine das Debianforum macht doch in der datenbank -hoffentlich- sowieso einheitlich große hashes draus.

Ansosnten noch die kleine anmerkung dass man in HTML auch vorherh angeben kann wie große das maximal sein soll. Dann wundert man sich wenigstens nicht über die obskre Fehlermeldung.

[Meillo]

Gibt's denn dazu schon was Neues? (@feltel)

Ich bin ein grosser Verfechter von langen Passwoertern, d.h. Passphrases, deshalb faende ich es schoen, wenn es die Begrenzung auf 32 (?) Zeichen nicht gaebe. Mit meinem eigenen Passwort bleibe ich zwar darunter, bin aber nicht allzuweit davon entfernt.

Ich habe gelesen, dass sehr lange Passwoerter (~1MB) sehr viel Arbeitsspeicher brauchen. 128 oder 256 Zeichen sollten aber kein Problem darstellen.

Kann man das denn bei phpBB einstellen?

[uname]

Welchen Zweck hat ein langes Passwort? Der Sicherheit dient es bestimmt nicht.

[cronoik]

Doch. Ein einstelliges Passwort lässt sich ohne Probleme auch ohne Programm erraten...

[uname]

Klar. Wenn man weiß dass das Passwort einstellig ist

Warum Passwörter erraten wenn sie unverschlüsselt übertragen werden, der Rechner Schadcode enthält oder der Server aufgrund einer Sicherheitslücke gehackt werden kann. Dann kann man das Passwort in beliebiger Länge einfach mitlesen. Ach und anstatt die verschlüsselten Passwörter auf dem Server zu entschlüsseln (z.B. MySQL-Datenbank) würde ich natürlich an der Webanwendung ansetzen, da sich ja von Zeit zu Zeit die Benutzer auch anmelden, funktioniert sogar bei SSH-Servern Wie gesagt ich sehe keinen Sicherheitsgewinn ab sagen wir 4 Zeichen. Gibt es ordentliche Challenge-Response-Verfahren auf JavaScript-Basis, um nicht bei jeder Anmeldung das Passwort im Klartext zu übermitteln (ähnlich ZeroBin) ?

[wanne]

Wie gesagt ich sehe keinen Sicherheitsgewinn ab sagen wir 4 Zeichen.

Würde ich so nciht sagen. Bei so kurzen Passwörtern würde ich sagen, dass die eine Entropie von 4 Bit haben. (Das ist der denn man hat, wenn man zufällig zeichen aus einem Englischen/Deutschen Text rauszieht (john arbeitet so im incremental mode). Zum vergleich: Die Entropie im Grundgesetz beträgt unter 1,9Bit)
d.h. im schnitt (2^4)^4/2 Versuche. Hier auf meiner Leitung, die im Moment in etwa 40MBit/s macht braucht die hydra gerade etwa 250ms pro Versuch (Was sich eigentlich nochmal vervielfachen lassen solte. Ich denke 10 ms sollten da eigentlich locker drin sein. Kein plan warum das so lahm läuft.) => Im schnitt etwa 2h für 4stellige passwörter. Durchaus machbar. Und da kann man bestimmt optimieren. Wenn man da dran arebitet kommt man bestimmt mit unter 10 min hin.
Wenn du Chinesisch tippst siht's natürlich deutlich anders aus. Da reicht 4Stellig locker.

Gibt es ordentliche Challenge-Response-Verfahren auf JavaScript-Basis, um nicht bei jeder Anmeldung das Passwort im Klartext zu übermitteln (ähnlich ZeroBin) ?

Bruacht mak kein JS führ ist schon in HTTP eingebaut nennt sich Digest Access Authentication oder von Microsoft NTLM HTTP Authentication. Wird beides nicht eingesetzt, weil https deutlich sicherer (Bei aktiviertem Javascript kann man so ziemlich jedes Challange Response ohne probleme Brechen. Einschließlich der genannten.), performanter und vor allem schöner (man kann eigene loginfelder desighnen statt, dass der nutzer irgend ein popup bekommt) ist.

Webanwendung ansetzen, da sich ja von Zeit zu Zeit die Benutzer auch anmelden

Dazu gibt's clientseitiges hashing und https. Die üblichen Tools Funktionieren nur hier nicht, weil das passwortfeld zu klein für die üblichen MD5-Hashes sind.

ch habe gelesen, dass sehr lange Passwoerter (~1MB) sehr viel Arbeitsspeicher brauchen. 128 oder 256 Zeichen sollten aber kein Problem darstellen.

Versthe ich nicht. Da schmeist man doch einmal md5sum drüber und nach spätestens 4ms ist das dann schön 16byte groß. Der interne Status von MD5 ist doch ~16*4=64Byte. Das kann den Braten nicht fett machen. Für andere Hashingvrfahren dürfte das änlich aussehen.

[uname]

Dazu gibt's clientseitiges hashing und https.

Kannst du oder sonstwer mir sagen was beim Webserver (Anwendung z.B. phpBB) wirklich als "Passwort" ankommt. Also beim SSH-Server kommt das Passwort laut strace immer im Klartext an. Aber vielleicht hast SSH ja auch nicht diesen hohen Sicherheitsgedanken wie Webserver und dahinterliegende Webanwendungen wie phpBB.

[Meillo]

ch habe gelesen, dass sehr lange Passwoerter (~1MB) sehr viel Arbeitsspeicher brauchen. 128 oder 256 Zeichen sollten aber kein Problem darstellen.

Versthe ich nicht. Da schmeist man doch einmal md5sum drüber und nach spätestens 4ms ist das dann schön 16byte groß. Der interne Status von MD5 ist doch ~16*4=64Byte. Das kann den Braten nicht fett machen. Für andere Hashingvrfahren dürfte das änlich aussehen.

Keine Ahnung, ich habe nur das gelesen: https://tracker.phpbb.com/browse/PHPBB3-11873

[feltel]

Das Datenbanklayout von phpBB 3.0 sieht für das Passwort- und das Neues-Passwort-Feld Varchar 40 vor. Man könnte jetzt zwar ohne Probleme das Feld verlängern, die Frage ist dann jedoch, ob alle passwort-relevanten Funktionen mit längeren Hashes klar kommen. phpBB 3.1 ist gerade im Betazyklus und das dortige Datenbanklayout sieht für das Passwortfeld 255 Zeichen vor. Auch im Sinne eines bald anstehenden möglichst reibungslosen Upgrades würde ich gerne von einer Änderung am Datenbanklayout absehen.

[wanne]

Also beim SSH-Server kommt das Passwort laut strace immer im Klartext an.

Ja irgend wo intern mag er das PW im klartext vorhalten. Aber ankommen tut es verschlüsselt. Und das kan ein eigener SSH-Server dann schlicht nicht entschlüsseln. Also wenn du deinen eigenen aufsetzt hast du keine cance der kann das dann nicht entschlüsseln.

[TRex]

Das Datenbanklayout von phpBB 3.0 sieht für das Passwort- und das Neues-Passwort-Feld Varchar 40 vor. Man könnte jetzt zwar ohne Probleme das Feld verlängern, die Frage ist dann jedoch, ob alle passwort-relevanten Funktionen mit längeren Hashes klar kommen. phpBB 3.1 ist gerade im Betazyklus und das dortige Datenbanklayout sieht für das Passwortfeld 255 Zeichen vor. Auch im Sinne eines bald anstehenden möglichst reibungslosen Upgrades würde ich gerne von einer Änderung am Datenbanklayout absehen.

Soll heißen, wenns soweit ist, gibts die Möglichkeit längerer Passwörter. Ist doch gut... und bis es soweit ist, bin ich auch dafür, die Füße stillzuhalten. Hashes als Passwörter sind sicher cool, aber ein statistischer Ausreißer.

[wanne]

Neues-Passwort-Feld Varchar 40 vor.

Warum Kann ich dann maximal 30stellige Passwörter benutzen?

Das Datenbanklayout

Speichern wir die Passwörter im Klartext?
Bleibt folgendes:
In das HTML im entsprechenden PHP ein 'maxlength = "30"' ind dass passwort feld einzubauen stört keinen.

[wanne]

Das müsste im Style die template/ucp_profile_reg_details.html und die ucp_register.html sein.

[Meillo]

Neues-Passwort-Feld Varchar 40 vor.

Warum Kann ich dann maximal 30stellige Passwörter benutzen?

Das Datenbanklayout

Speichern wir die Passwörter im Klartext?

In der DB sollten doch nur Hashes stehen, oder ist das bei phpBB anders? Hashes sollten eine fixe Laenge haben. Damit sollte kein Aenderung an der DB noetig sein. Alleine die Eingabemaske (und die Logik dahinter) sollte angepasst werden muessen.