Edit: hab das bei Dashlane doch falsch verstanden, man registriert sich mit einem Device key, welchen man verschlüsselt auf dem Gerät haben muss mit dem man sich anmeldet und Geräte kann man mit einem Email oder SMS one time passwort registrieren. Das kann man natürlich bei einer Browseranwendung schlecht machen.
OK... Das wäre in meinem Konzept gar nicht mal so schlecht:
Ich möchte ja ein Rest-Client und Rest-Server haben. Wobei der Rest-Client irgendwas sein kann, ein Webserver eine Grafische Lazarus-Anwendung egal was.
Aber um das neuverschlüsseln beim Passwort wechsel wirst du wohl oder übel nicht herum kommen können.
Das wäre der Harken dabei: aber mal im ernst:
A) Ab wann wäre das wirklich ein Problem? Ab wie viele Einträge in der DB?
B) Wie oft würde man dieses Password ändern?
Das Passwort möchte man doch eher ändern als das login passwort. Das ist immerhin ohne das entschlüsselpasswort nutzlos
Stimmt auch wieder. Jedoch hat das den Vorteil, dass man nicht alles Verschlüsseln muss.
Es würde also mehrer Ebenen geben. Eine ebene, mit Einträgen die nicht extra geschützt sein müssen, eine ebene mit Daten die extra Verschlüsselt sein sollten.
Es könnte auch noch eine Ebene geben, die auch Personen sehen, die nicht angemeldet sind. Das ist hier mein Ziel.
Der Benutzer soll entscheiden, wenn er alles verschlüsseln möchte bitte. Ist aber kein muss.
Ich denke die Idee mit dem Rest-Server hat doch immer mehr Vorteile...
Das mit dem Sicherheits-Token in deinem Beispiel habe ich auch schon gesehen. Das muss ich mir noch genauer anschauen, weil das wäre der nächste Punkt.
D.H. der Client würde diesen Token immer mit Senden. Wenn es den Token nicht gibt, ist man auch nicht angemeldet.
Du machst das ja mit der IP. Nun ist die Frage in wie weit man das per JavaScript z.b. im WebBrowser angreifen könnte.