アカウント名:
パスワード:
もう、いっそのこと公開鍵認証に移行するとか、は難しいんだろうなぁ。例えば、どこかが認証サービスを行って、他のサイトは Twitter の OAuth みたいなかたちで認証するみたいな。
OpenIDみたいなシステムで同じユーザーIDとメールアドレスとパスワードを使い回す理由がわからん覚えることが1つで便利だろうけど、1つ流失したら全部おしまい
逆に、同じパスワード入力したらブラウザがサイト毎に、個別のパスワードを自動生成、送信してくれる規格とか出来ればいいと思う。元パスワードが同じなら、同じサイトには必ず同じパスワードが生成されて、元パスワードの逆算は不可で。各サイトは生成されたパスワードしかわからないから、漏れても被害がそのサイトのみに限定される。
ワイタイムならぬ、ワンサイトパスワー
それに近いのは Mozilla Persona ?
個人的には、ちゃんとOpen ID connectしてくれれば、それでいいんだけどな。
# というかIDプロバイダを固定はしたくない。いざってときがあるし、より安全なのに切り替えがきかないとな# いまだと、Google/Microsoftで2要素有効がかなりマシかな...
## VeriSignのVIPはもうちょっとがんばって
私は手作業(自作スクリプト) [srad.jp]でそれをやってます。
アルゴリズムは、・サービス名と、パスフレーズを連結した文字列を生成する(パスフレーズ自体は秘密で全サービス共通)・md5 を取って、base64で可視化する。パスワードに使える文字によっては、+/=は取り除くというもの。サービス名slashdot.jp、パスフレーズpasswordなら、MD5 ("slashdot.jppassword") = 056f4e7e19e041883212ed3708b2d435なので、これをbase64化して、パスワードは BW9OfhngQYgyEu03CLLUNQ になります。実際には、「slashdot.jppassword」って文字列を与えたら、それに対応するパスワードを表示するperlスクリプトを使ってます。1linerで「perl -e 'use Digest::MD5; print Digest::MD5->new->add("slashdot.jppassword")->b64digest;'」って感じ。
アルゴリズムは、・サービス名と、パスフレーズを連結した文字列を生成する(パスフレーズ自体は秘密で全サービス共通)・md5 を取って、base64で可視化する。パスワードに使える文字によっては、+/=は取り除くというもの。
サービス名slashdot.jp、パスフレーズpasswordなら、MD5 ("slashdot.jppassword") = 056f4e7e19e041883212ed3708b2d435なので、これをbase64化して、パスワードは BW9OfhngQYgyEu03CLLUNQ になります。
実際には、「slashdot.jppassword」って文字列を与えたら、それに対応するパスワードを表示するperlスクリプトを使ってます。1linerで「perl -e 'use Digest::MD5; print Digest::MD5->new->add("slashdot.jppassword")->b64digest;'」って感じ。
っていうものです。
既存のアルゴリズムを使ってるので、Perlの動く環境さえあればどこでもパスワードを再生でき、「プログラムがないからパスワードを再生できない」なんてことにハマらないのが強み。
文字種が限られた場合にどうするかというのが最大の難点ですかね。上述slashdot.jppasswordの場合、「数字だけ4桁のサイト」に使おうとしたら、「BW9OfhngQYgyEu03CLLUNQ」から数字だけを抜き出すと「903」で一桁足りない。今は「桁数が足りない場合は繰り返す」というルールで「9039」を使うという統一ルールで運用してますが、運悪く数字が一文字も含まれないパスワードが生成されたらどうしよう、という感じ。あと、逆に「数字、アルファベット、記号それぞれ1文字以上使うこと」みたいなパスワード文字種に制限をかけてる場合にも使えないのも困ったり。
たしか、ドメイン名のハッシュをとって、そのハッシュとパスワードから、ドメインごとに違うパスワードをを生成してくれる拡張機能があったはず。
しかし、攻撃者がパスワードとドメイン名を知っていた場合、元のパスワードが復元できないようにするには、いろいろテクニックが要りそうなもんだけど。
それだと結局パスワード管理ツールを入れる方がいいな。サイトとパスワードを関連させてしまうのは脆弱性になるので、パスワード管理ツールでパスワードをランダムに生成させて、親パスワードで一括管理した方が手間は同じでより安全。
> サイトとパスワードを関連させてしまうのは脆弱性になるので、
そもそもパスワードを分けてる人は、今のままで問題無い。パスワードを分けろと言っても聞かない人の場合の話です。
"同じパスワード"というのは最悪の場合の話で、実際は違うパスワード使います。動作のイメージは、メールのAPOPが一番近いかな。（ハッシュに使う値はサーバ毎に固定。認証時だけでなく、パスワード登録時も同様にハッシュ値のみ送るのが異なる）
規格化できてブラウザが対応すれば、ユーザの手間は０。パスワード管理ツールとはレイヤーが違うので併用も可能。
×流失○流出
# 「～せざろうえない」と同じくらい気になる
otpauthってのがあるからそれが普及すればよくなるかも。Google認証システムみたいなやつね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
ID / パスワードでの認証に限界が (スコア:1)
もう、いっそのこと公開鍵認証に移行するとか、は難しいんだろうなぁ。
例えば、どこかが認証サービスを行って、他のサイトは Twitter の OAuth みたいなかたちで認証するみたいな。
Re:ID / パスワードでの認証に限界が (スコア:1)
OpenIDみたいなシステムで同じユーザーIDとメールアドレスとパスワードを使い回す理由がわからん
覚えることが1つで便利だろうけど、1つ流失したら全部おしまい
Re:ID / パスワードでの認証に限界が (スコア:2)
逆に、同じパスワード入力したら
ブラウザがサイト毎に、個別のパスワードを
自動生成、送信してくれる規格とか出来ればいいと思う。
元パスワードが同じなら、同じサイトには
必ず同じパスワードが生成されて、
元パスワードの逆算は不可で。
各サイトは生成されたパスワードしかわからないから、
漏れても被害がそのサイトのみに限定される。
ワイタイムならぬ、ワンサイトパスワー
Re:ID / パスワードでの認証に限界が (スコア:2)
それに近いのは Mozilla Persona ?
個人的には、ちゃんとOpen ID connectしてくれれば、それでいいんだけどな。
# というかIDプロバイダを固定はしたくない。いざってときがあるし、より安全なのに切り替えがきかないとな
# いまだと、Google/Microsoftで2要素有効がかなりマシかな...
## VeriSignのVIPはもうちょっとがんばって
M-FalconSky (暑いか寒い)
Re:ID / パスワードでの認証に限界が (スコア:1)
私は手作業(自作スクリプト) [srad.jp]でそれをやってます。
っていうものです。
既存のアルゴリズムを使ってるので、Perlの動く環境さえあればどこでもパスワードを再生でき、「プログラムがないからパスワードを再生できない」なんてことにハマらないのが強み。
文字種が限られた場合にどうするかというのが最大の難点ですかね。
上述slashdot.jppasswordの場合、「数字だけ4桁のサイト」に使おうとしたら、「BW9OfhngQYgyEu03CLLUNQ」から数字だけを抜き出すと「903」で一桁足りない。
今は「桁数が足りない場合は繰り返す」というルールで「9039」を使うという統一ルールで運用してますが、運悪く数字が一文字も含まれないパスワードが生成されたらどうしよう、という感じ。
あと、逆に「数字、アルファベット、記号それぞれ1文字以上使うこと」みたいなパスワード文字種に制限をかけてる場合にも使えないのも困ったり。
Re: (スコア:0)
たしか、ドメイン名のハッシュをとって、そのハッシュとパスワードから、ドメインごとに違うパスワードをを生成してくれる拡張機能があったはず。
しかし、攻撃者がパスワードとドメイン名を知っていた場合、元のパスワードが復元できないようにするには、いろいろテクニックが要りそうなもんだけど。
Re: (スコア:0)
それだと結局パスワード管理ツールを入れる方がいいな。
サイトとパスワードを関連させてしまうのは脆弱性になるので、
パスワード管理ツールでパスワードをランダムに生成させて、
親パスワードで一括管理した方が手間は同じでより安全。
Re:ID / パスワードでの認証に限界が (スコア:1)
> サイトとパスワードを関連させてしまうのは脆弱性になるので、
そもそもパスワードを分けてる人は、今のままで問題無い。
パスワードを分けろと言っても聞かない人の場合の話です。
"同じパスワード"というのは最悪の場合の話で、実際は違うパスワード使います。
動作のイメージは、メールのAPOPが一番近いかな。
（ハッシュに使う値はサーバ毎に固定。
認証時だけでなく、パスワード登録時も同様にハッシュ値のみ送るのが異なる）
規格化できてブラウザが対応すれば、ユーザの手間は０。
パスワード管理ツールとはレイヤーが違うので併用も可能。
Re: (スコア:0)
×流失
○流出
# 「～せざろうえない」と同じくらい気になる
Re: (スコア:0)
何か不味い事が起きたときには、そのサイト・アプリ・デバイスを切り離せばおしまい。
Re: (スコア:0)
ようはパスワードを使い回すのもOpenIDでどこでもログインできるようにするのも、
使い回しのパスワード または OpenIDのパスワード が漏れたら全部漏れることに変わりないってことかと。
何かまずいこと、っていうのに気づければいいですけどね・・・気づいた時にはOpenIDで連携してるすべてのサービスがやられてるわけですから・・・
Re:ID / パスワードでの認証に限界が (スコア:1)
だけど今度は、「秘密鍵のパスフレーズを空文字列にする馬鹿が、マルウェアで秘密鍵ファイルを盗まれる」というストーリーが見えてしまった。
秘密鍵は複数のサイトで共通にしておいてもセキュリティ上直ぐに問題じゃないからいいんだけど、空パスフレーズの秘密鍵を盗まれて全部やられるという。
秘密鍵盗まれちゃ駄目だろ。
公開鍵方式暗号って、興味のない人には複雑すぎる仕組みの気がする。
Re: (スコア:0)
otpauthってのがあるからそれが普及すればよくなるかも。
Google認証システムみたいなやつね。