ワードプレスオプションDBのAPIにユーザー名とパスワードを保存する方法は?


19

現在プラグインを開発していますが、他の人が使用できるように公開プラグインリポジトリでリリースする可能性が高いでしょう。

プラグインはAPIを使用します。このAPIを使用するには、ユーザー名とパスワードを渡す必要があります。したがって、プラグインはこれらのログイン資格情報をデータベースに保存する必要があります。APIではプレーンテキストで必要ですが、これらをプレーンテキストで保存したくありません。

だから私の質問は、これらの機密情報をどのように保存するのですか?ハッシュは公開されていないため、何らかの暗号化が必要です。

WordPressには、ブログごとに異なるユニークなキーを使用できますか?暗号化および復号化に使用するPHP関数は何ですか?すべてのWPインストールで動作する可能性が高い機能を探しています。


3
これはちょっと解決できません。リバーシブルにする必要がある場合、どれだけ暗号化してもかまいません。WPがそれを解読でき、WPが危険にさらされる場合、暗号化は重要ではありません。
11

しかし、なぜあなたのAPIはパスワードを知る必要があるのでしょうか?ユーザーがパスワードを知っていることをAPIが知っていれば十分ではありませんか?
onetrickpony

1
@One Trick Pony-ユーザーの介入なしにプロセスを自動化できるように、パスワードを保存する必要があります。
ブレイディ

1
@Rarst-WPが危険にさらされると、パスワードも危険にさらされることを認識しています。これを防ぐことはできません。防止できるのは、SQLダンプが取得された場合、パスワードがプレーンテキストではないということです。
ブレイディ

@Bradyうん、SQLダンプのみが危険にさらされる場合、暗号化が役立ちます。しかし、そのようなシナリオはありそうもないと思います。データベースにアクセスできる場合は、WPを侵害することも簡単です。
11

回答:


4

前の回答には同意しますが、実際に尋ねた質問に答えるために、wp-config.phpにこれらの定数のいずれかを使用することが思い浮かびます。

define( 'AUTH_KEY'、 'redacted');
define( 'SECURE_AUTH_KEY'、 '編集済み');
define( 'LOGGED_IN_KEY'、 '編集済み');
define( 'NONCE_KEY'、 'redacted');

これらはワードプレスのインストール全体で一意であることを意味し、既存のキーをワードプレスで見つけるための唯一のオプションです。別の方法として、管理者のメールアドレスなどにハッシュして作成した独自の定数を追加し、それを隠し設定オプションに保存して、誰かが誤ってキーを変更した場合にキーが失われないようにしますプラグインがインストールされます。危険なのは、最初のインストールでそれらが一意になっていなかったが、管理者/サイトの所有者が事後に失敗を修正することに決めた場合、パスワードの暗号化を誤って破ってはならないということです。

暗号化/復号化機能については、クイックGoogle検索により、請求書に収まるように見えるコードを含む次のリストが返されます。http//maxvergelli.wordpress.com/2010/02/17/easy-to-use-and-strong- encryption-decryption-php-functions /

関数encrypt($ input_string、$ key){
    $ iv_size = mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256、MCRYPT_MODE_ECB);
    $ iv = mcrypt_create_iv($ iv_size、MCRYPT_RAND);
    $ h_key = hash( 'sha256'、$ key、TRUE);
    return base64_encode(mcrypt_encrypt(MCRYPT_RIJNDAEL_256、$ h_key、$ input_string、MCRYPT_MODE_ECB、$ iv));
}

関数decrypt($ encrypted_input_string、$ key){
    $ iv_size = mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256、MCRYPT_MODE_ECB);
    $ iv = mcrypt_create_iv($ iv_size、MCRYPT_RAND);
    $ h_key = hash( 'sha256'、$ key、TRUE);
    return trim(mcrypt_decrypt(MCRYPT_RIJNDAEL_256、$ h_key、base64_decode($ encrypted_input_string)、MCRYPT_MODE_ECB、$ iv));
}

ここで使用されているAES暗号化のドキュメントは次のとおりです。http//www.chilkatsoft.com/p/php_aes.asp


4

これは、OAuthが設計されたまさにその状況です。

OAuthホームページから:

サービスプロバイダー開発者向け...

サポートしている場合...

  • Webアプリケーション
  • サーバーサイドAPI
  • マッシュアップ

ユーザーに代わって保護されたデータを保存している場合、ユーザーがWebにアクセスするためにパスワードをWebに広めてはいけません。OAuthを使用して、アカウントの資格情報を保護しながら、ユーザーがデータにアクセスできるようにします。

OAuthの利点は、ユーザーのパスワードを保存する必要がないことです。プラグインを最初にセットアップすると、アプリケーション(通常はAPIと同じサーバーでホストされ、ページリダイレクト、シックボックス、またはiframeのいずれかでロードされるページ)を介してユーザー名とパスワードでログインするよう求められます。 。

ユーザーがログインすると、サーバー(システム)は、システム(WordPress)がAPIとのインターフェースに使用できる安全なキーを作成します。このキーはユーザーアカウントとサイトに固有です-そして、毎回認証情報を渡すことなく、ユーザーに代わってAPIを使用することをWordPressのアプリケーションに許可します

この動作例を実際に見たい場合は、Jetpackをチェックしてください。

プラグインをアクティブにすると、接続されていないという苦情が表示されます。「接続」すると、WordPress.comから資格情報を入力し、WordPressとそのAPI間のOAuth相互作用を設定します。

ただし、これを一度行うだけで、WordPress.comのユーザー名/パスワードがローカルのWordPressデータベースに保存されることはありません


1
これを使うといいのですが、私が扱っているAPIは私のものではなく、OAuthシステムがありません。
ブレイディ

1
その場合、唯一の本当の選択肢は、パスワードをDBに保存する必要があることを受け入れることであり、パスワードを暗号化するかどうかは、セキュリティと実質的な違いはありません。前述したように、データベース内にあり、暗号化が可逆的である場合、WordPress(正当またはハッキングされた)にアクセスできる人はだれでもそれを手に入れることができます。
EAMann

0

これは重要な問題です。多くのサービスはまだOAuthをサポートしておらず、オプションデータベースにパスワードを保存すると、すべてのWordpressプラグインで読み取り可能になります(上記のコメントを参照)。

これは(まだ)質問に対する本当の答えではありませんが、コメントするには長すぎます。この「解決不可能な」問題に対する「最良の」可能な解決策を考え出すことを目指して、私はこれとの議論を引き起こしたいと思っています。

パスワードの暗号化が可能であると私に思わせる基本的な考え方は次のとおりです。

すべてのユーザーが持っている秘密情報は、Wordpressのパスワードです。秘密情報から派生したパスワードで暗号化されたサードパーティサービスに資格情報を保存し、ユーザーがログインしたときにのみ暗号化を解除できるようにする必要があります。

このようにして、少なくともWordpressのファイルとデータベースのコピーからパスワードを盗むことを不可能にすることが可能になるはずです。すべてのプラグインがログイン中にプレーンテキストのパスワードをキャプチャできるため、資格情報を盗む他のプラグインの問題を解決することはできません。

実際に復号化はかなり簡単です:サードパーティサービスの暗号化されたバージョンがデータベースに既に格納されていると仮定すると、'authenticate'フィルターにフックするか、wp_authenticate()関数を上書きすることにより、プレーンテキストユーザーパスワードのソルトハッシュを生成できます(によっての手段wp_hash_password())、そのハッシュされたパスワードをユーザーがログアウトするまでプライベートな場所に暗号化キーとして保存し('wp_logout'フックを使用してキーを削除します)、データベースの暗号化された値を解読するためにサードパーティのパスワードが必要になるたびにそれを使用します。

私はこの作品を作ることができるはずだと感じていますが、いくつかの未解決の問題があります:

  1. 暗号化の方法は?潜在的に、ユーザーがログアウトして再度ログインし、暗号化を実行するまでプレーンテキストパスワードを保存できます'authenticate'。ユーザーは、これが短くなるまでの期間を維持するためにログインするように求められる可能性があります。
  2. キーを保存する場所とログアウト中にキーを削除する方法 'authenticate'ユーザーが実際にログインしたときにのみ実行されることを正しく理解していますか?
  3. ハッシュされたパスワードを保存する方法がある場合、セッションCookieからキーを派生させることができますか?
  4. パスワードの変更を処理するのは誰ですか?このようなパスワードの変更をキャッチすることは可能であるように思われ、サードパーティのパスワードは新しいパスワードから派生したキーで再暗号化する必要があります。
  5. マルチユーザーサポートを提供する方法はありますか?理想的には、管理者ユーザーが設定でサードパーティのパスワードを設定できるようにして、それから権限の低いユーザーがサードパーティのサービスとやり取りするために、理想的にはそれらのパスワードを開示しなくても訴えることができます。このため、管理ユーザーは、他のユーザーが自分でのみ生成できるすべてのユーザーのキーを生成できる必要があります。それはどういうわけか可能ですか?
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.