[VOTING] XH 1.6.10

[frase]

@cmb
Ich hatte ganz bewusst nur den Link ohne Kommentar gesetzt - als Zeichen dafür, dass auch anderen das Problem bewusst ist.

Beide angesprochenen Lösungen scheinen mir nicht optimal.

Gerts Lösung: Die Probleme hast du schon beschrieben.

Dein Patch hat Charme.
Aber auch hier hast du das Problem bei lokalen Tests auch erkannt und beschrieben.
Das wäre mir nicht angenehm, jedesmal zur Passwortänderung aufgefordert zu werden.
Aber, ich finde es gut, dass zumindest mal darüber nachgedacht wird. 'ne richtig gute Lösung fällt mir eben auch nicht ein.

[Gert]

although not "test", but it is still a default password

Wenn ich CMSimple 5.1 mit Passwort "test" ausliefere, kann NIEMAND etwas tun, denn dieses Passwort ist unwirksam. Man kennt zwar das Passwort, kann sich damit aber nicht einloggen. CMSimple ist dann quasi geschlossen, und nur per ftp (wieder) administrierbar zu machen. "test" ist also das sicherste mögliche Passwort, aber nicht das bequemste

Vom hochladen der Datei setupControl.php bis zum neuen Passwort hätte ein Angreifer aber tatsächlich (jedes mal) ein paar Sekunden Zeit, sein eigenes Passwort zu vergeben

Aber auch hier hast du das Problem bei lokalen Tests auch erkannt und beschrieben.
Das wäre mir nicht angenehm, jedesmal zur Passwortänderung aufgefordert zu werden.

Das macht man lokal genau 1x nach dem Download, diese Vorlage kann ich dann immer wieder verwenden. Ich habe auch lokal niemals das Passwort "test" verwendet. So eine lokale Testinstallation will man ja vielleicht auch schnell mal für irgendwelche Tests hochladen, und dann denkt man mal nicht ans Passwort ...

[frase]

Das macht man lokal genau 1x nach dem Download, diese Vorlage kann ich dann immer wieder verwenden. Ich habe auch lokal niemals das Passwort "test" verwendet. So eine lokale Testinstallation will man ja vielleicht auch schnell mal für irgendwelche Tests hochladen, und dann denkt man mal nicht ans Passwort ...

Rrrrrrrr, auch wieder richtig.
Ich habe das ja gedanklich noch gar nicht richtig durchdrungen. So schnell bin ich nich
Trotzdem schön, dass sich Leute die sich auskennen, jetzt auch mal damit beschäftigen.
*Daumen hoch*

[Tata]

Gäbe es eine Möglichkeit, die Installation:
a) am Lokalhost evtl. ohne einem Passwort (oder mit z.B. "test") nutzen
b) nur mit neuem Passwort (den Regeln entsprechend) am Host zu installieren
?

[cmb]

Wenn ich CMSimple 5.1 mit Passwort "test" ausliefere, kann NIEMAND etwas tun, denn dieses Passwort ist unwirksam.

Ah, gut. Dass das in login.php ebenfalls abgefangen wird, hatte ich übersehen.

Aber auch hier hast du das Problem bei lokalen Tests auch erkannt und beschrieben.
Das wäre mir nicht angenehm, jedesmal zur Passwortänderung aufgefordert zu werden.

Das macht man lokal genau 1x nach dem Download, diese Vorlage kann ich dann immer wieder verwenden.

Ja klar, ich kann auch einen passenden Passwort-Hash direkt in config.php eintragen. Aber egal wie ich es mache, ich muss es beim Entwickeln jedesmal tun, wenn ich den aktuellen Branch cleane, oder in einen andern Branch wechsele. Okay, mit einem `phing set-passwd <password>` wäre das wohl akzeptabel.

Gäbe es eine Möglichkeit, die Installation:
a) am Lokalhost evtl. ohne einem Passwort (oder mit z.B. "test") nutzen
b) nur mit neuem Passwort (den Regeln entsprechend) am Host zu installieren
?

Man könnte wohl auf "localhost" als Domainnamen prüfen, aber ich denke, dass ist nicht hinreichend sicher. Eine Prüfung auf die Loopback-Adresse vielleicht schon. Vielleicht wirklich eine Idee, die man weiter verfolgen sollte.

[frase]

I've made a quick patch for this, but I still think this is not quite right, because that leaves room for an attacker to effectively taking over the installation (see my comments above). Also it's ugly for local installations, especially for development.

Vielleicht sollte man den Hinweis als XH-Message ausgeben, damit das nicht so leicht übersehen wird:

Code: Select all

        if (!empty($_SESSION['xh_must_change_password'])) {
            $o .= '<p class="xhWarning">You have to change your password!</p>';
        }

(Vielleicht kann das auch noch später eine Sprachvariable werden.)

Nachdem ich so ein wenig damit gespielt habe, finde ich diese Idee (deinen Patch) immer besser.
Auch am localhost kann man sich daran gewöhnen. Wie üblich wehrt sich das alte Hirn erstmal gegen alles Neue. Doch erstens ist es gar nicht so wild und zweitens dient es der Sicherheit.

Also: Schweiß von der Stirn gewischt (heute sollte ja jeder ein Handtuch bei sich haben, heute ist Towel Day!) und die Frage gestellt:
Sollten wir das nicht zur allgemeinen Diskussion (neuer Thread) stellen und vielleicht sogar schon in 1.7.3 integrieren?

[frase]

Nachtrag zum vorherigen Post:

Leider kann damit nicht verhindert werden, dass jemand seine Website mit dem Standard-Passwort online stellt.
Er würde es erst nach dem ersten Einloggen bemerken.
Im schlimmsten Fall könnte ein Fremder dieses einfach ändern - und der Besitzer könnte das nur per FTP korrigieren.

[Tata]

Vielleicht wirklich eine Idee, die man weiter verfolgen sollte.

Oder eben als Standardinstallation überhaupt kein Passwort verlangen und in der Konfiguration einen Schalter einbauen, der dann ein echtes Passwort verlangen würde. D.h., am Localhost könnte der Webmaster einfach alles öffnen und bearbeiten, ohne bei jedem Login mit der Passworteingabe die Zeit zu verschwinden. Sobald aber die Webseite fertig ist (Template, Stzlesheet, basic Content usw.) und soll an Server installiert sein, muss man irgendwo ganz deutlich eigegeben sein, dass Passwort Funktion in der Konfiguration eingeschaltet sein muss und dann entw. gleich ein Passwort gegeben, oder die Warnung, dass die Seite bleibt geschlossen, solange ein Passwort nicht gegeben wird.
Optional könnte die Konfiguration auch am Lokalhost wirken.
Etwa so?

logins.jpg

[olape]

Oder eben als Standardinstallation überhaupt kein Passwort verlangen und in der Konfiguration einen Schalter einbauen, der dann ein echtes Passwort verlangen würde.

Damit würden wir mehr Schaden als Nutzen machen.
Denn dann wäre es möglich, dass Websites, nicht nur wie bisher mit Standardpassword, sondern sogar ohne Password online wären.
Genau das Gegenteil soll erreicht werden.

Da wäre die Idee besser.

Man könnte wohl auf "localhost" als Domainnamen prüfen, aber ich denke, dass ist nicht hinreichend sicher. Eine Prüfung auf die Loopback-Adresse vielleicht schon. Vielleicht wirklich eine Idee, die man weiter verfolgen sollte.

[frase]

Vielleicht sollte ein Forums-Admin ab hier abtrennen und einen neuen Thread eröffnen.
Es scheint ja von einigem Interesse zu sein - und unwichtig finde ich das Thema wirklich nicht.

Eine Prüfung auf die Loopback-Adresse vielleicht schon. Vielleicht wirklich eine Idee, die man weiter verfolgen sollte.

Denke ich mittlerweile auch.
Lokal alles wie bisher.
Doch was dann, wenn es online ist?
Dann müsste wahrscheinlich eine Vorschaltseite erscheinen (ähnlich Gert) und die Site gar nicht nutzbar/sichtbar sein.
Oder anders: Kein Login möglich!
Das muss der Betreiber dann eben per FTP lösen.