コンピュータあれこれ、の備忘録です。comment追記@2015-04-03やはりいろいろと勘違いしておりました。JWTでencodeすれば暗号化されると思っていたのですが、暗号化ではなく署名が含まれいて改竄困難、の間違いでした。$payload;としてやると(urlsafeB64Decodeはphp-jwtに含まれています)、{&quot;typ&quot;:&quot;JWT&quot;,&quot;alg&quot;:&quot;HS256&quot;}{&quot;key1&quot;:&quot;value1&quot;}となります。jwtの文字列はbase64エンコードされいるだけの実質平文なわけです。署名が入っているので改竄困難ですが。脆弱性が見つかったらしいので(時間があれば脆弱性を付く例を書きたいのですが。Token)の存在を知ったのでPHPで試してみました。この仕組を使えばユーザーの認証を保存する必要がなくなって効率的だと思います。Railsでこの仕組を使っています。↓サーバーは、その情報が正しければランダムな文字列をデータベースに保存してさらにユーザーに送信。↓ユーザーはサーバーから送られてきたランダムな文字列を受け取ってcookieにセットし、その後のサーバーのやりとり全てでそのランダムな文字列を送信して、本人性を証明する↓サーバーはユーザーからランダムな文字列を受け取ったらそれがデータベースに存在しているか確認し、存在していればそのまま処理をして、存在しなければ失敗であるとユーザーに返却という感じになります。サーバー側でデータベースを用意する必要があるなどが挙げられるでしょう。JWTを使えば、ユーザーの検証のためのデータをデータベースに保存する必要がなくなります。サーバーは、その情報が正しければJWTを生成してユーザーに渡す。正しくなければユーザーに失敗と返す↓ユーザーはJWTを受け取ってcookieにセット、その後のやりとり全てでこのJWTを送信して本人性を証明する↓サーバーはユーザーからJWTを受け取ったらそれを検証する。このとき、データベースへのアクセスは必要ないとなります。問題点としては相対的にCPUパワーを使う点(ただ、必要な情報は鍵だけなので、その鍵を複数のノードに分散してやれば、無限にスケールします)と、JWTを生成するための鍵の保持でしょうか?鍵が公になってしまうとjwtを作り放題になり悲惨なことになります(ただ、expireを付けておくことが可能ですので鍵の交換は容易でしょう)。まあPKIってそういうものですが。ここまで書いてきてなんですが、私はこういったセキュリティやPKIにさほど詳しくないので、詳細な情報は他をあたって下さい。jwtを試してみます。使うライブラリは、jwtの公式からリンクされていた、https://github.com/firebase/php-jwtです。ディレクトリを作ってライブラリを入れて、そこから本番です。標準入力からjsonを受け取って、jwtに変換するコードです。標準入力からjwtを受け取って、検証してjsonに戻して表示するコードです。&quot;\n&quot;);}var_dump($decoded);さて、いろいろと試して遊んでみます。↑で作ったencode.phpは標準入力でjsonを受け取って、jwtを吐き出すものなので、以下のようにして使ってみます。eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJrZXkxIjoidmFsdWUxIn0.w7Zzc7MkaUeLxKlBrXd3qyS2HPRpzp9OSSKrWl8Ma1g↑出来ました。上記のようなjsonをjwtにした結果が得られました。今度は逆に、jwtからjsonに戻してみます。先ほどのjwt、「eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJrZXkxIjoidmFsdWUxIn0.w7Zzc7MkaUeLxKlBrXd3qyS2HPRpzp9OSSKrWl8Ma1g」を、decode.phpを使って戻せるか試します。&quot;bar&quot;}となります。おかしな文字列を入力してデコードさせてみます。先ほどのjwt、「eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJrZXkxIjoidmFsdWUxIn0.w7Zzc7MkaUeLxKlBrXd3qyS2HPRpzp9OSSKrWl8Ma1g」の最後の「g」を「G」にしてみます。failedとなり、いい感じですね。jwtが無効になる時間に対応しているようです。1525560586)と、エラーとなる。tokenというわけでした。nbf/iat/expといろいろとあって分かりにくい感じですが基本的にはiatとexpを使えば事足りるのではないでしょうか。comment一般的なWebサービスでは、クライアントの認証時にusernameとpasswordを入力してもらい、DBにあるsaltを使って入力されたpasswordを何度もhash化し、DBにあるそれと比較します。saltは何バイト以上だとか、hash化の回数は何回だとか、hash関数はどうだとか、いろいろとあって面倒な上に間抜けな感じがするので、公開鍵暗号を使って認証を行ってみました。公開鍵をサーバーにおいておくならば、仮に流出しても問題ありません。公開鍵の名前の通り公開してもよいほどでしょう。先進的なことを考えるのであればaltcoin等のアドレスにしてしまうなどもありでしょう。スマートフォン等のクライアントであれば、秘密鍵を生成して保存しておくことは現実的です(ブラウザだと、cookieにせよ何にせよ消えてしまうのでよろしくないと思います)。流れとしては、こんな感じです。↓サーバーは、usernameからDBを引いてきてそのユーザーの公開鍵を取り出す。次に受け取ったデータをハッシュ化する(hash1)。次に、「そのデータをハッシュ化したものを秘密鍵で暗号化したもの」を公開鍵で復号する(hash2)。hash1とhash2が一致したら、正しいユーザーによるリクエスト、一致しなければ不正なリクエストとする今回は、クライアント・サーバーともにPHPでプログラムを作成しました。(クライアントのプログラム。(サーバーのプログラム、ユーザーの認証を行う)動作方法は以下です。client1とclient2を作り、client1で正常な動作を確認し、client2ではauth.phpについてclient1で暗号化したものを渡して意図的にエラーを出しています。認証時、「任意の平文」と「任意の平文のハッシュを秘密鍵で暗号化」を2つ渡すのが面白いですね。デジタル署名を少し理解ました。暗号の世界は奥が深いです。~/.ssh/configの内容は合っているか。スペリングミスやIPアドレス、ユーザー名が間違っていないか。~/.ssh/id_rsa」のように直打ちして確かめてみる。PermitRootLoginをnoにして、AllowUsersにログインユーザーを加えてください。PermitRootLoginが許可されている状態は極めて危険です。様々なマシンをいろいろとベンチマーク。WordPress.。