新生鳩丸掲示板♯

パスワード照会を試してみました。

・必要なのは氏名、ID、電話番号、カード番号、有効期限、任意の4桁の数字

・入力後に送られるメールにURLが記載されており、そこにアクセスすると先ほど入れた「任意の4桁の数字」を求められる

・数字が正しければパスワードが表示される

上記のうち、@niftyが事前に知り得ないのは「任意の4桁の数字」のみですが、当然これをキーにパスワードを暗号化するわけにはいきません。

他の情報は@niftyに登録されている情報ですので、仮にこれらをキーにして暗号化されていても、システム管理者は復号可能であるということになりますね。

いや～。困りました。

>手元でパスフレーズの変更をしてみました。念のため以前頂戴していた暗号化メールを復号してみましたが特に問題を感じませんでした。

　……今やったらあっさりできました。

　gpg --edit-keys [鍵]

　して passwd で問題なく。

　なんか慌てて全てを速攻で変えようとしていたので、何かを間違えていたのかもしれません。

手元でパスフレーズの変更をしてみました。念のため以前頂戴していた暗号化メールを復号してみましたが特に問題を感じませんでした。

Version: PGP 6.5.8ckt - ja: http://www.hizlab.net/pgp/

を使っています。

パスフレーズだけ変更っていうのは可能だと思うんですが

やったことないのでほんとにできるかわかりませんが^^;

早速の対応おありがとうございます。小心者なんで心配してましたー。

>無料の@nifty　ID

というのがあるのをはじめて知りました。違いがあるのかもそうですが、いろいろ心配で@niftyホームページ内を調べてみました。2005/02までは葉書による再発行のみを行っていたようです。Webによる参照サービスは新しいサービスなんですね。そして＠nifty IDでは今でもパスワードは葉書による再発行のみのようです。

そうなると、昨年まで再発行しかシステム対応していなかったってことなんで運用を想像するに

「パスワードを確保するフィールド項目は１こしかない」

「登録終了の葉書を印刷するのは登録処理が終了した次の日（営業日だともっと期間が長い）」

だから、葉書が印刷する時点でパスワードが変更されていたら変更

されていたまま出力されるってことなのかも。

昨年までは、葉書が届くまでお客様がパスワード変更はされることがなかったので上記のような運用でも問題なかったとおもいます。

でもそうなら、システム屋としてどうかとおもいます。ぜひ予想がはずれていること希望します（笑）

>http://www.nifty.com/support/member/pwlost.htm

(snip)

>なんで再発行手続きの方法も併記してあるんだし、再発行のみにしないんでしょうか？それでもって、初期パスワード以外を印刷してくるんでしょうか？

>数年つかっているので早速変更します。。かなり不安です。。。

　ちょっと語弊があったかもしれませんが、今回送られてきたのは、無料の「@nifty ID 登録ユーザー」のパスワードです。ひょっとすると、通常の @nifty 会員のパスワードは扱いが違う可能性があります。

　その辺ちょっと確認できないのですが、いちおう追記しておきますね。

>ご迷惑をおかけしてます。通常のBふれっつ環境からだったのですが。。。

>もしかしたらリンクを紹介しようとしたからかも。。。

>ともあれごめんなさい。

　内容には全く問題ないと思います。

　誤検知のようでこちらこそ申し訳ないです。

ばけらさますみません。

ご迷惑をおかけしてます。通常のBふれっつ環境からだったのですが。。。

もしかしたらリンクを紹介しようとしたからかも。。。

ともあれごめんなさい。

http://www.nifty.com/support/member/pwlost.htm

をみると

「パスワード照会がクレジットカードをもっているとブラウザで確認可能」だけど

「セキュリティの問題上、当窓口でもお客様が設定されている現在のパスワードを確認することはできません。」

だとおもってました。

もちろん初期パスワード以外を印刷して送ってくるのは初めて知りました。

なんで再発行手続きの方法も併記してあるんだし、再発行のみにしないんでしょうか？それでもって、初期パスワード以外を印刷してくるんでしょうか？

数年つかっているので早速変更します。。かなり不安です。。。

>　よく考えたら、group だと解釈すると、今度はコメントの外に ":" が必須になるのではないでしょうか。

";"もですけど。

>というか最初からそういうつもりで書いた

　あうあう、読解力不足でした。

　すみません。

　まあ最終的には意図が汲めたということでひとつ。

>　そういう意味ではセッション ID とは異なる別のランダム値をあらためて用意する必要は無いので、車輪の再発明は必要ないともいえます。

というか最初からそういうつもりで書いた(高木さん【誰】が言っているように、セッションIDをそのままinput type="hidden"に含めればいいから別途定めるランダム値を生成する必要はないと言いたかった)のですが、圧倒的に舌足らずでした。ありがとうございます【謎】。

>group = display-name ":" [mailbox-list / CFWS] ";"

>　なので無くてよかったのですね。こちらは見逃していました。

　よく考えたら、group だと解釈すると、今度はコメントの外に ":" が必須になるのではないでしょうか。

>えっと、address = mailbox / group ですから、グループ1つ(= 有効なアドレスなし)もありなのではないですか?

　ああ、なるほど。ご指摘ありがとうございます。

　group は

group = display-name ":" [mailbox-list / CFWS] ";"

　なので無くてよかったのですね。こちらは見逃していました。

　ちょっと細かく書きなおしてみました。

　わかりやすくなったでしょうか?

えっと、address = mailbox / group ですから、グループ1つ(= 有効なアドレスなし)もありなのではないですか?

まあ、昨今の風潮を考えれば From: にアドレス不記載はすごく怪しいですが

>　通常は Cookie の値としてセッション ID が使われますが、その場合はターゲットのブラウザが自動的に Cookie: を再送してしまうので、攻撃者がこれを予測する必要はそもそもありません。

>　そうではなくて、input type="hidden" にランダムな値が入っているような場合は、攻撃者は罠にこの値も含めなくてはなりませんから、攻撃が困難になります。

　さらに補足すると、Cookie として使用している値と同じものを hidden 値に含めておき、そちらもチェックするという対策でも大丈夫なはずです (もちろん攻撃者が Cookie を盗めないという前提です。Cookie を盗めたら CSRF 以前の問題なので)。

　そういう意味ではセッション ID とは異なる別のランダム値をあらためて用意する必要は無いので、車輪の再発明は必要ないともいえます。

>> この方法の問題は、Referer を送出しないブラウザで管理画面が利用できなくなってしまうということです。

>逆に言うとそこまでチェックしないと対策にならないわけですね。

　そういうことです。空の Referer を受け付けてしまうと対策にならないということです。

>> たとえば、ユーザが管理画面にログインするたびにランダムな値を生成して、

>セッションIDはまさにそのような性質を持った値である(はずだ)から車輪を再発明する必要はないということですね。

　ああ、この辺は語弊がありますね。

　通常は Cookie の値としてセッション ID が使われますが、その場合はターゲットのブラウザが自動的に Cookie: を再送してしまうので、攻撃者がこれを予測する必要はそもそもありません。

　そうではなくて、input type="hidden" にランダムな値が入っているような場合は、攻撃者は罠にこの値も含めなくてはなりませんから、攻撃が困難になります。

　この辺の説明は難しいですね。

当然ご覧になっていると思いますが、

クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法

http://takagi-hiromitsu.jp/diary/20050427.html#p01

という記事が出ていたので、用語の解説と見比べてみました。

> この方法の問題は、Referer を送出しないブラウザで管理画面が利用できなくなってしまうということです。

逆に言うとそこまでチェックしないと対策にならないわけですね。

> もう一つの方法は、攻撃者が知り得ない値をリクエストに含めておくというものです。

> たとえば、ユーザが管理画面にログインするたびにランダムな値を生成して、

セッションIDはまさにそのような性質を持った値である(はずだ)から車輪を再発明する必要はないということですね。

いつの間にかUTF-8には対応していましたが今度は相対参照の解釈で残念な思いをするようになってました。