アカウント名:
パスワード:
XSSやSQLインジェクションのもとになるからとにかく入力に英数字以外のものを許してはならないというサニタイズ脳が、かえってシステムを危険にしてる実例ですね。
XSSやSQLインジェクションが起こると、自分たちの責任。仮にパスワードが英数字のみしかできなくても、パスワードを破られるのはユーザの責任。
どっちを選ぶかは明白でしょう。
とりあえずパスワードはSQLインジェクションの実証コードにしておけば
- それなりに長い- 記号もちゃんと入ってる- 割と覚えやすい- 利用しているサービスの脆弱性が検出できることもある
うん、よさそうだ。(ただしどこかに載ってるサンプルの流用はだめだぞ！)
# ただし危ないリクエストをはじく仕様の、Webサーバー用FWに差し止められる可能性があります。
> パスワードに記号を認めないのはどういった理由なのでしょうか。少なくとも、技術的に困難なことではありません。
わかってて書いているでしょうが、困難ではないですけど、確実にコストアップにつながりますよね。
とりあえず、「&」「?」「"」「'」あたりはHTMLやSQLなどのために対処が必要でしょうね。使用言語やライブラリなどによってコードのほうは記号未対応の場合と一緒でいいときもあるでしょうが、テスト項目のほうにはきちんと盛り込まないといけませんね。（パスワード強度を上げようとしてSQLインジェクションなどに陥っては意味がないですよね）
あと、「.」と「,」や「'」と「`」などの見間違えやすい記号を両方通すと書面等で通達するときにトラブルになりやすいかな？電話等の口頭の場合には「アポストロフィーって何？」とかなりそうですね。このあたりは英字の大文字と小文字を区別して受け入れる場合と同様にめんどくさそうです。
まあ、Pixivの件はどうか存じませんが大体、必要なセキュリティとコストの兼ね合いで仕様が定まるでしょう、マトモな開発に依頼すれば。
# 連投制限があるのでここで書いちゃいますが# パスワード数の上限設定はVARCHAR2(8)とかしちゃうせいでしょうね（大目に設定すればいいのに）
・ユーザーが入力したパスワード文字列を保存するなんていう危険な実装をしようという時点で、そんな開発はまともじゃないし狂ってます。受け取ったら即座にハッシュにして、そのあとはプログラム内ではそのハッシュを扱えばいいだけです。パスワード文字列をそのまま保持するなんてとんでもない！
・ユーザーが入力したパスワード文字列を画面に表示する必要性はありませんので、これで特に問題は起きません。ユーザーの入力ミスを防ぎたいなら、二つの欄に二度入力させるなどの方法で対応すべきです。
・パスワードを忘れたユーザーに、ユーザー自身が以前入力したパスワードを通知する必要はありませんし、また、かなりのユーザーが同じパスワードを複数のサービスで使ってるため、万一第三者に不正取得された場合にも被害が自サービスだけではすまない大ごとになりかねません。ランダムな文字列を自動生成してそれを通知すべきです。自動生成する文字列に限っては、ややこしい記号を使わずアルファベットと数字だけを使うようにしておけばいいことです。
＞確実にコストアップにつながりますよね。まったくです。
まあ、ぶっちゃけいうと、今となっては桁数増やす方がずっと楽。20文字でも30文字でも，コンピューターの記憶容量からすると誤差みたいな物だし。
ボトルネックは人間の記憶容量だな。最近は歳のせいか、物覚えが悪くて。
理想的にはそうですが、APOPのようなチャレンジ・レスポンス方式の場合、生パスワードが必要になりませんか？この辺り詳しい人がいたらお願いしたいです。
チャレンジ/レスポンス方式だからといって、生パスワードが必要とは限りません。プロトコルの設計次第です。例えば、HTTPのDigest認証 [wikipedia.org]では、パスワードハッシュを、更にチャレンジレスポンスでハッシュ化してるので、生パスワードを保存する必要はありません。
もっとも、この場合「パスワードハッシュ」がAPOPとかでの生パスワード相当であり、それが漏れたら同サービスでのなりすましは出来てしまうわけですが、影響が他に及ぶ心配がないというか「複数のサービスで同じパスワードを使い回している場合に、他のサービスに対しても攻撃が出来る」のを防ぐことにはなります。
> 生パスワードが必要になりませんか？
なります。だから「生パスワードを保管しているからセキュリティ的に問題あり。だから生パスワードが必要なサービスはやめましょう。」なんて一概にいえるはずはないんですよ。
どういう仕組みでも設計するときにはトレードオフの考慮は必要ですよ、当たり前すぎますが。
＞確実にコストアップにつながりますよね。
それくらいを見込んでコストを計算しないとね。サービスを劣化させてコストを縮小したい..というのはわかるけど、劣化させて安くしましたがほめられるというのも問題だろ？
＞パスワード強度を上げようとしてSQLインジェクションなどに陥っては意味がないですよね
そういう質の低いコードしか書けない安い人を雇って安くすると？
＞同様にめんどくさそうです
面倒なら、そもそもそんなシステム組むのやめたら？
＞＞パスワード強度を上げようとしてSQLインジェクションなどに陥っては意味がないですよね＞そういう質の低いコードしか書けない安い人を雇って安くすると？
この人、正気なのかな。
苦労して完璧にエスケープできるコードを書いて、十分にテストして安全性を保証するコストは、技術力の如何に関わらず結構なものです。しかもこのコストは無闇やたらと記号を入れるという決断さえしなければ、最初から要らないものだもの。しかも記号を入れても、とくにパスワードの強度が上がるわけでもないというのに。
なんだか、「シートベルトもエアバッグもなしで、しかもそれを使用している時と同等以上の安全性を技術力で実現しろ」といわれてる気分。不可能じゃないけど、金と技術の無駄づかいでしかない。
。。。。「タバコ自販機の顔認証」の方が例としては良かったかな？
>なんだか、「シートベルトもエアバッグもなしで、しかもそれを使用している時と同等以上の安全性>を技術力で実現しろ」といわれてる気分。
ちゃんとしたモノが作れないので、シートベルトもエアバッグも付けられないし、付けるとコストがかかっちゃうので、付けないということを言いたいわけですね。
必要なものが何かを理解してからプログラミングなり設計をされるとよいでしょう。
> わかってて書いているでしょうが、困難ではないですけど、> 確実にコストアップにつながりますよね。
その程度でコストアップとかいうのはサニタイズ脳じゃないですかね。
> 書面等で通達するときにトラブルになりやすいかな？
パスワードを書面で通達するんですか？初期パスワードなら紛らわしい文字は使わなければいいだけ。
かつてユーザ数2000人ほど(コンピュータリテラシは低い)の組織にシステムを導入したときの話ですが、初期パスワードは自動生成文字列を割り当てました。
が、紛らわしい文字を使うとログインできないと苦情が来て対応に追われることが予想されたため、0, o, O, 1, l, I, i, j, c, C, p, P, s, S, u, U, v, V w, W, x, X, z, Z は使わないようにして生成しました。
こんなんでも一見複雑そうに見えるパスワードにはなりますし、初期パスワードとしてユーザ名 + 番号みたいなものを与えてパスワードってそういうものなんだ、みたいな間違った学習をユーザにさせてしまうのはよろしくないですし。
だれか、このレスに「参考になる」をモデレートしてくれないかなぁ。
駄目なSIerがどういう間違いを犯すか、それをどう指摘・修正すれば良いかについて、大いに参考になるよ。
オフトピかもしれませんが。
１年ほど前の話なので、今はどうだか知りませんが、Amazonのログインパスワードについて、使える文字や文字数制限の注意事項が見あたらなかったので、英数字・記号を混ぜたパスワードを設定していました。問題なくログインできていました。
あるとき、欲しいものがあったので『1-click注文』しようとしたら、ログインしているにも関わらずなぜかパスワードを求められ、しかも正しくないパスワードだと言われました。
しばらく格闘した後、Amazonのログインパスワードを、記号を取り除いた新しいパスワードにしたら、『1-click注文』も使えるようになりました。
Amazonの中の人に、しっかりしてほしいと思った出来事でした。
何だかpixivが特別なような言い草ですが、web上のサービスでパスワードに記号が使えない物は、感覚的には半分ぐらいはあります。pixivはかなりのロングパスワードを受け付けるので、まだ良心的な方でしょう。
＃記号が使えなくても覚えられないぐらいの長いパスワードをKeePassなどで一括管理する方がいいと思うな＃もちろんマスターパスワードは記号入りかつ長い物を覚えておきます。一つなら可能だし。
最近むしろ増えてませんかね。私も気になってました。右へならえ的に仕様を決めてるんでしょうかね。
フレームワーク標準のバリデータをそのまま使ってるんじゃないでしょうか。自分で書けばいいんですが、できれば標準装備で欲しいところ。
サポートが苦労する話を聞きます。自分で設定したにも関わらず忘れて問い合わせられ、メモ書きしたらしいパスワードを電話越しに伝えてきて入力方法をイチイチ教えたり。アンダーバーだけでも他の問い合わせ1、2件消化できる時間が・・
うーん、皆で渡れば恐くない……って感じでしょうかね。
削ってはいけないコストな気もしますが、これはサービスする側の選択だからしょうがないですね。記号が使えないから登録しない、というほどこだわってる人は少ないでしょうし。
アンダースコアってキーボード見てもどれが該当するキーなのか分かりにくいですよね実際。マイナスに見えてしまう。
keepassでトコトン強化したらiPhoneで死にました30文字を入力するのはたまったものではなかったです
ikeepassが審査に通ることを心待ちにしています
＞「パスワードには英数字しか使えません」と言われて驚きました。記号を 1 文字でも混ぜておくだけで、パスワードの強度は飛躍的に上がるのに。
『飛躍的に』ってのは言い過ぎでしょ。
アルファベット26文字。大文字小文字で５２。数字を加えて６２。
仮に（たったの）10文字としても、６２の10乗と６３の10乗を比べて、『劇的に上がる』というのは言い過ぎだろう。
>「パスワードには英数字しか使えません」まだまし。
三井住友のvpassは数字のみだった。ふざけすぎだろ...
別のコメントにもあるように、Vpassは半角英数字6-8桁ですよ。
もっとひどい例もあるよ。さすがにどこのクレジットカードかは書かないけど、「会員番号(NOTカード番号)」と「カードの暗証番号(4桁数字)」のみで認証ってのが。しかも会員番号はしっかりカードに記載されてる。さすがにあきれました。
三井住友VISAカードのvpassパスワードは英数字6-8文字ですね。公式サイトではそれでお金が引き出せたりする訳じゃありませんが、買い物の認証に使われることもあるので、客観的に見ると確かに危険です。でもパスワード云々言うなら、元々暗証番号自体が極めて脆弱ですよね。ものすごい論点のバランスの悪さを感じます。
ちなみに三井住友銀行のone'sダイレクトは取引の重要性によって三段階の認証がありますが、第一認証は数字4桁です。第二・三認証は各個人の持っている番号カードの2桁の数字のいくつかを使います。
これらは金銭的にものすごく価値のあるもの、かつ一見脆弱な認証を
最近、アカウント名には記号(このときはハイフン)を使えるのにパスワードには使えないというシステムに遭遇しました。何か遠大な意図でもあったのだろうか。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
貧弱なパスワードを要求するシステム (スコア:2, 興味深い)
パスワードに記号を認めないのはどういった理由なのでしょうか。少なくとも、技術的に困難なことではありません。ウェブサービスを作成されている皆さんにちょっと考えてほしいと思った一件でした。
# これを以って pixiv を悪く言うつもりはないので AC
Re:貧弱なパスワードを要求するシステム (スコア:2, すばらしい洞察)
XSSやSQLインジェクションのもとになるからとにかく入力に英数字以外のものを許してはならないというサニタイズ脳が、かえってシステムを危険にしてる実例ですね。
Re:貧弱なパスワードを要求するシステム (スコア:1)
XSSやSQLインジェクションが起こると、自分たちの責任。
仮にパスワードが英数字のみしかできなくても、パスワードを破られるのはユーザの責任。
どっちを選ぶかは明白でしょう。
1を聞いて0を知れ!
Re: (スコア:0)
とりあえずパスワードはSQLインジェクションの実証コードにしておけば
- それなりに長い
- 記号もちゃんと入ってる
- 割と覚えやすい
- 利用しているサービスの脆弱性が検出できることもある
うん、よさそうだ。(ただしどこかに載ってるサンプルの流用はだめだぞ！)
# ただし危ないリクエストをはじく仕様の、Webサーバー用FWに差し止められる可能性があります。
記号に対応する必要はないという話ではないですよ (スコア:2, おもしろおかしい)
> パスワードに記号を認めないのはどういった理由なのでしょうか。少なくとも、技術的に困難なことではありません。
わかってて書いているでしょうが、困難ではないですけど、
確実にコストアップにつながりますよね。
とりあえず、「&」「?」「"」「'」あたりはHTMLやSQLなどのために対処が必要でしょうね。
使用言語やライブラリなどによってコードのほうは記号未対応の場合と一緒でいいときもあるでしょうが、
テスト項目のほうにはきちんと盛り込まないといけませんね。
（パスワード強度を上げようとしてSQLインジェクションなどに陥っては意味がないですよね）
あと、「.」と「,」や「'」と「`」などの見間違えやすい記号を両方通すと
書面等で通達するときにトラブルになりやすいかな？
電話等の口頭の場合には「アポストロフィーって何？」とかなりそうですね。
このあたりは英字の大文字と小文字を区別して受け入れる場合と同様にめんどくさそうです。
まあ、Pixivの件はどうか存じませんが
大体、必要なセキュリティとコストの兼ね合いで仕様が定まるでしょう、マトモな開発に依頼すれば。
# 連投制限があるのでここで書いちゃいますが
# パスワード数の上限設定はVARCHAR2(8)とかしちゃうせいでしょうね（大目に設定すればいいのに）
Re:記号に対応する必要はないという話ではないですよ (スコア:3, すばらしい洞察)
・ユーザーが入力したパスワード文字列を保存するなんていう危険な実装をしようという時点で、そんな開発はまともじゃないし狂ってます。受け取ったら即座にハッシュにして、そのあとはプログラム内ではそのハッシュを扱えばいいだけです。パスワード文字列をそのまま保持するなんてとんでもない！
・ユーザーが入力したパスワード文字列を画面に表示する必要性はありませんので、これで特に問題は起きません。ユーザーの入力ミスを防ぎたいなら、二つの欄に二度入力させるなどの方法で対応すべきです。
・パスワードを忘れたユーザーに、ユーザー自身が以前入力したパスワードを通知する必要はありませんし、また、かなりのユーザーが同じパスワードを複数のサービスで使ってるため、万一第三者に不正取得された場合にも被害が自サービスだけではすまない大ごとになりかねません。
ランダムな文字列を自動生成してそれを通知すべきです。自動生成する文字列に限っては、ややこしい記号を使わずアルファベットと数字だけを使うようにしておけばいいことです。
Re:記号に対応する必要はないという話ではないですよ (スコア:2, すばらしい洞察)
＞確実にコストアップにつながりますよね。
まったくです。
まあ、ぶっちゃけいうと、今となっては桁数増やす方がずっと楽。
20文字でも30文字でも，コンピューターの記憶容量からすると誤差みたいな物だし。
ボトルネックは人間の記憶容量だな。
最近は歳のせいか、物覚えが悪くて。
Re:記号に対応する必要はないという話ではないですよ (スコア:1, すばらしい洞察)
それだと、いずれにしろ、セキュリティ的に問題があるような気がする。
一方向ハッシュ取って、BLOBか、あるいは、Base64かけたうえで、テキストとして保存するべきだと思うんですが。
Re:記号に対応する必要はないという話ではないですよ (スコア:1)
理想的にはそうですが、APOPのようなチャレンジ・レスポンス方式の場合、生パスワードが必要になりませんか？
この辺り詳しい人がいたらお願いしたいです。
Re:記号に対応する必要はないという話ではないですよ (スコア:1)
チャレンジ/レスポンス方式だからといって、生パスワードが必要とは限りません。プロトコルの設計次第です。
例えば、HTTPのDigest認証 [wikipedia.org]では、パスワードハッシュを、更にチャレンジレスポンスでハッシュ化してるので、生パスワードを保存する必要はありません。
もっとも、この場合「パスワードハッシュ」がAPOPとかでの生パスワード相当であり、それが漏れたら同サービスでのなりすましは出来てしまうわけですが、
影響が他に及ぶ心配がないというか「複数のサービスで同じパスワードを使い回している場合に、他のサービスに対しても攻撃が出来る」のを防ぐことにはなります。
Re: (スコア:0)
> 生パスワードが必要になりませんか？
なります。だから「生パスワードを保管しているからセキュリティ的に問題あり。だから生パスワードが必要なサービスはやめましょう。」なんて一概にいえるはずはないんですよ。
どういう仕組みでも設計するときにはトレードオフの考慮は必要ですよ、当たり前すぎますが。
Re:記号に対応する必要はないという話ではないですよ (スコア:1)
＞確実にコストアップにつながりますよね。
それくらいを見込んでコストを計算しないとね。
サービスを劣化させてコストを縮小したい..というのはわかるけど、劣化させて安くしましたがほめられるというのも問題だろ？
＞パスワード強度を上げようとしてSQLインジェクションなどに陥っては意味がないですよね
そういう質の低いコードしか書けない安い人を雇って安くすると？
＞同様にめんどくさそうです
面倒なら、そもそもそんなシステム組むのやめたら？
Re:記号に対応する必要はないという話ではないですよ (スコア:1, すばらしい洞察)
＞＞パスワード強度を上げようとしてSQLインジェクションなどに陥っては意味がないですよね
＞そういう質の低いコードしか書けない安い人を雇って安くすると？
この人、正気なのかな。
苦労して完璧にエスケープできるコードを書いて、十分にテストして安全性を保証するコストは、
技術力の如何に関わらず結構なものです。しかもこのコストは無闇やたらと記号を入れるという
決断さえしなければ、最初から要らないものだもの。しかも記号を入れても、とくにパスワードの
強度が上がるわけでもないというのに。
なんだか、「シートベルトもエアバッグもなしで、しかもそれを使用している時と同等以上の安全性
を技術力で実現しろ」といわれてる気分。不可能じゃないけど、金と技術の無駄づかいでしかない。
。。。。「タバコ自販機の顔認証」の方が例としては良かったかな？
Re:記号に対応する必要はないという話ではないですよ (スコア:1)
>なんだか、「シートベルトもエアバッグもなしで、しかもそれを使用している時と同等以上の安全性
>を技術力で実現しろ」といわれてる気分。
ちゃんとしたモノが作れないので、シートベルトもエアバッグも付けられないし、
付けるとコストがかかっちゃうので、付けないということを言いたいわけですね。
必要なものが何かを理解してからプログラミングなり設計をされるとよいでしょう。
Re: (スコア:0)
> わかってて書いているでしょうが、困難ではないですけど、
> 確実にコストアップにつながりますよね。
その程度でコストアップとかいうのはサニタイズ脳じゃないですかね。
> 書面等で通達するときにトラブルになりやすいかな？
パスワードを書面で通達するんですか？
初期パスワードなら紛らわしい文字は使わなければいいだけ。
Re:記号に対応する必要はないという話ではないですよ (スコア:1, 参考になる)
かつてユーザ数2000人ほど(コンピュータリテラシは低い)の組織に
システムを導入したときの話ですが、初期パスワードは自動生成文字列を割り当てました。
が、紛らわしい文字を使うとログインできないと苦情が来て対応に追われることが予想されたため、
0, o, O, 1, l, I, i, j, c, C, p, P, s, S, u, U, v, V w, W, x, X, z, Z は使わないようにして
生成しました。
こんなんでも一見複雑そうに見えるパスワードにはなりますし、
初期パスワードとしてユーザ名 + 番号みたいなものを与えて
パスワードってそういうものなんだ、みたいな間違った学習を
ユーザにさせてしまうのはよろしくないですし。
Re: (スコア:0)
だれか、このレスに「参考になる」をモデレートしてくれないかなぁ。
駄目なSIerがどういう間違いを犯すか、それをどう指摘・修正すれば良いかについて、大いに参考になるよ。
英数字しか使えないかもしれませんなサービス (スコア:2, 興味深い)
オフトピかもしれませんが。
１年ほど前の話なので、今はどうだか知りませんが、
Amazonのログインパスワードについて、使える文字や文字数制限の注意事項が見あたらなかったので、
英数字・記号を混ぜたパスワードを設定していました。問題なくログインできていました。
あるとき、欲しいものがあったので『1-click注文』しようとしたら、
ログインしているにも関わらずなぜかパスワードを求められ、しかも正しくないパスワードだと言われました。
しばらく格闘した後、Amazonのログインパスワードを、記号を取り除いた新しいパスワードにしたら、
『1-click注文』も使えるようになりました。
Amazonの中の人に、しっかりしてほしいと思った出来事でした。
Re:貧弱なパスワードを要求するシステム (スコア:1, 参考になる)
何だかpixivが特別なような言い草ですが、web上のサービスでパスワードに記号が使えない物は、感覚的には半分ぐらいはあります。
pixivはかなりのロングパスワードを受け付けるので、まだ良心的な方でしょう。
＃記号が使えなくても覚えられないぐらいの長いパスワードをKeePassなどで一括管理する方がいいと思うな
＃もちろんマスターパスワードは記号入りかつ長い物を覚えておきます。一つなら可能だし。
Re:貧弱なパスワードを要求するシステム (スコア:1)
最近むしろ増えてませんかね。私も気になってました。
右へならえ的に仕様を決めてるんでしょうかね。
Re:貧弱なパスワードを要求するシステム (スコア:1)
フレームワーク標準のバリデータをそのまま使ってるんじゃないでしょうか。
自分で書けばいいんですが、できれば標準装備で欲しいところ。
言ってないことに反論するなよ
Re: (スコア:0)
サポートが苦労する話を聞きます。
自分で設定したにも関わらず忘れて問い合わせられ、
メモ書きしたらしいパスワードを電話越しに伝えてきて
入力方法をイチイチ教えたり。
アンダーバーだけでも他の問い合わせ1、2件消化できる時間が・・
Re:貧弱なパスワードを要求するシステム (スコア:1)
うーん、皆で渡れば恐くない……って感じでしょうかね。
削ってはいけないコストな気もしますが、これはサービスする側の選択だからしょうがないですね。記号が使えないから登録しない、というほどこだわってる人は少ないでしょうし。
アンダースコアってキーボード見てもどれが該当するキーなのか分かりにくいですよね実際。マイナスに見えてしまう。
Re:貧弱なパスワードを要求するシステム (スコア:1)
keepassでトコトン強化したらiPhoneで死にました
30文字を入力するのはたまったものではなかったです
ikeepassが審査に通ることを心待ちにしています
Re: (スコア:0)
＞「パスワードには英数字しか使えません」と言われて驚きました。記号を 1 文字でも混ぜておくだけで、パスワードの強度は飛躍的に上がるのに。
『飛躍的に』ってのは言い過ぎでしょ。
アルファベット26文字。大文字小文字で５２。数字を加えて６２。
仮に（たったの）10文字としても、６２の10乗と６３の10乗を比べて、
『劇的に上がる』というのは言い過ぎだろう。
Re: (スコア:0)
利用可能な全文字の総当りなんてしねーよ
Re: (スコア:0)
>「パスワードには英数字しか使えません」
まだまし。
三井住友のvpassは数字のみだった。
ふざけすぎだろ...
Re:貧弱なパスワードを要求するシステム (スコア:1)
別のコメントにもあるように、Vpassは半角英数字6-8桁ですよ。
もっとひどい例もあるよ。
さすがにどこのクレジットカードかは書かないけど、「会員番号(NOTカード番号)」と「カードの暗証番号(4桁数字)」のみで認証ってのが。しかも会員番号はしっかりカードに記載されてる。
さすがにあきれました。
うじゃうじゃ
Re: (スコア:0)
三井住友VISAカードのvpassパスワードは英数字6-8文字ですね。
公式サイトではそれでお金が引き出せたりする訳じゃありませんが、買い物の認証に使われることもあるので、客観的に見ると確かに危険です。
でもパスワード云々言うなら、元々暗証番号自体が極めて脆弱ですよね。
ものすごい論点のバランスの悪さを感じます。
ちなみに三井住友銀行のone'sダイレクトは取引の重要性によって三段階の認証がありますが、第一認証は数字4桁です。
第二・三認証は各個人の持っている番号カードの2桁の数字のいくつかを使います。
これらは金銭的にものすごく価値のあるもの、かつ一見脆弱な認証を
Re: (スコア:0)
最近、アカウント名には記号(このときはハイフン)を使えるのにパスワードには
使えないというシステムに遭遇しました。何か遠大な意図でもあったのだろうか。