Ein Kennwort in einen REST-API-Aufruf einfügen

Angenommen, ich habe eine REST-API, die auch zum Festlegen / Zurücksetzen von Kennwörtern verwendet wird. Nehmen wir auch an, dass dies über HTTPS-Verbindungen funktioniert. Gibt es einen guten Grund, dieses Passwort nicht in den Aufrufpfad zu schreiben? Sagen wir auch, dass ich es in BASE64 verschlüsseln werde?

Ein Beispiel wäre, ein Passwort wie folgt zurückzusetzen:

http://www.example.com/user/joe/resetpassword/OLDPASSWD/NEWPASSWD

Ich verstehe, dass BASE64 keine Verschlüsselung ist, aber ich möchte in diesem Fall nur das Passwort für das Schulter-Surfen schützen.

Ein guter Server protokolliert alle an ihn gesendeten Anforderungen, einschließlich URLs (häufig ohne variablen Teil nach '?'), Quell-IP, Ausführungszeit ... Soll dieses Protokoll wirklich (möglicherweise von einer großen Gruppe von Administratoren gelesen) enthalten sein Kritisch sichere Infos als Passwörter? Base64 ist kein Stopper gegen sie.

Was Sie vorschlagen, ist weder sicher noch restvoll.

@Netch hat das Problem mit den Protokollen bereits erwähnt, aber es gibt auch ein anderes Problem, bei dem Sie Passwörter anzeigen, die über HTTP gesendet werden, was es trivial macht, Passwörter mit jeder Art von Wire Sniffer oder Man-in-the-Middle-Angriff zu erfassen.

Wenn Sie eine GET-Anforderung mit REST ausführen, stellen die verschiedenen Elemente in der URL feinkörnigere Elemente dar. Ihre URL sieht so aus, als würden Sie einen NEWPASSWD-Teil eines OLDPASSWD zurückgeben, der Teil eines Reset-Passworts ist. Das ergibt keinen semantischen Sinn. GETs sollten nicht zum Speichern von Daten verwendet werden.

Sie sollten so etwas tun:

POST https://www.example.com/user/joe/resetpassword/
{oldpasswd:[data], newpasswd:[data]}

POST, weil Sie Daten schreiben, und https, weil Sie nicht möchten, dass sie abgehört werden.

(Dies ist wirklich die Low-Bar-Sicherheit. Das absolute Minimum, das Sie tun sollten.)

Die vorgeschlagene Regelung weist in mehreren Bereichen Probleme auf.

Sicherheit

URL-Pfade werden häufig protokolliert. Das Einfügen von nicht gehashten Passwörtern in den Pfad ist eine schlechte Praxis.

HTTP

Authentifizierungs- / Autorisierungsinformationen sollten in der Kopfzeile der Autorisierung angezeigt werden. Oder möglicherweise für browserbasierte Inhalte den Cookie-Header.

SICH AUSRUHEN

Verben wie resetpasswordin Ihrer URL sind im Allgemeinen ein deutliches Zeichen für ein nichtrepräsentatives Zustandsübertragungsparadigma. Eine URL sollte eine Ressource darstellen. Was bedeutet es für GET resetpassword? Oder LÖSCHEN?

API

Für dieses Schema muss immer das vorherige Kennwort bekannt sein. Sie werden wahrscheinlich mehr Fälle zulassen wollen; zB das Passwort ist verloren.

Sie können die Standardauthentifizierung oder die Digestauthentifizierung verwenden , bei denen es sich um allgemein bekannte Schemata handelt.

PUT /user/joe/password HTTP/1.0
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Content-Type: text/plain
Host: www.example.com

NEWPASSWD

Es werden keine hochsensiblen Informationen in den Pfad eingefügt, und es werden HTTP- und REST-Konventionen befolgt.

Wenn Sie einen anderen Autorisierungsmodus zulassen müssen (z. B. einen Token, der über einen überprüften Kanal gesendet wurde, um das Kennwort zurückzusetzen), können Sie einfach einen anderen Autorisierungsheader verwenden, ohne etwas anderes ändern zu müssen.

Abgesehen von der Sicherheit besteht das Problem darin, dass es sich nicht um einen sehr restvollen Ansatz handelt.

OLDPASSWDund NEWPASSWDstehe nicht für irgendetwas in deiner Ressourcenhierarchie und noch schlimmer, die Operation ist nicht idempotent.

Sie können also nur POSTals Verb verwenden und sollten die beiden Kennwörter nicht in Ihren Ressourcenpfad aufnehmen.

Das Problem ist, Klartext-Passwörter in Ihren Anfragen zu vermeiden. Es gibt zwei Möglichkeiten, um die Restful-Webservice-Anforderungen zu erfüllen.

1. Client-Side-Hashing

• Ich nehme an, Sie speichern Ihre Passwörter wie zB Hash (Passwort + Salt)
• Sie können das neue Passwort mit einem Salt auf der Client-Seite hacken
• Das heißt: Erstellen Sie ein neues Salt auf der Client-Seite, erstellen Sie einen Hash, zB einen Hash (newPassword + newSalt)
• Senden Sie den neu erstellten Hash plus das Salz an Ihren erholsamen Webservice
• Sende das alte Passwort auch als Hash (oldPassword + oldSalt)

2. Verschlüsselung

• Erstellen Sie eine "Einmalschlüssel" -Ressource (otk) für einen Benutzer wie / otk / john
• Diese Ressource gibt einen sicheren zufälligen eindeutigen Einmalschlüssel zurück, z. B. kbDlJbmNmQ0Y0SmRHZC9GaWtRMW0ycVJpYzhMcVNZTWlMUXN6ZWxLdTZESFRs und eine eindeutige ID, z. B. 95648915125
• Ihr erholsamer Webservice muss diese zufällige Information für die nächste sichere Kommunikation mit der ID 95648915125 speichern
• Verschlüsseln Sie Ihr neues und altes Passwort mit dem otk, zB AES (aus Sicherheitsgründen sollten Sie zwei separate otks für das alte und das neue Passwort verwenden)
• Senden Sie die verschlüsselten Kennwörter mit der ID 95648915125 an Ihre Änderungskennwortressource
• Eine Kombination aus otk und ID darf nur einmal funktionieren, daher müssen Sie diese Kombination nach dem Ändern des Passworts löschen
• Möglicherweise bessere Option: Senden Sie das aktuelle / alte Passwort per Basic-Auth.

Hinweis: Für beide Optionen ist HTTPS erforderlich!

Was sind die Merkmale eines Passwort-Reset-Vorgangs?

1. Es ändert sich etwas.
2. Es gibt einen Wert, auf den es festgelegt ist.
3. Nur einige Personen dürfen dies tun (der Benutzer, ein Administrator oder einer von beiden, möglicherweise mit unterschiedlichen Regeln, wie dies getan werden kann).

Punkt 1 bedeutet hier, dass Sie GET nicht verwenden können. Sie müssen entweder etwas, das die Kennwortänderungsoperation darstellt, in einen URI POSTEN, der eine Ressource darstellt, die Kennwortänderungen behandelt, oder etwas, das das neue Kennwort darstellt, in einen URI PUTEN, der das Kennwort darstellt oder etwas darstellt (z. B. den Benutzer), dessen Passwort ein Merkmal ist.

Im Allgemeinen würden wir POSTEN, nicht zuletzt, weil es unangenehm sein kann, etwas zu schreiben, das wir später nicht bekommen können, und natürlich können wir das Passwort nicht bekommen.

Punkt 2 werden daher Daten sein, die das neue Passwort darstellen, in dem was gepostet wird.

Punkt 3 bedeutet, dass wir die Anfrage autorisieren müssen. Wenn der Benutzer der aktuelle Benutzer ist, muss das aktuelle Kennwort überprüft werden (es muss jedoch nicht unbedingt das aktuelle Kennwort erhalten werden, wenn z. B. eine hashbasierte Abfrage vorliegt wurde verwendet, um das Wissen darüber zu beweisen, ohne es zu senden).

Die URI sollte daher so ähnlich wie <http://example.net/changeCurrentUserPassword>oder sein <http://example.net/users/joe/changePassword>.

Möglicherweise möchten wir das aktuelle Kennwort sowohl in den POST-Daten als auch im verwendeten allgemeinen Autorisierungsmechanismus erhalten.