私はボトルを使用して、進行中のプロセスをリモートでチェックできるようにする非常に単純なバックエンド API を作成しています。このサービスを利用するのは私だけです。というか、このサービスを利用するのは私だけです。これは、いくつかのエンドポイントで GET 要求を受け入れる非常に単純な RESTish API です。
私は Web の開発を実際に行ったことはありませんが、できるだけ単純なことをやりたいと思っていました。これでも、おそらく過度の注意が必要です。とにかく、私の非常に基本的なアイデアは、サーバーで https を使用し、基本的にハードコードされたパスキーで認証することでした。サーバーとクライアントにプレーンテキストで保存されますが、誰かがそれらのいずれかにアクセスできる場合、別の問題が発生します。
このアプローチについて明らかに間違っていることはありますか?
パスワード認証を使用している場合は、クライアントから送信したパスワードが正しいことを検証できるように、サーバーにパスワードを保存する必要があります。
特定のケースでは、最も単純なものが必要なため、基本認証を使用します。HTTP/HTTPS を介した基本認証はパスワードを base64 でエンコードしますが、これは保護手段ではありません。Base64 は双方向エンコーディングであり、データのチャンクをエンコードおよびデコードでき、それを行うための秘密は必要ありません。Base64 エンコーディングの目的は、あらゆる種類のデータ (バイナリ データであっても) を文字列として体系化することです。
パスワードを入力して HTTPS 経由で送信すると、HTTPS tunel によってパスワードが他人に知られることはありません。
誰かがあなたのサーバーにアクセスし、入力したパスワードが有効かどうかを確認するために使用しているパスワード「コピー」を読み取った場合、別の問題が発生します。保護する最善の方法は、ハッシュ化することです。ハッシュは一方向のコード化システムです。つまり、誰でもパスワードをハッシュ化できますが、データのチャンクをハッシュ解除してパスワードを発見することはできません。ハッシュ化されたパスワードを解読する唯一の方法は、ブルート フォースです。MD5 または SHA ハッシュを使用することをお勧めします。
簡単にするために。クライアントは http/https 基本認証を使用するため、パスワードを base64 でエンコードします。URL ではなく、ヘッダーを介して渡します。サーバーには、データベース上または必要な場所にパスワードのハッシュされたコピーが含まれます。バックエンド コードは、http 要求を受け取ってパスワードを取得し、base64 でデコードしてからハッシュします。ハッシュしたら、サーバーに保存されているコピーと等しいかどうかを確認します。
これです。それが役に立てば幸い！