ユーザIDの重複防止とパスワードリマインダについて
AO
２点ほど質問させてください。
# 説明が下手で長文になってしまい申し訳ありません。
１点目は、P347のユーザIDの重複防止についてです。
重複を防止するためには、既に登録済みのユーザIDを新規登録時に記入された場合、
弾かねばならないと思いますが、これは、そのユーザIDが登録済みであるかどうかを
悪意のある人間が確認するのに使われてしまう可能性がありますよね。
ログイン時の入力ミスやロックに関しては、特定できないようなエラーメッセージを
表示するという方法が紹介されていましたが、新規登録時には、どこに不備があって
登録できないのかは明示的に教えてあげないと正規の利用者は困ると思います。
これに対する対策はどのようにすればよいと思われますか？
２点目は、P354,355の利用者向けパスワードリマインダについてです。
こちらは、メールアドレスが登録されているかどうかの確認に利用されないために、
登録されていないメールアドレスでも登録されている場合と同じように振舞うべきと
書かれていますが、これは正規の利用者視点からするとかなりストレスフルな仕様に
思えます。
メールアドレスを複数持っていて使い分けていたり、プロバイダ変更などで変わって、
どのメールアドレスで登録していたか記憶があやふやという人は、少なくとも
パスワードリマインダを使う状況になっているようなユーザの中には、無視できない
割合で存在すると思います。
そういったユーザがパスワードリマインダを使用するとき、未登録アドレスでは
エラーになる仕様であれば、思い当たるメールアドレスを順番に試していけばいい
ですが、本の仕様だと、登録されていないメールアドレスで何度も試しては首をひねり、
諦めるか、ヘルプデスクに問い合わせ→そこで初めてメールアドレス自体の登録が
ないことを知り、徒労感が怒りに変わる、といったシナリオが思い浮かびます。
ユーザビリティをとるかセキュリティをとるかという話だと思いますが、本の中では
かなり一貫して正規のユーザへの影響も考慮されているようだったのに、
ここだけ著しくユーザビリティが下がっているような気がして違和感を感じました。
いくつかの商用サイトで非登録メールアドレスで（勿論自分のメールアドレスです）
試してみたところ、以下のような仕様のパスワードリマインダがありました。
・メールアドレスの入力とCAPTCHAを同時に求め、どちらの入力がエラーだったのか
わからないようなエラーメッセージを出す
・登録/非登録関係なく画面遷移はするが、その画面に、非登録アドレスには
メール送信しない仕様であることを明記している
後者については、本の(D)との差異は、『非登録アドレスにはメール送信しない仕様で
あることを明記する』だけですが、これだけでもユーザの混乱は大幅に減ると思います。
上記の２つの仕様は、本の仕様に比べてユーザビリティは高くなると思うのですが、
セキュリティ的にはどの程度劣るでしょうか？
先生のご意見を伺いたいです。
以上、よろしくお願いいたします。
徳丸浩
1.ユーザIDの重複防止について ユーザIDの重複を防止すると、ユーザIDの存在チェックに使われる懸念があるというのはその通りだと思います。
これに対しては、ユーザIDをログインIDに使用せず、ログイン時にはメールアドレス等を使用するという案が考えられます。
メールアドレスについても重複の可能性がありますが、これは「ただいまこのメールアドレスに対する新規ユーザ登録の操作がなされましたが、既にこのメールアドレスに対してユーザ登録されています。もし登録操作した覚えがない場合はxxx宛ご連絡ください。」という内容の注意を記載して新規登録は中止すればよいでしょう。
ユーザIDの存在の有無を第三者が確認できて良いか否かは、サイト仕様によると思いますが、ログインIDとして使わないユーザIDであれば、確認できても許容できる場合が多いように思えます。
2.パスワードリセットについて
こちらは中々難しい問題です。そもそもの前提として、パスワードリセットはセキュリティ強度を下げる方向に作用するので、利便性とセキュリティの微妙な線引きが要求されるからです。
パスワードリセットに限らず一般論として、以下の基準で判断するのはどうで
しょうか。
・メールアドレスの登録の有無については、そのメールアドレスに送信する情報
のみとする。・新規登録の場合は、無条件に、そのメールアドレスに送信する。内容は、
(1)既に登録されている、あるいは、(2)新規に登録されようとしている・パスワードリセットの場合は、登録されている場合のみ送信する・アカウントロックの場合は、登録されているメールアドレスにロックの旨を通
知する。アカウントロックかどうかはメールを見るように誘導する(P339)
パスワードリセットの場合は、ご指摘のように、『非登録アドレスにはメール送信しない仕様であることを明記する』とよいと思いました。
5章の内容は、あくまで仕様例・実装例ですので、サイトの性格や、要求される
セキュリティ水準により仕様・実装は変わってきます。このため、本書に書かれて
いる趣旨をご理解いただいた上で、実際のサイト仕様は個別に判断していただく
べきだと思います。
以上、簡単ですが回答させていただきます。不明な点、あるいは異論等があればご遠慮なくコメントください。他の方がコメントいただいても結構です。
2011年9月24日22:39 AO <akr...@gmail.com>:
> --
> このメールは Google グループのグループ「「体系的に学ぶ 安全なWebアプリケーションの作り方」サポートML」の登録者に送られています。
> このグループに投稿するには、wasbook...@googlegroups.com にメールを送信してください。
> このグループから退会するには、wasbook-reade...@googlegroups.com にメールを送信してください。
> 詳細については、http://groups.google.com/group/wasbook-readers?hl=ja からこのグループにアクセスしてください。
>
>
--
徳丸浩 htok...@gmail.com
AO
徳丸さん、迅速なご回答ありがとうございました。
> 1.ユーザIDの重複防止について
> メールアドレスについても重複の可能性がありますが、これは「ただいまこのメールアドレスに対する新規ユーザ登録の操作がなされましたが、既にこのメールアドレスに対してユーザ登録されています。もし登録操作した覚えがない場合はxxx宛ご連絡ください。」という内容の注意を記載して新規登録は中止すればよいでしょう。
> ユーザIDの存在の有無を第三者が確認できて良いか否かは、サイト仕様によると思いますが、ログインIDとして使わないユーザIDであれば、確認できても許容できる場合が多いように思えます。
はい、私も、ユーザID＝ログインIDでなければ問題ないと思います。
ただ、上記の案だと、メールアドレス＝ログインIDなので、メールアドレスの登録有無が
わかってしまうのはまずくないでしょうか？
とはいえ新規登録時に何が原因で登録できないのかを伏せることはできないと思いますので、
とれる対策としてはせめてツールで調査されてしまわないようにCAPTCHAを併用するぐらい
ですかね・・・。
2.パスワードリセットについてはよくわかりました。ありがとうございました。
> 5章の内容は、あくまで仕様例・実装例ですので、サイトの性格や、要求される
> セキュリティ水準により仕様・実装は変わってきます。このため、本書に書かれて
> いる趣旨をご理解いただいた上で、実際のサイト仕様は個別に判断していただく
> べきだと思います。
４章はMust、５章はShouldというところでしょうか？了解いたしました。
申し遅れましたが、このような素晴らしい本を世に出していただけたことに感謝します。
一人でも多くのエンジニアがこの本を手にとってセキュアなアプリケーションの実装に
役立ててくれることを祈り、周りに宣伝しておきます。;-)
徳丸浩
こんにちは。徳丸です。
>ただ、上記の案だと、メールアドレス＝ログインIDなので、メールアドレスの登録有無が
>わかってしまうのはまずくないでしょうか？
メールアドレスの登録有無は画面に表示しないように実装できると思います。
・指定のメールアドレスに対して、受け取り確認のメールを送信する
・画面には、「メール記載の確認番号を入力して下さい」などと表示しつつ、「ただし既にメールアドレスに対してユーザ登録済みであれば、メールにその旨を記載しています」などと注記する
・メールの本文には、新規登録と登録済みの場合で表示を変える。登録済みの場合は、新規登録が進めないようにしておく
メールアドレスに対する情報は以下の原則に従えばよいと思います。
・確認ずみのメールアドレスに対して、認証後に画面表示するのはOK
・確認済みでないか、認証していない場合（パスワードリセットなど）は、そのメールアドレス宛に送信する
--
徳丸浩 htok...@gmail.com
AO
とてもよくわかりました。その方法がベストですね！
ご返答ありがとうございました！