アカウント名:
パスワード:
実際、パスワードを平文で保存しているおそろしいシステムを見たことがありますが、統計とれるほどに一般的だとはさすがに信じたくないところです。
平文ではありませんが、Windows (Active Directory) であれば「暗号化を元に戻せる状態でパスワードを保存する」 [microsoft.com] というポリシーが設定できますので、これを仕掛ければ良さそうに見えます。
プロトコルの原理上、PPP CHAP [wikipedia.org] をサポートするときにはパスワードが必要です。
リモート アクセスまたはインターネット認証サービス (IAS) を介してチャレンジ ハンドシェイク認証プロトコル (CHAP) を使用する場合は、このポリシー設定を有効にする必要があります。また、Microsoft インターネット インフォメーション サービス (IIS) のダイジェスト認証を使用する場合も、このポリシーが必要です。(Windows XP セキュリティ ガイド) [microsoft.com]
最近では流行らないと思いますが、メール関連でも APOP や CRAM-MD5 をサポートするとなると、必然的にパスワードは平文(または復号可能な暗号)で保存せざるを得ないと思います。
パスワードを平文で保存しているおそろしいシステム
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ? -- Debian初級
どうやって知った? (スコア:2, 興味深い)
Source: Perfect Passwords, Mark Burnett 2005
って書いてました。でこの本の著者はどうやって知ったんだろう?
ついでに:約9人に1人がテーブル9.1(Top500のことかな)のパスワードを使ってるらしいです。
AVG anti-virus data base out of date
Re:どうやって知った? (スコア:2, 興味深い)
Re:どうやって知った? (スコア:1)
>(つまり、大元のソースはどのように統計をとったのでしょう)
「パスワードを教えていただけませんか?」
と言ってチョコレートを渡した [srad.jp]だけではないかと。
Re: (スコア:0)
Re:どうやって知った? (スコア:1)
# 管理がアマいだけならsaltかけましょう♪
で、もう一つの可能性としては、(以下略)
Re:どうやって知った? (スコア:3, 参考になる)
平文ではありませんが、Windows (Active Directory) であれば「暗号化を元に戻せる状態でパスワードを保存する」 [microsoft.com] というポリシーが設定できますので、これを仕掛ければ良さそうに見えます。
プロトコルの原理上、PPP CHAP [wikipedia.org] をサポートするときにはパスワードが必要です。
最近では流行らないと思いますが、メール関連でも APOP や CRAM-MD5 をサポートするとなると、必然的にパスワードは平文(または復号可能な暗号)で保存せざるを得ないと思います。
Re: (スコア:0)
> 必然的にパスワードは平文(または復号可能な暗号)で保存せざるを得ないと思います。
CRAM-MD5 については、ハッシュで保存できます。
MD5 以外でも逐次的なハッシュ関数なら、「途中まで計算したハッシュ値」を保存しておいて、
認証の際に続きを計算するという方式が採用できます。実装されているサーバは多くないかも
しれませんが。
# SSL も秘密鍵を復号可能な形で保存するなんて、恐ろしい子!ですかね。
Re: (スコア:0)
この場合も、サーバで保持しているハッシュ値が漏れるとアウトですよね?
違いは、生パスワードと違い、もし同じパスワードを設定している別のサーバがあった場合に、
芋づる式に入れなくなるということですかね?
Re:どうやって知った? (スコア:1)
(コンピュータリテラシーはかなり高いと思われるところだったのですが...)
のこりの2割は各々ユニーク(同一パスワードは1件しかない)と考えて差し支えないと思いますので、top500を得るにはこういったデータだけで問題ないのではないでしょうか?
Best regards, でぃーすけ
Re: (スコア:0)
Re: (スコア:0)
「パスワードのハッシュとチャレンジを結合したもの」のハッシュを計算するだろ。常考。
Re: (スコア:0)
MS-CHAP とかの話ですかね?
もし「パスワードのハッシュ」を利用するなら、それがサーバに保存されている必要があります。
このとき、保存した「パスワードのハッシュ」が漏れてしまえば、認証をパスすることが可能です。
つまり、ハッシュ化して保存したところで、/etc/passwd(shadow) のような意味で、
安全性が増すわけではないため、常考というほどのメリットはありません。
Re:どうやって知った? (スコア:1, 参考になる)
それは当然でしょう。クライアントから与えられたパスワードからハッシュを計算して、サーバが保存している「ハッシュの値」と比較しないといけませんから。
>このとき、保存した「パスワードのハッシュ」が漏れてしまえば、認証をパスすることが可能です。
これは通常考えにくいです。「パスワードのハッシュ」が漏れても、プログラム(システム)が常考レベルで改変されていないなら、「漏れた『パスワードのハッシュ』をハッシュ化」した値と保存している「ハッシュの値」と比較しますから、認証をパスできません。
認証をパスできる可能性としては
[1] 「パスワードのハッシュ」からパスワードが類推できた(ハッシュ値が既知のフレーズや「よく使われる危険なパスワード殿堂入り」あるいは天文的な確率の奇跡)
[2] ハッシュ関数の不備あるいは選択ミス
[3] プログラム(システム)が常考レベルでなかった orz
[4] プログラム(システム)が改変されていた(既にルートキットが進入済み)
など・・・と考えられますが,それは「パスワードのハッシュ」をサーバ保存したからではなく、運が悪いか、システム運用者の無知の可能性が高いでしょう。
そもそも、適切に十分なハッシュ値からの認証が現実的なコストで可能であるなら、ワンタイムパスワードでも公開認証方式でも解読されて、今日の暗号理論が崩れますぞい。その方法を知ってるなら是非タレコんでください。
Re: (スコア:0)
えっと、通常の CHAP や APOP が生パスワード(に復元可能なデータ)を保存せざるを得ないのは、プロトコル策定した人たちが、単に無知だったからだと思ってます?(^^;
毎回異なるチャレンジを食わせた後のハッシュ結果が、毎回同じ「保存しているハッシュの値」になるなんて、ありえないと思いますよ。
Re: (スコア:0)
#1486382
> パスワードを平文で保存しているおそろしいシステム
それは確かに恐ろしい。
#1486485
> challenge responseで認証するには、平文(か平文に戻せる)システムが必要なんですが。
間違い。理由は下の文。
#1486503
> 「パスワードのハッシュとチャレンジを結合したもの」のハッシュを計算するだろ。常考。
正しい
#1486559
> もし「パスワードのハッシュ」を利用するなら、それがサーバに保存されている必要があります。
> このとき、保存した「パスワードのハッシュ」が漏れてしまえば、認証をパスすることが可能です。
正しい
Re: (スコア:0)
俺流まとめ (スコア:0)
#1486382
> パスワードを平文で保存しているおそろしいシステム
しかしパスワードを平文でネットワークに流すシステムよりマシ。
#1486485
> challenge responseで認証するには、平文(か平文に戻せる)システムが必要なんですが。
間違いではない。しかし,
#1486503
> 「パスワードのハッシュとチャレンジを結合したもの」のハッシュを計算するだろ。常考。
工夫次第ではこういうことも可能。
HMAC の場合でいうと,「パスワードと『パスワードとチャレンジを結合したもののハッシュ』
を結合したもののハッシュ』といったところだろうか。MD5 のように「
Re: (スコア:0)
>> このとき、保存した「パスワードのハッシュ」が漏れてしまえば、認証をパスすることが可能です。
>
>正しい。が,ハッシュ値でそのまま認証をパスできるわけではない。そのハッシュ値に衝突する
>パスワードが見つかれば可能。と #1486593 は言いたかったのだろう。
>
>#1486593
>> これは通常考えにくいです。
>
>Charange Response の話が並行してあるため,混乱を招きやすいが,
>ハッシュ値の計算がサーバ側でおこなわれるのであれば,まぁ,言いたいことは
>分かる,気がする。
一つ前のまとめをしている方に比べて、要点
Re: (スコア:0)
前提としているんじゃないかということが言いたかったんだ。
昔,UNIX マシンに telnet でログインしていたときのような。
あ,でもそこから「時間稼ぎになる」ってまとめるのは完全に間違えていますね。
1行でまとめるなら
「ハッシュ化してても漏れたらアウト」
ってことですね。
# 何より Charange ってスペルが恥ずかしいんだが。
Re: (スコア:0)
すみません、この部分は訂正です。
やや使いづらいですが、OTPのようにハッシュを遡る方法が抜けていました…他にもありますかね?
(/etc/shadow のような方式は、生パスワードをサーバ側入力に必要とするので除外していいと思いますが)
いずれにせよ、チャレンジ/レスポンス方式の場合には、いかなるハッシュ計算方法/保存方法であっても、
保存情報が漏れれば、攻撃側で認証をパスするための計算が可能だという結論は変わりません。
Re: (スコア:0)