KeyHelp-Loginseite verstecken oder schützen

[force73]

Hallo in die Runde,

gibt es eine Möglichkeit, den Standardlogin von KeyHelp zu verstecken oder direkt per .htaccess zu schützen?

Von Firewall oder DDOS-Filtern abgesehen wäre es mir lieb, wenn externe Personen gar nicht erst bis zum Login durchkommen würden.

Besten Dank,

Christian

[nikko]

Das könnte funktionieren, indem du deine fertige . htaccess ins Verzeichnis von KH packst.

[Alexander]

Das könnte funktionieren, indem du deine fertige . htaccess ins Verzeichnis von KH packst.

Anmerkung hierzu: So eine Datei (grundsätzlich alles, was du in das Verzeichnis /home/keyhelp/www/keyhelp/ ablegst) würde nach einem KeyHelp Update nicht mehr existieren und müsste neu angelegt werden.

Ich könnte aber in den Einstellungen ergänzen, das man den administrativen Zugang via IP / IP-Range einschränken kann, sofern das gewünscht wird.
Am besten gleich noch mit Möglichkeit, die Sperre über die Console wieder aufzuheben, sofern man sich durch falsche Einstellung doch mal aussperren sollte.

[Tobi]

Obscurity ist not Security.

Ein Login vor dem Login ist zwar sicherer als sicher aber trotzdem würde so etwas wie eine Two-Factor authentication mehr Sicherheit bieten.

Darüber hinaus wird der User doch ohnehin nach X Versuchen gesperrt, oder nicht?

[mrbird]

Aber mit IP / IP-Range fände ich auch gut. Da ich eh nur im Büro reingehe und dort ne feste IP hab wäre das ein nettes Feature.

[force73]

Vielen Dank an euch alle für eure Antworten, es entsteht an dieser Stelle sogar eine Diskussion, das gefällt mir noch besser als reine Ideen.

"auf die Schnelle" arbeite ich jetzt mit einer .htaccess im KeyHelp-Verzeichnis, aber mittelfristig wäre es gut vorstellbar, direkt aus dem System heraus Optionen zu haben.

• Integration von 2FA als Login-Option ist für PHP sehr gut dokumentiert (TOTP (time based - most common algorithm; z. B. Google Authenticator)
  und HOTP (event based) als Option)

• zusätzlich/alternativ: "verstecken" des KeyHelp-Loginscreens oder im einfachsten Fall über "geheime" URL

Grüße,
Christian

[select name from me;]

2FA mit TOTP finde ich persönlich ziemlich bescheiden und wacklig.

2FA mit U2F Sticks finde ich super und nutzen wir in unserem Unternehmen schon eine ganze Weile.

Leider hat der Firefox seit Quantum im Moment Probleme und man kann es quasi nur im Chrome nutzen.
Mit Version 60 kommt allerdings die Web Authentication API.

TL;DR
Ich bitte um U2F.

[Alexander]

@Christian

Ich hab deine fleißige Vorarbeit zu dem Thema noch nicht vergessen . Kam leider noch nicht dazu

[nikko]

IP Range ist nicht mehr interessant, wenn es dyn IPs gibt.

[select name from me;]

@Christian

Ich hab deine fleißige Vorarbeit zu dem Thema noch nicht vergessen . Kam leider noch nicht dazu

Das ist nett.

Ich behalte das Thema mit Firefox sowieso auf dem Schirm. Ich melde mich bei Dir, wenn ich dafür eine Lösung habe.
Vielleicht spart Dir das dann etwas Zeit und Du kannst im Idealfall sogar etwas kopieren.

[select name from me;]

IP Range ist nicht mehr interessant, wenn es dyn IPs gibt.

Das klappt gut, wenn man statt IPs auch DynDNS Hosts akzeptiert und beim Login auflöst.

[Tobi]

IP Range ist nicht mehr interessant, wenn es dyn IPs gibt.

Das klappt gut, wenn man statt IPs auch DynDNS Hosts akzeptiert und beim Login auflöst.

Mist das wollte ich grade schreiben...

[nikko]

Für jeden, der den Server für sich alleine nutzt, ist .htaccess zusätzlich - aus meiner ganz persönlichen Sicht - vollkommen ausreichend. Sobald der Server für Kunden bereit gestellt wird, wäre eine 2FA zusätzlich cool, IP-Range scheidet da leider aus. Es muss auch bedienbar bleiben

[Tobi]

Solange die IP Range pro Useraccount definierbar ist und auch REVERSE-DNS für dyndns etc. unterstützt fände ich die IP Range Geschichte fast spannender als 2FA.

[select name from me;]

Spannend. Ja.

Allerdings kann ich aus eigener Erfahrung sagen, dass die Einschränkung nach IP / DynDNS Host nur selten genutzt wird.

2FA ist auch aus Sicht der DSGVO ein starkes Argument.