REST API呼び出しにパスワードを入れる

パスワードの設定/リセットにも使用されるREST APIがあるとします。また、これがHTTPS接続で機能すると仮定します。そのパスワードを呼び出しパスに入れない正当な理由はありますか、BASE64でエンコードすることもできますか？

例として、次のようなパスワードをリセットします。

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

BASE64は暗号化ではないことを理解していますが、この場合はショルダーサーフィンのパスワードを保護したいだけです。

適切なサーバーは、URL（多くの場合、「？」の後の可変部分なし）、ソースIP、実行時間など、送信されたすべての要求をログに記録します。パスワードとして非常に安全な情報？Base64はそれらに対するストッパーではありません。

あなたが提案しているのは、安全でもRESTfulでもありません。

@Netchはすでにログの問題について言及していますが、HTTPで送信されているパスワードを表示しているため、あらゆる種類のワイヤースニファーまたは中間者攻撃でパスワードをキャプチャするのが簡単になるという別の問題もあります。

RESTを使用してGETリクエストを行う場合、URLのさまざまな要素は、よりきめ細かい要素を表します。URLは、リセットパスワードの一部であるOLDPASSWDのNEWPASSWD部分を返しているようです。それは意味論的な意味をなさない。GETを使用してデータを保存しないでください。

次のようなことをする必要があります。

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

データを書き込んでいるのでPOSTし、データを盗聴したくないのでhttps。

（これは実際には低レベルのセキュリティです。絶対に最低限行うべきです。）

提案されたスキームには、いくつかの領域で問題があります。

セキュリティ

URLパスは頻繁に記録されます。ハッシュされていないパスワードをパスに配置することは適切ではありません。

HTTP

認証/承認情報がAuthorizationヘッダーに表示されます。または、潜在的に、ブラウザベースのものの場合、Cookieヘッダー。

残り

resetpassword通常、URL などの動詞は、非代表的な状態転送パラダイムの明確な兆候です。URLはリソースを表す必要があります。GETとはどういう意味resetpasswordですか？または削除しますか？

API

このスキームでは、常に以前のパスワードを知っている必要があります。おそらくもっと多くのケースを考慮したくなるでしょう。たとえば、パスワードが失われます。

基本認証またはダイジェスト認証を使用できます。これはよく理解されているスキームです。

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

NEWPASSWD

パスに超機密情報を配置せず、HTTPおよびRESTの規則に従います。

他の認証モード（パスワードをリセットするために検証済みのチャネルを介して送信されるトークンなど）を許可する必要がある場合は、他の認証ヘッダーを変更せずに使用できます。

セキュリティとは別に、これに関する問題は、あまりRESTfulなアプローチではないことです。

OLDPASSWDさらにNEWPASSWD、リソース階層内の何も支持しないでください。さらに悪いことに、操作はi等ではありません。

そのためPOST、動詞としてのみ使用でき、リソースパスに2つのパスワードを含めないでください。

問題は、リクエストにプレーンテキストのパスワードを使用しないことです。安らかなWebサービスの要件を満たすには、2つのオプションがあります。

1.クライアント側のハッシュ

• たとえば、hash（password + salt）のようなパスワードを保存していると思います
• クライアント側でソルトを使用して新しいパスワードをハッシュできます
• つまり、クライアント側で新しいソルトを作成し、hash（newPassword + newSalt）などのハッシュを作成します
• 新しく作成したハッシュとソルトを安らかなWebサービスに送信します
• 古いパスワードもハッシュとして送信します（oldPassword + oldSalt）

2.暗号化

• / otk / johnなどのユーザー用の「ワンタイムキー」（otk）リソースを作成する
• このリソースは、kbDlJbmNmQ0Y0SmRHZC9GaWtRMW0ycVJpYzhMcVNZTWlMUXN6ZWxLdTZESFRsと一意のID（例：95648915125）を含む、安全でランダムな一意のワンタイムキーを返します。
• ID 95648915125との次の安全な通信のために、安らかなWebサービスはこのランダムotkを保存する必要があります
• AESなどのotkを使用して新しいパスワードと古いパスワードを暗号化します（セキュリティ上の理由から、古いパスワードと新しいパスワードには2つの別のotkを使用する必要があります）
• ID 95648915125のパスワード変更リソースに暗号化されたパスワードを送信します
• 1つのotkとIDの組み合わせは1回しか機能しないため、パスワードを変更した後にその組み合わせを削除する必要があります
• 考えられるより良いオプション：Basic-Authで現在/古いパスワードを送信します。

注：両方のオプションにHTTPSが必要です！

パスワードリセット操作の機能は何ですか？

1. それは何かを変えます。
2. 設定されている値があります。
3. 一部のユーザーのみが許可されています（ユーザー、管理者、またはそのいずれか、おそらくそのどちらかを行う方法に関して異なるルールを持っています）。

ここでのポイント1は、GETを使用できないことを意味します。パスワード変更操作を表す何かをパスワード変更を処理するリソースを表すURIにPOSTするか、新しいパスワードを表す何かをパスワードまたは何かを表すURIにPUTする必要があります（例：そのパスワードが機能であるユーザー）。

通常、POSTを行います。特に、後で取得できないものをPUTするのが面倒な場合があり、もちろんパスワードを取得できないためです。

したがって、ポイント2は、POSTされる新しいパスワードを表すデータになります。

ポイント3は、リクエストを承認する必要があることを意味します。つまり、ユーザーが現在のユーザーである場合、現在のパスワードを証明する必要があります（ただし、ハッシュベースのチャレンジの場合、必ずしも現在のパスワードを受け取る必要はありません）送信せずにその知識を証明するために使用されました）。

URIは、そのためのようなものでなければなりません<http://example.net/changeCurrentUserPassword>か<http://example.net/users/joe/changePassword>。

使用されている一般的な認証メカニズムだけでなく、POSTデータでも現在のパスワードを受け取りたいと判断するかもしれません。