htpasswd - Passwort wieviele Stellen?

iceview

Lieutenant
Dabei seit
Jan. 2008
Beiträge
650
Hallo zusammen,

wie lang darf ein Passwort innerhalb einer .htpasswd Anweisung sein?
md5, crypt oder sha machen hier auch sicherlich einen Unterschied oder?

Danke
 

iceview

Lieutenant
Ersteller dieses Themas
Dabei seit
Jan. 2008
Beiträge
650
@1668mib:
Muss ich das, wenn ich ein Passwort ablegen möchte und vorher die Anzahl der möglichen Stellen nachfrage?
Ergänzung ()

@smurfy: Ja der Apache kommt zum Einsatz.
 

Yuuri

Fleet Admiral
Dabei seit
Okt. 2010
Beiträge
12.632
Muss ich das, wenn ich ein Passwort ablegen möchte und vorher die Anzahl der möglichen Stellen nachfrage?
Theoretisch ja schon...
Zitat von http://de.wikipedia.org/wiki/Md5:
Message-Digest Algorithm 5 (MD5) ist eine weit verbreitete kryptographische Hashfunktion, die aus einer beliebigen Nachricht einen 128-Bit-Hashwert erzeugt.

MD5 erzeugt aus einer Nachricht variabler Länge eine Ausgabe fester Länge (128 Bit).
beliebig/variabel = theoretisch unendlich, zumindest bis dir der Speicher ausgeht
 
1

1668mib

Gast
Welcher Speicher? Also da könnte es auch schon vorher Probleme bei der Übermittlung geben... von den Schwierigkeiten bei der Eingabe für den User ganz zu schweigen... wehe man vertippt sich mal...
Also das Ergebnis ist ja immer gleich lang.

Und für die Anweisung in der Datei ist es egal, weil jeder Algorithmus unabhängig vom Passwort immer einen (pro Algorithmus) gleich langen Hash generiert...
 

Yuuri

Fleet Admiral
Dabei seit
Okt. 2010
Beiträge
12.632
Welcher Speicher? Also da könnte es auch schon vorher Probleme bei der Übermittlung geben... von den Schwierigkeiten bei der Eingabe für den User ganz zu schweigen... wehe man vertippt sich mal...
Also das Ergebnis ist ja immer gleich lang.
Theoretisch könntest du ja Petabyte große Dateien übergeben. Wird dann halt irgendwann nur schwer mit dem Speicher, weil der nun mal nicht unendlich groß ist. Vom Passwort hab ich gar nicht geredet, war ja nur auf MD5 selbst bezogen.
 
1

1668mib

Gast
Naja vom Algorithmus her dürfte es keine Grenzen geben... auch wenn es keinen Sinn macht: man könnte ja die Ausgabe eines Zufallszahlengenerators hashen lassen ;-)

Also wenn das zu hashende "Objekt" halt übergeben werden muss als Ganzes, dann gibt es Speichergrenzen, ja.
 

iceview

Lieutenant
Ersteller dieses Themas
Dabei seit
Jan. 2008
Beiträge
650
Okay verstanden. Also im Gegensatz zu Crypt kann ich mit md5 ein z.B. 30stelliges PW etablieren.

Ist dabei die Wahl von md5 oder SHA egal?
 
1

1668mib

Gast
Es ist eigentlich kein Geheimnis, dass man md5 für sowas nicht nehmen sollte... aber was heißt schon "sollte". Man sollte sich auch versuchen selbst zu informieren...
 

Daaron

Fleet Admiral
Dabei seit
Dez. 2011
Beiträge
13.487
Sicher ist md5 nicht Fort Knox... aber die Frage ist auch, was man da eigentlich lagert und welchen Zweck das PW erfüllen soll. Und dann ist da noch dei Frage nach dem OS. Auf nem Windows Server wirds nix mit den netten Spielzeugen.

Soll das PW permanent User authentifizieren? Dürfen die User hier am Ende sogar ihr eigenes Passwort wählen? Dann führt kein Weg an -B vorbei.
Soll das PW nur temporär einen Ordner vor neugierigen Bots schützen? Macht z.B. Sinn, wenn man eine Webseite einem Kunden zur Evaluierung/Endabnahme bereitstellen will. Dann vergibt man eh ein quasi-triviales PW, dass nach ner Woche im Müll landet. Hier reicht wirklich MD5.
 

iceview

Lieutenant
Ersteller dieses Themas
Dabei seit
Jan. 2008
Beiträge
650
Als OS ein Debian 7.

Zweck einen Ordner im /var/www für Sicherungsdaten einzurichten, welcher dann via Skript alle 6h aufgerufen wird. Lagern wird dort eine Sicherungsdatei einer Datenbank (7z mit AES).

Mein Gedanke war, damit man sich quasi das remote Backup per Script holen kann:

- Allow Override Direktive im /var/www auf AuthConfig anstelle von none
- htaccess anlegen mit einem Username
- htpasswd im /usr/share -> md5 oder sha -> Passwortlänge >30 Zeichen bestehend aus dem Pool von 62 Zeichen + Sonderzeichen

Das ganze hinter einem reverse Proxy und nur via https zu erreichen.
 
1

1668mib

Gast
@Daaron: Natürlich. Aber wenn es "bessere" Möglichkeiten als MD5 gibt, sehe ich keinen Grund, es dort noch zu verwenden... selbst wenn es nur ein temporärer Zugang ist.

Wenn Leute sich nicht mal selbst informieren können, ob MD5 oder ein anderer Hash-Algorithmus, dann habe ich halt wenig Vertrauen in die übrigen Sicherheitsstrategien...
 

Daaron

Fleet Admiral
Dabei seit
Dez. 2011
Beiträge
13.487
Wenn es wirklich sicherheitsrelevante Daten sind und es eh kein MS-Server ist, dann mach Nägel mit Köpfen. Nimm -B (bcrypt). Ist der aktuell sicherste verfügbare Algorithmus. Da steht auch nix von Zeichenlimit (anders als beim veralteten crypt).

Andererseits: Crack mal den MD5-Hash eines 30stelligen Passworts (Alphanumerisch+Sonderzeichen)... Dafür gibts keine RT.

Was hier auch zu bedenken ist:
All die Probleme mit MD5 und SHA kommen daher, dass für diese Verfahren verhältnismäßig umfangreiche Rainbow Tables gibt. Sollte also ein User dasselbe Passwort für 2 Dienste verwenden und man kann es bei einem der Dienste per RT entschlüsseln, kennt man das PW für den anderen Dienst. Dafür muss man aber den Hash in die FInger kriegen. Normalerweise heißt das: irgendwo n Datenbank-Dump abgegriffen.
Hier hingegen liegen Hash und damit geschützte Daten so oder so im selben File System. Hier muss man nicht noch ein Klartext-Passwort (und erst recht nicht von nem 30stelligen computergenerierten) irgendwie cracken. Wenn man im FS schon die .htpw lesen kann, dann kann man auch direkt das lesen, was durch die .htaccess geschützt werden soll.

Denk bei deinem Plan daran, dass .htpw vom zuständigen User lesbar sein muss, also in deinem Falle wohl www-data. Andererseits darf sie NUR von diesem User (und natürlich Root) lesbar sein.
Oder guck mal, ob http://httpd.apache.org/docs/2.2/mod/mod_authn_dbd.html eine Überlegung wert ist. Ausprobiert hab ich das Ding aber noch nie....
 
Zuletzt bearbeitet: (unvorhergesehener Formatierungsmumpitz)
1

1668mib

Gast
Da hast du nach heutigem Stand der Hardware sicher nicht unrecht, dass bei einem so langen Passwort der Hash-Algorithmus eine sehr untergeordnete Rolle spielt.
Da würde man eher anders versuchen, dass Passwort in Erfahrung zu bringen...
 

iceview

Lieutenant
Ersteller dieses Themas
Dabei seit
Jan. 2008
Beiträge
650
Hm. Da ich ja zusätzlich den Dump (und es ist immer physikalisch nur einer im Verzeichnis) noch mit einem 7z verschlüsselt ablege, denke ich, dass wohl mit dem vorgeschlagenen bcrypt wohl genüge getan.

Der Dump wäre im schlimmsten aller unwahrscheinlicher Fälle weg, aber bis ein 30stelliges PW eines AES geknackt ist hab ich wohl auch schon länger graue Haare...
 
1

1668mib

Gast
Ich kann mir nicht vorstellen, dass die Daten so wertvoll sind, dass sich jemand die Mühe macht, das AES-PW zu knacken :-)
Also bis die Hardware so weit wäre, dürften die Daten schon uninteressant sein... und einige von uns froh, wenn sie überhaupt noch Haare auf dem Kopf haben...
 

Daaron

Fleet Admiral
Dabei seit
Dez. 2011
Beiträge
13.487
Also ich hab ne Heavy Metal Matte (mit n paar grauen Strähnen an den Schläfen)...

Mir fallen da echt viel bessere Wege ein, um an die Daten zu kommen. Der Hash-Algorithmus spielt hier echt keine Rolle. Das .htaccess-PW könnte man noch mit Brute-Force knacken (außer, man konfiguriert Fail2Ban passend... BÄM, keine Chance ohne Botnet). Bei dem AES-PW hilft nur noch Social Engineering.
Viel einfacher wäre es, direkt in den Server einzudringen und die Datenbank selbst aus /var/lib/mysql zu klauen. Oder man könnte, wenn man eh schon Zugriff auf die Maschine hat, einfach rotzfrech das Root-PW der Datenbank ändern. Oder man legt irgendwo anders einen eigenen SQL Server ein und konfiguriert den gekaperten Server um, dass er als Replication Master für die eigene Kiste läuft.
 

ice-breaker

Commodore
Dabei seit
Nov. 2008
Beiträge
4.133
Wenn es wirklich sicherheitsrelevante Daten sind und es eh kein MS-Server ist, dann mach Nägel mit Köpfen. Nimm -B (bcrypt). Ist der aktuell sicherste verfügbare Algorithmus. Da steht auch nix von Zeichenlimit (anders als beim veralteten crypt).
Bcrypt hat ein Limit von 72 Bytes, d.h. es werden nur die ersten 72 Bytes zum Hashen genutzt. Das ist nur leider kaum irgendwo dokumentiert, da wird einfach immer nur mit "use bcrypt" um sich geworfen und fertig. Passt wunderbar zu den 5 Monkeys, die meisten wissen gar nicht warum sie bcrypt empfehlen, sie haben es einfach gehört und wiederholen es. Und was dann die Unterschiede von einem Bcrypt zu einem PBKDF2 mit SHA2 und hoher Anzahl Iterationen sind? Ja das hat man dem Affen nicht gesagt ^^.
 
Top