アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
SSLの証明書 (スコア:0, すばらしい洞察)
>SSLのクライアント認証方式が挙げられるが、「この方式では、フィッシングに
>よるパスワード詐取の対策は可能だが、事前にユーザーに電子証明書を配布する
>必要があり導入コストが高いなどの問題があった」
SSLの証明書買うのに躊躇するような企業のサイトに、ログインして
個人情報を預けるほうが不安なんだがなあ。
# とりあえず、個人情報は500円換算で債権化しときますね
Re:SSLの証明書 (スコア:1, すばらしい洞察)
#間違ってるかもしれんので臆病者のAC
Re:SSLの証明書 (スコア:1)
クライアント証明書ほどの安全性でなくても、とりあえずユーザパスワードを事前に知らない限り認証が成立しない方式だとしたら、一見の価値はあると思いますよ。技術的に新しいかよりも、利便性と安全性のバランスの実装が肝かもね。
Re:SSLの証明書 (スコア:0)
いっそ発想を転換してみるとどうだろう、と最近思います。SSL クライアント証明書の鍵配布問題を厳格に考えるのをやめにして、いっそメールで配ってしまえばどうでしょう。確かにそのメールをスニッフィングされれば(パスフレーズで保護するとしても)安全とは言えませんが、1回かぎりです。共通鍵認証で毎セッション、パスワードがやりとりされるよりはずっとマシだという考え方はありではないでしょうか。
SSL クライアント証明書を厳格に扱いすぎるあまり、使えない状況になっているのはもったいない気がします。
Re:SSLの証明書 (スコア:1)
クライアント証明書はWebブラウザに導入して初めて使えますので、
メールで配布するというだけでは使い物にならないように思います。
また一度導入すれば終わりではなく、定期的に証明書を更新する必要も生じます。
それらクライアント証明書の運用に掛かる様々な費用を考慮すると、
現時点ではクライアント証明書は安価なサービスには見合わないように思います。