htpasswd - Passwort wieviele Stellen?
- Ersteller iceview
- Erstellt am
1
1668mib
Gast
Hast du verstanden, was Hashing-Algorithmen wie MD5 machen?
Smurfy1982
Commander
- Registriert
- Nov. 2008
- Beiträge
- 2.182
Kommt auch darauf an, welcher HTTP Server zum Einsatz kommt.
Lt. Apache Doku http://httpd.apache.org/docs/current/programs/htpasswd.html sind es unter Windows 255 Zeichen beim htpasswd Tool. Unter Linux ist mir hier nichts bekannt, arbeite mit maximal 30 Zeichen Passwörtern.
Lt. Apache Doku http://httpd.apache.org/docs/current/programs/htpasswd.html sind es unter Windows 255 Zeichen beim htpasswd Tool. Unter Linux ist mir hier nichts bekannt, arbeite mit maximal 30 Zeichen Passwörtern.
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...
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
- Registriert
- Okt. 2010
- Beiträge
- 13.928
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.1668mib schrieb:
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.
Also wenn das zu hashende "Objekt" halt übergeben werden muss als Ganzes, dann gibt es Speichergrenzen, ja.
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...
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.
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.
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.
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...
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...
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....
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...
Da würde man eher anders versuchen, dass Passwort in Erfahrung zu bringen...
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...
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...
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...
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.
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
- Registriert
- Nov. 2008
- Beiträge
- 4.132
Daaron schrieb:
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 ^^.
1
1668mib
Gast
@ice-breaker: Danke für den Bild-Link.
Aber warum 5 Affen? oO ;-)
Aber warum 5 Affen? oO ;-)
