DynDNS und # am Anfang und Ende des Kennworts

[maxtek]

Hallo zusammen,

ich habe hier folgendes Problem:
Ein Kunde stellt mir DynDNS Accounts bei selfhost.de zur Verfügung. Der Kunde vergibt die Kennwörter nach dem Muster #xxxxxx#, wobei die xe für alphanumerische Zeichen stehen.
Mit # am Anfang und am Ende des Kennworts funktioniert das Update der IP bei Selfhost leider nicht (Zuletzt gestetet mit dem 6.32er LCOS).

Da es sich um eine ganze Menge Accounts handelt, ist eine Änderung der Kennwörter die zweite Wahl.
Kann jemand das Problem nachvollziehen?

gruss
Nils

[backslash]

Hi maxtek

unabhängig davon, daß ich da eher ein Problem bei Selfhost als am LANCOM sehe: wozu die # - sie bringen *KEINE* zusätzliche Sicherheit und verlängern das Paßwort auch nicht - da ja bekannt ist, daß sie drin stehen...

Derartige Paßwörter sind der Kryptographie-GAU, da sie selbst dazu herangezogen werden können um Verschlüsselungen zu brechen...

Da es sich um eine ganze Menge Accounts handelt, ist eine Änderung der Kennwörter die zweite Wahl.

Aus oben genannten Gründen ist die Änderung der Paßwörter nicht nur die erste sondern die EINZIG SINNVOLLE Wahl

Gruß
Backslash

[alf29]

Moin,

Naja, wenn dazwischen genug Zahlen stehen, können die Gartenzäune unter Sicherheitsaspekten
ja egal sein (wobei sechs natürlich nicht übermäßig viele sind).

Die Frage wäre eher, was bei der Sache schief geht - lehnt der Server die HTTP-Anfrage ab oder
was passiert? ein 'trace + connact' wäre dafür evtl. interessant.

Gruß Alfred

[Jirka]

Hallo Nils,

wie Backslash schon vermutete, liegt das Problem hier bei Selfhost. Für Selfhost ist der http(s)-Request scheinbar mit dem Auftreten eines Rautenzeichens beendet. Da das Passwort somit noch nicht vollständig übermittelt ist (und die anderen nachfolgenden Daten wie z. B. IP ebenfalls nicht) klappt das dann nicht.
Das wäre ein Fall für den Selfhost-Support. Teile mit, dass Dein LANCOM "status=401" als Ergebnis des DynDNS-Updates ausgibt und dass Du Deine Zugangsdaten (username, password) überprüft hast.

Bis das Problem geklärt ist, stellst Du das Selfhost-Script im LANCOM bitte aus, wenn Du das Standard-Script verwendest (über LANconfig-Assistent).

Viele Grüße,
Jirka

[alf29]

Moin,

wie Backslash schon vermutete, liegt das Problem hier bei Selfhost. Für Selfhost ist der http(s)-Request scheinbar mit dem Auftreten eines Rautenzeichens beendet. Da das Passwort somit noch nicht vollständig übermittelt ist (und die anderen nachfolgenden Daten wie z. B. IP ebenfalls nicht) klappt das dann nicht.

Wie wird das Paßwort denn bei Selfhost hereingereicht? Als echtes HTTP-Paßwort, d.h. die URL hat
die Form

Code: Alles auswählen

http://user:passwort@host/.....

oder als Teil der POST-Daten in der URL? Wenn ersteres, sollte das eigentlich kein Problem sein,
weil dabei Benutzername und Paßwort vorher abgespalten werden und getrennt von der URL laufen.

Wenn das Paßwort aber teil der URL ist, wäre es eventuell einen Versuch wert, die Gartenzäune
im Paßwort als '%23' zu enkodieren (wobei man darüber streiten kann, ob das LANCOM das
automatisch machen sollte, wofür es aber erkennen müßte, wo die POST-Daten in der URL
anfangen).

Gruß Alfred

[Jirka]

Hallo Alfred,

es ist sowohl die Authentifizierung per HTTP als auch per GET-Parameter möglich.

Ich hatte in meinem Script seinerzeit von Authentifizierung per HTTP auf Authentifizierung per GET-Parameter umgestellt, da bei fehlgeschlagener Authentifizierung per HTTP (Basic Authentication) vom LANCOM der HTTP-Protokoll-Error 401 geliefert wird und nicht die (gewünschte) Status-Antwort 401 von selfHOST. Auch im LANconfig-Standard-Script wird die Authentifizierung per GET-Parameter verwendet.
Im letzten Posting hatte ich ebenfalls mit Authentifizierung per GET-Parameter getestet.

Die Gartenzäune mit '%23' zu ersetzen ist eine gute Idee, da hätte ich ja auch selber drauf kommen können.
In Opera geht es damit auf Anhieb...
Im LANCOM müßte man noch das %-Zeichen beachten und selbiges verdoppeln. Also '#' durch '%%23' ersetzen, dann sollte es funktionieren.

Verhält selfHOST sich denn somit korrekt?

Viele Grüße,
Jirka

[alf29]

Moin,

Verhält selfHOST sich denn somit korrekt?

Vermutlich, bei einem HTTP-POST müssen die angelieferten
Daten auch URL-enkodiert werden. Das tut das LANCOM
bei POST-Requests auch, weil es an dieser Stelle auch
genau 'weiß', was die URL ist und was die POST-Daten.
Bei einer URL in der Aktionstabelle müßte man mit einer
Heuristik aber erstmal feststellen, daß die dort hinterlegte
URL ab einer bestimmten Stelle POST-Daten enthält. In
vielen Fällen ist das alles ab dem ersten Fragezeichen
in der URL, aber z.B. bei der URL dieses Threads gibt
es so etwas nicht und der Gartenzaun ist trotzdem
enkodiert. Eventuell muß man auch die ganze URL so
behandeln, ich weiß es aber wie gesagt nicht im Detail.

Gruß Alfred
enthält