大学パスワード管理の現状 115
ストーリー by Oliver
目をそむけたくなる 部門より
目をそむけたくなる 部門より
Anonymous Coward曰く、"京都大学メディアセンターのパスワードの現状についてのレポートがありました。とくとご覧あれ。"
俺の大学ではパスワード変更時にかなり厳しく入力されたパスワード候補をチェックし、/etc/shadowは当然のこと、さらに定期的にJohn等のクラッカーでチェックして警告を受けてもパスワードを変更しなかったユーザはアカウント停止にしているのだが、他の大学はどうだろう。パスワード再発行の回数はたしかに増えるが、それだけの価値があると思っている。普段はリモートからメールチェックだけしていて、停止解除のために身分証明書持参で現れなければいけない連中には不評だが、自業自得だ。
弱いパスワードを登録できた時点で負け (スコア:5, 参考になる)
ちなみに辞書攻撃可能なパスワードだと市販PC程度のスペックの マシンでも 100ms程度 で破られます。みんなが考えているよりも簡単です。 そんなに難しくもなく、ちょっとヒントを言うと 去年のCRYPTO2001 ( CRYPTO2002 [iacr.org] ) でのランプセッションの余興に パスワード破りのデモがあったのですが、それを一般のシステムに 応用すればすぐできます。 京都大学のように２４０００個のパスワードがあっても 全部走査するのも１時間かかりません。
組み込みシステムのような記憶領域の容量がない場合、PAMのように検査用辞書を持つことができません。その時は、僕の作った遷移状態（マルコフ連鎖）を使った文字列の複雑さを計算する 非常に小さい評価関数 [h2np.net] を試してみてください。かなり良い成績を出すはずです。
すずきひろのぶ
なんじゃこりゃー (スコア:1, おもしろおかしい)
% ./peval
hironobu
7 hironobu
RKEaBh@$
51 RKEaBh@$
12345678
126 12345678
あと、ドキュメントにはスペルチェッカをかけるようにしてください。
小さな評価関数は小さな評価関数以上でも以下でもない (スコア:1)
むりなものは無理です。 もう一度書きますが、Fool Proofなパスワードセキュリティのシステムではありません。 あくまでも遷移状態からみた文字列の複雑さを計算する非常に小さな評価関数です。 それだけで過大な期待をするのは間違いです。
Linuxや*BSD、あるいはUNIX系のシステムでパスワードセキュリティのシステムを使うなら、 PAMを組み込むこと が今の所、最良の方法だと言えるでしょう。ただし、それでもすらも完璧だということはありません。
組み込みシステムのようなメモリや記憶容量のないコンピュータの中に入れる目的なので実行コードも2kbyteを切ります。 そのため 知識データベースを用いていないので、当然、知識による判断はできません。 12345678の入力でも、この函数からの戻り値に対するスレッシュホールドを上げれば対処できますが、たとえば誕生日や電話番号、あるいは学籍番号のようなものは判断できません。
容量が小さく、計算が速く、何でもできるような 万能なマジックがあると思うのは危険 です。
すずきひろのぶ
Re:弱いパスワードを登録できた時点で負け (スコア:1)
Fool Proofな目的に作ったのではなく、純粋に遷移で 見ているので12345678とか%%%%%%%%というのも いい点数が出てしまいますが、まあ、 そーゆーパスワードを選ぶ人は何をやっても救えない というスタンスでやっています。ちなみにランダムな８桁の数字は結構、丈夫ですよ。
すずきひろのぶ
Re:弱いパスワードを登録できた時点で負け (スコア:1)
パスワードを決めるときには
- なるべく長く
- 英大文字・英小文字・数字・記号を入れる
- 同じ文字を何度も使わない
- 英語・日本語などの単語になっていない
にするようにとよく言われます。これらは守るべきです。たとえこれらの情報が破る側にヒントとして与えられたとしても、これだけでは探索空間が大きすぎて、ちょっとやそっとでは破れません、たぶん。 :-)「破る人間の裏をかいて」数字ばかりとか記号ばかりとか長さ3文字とかにしている人はきっといるだろうと思うのですが、それはやっぱり危険です。破る側がちょっと「普通でないもの」を試したらすぐに破られてしまいますから。
鵜呑みにしてみる？
Re:弱いパスワードを登録できた時点で負け (スコア:1)
というだけでは十分ではなく パスワードクラックの辞書には載っていないこと が必要です。 フランス語、ドイツ語、イタリア語、スペイン語などの卑しい言葉で、かつ文字O(オー)を数字0(ゼロ)などに変えるありがちな方法は 上記の要件は満たしますが、辞書攻撃ではたぶんダメでしょう。 ちなみにパスワードクラックの辞書は数十万、 あっても数百万の範囲ですので、８桁ランダム数字の方が それよりは少しは期待がもてます。
また人間が選ぶランダムな文字列でという要件を入れても、 人間の脳は乱数生成器を持っていないので:-) 人間が文字を意図的に選択するという点で弱くなる可能性があります。
それを避けるために、たとえばmkpasswdというプログラムを使ってパスワード候補の文字列生成したり(これはGNUのmkpasswdではなくNISTの人が作ったもの)、 それがなかったら、
% cat /dev/urandom | mimencode |head -1
として表示される文字列から任意の長さを選ぶとか人間の恣意的な データが含まれないようにした方がいいでしょう。 あとはその人の運次第。
すずきひろのぶ
Re:弱いパスワードを登録できた時点で負け (スコア:1)
// クラックする際に参考にするという意味ではなく。 :)
鵜呑みにしてみる？
物議を醸しそうだが (スコア:3, 興味深い)
公表された勇気に
拍手を送りたいと思います。
# 確認もせずに言っていいのか？ > 俺
厳しすぎ…かどうか判断つきかねますが (スコア:2, 参考になる)
でも大学で専門教育を受ける人たちというのは、今後企業などの組織で管理者になる可能性が高いのですから、せめてコンピュータに関係する学部学科では厳しくしておいたほうがいいと思います。
でも、シャドウパスワードとかあるのですから、解析なんてされるものなのでしょうか。
シャドウパスワード (スコア:1)
なんででしょう。
Re:厳しすぎ…かどうか判断つきかねますが (スコア:1)
＞解析なんてされるものなのでしょうか。
なんせ、教官はroot権限を持っているんですから/etc/shadowの読み込み権限持っているじゃないですか。
/etc/shadowに書き込まれる文字列の計算式は公開されているものだし。
大学はマシンが多いから並列処理すれば比較的早く発見できます。
.::.:... .::....: .::...:: .::.:.:: .::..:.: .:::..:.
I 1 2 B H4[keR. :-)
暗号化後の文字列がない場合 (スコア:2, 参考になる)
シャドウパスワードが導入されていてそれが困難な場合であっても、やはりパスワードの単純さや規則性の有無が解析のしやすさに関係するのでしょうか。
アタックの効率は落ちるでしょう。 (スコア:1)
のくだりがあることから、一般ユーザ権限で読み取れると
考えて問題ないでしょう。
shadowにしたからといって暗号強度が上がるわけでもありません。
が
では、shadowファイルが読めなかったら？
アタック手法に掛かる時間的コスト以外の点では
結局ブルートアタックを行うので、「解析しやすさ」に
変わりはないと思います。
ですがアタックの効率は落ちるでしょう。
お・そ・ら・く。
なぜか？
shadowファイルが読めた場合はその暗号化済列をつかって
パスワード候補→暗号化→shadowの内容とマッチング
という手順でブルートアタックされると考えられます。
一方、ファイルが読めなかった場合の
いくつかあるアタック手法中で効率がよさそうなのは
一般ユーザ権限からの○○コマンドをスレッド化してアタック
するものではないかと思います。
# 深くは突っ込まんでください
2つの手法を同じ計算資源を使って行ったと考えても
格段に前者のほうがコストが低いと考えられるので
アタック効率は落ちると思います。
うーん (スコア:2, 参考になる)
意味がなくってちょっと困ってます。
厳しくしていると、いつのまにか
端末のＰＣにリモートアクセス用のＩＳＤＮ－ＴＡとか
勝手に繋ぎ、そっち経由で使われてしまう事も経験しました。
（当然パスワードも管理してない）
元記事の母集団は、全て大学の最下層？学部１年程度だと考えますが
会社などの組織でこの調子で
「パスワードが簡単だから使っちゃダメ」とかやると
後でとんでもないトバッチリが上から振ってくるので
「ご説明」に本当に苦労します。
Re:うーん (スコア:1)
全学年、大学院まで合わせた合計ですね。
理系は４回生で殆どが研究室配属になり研究室のパソコンが使えますし、
学部の方で与えられるメールアドレスで事足りるので
メディアセンターのPCを利用する機会もぐんと減るということを
加味していない元記事の分析はやや甘いという印象を受けます。
Re:うーん (スコア:1)
けど、メディアセンタの端末を使う機会が無いので
passwdする動機がありません。。
ということで理系のほうがラボに入り浸っている分・・・
という言い訳。
昔の話 (スコア:2, おもしろおかしい)
某帝国大学はおちゃめ。
Re:昔の話 (スコア:1)
ネタ的にそっちの方が面白いというだけでしょう．
Re:ECCをなめてはいかん (スコア:1)
元ネタを知らなければここまで偏った選択にはならんでしょう。
うじゃうじゃ
工学部の連中が・・・ (スコア:1)
パスワードがバレてしまった人の多かった学部を
順に並べると、
総合人間学部、教職員、工学部・工学研究科、理学部・理学研究科
と。
総合人間学部は、まあ分かりますが
教職員、工学部・工学研究科、理学部・理学研究科といった
普段からコンピュータをよく使っているような人々に限って
このザマは・・・何でしょう?
MLでも (スコア:2, すばらしい洞察)
Re:工学部の連中が・・・ (スコア:1)
- 計算機をよく使う人のほうがパスワードを初期パスワードから変更している割合が高い
- 初期パスワードはランダムだが、パスワードを変更するときに覚えやすくばれやすいパスワードを選ぶ人がけっこういる
と考えれば、の説明はつきます。パスワードを変えるまでの時間間隔と、パスワードの単純さの間に相関があったら面白いと思いますが（既にそういう調査結果はあってもおかしくないので、ぼくが知らないだけかも）、この調査結果だけならまあ、感覚的にはわかっていた状況を実際に調べて確認したという意味合いが強いのでしょう。
鵜呑みにしてみる？
Re:工学部の連中が・・・ (スコア:1)
が、よく考えながら読まないと何を意味しているのかわからないので、具体的なコメントは控えます（「パスワードを忘れた人数」はどうしてわかるんだろう）。親コメント #89700 [srad.jp] の後半部分は、この調査ではパスワード変更の頻度とパスワードの単純さの関係については調べていないという誤解に基づいて書いてしまったので、撤回します。
鵜呑みにしてみる？
Re:工学部の連中が・・・ (スコア:1)
パスワードって自分で決めないほうが安全なのかもしれない。ドイツだとキャッシュ カードの暗証番号も銀行が決めてくれる。覚えにくくてやっかいだけど、安全と引 き替えならまあ、我慢するしかないか。
佐藤亮一 in Frankfurt Germany
Re:工学部の連中が・・・ (スコア:1)
京大の場合だとアカウント発行時にアカウント名と初期パスワード の印刷された小さなラベルをもらいます。で、ある文系学生に 「メールアドレス教えて」といったところ、このラベルを そのまま見せられたことがあります。 そのときはすぐにパスワードを変更しろと言っておきましたが、 もしこうやって見せた相手のなかに悪意のある人間がいたら どうなることか。
この調査には現れていないけど、こういう「パスワードの 管理方法」に関する教育も重要ですよね。
Re:工学部の連中が・・・ (スコア:1)
そのラベルは学生の見ている前で大学事務の人がラベルの並んだ帳簿をめくって渡してくれるので
探している間に同じクラスの十数人のパスワードを見ることが出来ました。
Re:工学部の連中が・・・ (スコア:1)
Re:工学部の連中が・・・ (スコア:1)
鵜呑みにしてみる？
Re:工学部の連中が・・・ (スコア:1, すばらしい洞察)
それはわざわざ書くまでもない常識だと思ったので省略しましたが。
でも、本当の１番の理由は被害に遭いやすいからではなく、 「パスワードはちゃんとしたのをつけなくていい」というメッセージを暗黙のうちに利用者に伝えてるってことかもしれない。いくら講義や手引き書で立派な ことを言ってても、配る初期パスワードが誕生日では、言行不一致というものです。で、利用者は「言」のほうじゃなくて「行」のほうをよくみてて真似ると。
saitoh
Re:工学部の連中が・・・ (スコア:1)
それと、結局「被害に遭う可能性があるような初期パスワード」と「被害に遭ったと主張される可能性があるような初期パスワード」って同じことですよね。どの理由が1番かは別として、これは重要な指摘だと思います。個人的に「スコア +1: 覚えておきたい考え方」。
鵜呑みにしてみる？
Re:工学部の連中が・・・ (スコア:1)
他に、日立のシステムエンジニア8人中、ショキパスワ-ドから変更しなのが2人、で、一人が破られてるってのも。あんたプロとちゃうの?
今の学校の現状 (スコア:1)
＞教職員、工学部・工学研究科、理学部・理学研究科といった
＞普段からコンピュータをよく使っているような人々に限って
＞このザマは・・・何でしょう?
別にコンピュータを使うからと言って、
コンピュータのプロではない。使えればいいのだ。
パスワード？そんなん知ったことない。
今の学校そんなもんです。
.::.:... .::....: .::...:: .::.:.:: .::..:.: .:::..:.
I 1 2 B H4[keR. :-)
Re:今の学校の現状 (スコア:1)
> # パスワードクラックされた時点でセキュリティの授業単位は、剥奪ですな
それいいなあ．
でも「セキュリティの授業」ってあるのかなあ…？
Re:今の学校の現状 (スコア:1)
ありますよ。
その名前も「セキュリティ概論」
「特論」の方が受ける気が沸くんですけどね
教科書は「図解でわかるセキュリティ」
ここでハッカーズジャパンとか、
UNIXセキュリティハンドブックとかは使いません。
あくまで一般的なセキュリティです。
＃ちなみに私が教室貸し切って放課後にやる実習は楽しいですよ。
＃教科書なしだけど、LAN内部でやばい事しますから
.::.:... .::....: .::...:: .::.:.:: .::..:.: .:::..:.
I 1 2 B H4[keR. :-)
もっと酷い例 (スコア:1)
ＩＤ：学籍番号
初期パスワード：イニシャル＋生年月日
なんてのがありましたよ．
しかも，ほとんどの学生がパスワード変更せずに使ってた．
今でも同じ状況なんだろうか？恐ろしい．
Re:もっと酷い例 (スコア:1)
ID: 学籍番号
初期パスワード: 誕生日の月日
だったので、
4月になるとお誕生日リスト作って遊んでました(ぉぃ
実習の一回目でパスワード変更するのでそのままの人は少なかったですが…。
Re:もっと酷い例 (スコア:1)
ぁ、それうちか（^^;
イヤ、うちは生年月日だけだったような気がするな（^^;;
学籍番号はそれ自体が個人情報だから、メールアカウントとしても利用されるUser IDとして使うべきじゃない、と私は思うんですけどね。メールを送るだけで個人情報をさらすことが強制されるのは良くないと思うのですよ。
...学校側にそのように進言したら、「わかってるけどめんどーだから」みたいなことを言われたさ。
文系キャンパスが多摩動物公園付近にある、某私立大学ね。
Re:もっと酷い例 (スコア:1)
わからないんでしょうかねえ。。。
拙者:「おめー、セキュリティ、どうしてる?」
友人:「オレ、セキュリティなんか気にしなくてもいいよ」
拙者:「なぜ?」
友人:「だって、クラックされても全然平気だし」
拙者:「はあ?」
友人:「盗まれるとヤバいようなデータ入ってねえもん」
・・・
Re:もっと酷い例 (スコア:1)
こう考えると、大学から発行されたアカウントを使っていない人もアカウントが盗まれないよう守る必要があります。それでは面倒なので、アカウントが不要な人が自分のアカウントを消すことができる仕組みも必要でしょう。大学に入学したら教養としてコンピュータを扱うだろうから、初めは全員のアカウントが必要になるでしょうが。
鵜呑みにしてみる？
Re:もっと酷い例 (スコア:1)
「窓じゃ、あぶねえよ」って通知したら
「PCにはだいじなデータは入れないし、大事なことには
使わない」と、きた。
そーゆーことだけで済む話じゃあないんだが。
単なるクライアントをやりたけりゃ、窓でなくて
オープンソースのましんでいいってば、さあ。
Re:もっと酷い例 (スコア:1)
ID：学籍番号
初期パスワード：名字をアルファベット
でした。友人からパスワード盗まれた、といわれて聞いてみたらそんな状況。
盗まれるのが当たり前だって。
普通にfingerで名前引けたし、セキュリティなんて何も考えてなかっ たんだろうな。ちなみに去年の話です（汗）
Re:もっともっと酷い例 (スコア:1)
今は危ないパスワードは拒否されるようになってますが。
今の職場は何重にもパスワード&セキュリティチェックが
行き届いてるので、「さすがだなぁ」と感心しています。
会社だと… (スコア:1)
# セキュリティのため、と変更すると怒られる。パスワードの意味なし :-b
更にどのサブシステムも他のサブシステムにデータ送信用とか言って、その id/passwd を教えてるので、一体どれだけの人が各システムのメイン id/passwd を知っているのか把握しきれてないのが現状です。
システム管理者の方針なので従うしかないんだけど、物凄く間違ってる気がしてならないのは、考え過ぎなんでしょうか…。社内だから大丈夫って訳ではないですよね？
Re:会社だと… (スコア:2, 興味深い)
- 社内にプライベートなデータは持ち込まない
- 機密データを扱うアカウントは個人用とは別
という前提なら間違ってないような気もしますけどね... 業務上の理由で作りかけの代物にアクセスする必要もあるでしょうし (しかも担当者ドロンとか :-) のせいで)。# 多分、そういう事ではないんだろうなぁ...
Re:会社だと… (スコア:1)
メイン環境の id/passなし(!) に依存してシステム作っちゃって，
本番環境では別のセキュリティ管理部署からチェックが入って，泣いたり…
だいたい今時 rsh なんて使うなって．(T_T)
Linuxのログインパスワード (スコア:1)
で、この春はいわゆる『Linux授業』があるのですが、まぁrootのパスワードが最初だけ全員同じなのは仕方ないとして、授業中に作るユーザのパスワードが“辞書に載っている”と警告もらう人が多いのなんの。
また、IDとパスワードを同じにしている人も決して少なくなく。
銀行のカードなどと違って危険性が具体的に掴みにくい分、セキュリティ意識が薄いのかもしれません。
学校という空間のせいもあるでしょうけど・・
職場でのお話。 (スコア:1, 参考になる)
去年入社した後輩(大学院卒)に「このデータ、ここをこう直しておいて」と頼んでしばらくしたら、「終わりましたが上書きできません」とのこと。作成した当人以外はread onlyなんだからこれは当然。
「あぁ、上書きは後で俺がやっとくから」と答えると「やっときましょうか？」というお返事。「だって俺のパスワード知らないだろ？」と言ったら「えぇ、パスワードってxxx(デフォルトのパスワード。最初は皆同じで変更しなくても使いつづけられる)じゃないんですか！？」と逆に驚かれた。
確かにウチの職場は「何でわざわざ変えるの？」という意見が主流派(まったく…)だが、そこで驚くということは、やはり大学でもパスワードっていうものに対してその程度の認識(デフォルトをそのまま使う)しかなかったのか？
#バレたらアレなんで、一応AC。
実情はもっと酷いでしょう (スコア:1)
京都大学でコレなんですから...
大学全体で全員共通 + 推測可能な初期パスワードを使っていた例知ってるので、これぐらいでは驚けません。
Takeshi HASEGAWA
Tip & Trick (スコア:1, 参考になる)
まず、適当な英文を考える。
次に各単語の一文字目をとる。名詞なら大文字に。
その順番を逆にする
で、途中に!やら;やら記号を最低2個いれる。
という風に。これだと一見ランダムな文字列だけど適度に覚えやすい。パスワード変更の際も一文字目じゃなくて二文字目にすれば別の文を覚えなくてもOK。で、パスワードが書かれた紙が発見されようものなら問答無用でアカウント停止2週間。アカウント／パスワードがないと課題を提出できない1,2年生向け講義が多いから死活問題。
Re:Tip & Trick (スコア:2, 参考になる)
1. ある単語や単語列を考える。(例:slashdot)
2. それを入力するとき、ひとつ右のキーで入力。 (d;sjfpy)
これで一見するとランダムな文字列が生成されます。
もちろん、ひとつ上、ふたつ右とかでもよいですが。
タッチタイプができればぜんぜん難しくありませんし、むしろパスワードそのものを憶えていないので、セキュリティは抜群かと？