間抜けなパスワード管理 80
ストーリー by mhatta
なかなかワイルドなやり口だ 部門より
なかなかワイルドなやり口だ 部門より
pinbou 曰く、
本家のストーリーを読むと、別にAOLに限ったことではないというか、昔のSolarisやちょっと前のMac OS Xなどにも似たような問題があったようだ。本家/.の記事より。AOL.comでは最大16文字のパスワードを設定できることになっていた。ところがワシントン・ポストのSecurity Fixブログの記事によると、ユーザは確かに16文字までパスワードを入力できるものの、システム側はなんと最初の8文字しか読まないらしいことが判明したらしい。すなわち、パスワードをpassword123やpassword456と設定していても、結局パスワードとしてpasswordを使っているのと同じことになってしまうのだ。
そういや (スコア:4, 参考になる)
DES使ってたらそうなるんだっけ?
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/ja/securit... [redhat.com]
Re:そういや (スコア:3, おもしろおかしい)
付与された学内ネットワークのパスワードを変えようと思い、
15文字程度のものに変更したところログインできなくなった。（打ち間違いではない）
困って管理部署に行き事情を話したところ「ハァ？なんでそんな長いパスワードにするの？」という反応。
8文字以下にしろと言われて渋々そうしました。
どうやら僕以外に長いパスワード使う学生はいなかったらしい。
# その後その学校で個人情報漏洩があったのとは無関係にAC
Re:そういや (スコア:2, 参考になる)
>>長い＝安全と思っているのならば、その考え自体が甘いと思いますが。
このハナシ [microsoft.com]の中にある１５文字より短いうんぬんて事じゃね～のか？
＊＊たこさん＊＊・・・
Re:そういや (スコア:1, おもしろおかしい)
それ以上は数えられないんですよ。指が足りなくて。
Re:そういや (スコア:1)
「タネ(seed)」ではなく「塩(salt)」です。
Re:そういや (スコア:1, 参考になる)
旧来のDESを使ったパスワードでは、OSを問わずそうなります。
NetBSDの場合、/etc/passwd.conf で localcipher として md5, sha1, blowfish の
いずれかを指定すれば、そういう制限はなくなります。
一昔前のUNIXでは常識でしたね (スコア:4, 参考になる)
大抵の初心者案内などには最初の8文字しか認識されないので注意せよなどの記述があったものです。
Re:一昔前のUNIXでは常識でしたね (スコア:2, 興味深い)
ただ、UNIXからパスワードが9文字以上使える非UNIX(具体的にはVMS)にtelnetで入ろうとしたら、UNIX側のtelnetがパスワードを8文字に切り詰めてから送るという仕様だったためにログインできなくなりました。これは間抜けな仕様。
コンパイラからして (スコア:0)
Re:コンパイラからして (スコア:0)
ばあちゃんがそう言ってたんですか。「識別子は最大６文字しか書けない」時代もあったから結構若いおばあちゃんだね。
Re:コンパイラからして (スコア:4, おもしろおかしい)
（なのに今それを言うと奴は非常に怒ります）
Re:コンパイラからして (スコア:1)
BASICだと (Re:コンパイラからして) (スコア:1)
もちろん、全部グローバル変数。
互換性を保持するのは苦労が多い (スコア:3, 参考になる)
って本家にもすでにそういうコメントがついてるので余計なものなんだけど
いまどき残ってるのかどうか知らないけれど混在環境でNISがうごいていたりするとてきめんですね
Linuxの一部ではMD5ハッシュを格納していてかなり長いパスワードまで分別してくれるけど
MD5はMD5でコリジョンが見つかっていたりして気にする人は気にするでしょうな
WindowsネットワークのLANMANのパスワードも最初の設計（14文字を7文字ずつDES）との互換性を保持するために長らく危険危険言われてましたが
この話その話も 互換性をとるか 安全性をとるか というせめぎ合いがあるんでしょうな
Re:互換性を保持するのは苦労が多い (スコア:3, 参考になる)
NISでMD5を使っていると, たとえそれぞれのシステム(例えばLinuxとFreeBSD)でMD5をサポートしていたとしても互換性が無いためダメなんですよね. こうなるとDESしか取るハッシュが無いという.
今ではLDAPにpam_ldapを組み合わせることでUnix系システムの認証統合は簡単に出来ますし, sambaを経由することでWindows系の認証も一元管理できますから楽なものです.
関係があるのかどうか分かりませんが (スコア:2, 興味深い)
プロバイダ側に何か変更があったのかなぁ、程度で流していましたが、今思い返せば、プロバイダ側からは何のアナウンスもなかったと思いますし、ひょっとしてウチのメーラーの問題なのかしら。
Re:関係があるのかどうか分かりませんが (スコア:1)
銀行でもいい加減なところ [downloaders.cn]もあるようですし。
Re:互換性を保持するのは苦労が多い (スコア:1)
> 14文字を7文字ずつDES
やっぱりこれと関係してる？
同じドメイン上の同じユーザーの同じパスワードなのに
98ではOKでXP端末からでは入れなくて
悩みまくる、と。
#ID発行した時点でデフォルトのパスワードが16桁で設定されてたのだよ。駄目じゃん。
某社のグループウェア (スコア:3, 興味深い)
で、パスワードを0文字、つまりパスワード設定がしてない状態だと、パスワードの入力欄に
「abcdefg」って入力しよようが「123456」って入力しようが、何を入力してもログオン出来て
しまう。
Re:某社のグループウェア (スコア:1)
パスワード管理が出来ないような会社もあるのですよ。
それでもグループウェアは使いたいとなると
パスワードは設定しないとか、全員同じパスワードにしてしまうとか
せざるを得ないのです。
某社の旧サービス (スコア:1)
とてつもない重要なマシンには、パスワード管理なんて不要のようです。
『複数の物理的な鍵を、同時に回す』だけですから。
そういえば、PHPで作られた旧サービスには、こんなのが。
……ギャーと思いつつ、声を抑え、ひっそりと大急ぎで修正しました。
# パスワードではないが、認証という点で考えると
# 玄関の鍵閉めて、鍵を挿したまま出かけるようなものだな。
==========================================
投稿処理前プレビュー確認後書込処理検証処理前反映可否確認処理後……
Re:某社のグループウェア (スコア:1, 興味深い)
９文字以上の文字をパスワードとして登録しておくと
ログイン画面では９文字以上を登録していた場合は前８文字
だけでないと認証に成功しない素敵サイトがあった。
さらにパスワード変更画面では登録しておいたパスワードを
そのまま使わないといけなかったりした
一応おかしいんじゃないとメールしたけど無視されたので
その会社のサービスはそれ以来まったく使っていない
昔のSolaris？ (スコア:2, 参考になる)
Re:昔のSolaris？ (スコア:3, 参考になる)
/etc/security/policy.conf の CRYPT_DEFAULT を参照。
念の為。
Re:昔のSolaris？ (スコア:3, 参考になる)
passwd(1)のマニュアル [sun.com]をみれば、最初の8文字しか使われないことは書いてあるので、別に不具合ではないですね。8文字では足りないような場合には暗号化形式をcrypt()ではないものにするということで。ご参考までSolaris 9のpolicy.confのman [sun.com]。
人生は七転び八起き、一日は早寝早起き
Re:昔のSolaris？ (スコア:1)
昔の Solaris どころか、今時の Linux でも直面しています。
Red Hat Enterprise Linux 3, 4 で、 chpasswd(8) [linux.or.jp] を使用するシステムは、 みな該当します。（5 では直っているのだろうか？） リンク先の man ページには、
とあるわけですが、大規模なシステムでは 8 文字で良いというのが Red Hat or Linux 流？ 仕方がないので MD5 での暗号化を行って chpasswd -e に引き渡すようなスクリプトで置き換えて対処しようとしています。# 実は何か良い方法があるのでしょうか？
ネットワーク機器も (スコア:2, 参考になる)
本来、128文字まで送ることの出来るバスワードも、短くしか送らないネットワーク機器があります。
そんなことは、マニュアルの奥底を読まないとわからないので、普通の機材選定者では気がつきません。
管理 ? (スコア:1, 興味深い)
> ユーザは確かに16文字までパスワードを入力
> システム側はなんと最初の8文字しか読まないらしいことが判明したらしい。
って「管理」の問題なんですか？
認証システムの問題ではなくて？
「最初の8文字しか読まない」というのは「最初の8文字までしか記録しない」ということ？
まぁそうすると9文字以上のパスワードは通らなくなるので、
やっぱ管理の問題でなくて、認証の問題かと。
Re:管理 ? (スコア:1)
その方式が十分な強度を保っているかを確認するのも管理の問題
Re:管理 ? (スコア:0)
> その方式が十分な強度を保っているかを確認するのも管理の問題
その「管理」と「間抜けなパスワード管理」の「管理」が同じだとは思えない。
思えるの？
Re:管理 ? (スコア:1, すばらしい洞察)
最初の8文字も、記録されるわけではなくて、使われるだけかと。
hogehoge123というパスワードで設定したとして、認証時に
hogehoge456 でも認証は通るし、もちろん hogehoge でもいい。
昔からそういうシステムはけっこうあるので、何でこれをもって
「間抜けなパスワード管理」という話題になるのか不思議。
DESは昔はアメリカ以外で使えなかったからかな。
DES使ってると8文字までですよね。
そういう事情を知らない人が、「すごい間抜けな仕様をみつけた！」
と自分が大発見したように喜び勇んで投稿したんだろうか。
Re:管理 ? (スコア:0)
ええ～！？
本当なんですか？
私からは非常に間抜けなバグにしか見えませんが・・・。
新入社員に対する、テスト項目抽出の教育に使えるレベルに問題だと思います。
Re:管理 ? (スコア:4, すばらしい洞察)
> ええ～！？ 本当なんですか？ 私からは非常に間抜けなバグにしか見えませんが・・・。
たぶん話の前提が異なっているんでしょう
AOL.comが「16文字使えると喧伝しているにもかかわらず先頭から8文字しか有効じゃない」というのは
非常に間抜けな「状況」にまちがいありません
（仕様書を見ていないので仕様書のミスなのか実装の際のバグなのかは判断できませんが）
そこには論点らしい論点は残っていないということなのではないかと
むかしからそういうシステムは結構ある という肯定的? な話題が多いのは
なんで8文字以降が無視されるのか とか 他のOSなどで同じ状況が起きているのはなぜなのか とか
謎っぽい原因につながる情報を提供したい人が多いってことです
謎っぽい原因その１ (スコア:2)
#define passwd_len 8
ってのがあったから
char upasswd[passwd_len+1];
int i;
for (i=0;i<passwd_len;i++) { [あってる？] }
って素直に使うと8文字になってしまった
Re:謎っぽい原因その１ (スコア:1, すばらしい洞察)
crypt(3) およびそれに依存する関数（スクリプト言語含む）を使ってるだけじゃないの？
で，今回の件を「間抜けなバグ」と言っている人ほど，同じ間違いを犯しやすい．crypt(3)
などの「古い実装」の性質を知らないから．たぶん古参の方々はそこに警鐘を鳴らしたいの
だが，如何せん「間抜けか否か」に論点があるような流れになってしまっているのが問題．
「16文字のうち先頭8文字しか使わない」のは，おそらく仕様とは考えられないので，
確かに「間抜けなバグ」だろう．しかし，「間抜け」からも学ぶべきことがある．
ってことで．
Re:管理 ? (スコア:1, すばらしい洞察)
最初の8文字が分かりやすい単語で後ろの8文字にランダムな
文字列がついているようなパスワードでセキュアだと信じている
ユーザが居れば、困ったことになりますね
実装を裏側まで理解しないと使えない認証システムだ
ということです。昔からあろうがなかろうが愚かなことです。
実装上の単純ミスのような気がしますが。
仕様からそうだとするとより一層うんこですね
Re:管理 ? (スコア:1, すばらしい洞察)
> ということです。昔からあろうがなかろうが愚かなことです。
PAMとか実装される前の時代のLinux/UNIXを使うならば、
当然、実装を裏側まで理解して使うことが求められてました。
知らなきゃ「常識だろ、勉強しろ」とユーザが怒られる時代。
また、特にオープンソース系のOS上では、利用者を抱えてる管理者が、
パスワードの注意メッセージ出したいと思うならば、
password.cとか、シェルとかを自分で書き換えるぐらい
やって当然みたいな風潮。
そもそも、20世紀のシステム開発では、まだユーザビリティなんて
言葉はほとんど浸透していなかった。
ま、それ以前に、動く／動かないの問題というか、例えば
Redhatは動かないソフト満載でも普通に出荷してましたし・・・。
こういう話は確かに、今から見れば、愚かなことと切り捨てることも出来るかもしれませんが、
それは、例えるなら、エアバッグも衝突安全ボディも装備していない車を作るなんて
ありえないと、昭和の自動車開発エンジニアを愚か扱いするみたいな印象。
Re:管理 ? (スコア:1)
互換性の問題だった気がする (スコア:2, 参考になる)
記録している値（ハッシュ値）からは、一方行ハッシュ関数だから元のパスはわからない。
その後、8文字問題が指摘されるようになってきた。
パスワードファイルで、IDとパスの他に旧実装か新実装のどちらのハッシュ値かも記録し、パスを平分で送って貰えば旧実装のハッシュ値を新実装のハッシュ値に入れ替える事が可能だけど、平分では送らずにパスだけではなく日付データとか他のも入れて生成したハッシュ値を送るようなシステムが無いとは限らないので、それとの互換性でパスワード生成の一方行ハッシュ関数は古いシステムを切り捨てないことには変えられない。
互換性のために、デフォは出来るだけ旧システムを引っ張り続ける傾向がある。
システム的な問題ではなく、どれを選択するかの管理の問題の気もするけどな。OSのユーザー認証システムで選択出来ないから使い続けた訳ではないはず。
Re:管理 ? (スコア:0, フレームのもと)
どうでもいいよ、そんな違いの話は。
Re:管理 ? (スコア:0)
> どうでもいいよ、そんな違いの話は。
パスワードの管理の問題
と
パスワード認証システムの問題
は、
大きく違うモノで、どうでもいいものではないと思いますよ。
まぁあなたにはどうでもいいんでしょうけども。どうでもいいなら書かないほうがいいと思いますよ。
Re:管理 ? (スコア:0, すばらしい洞察)
某銀行 (スコア:1, 興味深い)
携帯からログインした場合のパスワードの文字数が違います
携帯の場合は４文字までで、
例えば、私の場合の yamamoto ってパスワードなら yama でログイン可能です
トピックのタイトル (スコア:1)
妖精哲学の三信
「だらしねぇ」という戒めの心、「歪みねぇ」という賛美の心、「仕方ない」という許容の心
/.Jのパスワードは？ (スコア:0)
なぜなんでしょうね？
「まあ１９文字もあれば十分だろ」ってことでしょうか。
Re:/.Jのパスワードは？ (スコア:0)
ファイル名の最大文字数とかも、PATH_MAXとか、MAX_PATHですが、これに\0が入るのかどうかという議論はいつも見かけるけど、僕も答えを知らない・・・。セキュリティホールになってしまうんですけどねぇ。
Re:/.Jのパスワードは？ (スコア:1, 興味深い)
なのに，パスワードを変更するときは「6-19 文字」となっているのが謎ってことじゃない
でしょうか．
PATH_MAX は POSIX では nul を含む文字数と定義されているようです．
Re:実は関係ない話なんだけど (スコア:2, 参考になる)
> The following special characters are recognized: @ and Control-U (kill);
> #, DEL and back space (erase); carriage return and line feed (end of line).
他のシステムというと…むかしHP-UXでこの制約に引っかかった人がたくさんいたのを覚えています
http://docs.hp.com/ja/5991-6484/ch02s03.html [hp.com]
Re:実は関係ない話なんだけど (スコア:1)
Re:実は関係ない話なんだけど (スコア:1)
例えば、パスワードが「with spc」だとして
「PASS "with spc"」だと通るが「PASS with spc」だと通らないPOP3 daemon もあれば、
「PASS with spc」だと通るが「PASS "with spc"」だと通らないPOP3 daemon もあったりして、
おかげで、クライアントとサーバの組み合わせによって、使えたり使えなかったりします。
しかたないので、手持ちのPOP3クライアントは、両方を試すようにしました…