KeyHelp Community

Ich brauche mal ein wenig Input bzw. Entscheidungshilfe ...

Folgende Aufgabenstellung / Vorab-Informationen:

---
Über die KeyHelp-API sollen Benutzeraccounts von KeyHelp-Server-A zu KeyHelp-Server-B migriert werden.
Nahezu alle Passwörter im KeyHelp werden in Hash-Form gespeichert.

Stand jetzt: Man kann über die API nur Klartext-Passwörter setzen. Eine Migration wäre somit nur sofern möglich, wenn alle Passwörter (Email, KeyHelp-Account, FTP, etc) im Zuge der Migration neu festgelegt werden, der Nutzer also neue Zugangsdaten bekommt.
---

Variante 1)
-> So belassen wie es aktuell ist. Der Nutzer muss sich ggf. auch mit einem anderen Hostnamen verbinden, muss somit ohnehin seine Zugangsdaten ggf. anpassen. Allerdings umso mehr Datensätze bestehen, umso umständlicher wird dieses Anpassen.

Variante 2)
-> Bei allen entsprechenden API-Endpoints kommt das Feld "password_hash" dazu. Welches man sowohl bei [GET] lesen, als auch bei [POST] / [PUT] beschreiben kann.
Z.B. Kann man so bei Server-A alle Email-Accounts und dessen Feld "password_hash" auslesen, um sie dann bei Server B wieder exakt so einzuspielen - inklusive des derzeitigen Passworts, da der Passwort-Hash 1-zu-1 übernommen wird.
Der Kunde muss nun lediglich seinen Hostnamen bei den Verbindungseinstellungen seines Email-Clienten anpassen.

Variante 3)
Wie 2), aber das Feld "password_hash" muss erst z.B. extra query Parameter:
https://<KeyHelp-Server>/api/v1/emails/?password_hash=1
... aktiviert werden, erst dann taucht das Feld im Response-Body des API-Requests auf, bzw. erst dann kann es beschrieben werden.


Variante 3 ist vll. ein bisschen zu pedantisch, allerdings mag ich mich auch nicht recht damit anfreunden, bei Variante 2) immer den Password-Hash bei allen entsprechenden API-Endpunkten mit auszugeben - obwohl dies im Sinne der Dokumentation wahrscheinlich am einfachsten zu verstehen ist. Wenn man halt mit dem Feld "password_hash" nichts anfangen kann, dann ignoriert man es einfach.

Besten Dank für eure Eingaben .


(@Mods, Bewusst kein Vote erstellt, um das Ergebnis nicht zu verfälschen.)

Ich wäre für Variante 4

Wie wäre es wenn der Transfervorgang temporäre Passwörter setzt und nach dem Transfer die Original-Hashes zurückspielt?

Das hätte den Vorteil, dass der User am alten Server automatisch ausgesperrt wird sobald der Transfer gestartet wurde und sich erst dann am neuen Server wieder anmelden kann sobald der Transfer komplett abgeschlossen ist.

Manchmal ändert sich bei einem Account-Transfer nicht zwangsläufig der Hostnamen. Wenn ich alle Accounts von alt nach neu verschieben will bin ich sogar glücklich wenn alles bleibt wie es war.

Tobi wrote: ↑Tue 27. Apr 2021, 14:32 ...
Manchmal ändert sich bei einem Account-Transfer nicht zwangsläufig der Hostnamen. Wenn ich alle Accounts von alt nach neu verschieben will bin ich sogar glücklich wenn alles bleibt wie es war.

Ich verstehe Alex seine Aussage bezogen auf "einzelne" Benutzeraccounts, während deine sich eher in die Richtung "kompletter Serverwechsel" bewegt.

Somit wäre es ein Fall für Backup & Recovery.

Ein verschieben von Usern zwischen 2 Serveren (Sei es aus Lastgründen oder weiß der Geier) zieht somit auch einen HN wechsel mit sich.

@Alexander:

V3 ergibt den meisten Sinn.

@Tobi, deine Variante könnte man sich ja dann mit Hilfe der API so bauen.

Server A - 1. Request: Man frag die Daten ab (Variante 2 / Variante 3)
Server A - 2. Request: Man ändert das Passwort
Server B - 1. Request: Man legt die Daten an inklusive des mit Variante 2 / Variante 3 beschriebenen Übernahme des Passwords durch das password_hash Feld

---

Prinzipiell geht es mir darum, ob es für euch okay ist, das "password_hash" Feld bei allen API-Endpunkten, die es betreffen würde (/clients/, ftp-users/, /emails/, /databases/, /directory_protections/) künftig mit auftaucht (Variante 2), oder erst zugeschaltet werden muss (Variante 3).

Mal andersrum gefragt? Wo wäre der Sicherheitsgewinn, wenn der Passwort-Hash extra angefordert werden müsste? Ich meine, ich kann es nachvollziehen dass das ein eher komisches Gefühl verursacht, auf der anderen Seite müsste diese Möglichkeit (also Passwort-Hash mit anfordern) ja auch dokumentiert werden und wäre damit öffentlich (und somit für jeden "Bösen" nicht wirklich eine Hürde)

Ich würde das ganze im Frondend konfigurierbar machen, sodass man es sich aussuchen kann. Grundsätzlich wäre ich aber bei Variante 3

Grundsätzlich find ich die Variante mit dem Passwort Hash genial. Das hätte mit viel Zeit für das Migrationsscript erspart
Aber ich bin auch ein Freund von Sicherheit. Den Passwort Hash anfordern finde ich persönlich keine gute Variante. Wie schon mhaage geschrieben hat, das wird ja dokumentiert und somit ein Angriffspunkt.
So wie man die API aktivieren kann, sollte pro API User eine Checkbox für den Passwort Hash existieren.
Gruß
Sascha

Hallo,

genial. War gerade dabei was zu basteln und den Hash manuell aus der DB zu ziehen.

Ich fände Variante 2 am besten. Eine extra Sicherheit muss meiner Meinung nach nicht. Mit der API komm ich auch jetzt schon an fast alles. Setzt man das Passwort eben damit neu.

Aber wenn es nicht zu aufwendig ist, finde ich auch die Variante gut, das man das in Keyhelp, ebenso wie die API zusätzlich aktivieren kann.

Gruß Arne

Sehr schön, dann ist's beschlossen -> Checkbox in den API Einstellungen .
Besten Dank für das Feedback.