dann scheint es an irgend welchen Unterschieden in der verwendeten Firmware, des Kennwortes oder der Testdurchführung zu liegen.
Hast Du auch mal in Erwägung gezogen, daß schlicht
Dein Testaufbau falsch gewesen sein könnte und daher bei Dir das falsche Ergebnis dabei herauskam?
Ist zwar schwer "off-topic", aber ich wage mal die Behauptung (und versuche auch, den Beweis anzutreten), daß Du hier schweren Unsinn getestet hast. Wenn das hier nichts zu suchen hat, werden die Moderatoren es hoffentlich in einen anderen Thread auslagern und nicht nur entsorgen (Danke vorab).
--------------------------------------------------------------------------------------------------------------------------------------------
Sowohl beim Setzen eines Kennworts als auch in der Login-Maske ist das Kennwortfeld mit einem
"maxlength"-Attribut definiert, das einen Wert von 32 hat. Für die Aktionen beim Erreichen der max. Länge der Eingabe ist - afaik - der Browser zuständig (z.B. für ein kurzes akustisches oder optisches Signal) - eine generelle Festlegung (aka Spezifikation) gibt es da m.W. nicht.
Was passiert z.B., wenn man (unter F(ire)F(ox) 67.0.1, Windows 7 x64) jetzt auf die Idee kommt, etwas in ein solchermaßen beschränktes Eingabefeld zu kopieren, was diese Länge überschreitet?
Das ist ganz einfach festzustellen ... man öffne die Anmeldeseite (s)einer FRITZ!Box und drücke dort einfach mal die F12 - dieses ruft dann die Developer-Tools auf.
Dazu gehört auch die JS-Console und so kann man da nette Spielereien mit dem Inhalt der angezeigten Login-Seite machen, u.a. das Feld für die Kennworteingabe näher untersuchen, dieses hat die ID "uiPass":
Code:
>> document.getElementById("uiPass").value.length
<- 0
>> document.getElementById("uiPass").getAttribute("maxlength")
<- "32"
>> // jetzt einfach mal 31 Zeichen in das Feld kopieren (Vorlage: 1234567890123456789012345678901234567890 - einfach soviel markieren und kopieren, wie man braucht), danach abfragen
>> document.getElementById("uiPass").value.length
<- 31
>> document.getElementById("uiPass").value
<- "1234567890123456789012345678901"
>> // jetzt mit 32 Zeichen
>> document.getElementById("uiPass").value.length
<- 32
>> document.getElementById("uiPass").value
<- "12345678901234567890123456789012"
>> // und nun - drumroll - mit 33 Zeichen
>> document.getElementById("uiPass").value.length
<- 32
>> document.getElementById("uiPass").value
<- "12345678901234567890123456789012"
Die Ausgabe nach dem versuchten Kopieren von 33 Zeichen ist auch kein Unfall ... man kann das gleich noch einmal mit anderen Werten im Eingabefeld testen, bevor man versucht, die Zeichen hineinzukopieren (hier habe ich gleich die 40 Zeichen von oben genommen beim zweiten Versuch):
Code:
>> document.getElementById("uiPass").value.length
<- 8
>> document.getElementById("uiPass").value
<- "ABCDEFGH"
>> document.getElementById("uiPass").value.length
<- 32
>> document.getElementById("uiPass").value
<- "12345678901234567890123456789012"
Wir können also schon einmal festhalten, daß es - beim von mir verwendeten Browser, bei Dir fehlt die Angabe dazu - keinen Unterschied macht, wie man versucht, die Daten in das Feld zu kriegen, ob mit der Tastatur oder per Copy&Paste ... ab "maxlength" wird abgeschnitten. Das KÖNNTE zwar bei einem anderen Browser anders sein, aber um das zu prüfen, müßte man halt mehr über den Testaufbau wissen.
Nun heißt das aber tatsächlich noch nicht, daß man die Länge der Daten in diesem Feld NIEMALS über diese festgelegten 32 Zeichen hinaustreiben könnte. Bei einer Zuweisung greift dieses Attribut nämlich tatsächlich nicht:
Code:
>> document.getElementById("uiPass").value
<- ""
>> document.getElementById("uiPass").value.length
<- 0
>> document.getElementById("uiPass").getAttribute("maxlength")
<- "32"
>> document.getElementById("uiPass").value = "1234567890123456789012345678901234567890"
<- "1234567890123456789012345678901234567890"
>> document.getElementById("uiPass").value.length
<- 40
>> document.getElementById("uiPass").value
<- "1234567890123456789012345678901234567890"
Wenn man es also drauf anlegt, kann man auch mehr als 32 Zeichen in so ein Eingabefeld prügeln und außerdem könnte man ja auch noch direkt den POST-Request an die Box, der den Inhalt dieses Feldes enthält, manipulieren ... nirgendwo steht, daß der aus einem Browser mit JS-Support kommen muß.
Aber das weiß AVM eben auch ... schaut man sich jetzt die Lua-Dateien für das GUI an (ich nehme hier mal die "boxuser_edit.lua"), werden die Variablen am Ende (tatsächlich ohne weitere Längenprüfung) über die Funktion "box.set_config(<table>)" an den "ctlmgr" übergeben.
Das läßt sich bekanntlich mit der "
set.lua" auch machen und notfalls auch über "ctlmgr_ctl". Aber testen wir es doch zunächst mal mit der erwähnten "set.lua" - als erstes die Anzeige für den Benutzer "test_upnp", dessen Kennwort ich einfach mal gelöscht habe:
Code:
root@FB7490:~ $ getsect boxusers /var/flash/ar7.cfg | decode_secrets | grep -C 3 test_upnp
users {
enabled = yes;
id = 10;
name = "test_upnp";
email = "";
password = "";
vpn_access = no;
root@FB7490:~ $
Die Verwaltung von Variablen/Objekten, die als Array vorliegen, erfolgt ja über Indizes, daher brauchen wir erst einmal die Benutzer-ID oder den Index dieses Account, denn die ID ist leider nicht die angezeigte "10", zumindest nicht zwingend:
Code:
root@FB7490:~ $ echo "L=boxusers:settings/user/list(UID,id,name)" | queries.lua | grep test_upnp
L_4_name="test_upnp"
root@FB7490:~ $ echo "L=boxusers:settings/user/list(UID,id,name)" | queries.lua | grep L_4
L_4_index="user3"
L_4_UID="boxuser10"
L_4_id="10"
L_4_name="test_upnp"
root@FB7490:~ $ echo "L=boxusers:settings/user3/name" | queries.lua
L="test_upnp"
root@FB7490:~ $ echo "L=boxusers:settings/user3/password" | queries.lua
L=""
root@FB7490:~ $ echo "L=boxusers:settings/user2/password" | queries.lua
L="****"
root@FB7490:~ $
Unser Benutzer "test_upnp" ist also "user3" (das ist leichter als die Array-Schreibweise, die auch funktionieren würde) und hat kein Kennwort. Im Gegensatz zum Benutzer 2 (letzte Zeile oben) wird das tatsächlich auch "angezeigt" vom "ctlmgr", ein vorhandenes Kennwort wird aber immer nur mit den gezeigten vier Sternen ausgegeben.
Was passiert jetzt, wenn wir erst mal überhaupt ein Kennwort für "user3" setzen?
Code:
root@FB7490:~ $ echo "boxusers:settings/user3/password=ABCDEFGH" | set.lua
OK
root@FB7490:~ $ getsect boxusers /var/flash/ar7.cfg | decode_secrets | grep -C 3 test_upnp
users {
enabled = yes;
id = 10;
name = "test_upnp";
email = "";
password = "ABCDEFGH";
vpn_access = no;
root@FB7490:~ $ echo "L=boxusers:settings/user3/password" | queries.lua
L="****"
root@FB7490:~ $
Kennwort auf "ABCDEFGH" gesetzt, Anzeige aber "****", der Weg funktioniert aber - das sei hiermit bewiesen.
Also testen wir das jetzt wieder mit den 31, 32 und danach mit mehr als 32 Zeichen, das Auslesen machen wir über die "ar7.cfg", da können wir das gesetzte Kennwort dann auch sehen:
Code:
root@FB7490:~ $ echo "boxusers:settings/user3/password=1234567890123456789012345678901" | set.lua
OK
root@FB7490:~ $ getsect boxusers /var/flash/ar7.cfg | decode_secrets | grep -C 3 test_upnp
users {
enabled = yes;
id = 10;
name = "test_upnp";
email = "";
password = "1234567890123456789012345678901";
vpn_access = no;
root@FB7490:~ $ echo "boxusers:settings/user3/password=12345678901234567890123456789012" | set.lua
OK
root@FB7490:~ $ getsect boxusers /var/flash/ar7.cfg | decode_secrets | grep -C 3 test_upnp
users {
enabled = yes;
id = 10;
name = "test_upnp";
email = "";
password = "12345678901234567890123456789012";
vpn_access = no;
root@FB7490:~ $ echo "boxusers:settings/user3/password=123456789012345678901234567890123" | set.lua
Das Kennwort ist ungültig.
root@FB7490:~ $
... und siehe da, ab dem Überschreiten der max. Länge von 32 Zeichen für das Passwort, läßt es sich gar nicht mehr speichern - das System liefert sogar die passende Fehlermeldung.
Nun erfolgte dieser Test aber tatsächlich an einer 113.07.11 ... diese Angabe zum Testaufbau fehlte auch noch von meiner Seite - absichtlich. Denn auf die Frage der FRITZ!OS-Version komme ich jetzt noch einmal zurück. Die 07.03, mit der Du bei der 6890 getestet hast (was ja
@Olaf Ligor schon nicht nachvollziehen konnte und der hatte die absolut identische Firmware-Version), gehört ja in dieselbe Linie, wie z.B. die ältere 07.01 für die 7490 - also versuchen wir das doch einfach mit dieser Version auch noch einmal:
Code:
root@FB7490:~ $ /etc/version
113.07.01
root@FB7490:~ $ echo "boxusers:settings/user3/password=123456789012345678901234567890123" | set.lua
Das Kennwort ist ungültig.
root@FB7490:~ $
oder auch mit einer anderen Box (6490) und einer noch älteren FRITZ!OS-Version:
Code:
/var/media/ftp/pentest/bin # /etc/version
141.06.83
/var/media/ftp/pentest/bin # echo "boxusers:settings/user1/password=123456789012345678901234567890123" | ./set.lua
Das Kennwort ist ungültig.
/var/media/ftp/pentest/bin #
Die Ergebnisse sind also dieselben - von der 06.83 bis zur 07.11 ... spätestens beim Versuch des Speicherns eines Kennwortes mit mehr als 32 Zeichen, gibt es im FRITZ!OS einen Fehler.
Ich kann hier auch absolut nichts sehen, wo AVM irgendeine Security-Sünde begehen würde, die man auch tatsächlich AVM zurechnen müßte oder könnte. Den HTML-Standard hat AVM nicht verbrochen, Java-/ECMA-Script auch nicht und m.W. stellt AVM auch keinen Browser her, wenn man Programmierung so nennen will. Die Länge der Eingabe wird begrenzt und zu lange Daten werden auch beim Speichern im Backend abgewiesen.
Ob und wieviele Tasten der Benutzer noch drückt, wenn die 32 Zeichen voll sind, interessiert hier gar nicht ... erst dann, wenn jemand für ein Login per API auf die Idee käme, mit einem längeren Kennwort den MD5-Hash zu berechnen, spielt das u.U. wieder eine Rolle - nur wird dieser Hash-Wert dann nicht zum Ergebnis aus den 32 gespeicherten Zeichen passen.
Da hier aber eben gar kein Kennwort mehr "über die Leitung geht" (das ist ja schon bei der Login-Maske nicht wirklich der Fall, weil der Hash ja lokal berechnet wird), interessiert es auch nicht, über wieviele Zeichen irgendein Benutzer-Programm diesen Hash nun bilden will - sind es mehr als die 32 gespeicherten Zeichen oder gar andere, paßt eben der Hash nicht ... fertig. Punkt. Ob so ein Programm dann seinerseits "smart" ist, die Vorgaben von AVM kennt und bei 32 Zeichen Kennwort abschneidet, liegt wieder an dessen Entwickler.
Wo soll hier irgendeine Lücke vorhanden sein?