htpasswd - Passwort wieviele Stellen?

[Daaron]

72 Byte = 72 Zeichen in ASCII.... sicher genug, würd ich sagen.

...und sowohl PBKDF2 als auch SHA2 mit mehreren Iterationen sind hier schlichtweg nicht MÖGLICH. Die sicherste Methode, die Apache unterstützt, ist bcrypt. Daher auch: Ist der aktuell sicherste verfügbare Algorithmus.

Man könnte jetzt natürlich PBKDF2 in Apache integrieren. Genauso könnte man ein Salt-Verfahren für die bestehenden Hash-Verfahren einbauen. Könnte man... Upstream MACHT es aber keiner. Es IST nicht vorhanden. Es ist also schlichtweg scheißegal, was du mit deinen 5 Affen treibst. Hier wird dir auch der letzte Affe noch sagen: Lies die Dokumentation. Was du machen willst funktioniert nicht. Implementiere es selbst oder nimm, was da ist.

 

[ice-breaker]

72 Byte = 72 Zeichen in ASCII.... sicher genug, würd ich sagen.

widerspricht aber deiner Aussage, eines Supports für unendlich lange Passwörter

...und sowohl PBKDF2 als auch SHA2 mit mehreren Iterationen sind hier schlichtweg nicht MÖGLICH. Die sicherste Methode, die Apache unterstützt, ist bcrypt. Daher auch: Ist der aktuell sicherste verfügbare Algorithmus.

der sicherste unter diesen Einschränkungen!

 

[1668mib]

Naja Daaron schrieb "da steht nichts von Zeichenlimit" ;-)

 

[Daaron]

Die Apache-Dokumentation sagt schlichtweg nichts über ein Zeichenlimit von bcrypt aus, während sie bei Crypt Hash explizit auf die 8 Zeichen hinweist. Ob und wie bcrypt dann doch limitiert, darüber habe ich keine Aussage getroffen... und es spielt hier auch keine Rolle. Schließlich soll hier ein 30-40 Zeichen langes PW verwendet werden.

Und mal ernsthaft: Wie lang ist dein längstes PW?

Ach ja: Bcrypt über 50 Zeichen ist immer noch deutlich besser als MD5 oder SHA (ohne Salt) über 500 Zeichen.... Also was solls? Haarspalterei.

 

[IMakeULoveMe]

@ice-breaker
Mich würde noch interessieren warum es schlimm ist wenn bcrypt nur die erste 72 Bytes Verwendet.
Die meisten werden sich gar keine 72 Bytes merken können.
Schlimmstenfalls kann man ja mit SHA vorhashen.
Wahrscheinlich ist es derzeit egal ob man nun bcrypt or PBKDF2 nimmt.

 

[Daaron]

Na ja, ein Problem existiert: Wenn du eine Wortgruppe (z.B. einen Songtitel + Interpret) als Passwort verwendest.
Wobei das selbst bei "The Misinterpretation Of Silence And Its Disastrous Consequences (Wombs and Tombs Mix)" von Type 0 Negative noch kein Problem wäre... Und wie du schon sagtest: vorher Hashen und gut.

Egal ob man vorher hasht oder nicht. Zum aktuellen Zeitpunkt ist bcrypt (und im gleichen Atemzug die neue Crypt-API von PHP) die beste Wahl hinsichtlich Entwicklungsaufwand und Sicherheit. Leichter zu schreiben als MD5+Salt, sicherer als 50 Iterationen von SHA.

 

[ice-breaker]

Mich würde noch interessieren warum es schlimm ist wenn bcrypt nur die erste 72 Bytes Verwendet.
Die meisten werden sich gar keine 72 Bytes merken können.

es ist nicht unbedingt ein Problem, weil 72 Zeichen für ein Passwort ausreichen sind. Aber so ganz optimal ist es für so einen Algorithmus auch nicht, wenn er seine Eingabemenge begrenzt.

Schlimmstenfalls kann man ja mit SHA vorhashen.

sollte man nicht tun. Sowas sollte man den Kryptologen überlassen solche Systeme zu entwerfen, schlimmstenfalls verschlechtert man seinen Hashing-Prozess damit deutlich.

Wahrscheinlich ist es derzeit egal ob man nun bcrypt or PBKDF2 nimmt.

vermutlich ja, aber eben nur solange wie bcrypt eben noch weiterhin als so sicher gilt, wie es aktuell ist. Was eben daher rührt, das keine großartigen Forschungen in Richtung Kryptoangriffen gemacht wurden.
Es ist eben wie mit RSA, man kann dessen Sicherheit nicht beweisen, erachtet es aber trotzdem als sicher.

Leichter zu schreiben als MD5+Salt, sicherer als 50 Iterationen von SHA.

50 Iterationen sind ja auch lächerlich. Vor einigen Jahren erachtete man 1000 Iterationen als sinnvoll, und das war mit schwächerer Hardware...

 

[Daaron]

vermutlich ja, aber eben nur solange wie bcrypt eben noch weiterhin als so sicher gilt, wie es aktuell ist.

Nochmal: PBKDF2 bringt nichts.
Relevant ist nicht, welche Crypto-Verfahren weltweit irgendwo existieren. Relevant ist, was die Zielgruppe nutzen kann. Apache unter Windows kann nur MD5, also nimmt man MD5. Apache unter Linux kann maximal bcrypt, also nimmt man bcrypt. Nirgendwo kann Apache PBKDF2, also nimmt man PBKDF2 nicht.

Wenn irgendwann mit Apache 2.6 oder Apache 3 oder wieauchimmer mal PBKDF2 hinzugefügt wird, ok. Dann kannst du wieder damit kommen... und dann ist da noch die Sache mit der Paketverwaltung. Kaum jemand macht sich die Mühe, manuell einen HTTPD zu kompilieren.
Zum aktuellen Zeitpunkt bieten weder Debian 7, Ubuntu 12.04 noch CentOS6 (und RHEL) überhaupt Apache 2.4 an. Die Dinger laufen ALLE noch auf Apache 2.2. Dein PBKDF2 wird also für .htaccess/.htpasswd noch 1-2 Jahrzehnte warten müssen....

 

[ice-breaker]

Die Frage von iloveume war aber eben genereller Natur und nichtauf den Apache bzw. crypt bezogen

 

[iceview]

Ich hab jetzt 32 Stellen aus a-z A-Z und 0-9 generiert. Das ganze mit SHA verschlüsselt und gut ist... ich denke die Wahrscheinlichkeit einen Hack zu erleben (im wahrsten Sinne des Wortes) ist gegen 0.