危ないユーザ名とパスワードの特徴は? 78
ストーリー by mhatta
ありがちなパターンばかりだが 部門より
ありがちなパターンばかりだが 部門より
Japan.internet.comの記事より。チェック・ポイント・ソフトウェア・テクノロジーズのニュースレターによると、米国メリーランド大学 A. James Clark School of Engineeringの研究者が、ユーザ名とパスワードの安全性に関する定量的な研究を行った。
報告によれば、辞書攻撃で最も試行回数が多かったユーザー名トップ10はとなっており、ネットワーク機器のデフォルト設定や、管理者・開発者が使いがちな名称が並んでいる。また、パスワードに関してはユーザ名そのままや、末尾に数字を付けるなど一部を変化させて試行する場合が多いそうだ。
- root(2位の12倍以上試行)
- admin
- test
- guest
- info
- adm
- mysql
- user
- administrator
- oracle
これを機会に、身の回りのアカウント情報を見直してみてはいかがだろうか。
攻撃耐性 (スコア:5, おもしろおかしい)
Re:攻撃耐性 (スコア:3, 参考になる)
Re:攻撃耐性 (スコア:2, おもしろおかしい)
#後悔していますorz
友人のアカウント「エンジェルなんちゃら」は
「angel～」ではなくて「engelu～」でした
#類は友を呼ぶ…
☆大きい羊は美しい☆
Re:攻撃耐性 (スコア:1)
別にセキュリティになんの貢献もしてくれません。
# 機能追加してビルドしたら大量のエラーが・・・
# どこのどなたか存じませんが勘弁してください。
Re:攻撃耐性 (スコア:0)
理想と現実 (スコア:4, 興味深い)
つうか、いろんなサービスで、IDだのパスワードだの要求される事大杉！！
普通の名詞、個人の名前、電話番号、郵便番号、生年月日、住所の類は類推されやすいからダメ。紙にメモを取るなんてもっての他！短いパスワードは総当りに弱いから文字列は長くしろ！同じパスワードを使い回すヤツはいね！などなどなど…
いや、おっしゃられる事は解らないではないですし、御説ご尤もなんですが。ランダムに近い長いパスワードなんて、幾つも覚えておけるような脳みそがこちらには無いもんですから、ほとほと困り果てているのです。
結局、メモに頼ってる現状なんですが、皆さんどうされてるんでしょうか？
頭の中で変換出来る程度の簡単に暗号化をしたメモ（『かみあさ語』みたいな１文字ずらし２文字ずらしさらにリバースとか）ってのが一番現実的かなぁ？と思ってるんですが、いかがでしょうか？
Re:理想と現実 (スコア:4, 参考になる)
ネットが世界中に公開されているのに対して、紙のメモは物理アクセスが必要になりますから、メモさえしっかり管理しておけば悪くないと思うんですけどね。
紙に書くのもめんどくさいので、私はID Manager [woodensoldier.info]やRoboForm [roboform.com]、KeePass Password Safe [sourceforge.net]などの、ローカルアプリケーションでアカウントの管理をしています。パスワードの自動生成もできるし。
Re:理想と現実 (スコア:3, すばらしい洞察)
「_」（アンダースコア）が使えないとか、数字を必ず混ぜろ、記号は使えない、文字数固定、といった制約が多いと、
弱くて構わないシステムにも多数のユーザ名を作成する事になり、管理の難しさが上がります。
Re:理想と現実 (スコア:1)
そういうやつにはあえて大文字のパスワードを設定してやります。
その昔とあるBBSで「新規に登録するパスワードには必ず記号をまぜろ」とかにシステム変更した際、あえて昔から使っている記号の混じってないパスワードを使い続けました。
さて、そんな私はセキュリティ意識が高いのでしょうか、それとも低いのでしょうか。
めんどくさがりであることは確か(笑)。
Re:理想と現実 (スコア:3, 興味深い)
メモを取らずに安易なパスワードを作るくらいなら、複雑なパスワードを作ってメモをした方がセキュリティ上いいだろう、という事だそうです。
紙にメモする場合には家屋への侵入など物理的な脅威に配慮し、ファイルにメモする場合にはそのファイルとログインパスワードを厳重に管理する必要がありますが、複雑なパスワードを多数使うことができるそうです。
え？ 私ですか？ 私のパスワードは人には決して教えられない恥ずかしいものですよ。
昔は「MS型式番号MS名」が多かったけど、今はもっとアレゲなものに……。
-- Where your reading book is, there will your heart be also 天戸 司郎 (Silo Amato)
Re:理想と現実 (スコア:2, 参考になる)
っKeyRing [sourceforge.net]
Re:理想と現実 (スコア:2, 参考になる)
普段使う20個くらいは暗記してます。
普段使わないものは鍵のかかる引き出しにメモが(ry
度々見るオススメの方法は
・パスワード生成アルゴリズムを1つ決める
例えば、(すごく簡単な例ですが)サービス名に誕生日を挟み込んでセミコロンをつける
slashdot → s5l2a3s;
google → g5o2o3g;
そうすれば、覚えるのは1つで良い。
ってのがあるらしいですが、私は無理。 1個ばれて類推されたら全部バレそうで怖い。
# 上のアルゴリズムは簡単すぎる例なので実際はもっと類推されにくいアルゴリズムを使うのですが
Re:理想と現実 (スコア:4, 参考になる)
> 度々見るオススメの方法は
> ・パスワード生成アルゴリズムを1つ決める
これでやってます。アルゴリズムは、
・サービス名と、パスフレーズを連結した文字列を生成する(パスフレーズ自体は秘密で全サービス共通)
・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;'」って感じ。
パスワードからパスフレーズの逆算はまず無理なので、
> 1個ばれて類推されたら全部バレそうで怖い。
の心配はしてません。
Re:理想と現実 (スコア:1)
ただ、ケ、ム、レ、ロ辺りのキーボードの端にある文字を使うと悲惨なことになる場合があるのでお勧めしません。
Re:理想と現実 (スコア:1)
Re:理想と現実 (スコア:1)
忘れたときのためにメモしておくのは曲のタイトル。
14〜16文字ぐらいのパスワードになるので比較的強いかと。
記号類をどうやったらこれに組み込めるか思案中。
Re:理想と現実 (スコア:1)
辞書に出ているような安易な言葉を使えなくする、という事が目的かもしれないけど、現実としては「英文字だけの文字列の最後に数字の1（または0）を付加」というパターンが使われることが多いなんていう事も聞いた事があります…。
あと、「定期的に変えろ」というのもよくありますが、これもどうなんでしょうかねぇ。これは「万一パスワードが破られた時の被害を最小限にするため」だと思うのですが、実際犯罪するような奴らは「パスワード破ったぜ、へへへ、しばらくの間、頂きだ！」なんて呑気な考えではなく、短時間で出来る限り、最大限の事をやってしまうと思うんですけどね。長期間変更してないパスワードって、長期間破られてないパスワードってことである意味安全？
Re:理想と現実 (スコア:1, すばらしい洞察)
外向きと内向き (スコア:2, すばらしい洞察)
でそのパスワードについても“外”を向いてる所には「jvf3*A#u」みたいなガチガチのパスワードを設定していても、内向きには比較的安直なパスワードを設定しているところも多いので改めて注意が必要かと。
Re:外向きと内向き (スコア:2, おもしろおかしい)
ちょ、待てよ、俺のパスワード晒すなよ！！！
# と焦った人はいるかもしれない
Re:外向きと内向き (スコア:0)
あっしがそうでやんす。
非Win/Mac な端末(全てモニタなし)なんて、おいら以外誰も。なんだもん。
そもそもリモートログイン自体、僕だけが。
つまるところ面倒なので一桁(適当な記号を当ててるけど)でたくさん。
某社で唯一のSE氏は、同じ理由で付箋にパスワードってやってますよ。
# 外に晒すときには、もちろんガチゴチに固めてるでござる。念のため。
Re:外向きと内向き (スコア:1)
Re:外向きと内向き (スコア:0)
モニタもなくて「端末」と呼べるのかという疑問が少々・・・
リモートログインしてるなら「端末」は手元の機械のことですよ？
え？テレタイプ？ そりゃ誰も使わないわけだ。
oracle・・・ (スコア:1, 参考になる)
個人が利用してしまいがちなパスワードとは異なってくるでしょうね。
例えば、qwertyuiとかasdasdasとかzxczxczxとかのように
キーの並びに沿って押したようなパスワード、
testuserとかtestとかguest、そのサービスの会社名というのも比較的ありがちで、
しかもIDも同一だったりして、テストで作ったようなアカウントでログインできてしまう。
#第三者によるものか、自社社員によるものかは様々で、他社の事は詳しく知りませんが、
#自社で提供している会員制サービスのアカウントにはそのようなものが存在していました。
Re:oracle・・・ (スコア:1, すばらしい洞察)
パスワードをハッシュもせずに管理者が見ることのできるサービスだったんですか？
# プライバシーポリシーにはパスワードの管理方法もきちんと書いておいてほしい。
Re:oracle・・・ (スコア:0)
1番目の可能性としてはハッシュに対して辞書攻撃を行った結果そういうパスワードがみつかった
2番目の可能性としてはチャレンジレスポンス認証のために平文あるいは復号可能な形式でパスワードを保存していた
--
ハッシュは手段であって解法ではない
Re:oracle・・・ (スコア:0)
自社サービスと言っても、GMailのような広く公開されたものではなく、
元から限られた経路で限られた相手に提供という担保はあります。
それにしても、様々なパッケージで複数提供しておりますので一概には言えませんが…
そう言った保存がされているものもおそらくあるかと思います。
ただ、前提が「IDが公知な単語」というユーザーにおいて「IDとPWが同一」という状況です。
それは、別に管理者で無くてもスクリプトで確認が出来るレベルの話でしょう。
実際、最初にそのようなアカウントがあると私が気がつ
Re:oracle・・・ (スコア:0)
>キーの並びに沿って押したようなパスワード、
1qazxsw2やzaq12wsxなどですね。
#類似系に1234rewqやzxcvfdsa等
うわなにを (スコア:0)
あれ (スコア:1)
scottじゃないのか……
Re:あれ (スコア:0)
Re:あれ (スコア:0)
せめて記号を1文字 (スコア:1)
安易なパスワードでも、これだけで強度はグッと上がります。この程度なら誰でも出来るはず・・・
(参考)
最強のパスワードを作る(1) [nikkeibp.co.jp]
最強のパスワードを作る(2) [nikkeibp.co.jp]
最強のパスワードを作る(3) [nikkeibp.co.jp]
Re:せめて記号を1文字 (スコア:1)
何回か入力してるうちに、こんなランダムなパスワードでも覚えちゃえるもんです。
フィルタを (スコア:1, 参考になる)
デフォルト設定を無効にし忘れてやられるようなのは、ここでは考慮する必要ないだろう？
一部のルータ (スコア:1, 興味深い)
Re:一部のルータ (スコア:3, おもしろおかしい)
ユーザ名にはrootを入れてください
初期パスワードはxxxです
と書かれたページにリダイレクトされる
Re:一部のルータ (スコア:1, すばらしい洞察)
意外 (スコア:0)
# お金かかってるシステムのが中身がショボいって場合も多々ありますが
Re:まだ (スコア:3, おもしろおかしい)
パスワード無し(Enter)というオチだった時の脱力感と来たら
# 真っ先に試すか、最後まで気付かないかじゃない？ ＜ パス無し
トップ10か (スコア:0)
"system" とかが無いのが意外といえば意外
一番の驚きは (スコア:1)
Re:一番の驚きは (スコア:1)
Re:トップ10か (スコア:0)
さぁみなさん (スコア:0)
チェックしたら発表するんですよね。私はチェックしないぞ。本人も忘れているぐらいの特権は
問題外では？ (スコア:0)
ssh公開鍵認証のみ許可（パスワード認証禁止）にした上で、一般ユーザはsu禁止。これが最低レベルでしょ？
# sshポートのアクセスログを見ると、パスワード認証は怖くて使えなくなります。
Re:問題外では？ (スコア:1)
問題外なのはここに来る方々は判っているだろうけど、
実際調査したらこうなりました、って事でしょう。
Re:Webメールとの組合せ (スコア:1, 興味深い)
「ユーザがうちのサービスに入力してるメールアドレスとパスワード、mixiに入れたら何割通ると思う？」
なんて話で盛り上がりました。
結論：結構通っちゃうんじゃね？
Re:Webメールとの組合せ (スコア:1)
＞あなたのところサービスはわかっちゃうんですか？
ユーザがパスワードを無くしたときに、
新しいパスワードを発行するタイプではなく
忘れてるパスワードを送ってくれるタイプのサービスでは
保存していると思いますよ。
# サービスとしてどっちがよいかは微妙かと思う。
# 新しいパスワードを発行するまでのプロセスと
# 今のパスワードを送るまでのプロセス。
# 新しいパスワードを発行した場合、利用者がそれになじめるか
# また元のパスワードに戻すんだったらそれを利用者ができるのか
# そんなサービスの部分で気を遣わなくてはならなくなりますからね。
# 扱っている情報の重要さも影響しますし。
Re:Webメールとの組合せ (スコア:1)
「だからパスワードはサイト毎に違うのを使おうね」
という啓蒙はあまり見ない気がする。。。私が見てないだけ？