貧弱なパスワードは貧弱なウイルス対策ソフトよりも深刻な問題である 64
ストーリー by reo
今更ではあるが数字を見せられると納得させられる 部門より
今更ではあるが数字を見せられると納得させられる 部門より
ある Anonymous Coward 曰く、
本家 /. 記事 "Poor Passwords A Worse Problem Than Poor Antivirus" より、
ウイルスやワームについてはよく話題に上がるが、貧弱なパスワード管理のほうがより深刻な問題である、という調査結果が Channel Insider と CompTIA によって報告されている。Larry Walsh 氏が彼の Security Channel blog に書いたところによると、SIer やセキュリティサービスプロバイダはセキュリティ評価を行う際に、ウイルス対策ソフトよりもパスワード管理の方に多くの問題がある場合が多いと述べているそうだ。Walsh 氏やそのブログ記事は、ユーザーは依然パスワードについて無頓着であり、また現状のビジネスはこの深刻な脆弱性に気を払っていないと主張している。
Walsh 氏の記事で映画「スペースボール」が話題に上るが、これがどういうことかというとこういうこと (YouTube 動画, Lifehacker 記事より) らしい。
いちいち考えてらんない (スコア:3, すばらしい洞察)
そうなるといちいち暗記なんてしてられません。
さらに、定期的にパスワードを変更させられたりした挙句、ログイン失敗して無効になった日には、
パスワードの問い合わせや再設定に余計なコストがかかるわけであり、ユーザに貧弱でないパスワード管理を要求するのは、
もう今の時代、現実的ではないんじゃないでしょうか。
そんな、全てのパスワードを定期的に変更しつつ、全てのパスワードをアルゴリズムから類推されないパターンにしつつ、
それらをメモなど記録媒体に書き留めず頭の中に入れている人なんて、存在するんでしょうか？
私にはそれらを一般ユーザに求めるなんてナンセンスとしか思えません。
Re:いちいち考えてらんない (スコア:1)
大半のパスワードについては、
「暗号化してUSBメモリにでも入れて、それを鍵のかかった引き出しか金庫にでもしまっておく」
で現実的にはOKだと思う。もちろん盗まれた場合は、パスワードを全部変更しなければ
ならないのでかなりの手間なのだが。
もちろん銀行のキャッシュカードの暗証番号みたいに、絶対に暗記しないとダメなのもあるけどね。
貧弱なパスワードを要求するシステム (スコア:2, 興味深い)
パスワードに記号を認めないのはどういった理由なのでしょうか。少なくとも、技術的に困難なことではありません。ウェブサービスを作成されている皆さんにちょっと考えてほしいと思った一件でした。
# これを以って pixiv を悪く言うつもりはないので AC
Re:貧弱なパスワードを要求するシステム (スコア:2, すばらしい洞察)
XSSやSQLインジェクションのもとになるからとにかく入力に英数字以外のものを許してはならないというサニタイズ脳が、かえってシステムを危険にしてる実例ですね。
Re:貧弱なパスワードを要求するシステム (スコア:1)
XSSやSQLインジェクションが起こると、自分たちの責任。
仮にパスワードが英数字のみしかできなくても、パスワードを破られるのはユーザの責任。
どっちを選ぶかは明白でしょう。
1を聞いて0を知れ!
記号に対応する必要はないという話ではないですよ (スコア:2, おもしろおかしい)
> パスワードに記号を認めないのはどういった理由なのでしょうか。少なくとも、技術的に困難なことではありません。
わかってて書いているでしょうが、困難ではないですけど、
確実にコストアップにつながりますよね。
とりあえず、「&」「?」「"」「'」あたりはHTMLやSQLなどのために対処が必要でしょうね。
使用言語やライブラリなどによってコードのほうは記号未対応の場合と一緒でいいときもあるでしょうが、
テスト項目のほうにはきちんと盛り込まないといけませんね。
（パスワード強度を上げようとしてSQLインジェクションなどに陥っては意味がないですよね）
あと、「.」と「,」や「'」と「`」などの見間違えやすい記号を両方通すと
書面等で通達するときにトラブルになりやすいかな？
電話等の口頭の場合には「アポストロフィーって何？」とかなりそうですね。
このあたりは英字の大文字と小文字を区別して受け入れる場合と同様にめんどくさそうです。
まあ、Pixivの件はどうか存じませんが
大体、必要なセキュリティとコストの兼ね合いで仕様が定まるでしょう、マトモな開発に依頼すれば。
# 連投制限があるのでここで書いちゃいますが
# パスワード数の上限設定はVARCHAR2(8)とかしちゃうせいでしょうね（大目に設定すればいいのに）
Re:記号に対応する必要はないという話ではないですよ (スコア:3, すばらしい洞察)
・ユーザーが入力したパスワード文字列を保存するなんていう危険な実装をしようという時点で、そんな開発はまともじゃないし狂ってます。受け取ったら即座にハッシュにして、そのあとはプログラム内ではそのハッシュを扱えばいいだけです。パスワード文字列をそのまま保持するなんてとんでもない！
・ユーザーが入力したパスワード文字列を画面に表示する必要性はありませんので、これで特に問題は起きません。ユーザーの入力ミスを防ぎたいなら、二つの欄に二度入力させるなどの方法で対応すべきです。
・パスワードを忘れたユーザーに、ユーザー自身が以前入力したパスワードを通知する必要はありませんし、また、かなりのユーザーが同じパスワードを複数のサービスで使ってるため、万一第三者に不正取得された場合にも被害が自サービスだけではすまない大ごとになりかねません。
ランダムな文字列を自動生成してそれを通知すべきです。自動生成する文字列に限っては、ややこしい記号を使わずアルファベットと数字だけを使うようにしておけばいいことです。
Re:記号に対応する必要はないという話ではないですよ (スコア:2, すばらしい洞察)
＞確実にコストアップにつながりますよね。
まったくです。
まあ、ぶっちゃけいうと、今となっては桁数増やす方がずっと楽。
20文字でも30文字でも，コンピューターの記憶容量からすると誤差みたいな物だし。
ボトルネックは人間の記憶容量だな。
最近は歳のせいか、物覚えが悪くて。
Re:記号に対応する必要はないという話ではないですよ (スコア:1, すばらしい洞察)
それだと、いずれにしろ、セキュリティ的に問題があるような気がする。
一方向ハッシュ取って、BLOBか、あるいは、Base64かけたうえで、テキストとして保存するべきだと思うんですが。
Re:記号に対応する必要はないという話ではないですよ (スコア:1)
理想的にはそうですが、APOPのようなチャレンジ・レスポンス方式の場合、生パスワードが必要になりませんか？
この辺り詳しい人がいたらお願いしたいです。
Re:記号に対応する必要はないという話ではないですよ (スコア:1)
チャレンジ/レスポンス方式だからといって、生パスワードが必要とは限りません。プロトコルの設計次第です。
例えば、HTTPのDigest認証 [wikipedia.org]では、パスワードハッシュを、更にチャレンジレスポンスでハッシュ化してるので、生パスワードを保存する必要はありません。
もっとも、この場合「パスワードハッシュ」がAPOPとかでの生パスワード相当であり、それが漏れたら同サービスでのなりすましは出来てしまうわけですが、
影響が他に及ぶ心配がないというか「複数のサービスで同じパスワードを使い回している場合に、他のサービスに対しても攻撃が出来る」のを防ぐことにはなります。
Re:記号に対応する必要はないという話ではないですよ (スコア:1)
＞確実にコストアップにつながりますよね。
それくらいを見込んでコストを計算しないとね。
サービスを劣化させてコストを縮小したい..というのはわかるけど、劣化させて安くしましたがほめられるというのも問題だろ？
＞パスワード強度を上げようとしてSQLインジェクションなどに陥っては意味がないですよね
そういう質の低いコードしか書けない安い人を雇って安くすると？
＞同様にめんどくさそうです
面倒なら、そもそもそんなシステム組むのやめたら？
Re:記号に対応する必要はないという話ではないですよ (スコア:1, すばらしい洞察)
＞＞パスワード強度を上げようとしてSQLインジェクションなどに陥っては意味がないですよね
＞そういう質の低いコードしか書けない安い人を雇って安くすると？
この人、正気なのかな。
苦労して完璧にエスケープできるコードを書いて、十分にテストして安全性を保証するコストは、
技術力の如何に関わらず結構なものです。しかもこのコストは無闇やたらと記号を入れるという
決断さえしなければ、最初から要らないものだもの。しかも記号を入れても、とくにパスワードの
強度が上がるわけでもないというのに。
なんだか、「シートベルトもエアバッグもなしで、しかもそれを使用している時と同等以上の安全性
を技術力で実現しろ」といわれてる気分。不可能じゃないけど、金と技術の無駄づかいでしかない。
。。。。「タバコ自販機の顔認証」の方が例としては良かったかな？
Re:記号に対応する必要はないという話ではないですよ (スコア:1)
>なんだか、「シートベルトもエアバッグもなしで、しかもそれを使用している時と同等以上の安全性
>を技術力で実現しろ」といわれてる気分。
ちゃんとしたモノが作れないので、シートベルトもエアバッグも付けられないし、
付けるとコストがかかっちゃうので、付けないということを言いたいわけですね。
必要なものが何かを理解してからプログラミングなり設計をされるとよいでしょう。
Re: (スコア:0)
> わかってて書いているでしょうが、困難ではないですけど、
> 確実にコストアップにつながりますよね。
その程度でコストアップとかいうのはサニタイズ脳じゃないですかね。
> 書面等で通達するときにトラブルになりやすいかな？
パスワードを書面で通達するんですか？
初期パスワードなら紛らわしい文字は使わなければいいだけ。
Re:記号に対応する必要はないという話ではないですよ (スコア:1, 参考になる)
かつてユーザ数2000人ほど(コンピュータリテラシは低い)の組織に
システムを導入したときの話ですが、初期パスワードは自動生成文字列を割り当てました。
が、紛らわしい文字を使うとログインできないと苦情が来て対応に追われることが予想されたため、
0, o, O, 1, l, I, i, j, c, C, p, P, s, S, u, U, v, V w, W, x, X, z, Z は使わないようにして
生成しました。
こんなんでも一見複雑そうに見えるパスワードにはなりますし、
初期パスワードとしてユーザ名 + 番号みたいなものを与えて
パスワードってそういうものなんだ、みたいな間違った学習を
ユーザにさせてしまうのはよろしくないですし。
Re: (スコア:0)
だれか、このレスに「参考になる」をモデレートしてくれないかなぁ。
駄目なSIerがどういう間違いを犯すか、それをどう指摘・修正すれば良いかについて、大いに参考になるよ。
英数字しか使えないかもしれませんなサービス (スコア:2, 興味深い)
オフトピかもしれませんが。
１年ほど前の話なので、今はどうだか知りませんが、
Amazonのログインパスワードについて、使える文字や文字数制限の注意事項が見あたらなかったので、
英数字・記号を混ぜたパスワードを設定していました。問題なくログインできていました。
あるとき、欲しいものがあったので『1-click注文』しようとしたら、
ログインしているにも関わらずなぜかパスワードを求められ、しかも正しくないパスワードだと言われました。
しばらく格闘した後、Amazonのログインパスワードを、記号を取り除いた新しいパスワードにしたら、
『1-click注文』も使えるようになりました。
Amazonの中の人に、しっかりしてほしいと思った出来事でした。
Re:貧弱なパスワードを要求するシステム (スコア:1, 参考になる)
何だかpixivが特別なような言い草ですが、web上のサービスでパスワードに記号が使えない物は、感覚的には半分ぐらいはあります。
pixivはかなりのロングパスワードを受け付けるので、まだ良心的な方でしょう。
＃記号が使えなくても覚えられないぐらいの長いパスワードをKeePassなどで一括管理する方がいいと思うな
＃もちろんマスターパスワードは記号入りかつ長い物を覚えておきます。一つなら可能だし。
Re:貧弱なパスワードを要求するシステム (スコア:1)
最近むしろ増えてませんかね。私も気になってました。
右へならえ的に仕様を決めてるんでしょうかね。
Re:貧弱なパスワードを要求するシステム (スコア:1)
フレームワーク標準のバリデータをそのまま使ってるんじゃないでしょうか。
自分で書けばいいんですが、できれば標準装備で欲しいところ。
言ってないことに反論するなよ
Re: (スコア:0)
サポートが苦労する話を聞きます。
自分で設定したにも関わらず忘れて問い合わせられ、
メモ書きしたらしいパスワードを電話越しに伝えてきて
入力方法をイチイチ教えたり。
アンダーバーだけでも他の問い合わせ1、2件消化できる時間が・・
Re:貧弱なパスワードを要求するシステム (スコア:1)
うーん、皆で渡れば恐くない……って感じでしょうかね。
削ってはいけないコストな気もしますが、これはサービスする側の選択だからしょうがないですね。記号が使えないから登録しない、というほどこだわってる人は少ないでしょうし。
アンダースコアってキーボード見てもどれが該当するキーなのか分かりにくいですよね実際。マイナスに見えてしまう。
Re:貧弱なパスワードを要求するシステム (スコア:1)
keepassでトコトン強化したらiPhoneで死にました
30文字を入力するのはたまったものではなかったです
ikeepassが審査に通ることを心待ちにしています
Re:貧弱なパスワードを要求するシステム (スコア:1)
別のコメントにもあるように、Vpassは半角英数字6-8桁ですよ。
もっとひどい例もあるよ。
さすがにどこのクレジットカードかは書かないけど、「会員番号(NOTカード番号)」と「カードの暗証番号(4桁数字)」のみで認証ってのが。しかも会員番号はしっかりカードに記載されてる。
さすがにあきれました。
うじゃうじゃ
パスワード長に上限を設ける馬鹿サイト (スコア:2, 参考になる)
先日クレジットカード番号漏洩を起こした、アミューズのネットショップy「アスマート」 [amuse.co.jp]ですが、会員登録をしようと、パスワードに10文字を入力したところ、「パスワードは8文字以下」でないといけないとのエラーが出まして、試しに、1文字にしたところ登録できてしまうようでした。
いったいどういう理由で、パスワードの長さを短くさせているんでしょうね。
Re:パスワード長に上限を設ける馬鹿サイト (スコア:2)
長いパスワード好むユーザからは、追加料金取りましょう。
銀行も免許証も、よんケタ(＋数値のみ)なんだよなぁ。
Re: (スコア:0)
#define MAX_PASSWORD 8
struct USER_T {
char[MAX_USERNAME+1] firstname;
char[MAX_USERNAME+1] lastname;
char[MAX_PASSWORD+1] password;
/* ... */
}
Re: (スコア:0)
え？
DBにだって制限あるんだから1PBの文字列入れさせろとか言われても困るよ
文字数の制限があることじゃなくて文字数の制限が短すぎるのが問題なんだよ
Re: (スコア:0)
いっそのこと、パスワード無しにしちゃえば。ユーザー名がパスワード代わり。
メールアドレスさえあれば、会員登録はできるんだろうし。
貧弱な (スコア:1)
貧弱な人間は貧弱なパスワードよりも深刻な問題である。
○か×か？
# Yes, Sir.
仕方がない (スコア:1)
外出中にうちのセキュリティ担当者から、“今日中に全パソコンにセキュリティ対策を施さなくてはならないので君のパスワードを今この電話で教えろ”とか電話がかかってきた時から、馬鹿馬鹿しくなって適当なパスワードを使ってますねぇ。
最近セキュリティ関係に（上が）うるさくなってるので仕方がないのでしょう。
Re:仕方がない (スコア:1)
だいぶ粘りましたが、怒られたので教えました。
というオチですいません。
脆弱なユーザ名も止めたらどうか (スコア:0)
Re:脆弱なユーザ名も止めたらどうか (スコア:1)
最近はsshdもroot禁止してないの方が珍しいし、コンソールからもsudoのみならあんまり問題ないと思ってる。
ところでこのrootを変更するにはどこいじる必要あるんだろう?
もしかして/etc/passwd(shadow)を書き換えればOK?
# いますぐ試すのは怖いな
Re: (スコア:0)
rootをadministratorに書き換えて遊んだ事があるけれど
どこにハードコードされた地雷があっても泣かない覚悟があるならやってみたらいいよ
Re:脆弱なユーザ名も止めたらどうか (スコア:1)
これはハードコードされた地雷にやられたことがあったって意味?
それともそれが怖いので止めたって意味?
前者ならぜひ実例を聞いてみたいですね。
Re: (スコア:0)
自分で開発したプログラム以外で、どんなとこに地雷があったか教えてくれると参考になるんだけどなあ。
せめて、「ほんのちょっと」だったのか「意外にあった」のかだけでも。
# toor だと文字数同じで大文字含まれていないから安全度高いかな
Re:脆弱なユーザ名も止めたらどうか (スコア:1)
C限定だが、ググってみた [google.co.jp]
比較的最近のNetBSDのsuと思われるもの [nict.go.jp]もヒットしました。
ヒットした行だけを読む限り、suするとき、いちいちsu super_user_nameと入力しないといけなくなるっぽいです。(一切使えなくなるわけじゃないっぽいのが救い)
1を聞いて0を知れ!
Re: (スコア:0)
一般のプログラムでは、名前(root)でなく、uid 番号で判定しているモノがほとんどだったような。
by Linux on busybox
Re:脆弱なユーザ名も止めたらどうか (スコア:1)
貧弱なユーザーと呼ばれないために
漫画雑誌の怪しげな通販グッズを買うんですね
．．．．．．．．古！
------------
惑星ケイロンまであと何マイル？
Re: (スコア:0)
インストール時にパスワードを聞かれますが
その際スーパーユーザの名前も聞くようにすればいいんですかね
Re: (スコア:0)
Re:変えれるものなら変えたい (スコア:1)
あるある。
ユーザー名とパスワードの組み合わせで強度を確保するのに、何で固定ユーザー名だけを押し付けるのかと。
怠慢以外の何者でもないよね。
出先のルータがそういうやつで、しかもWAN側から設定画面に入れるようになってた。
そこのなんちゃって管理者が休みの日でも自宅からメンテできるようにしてたらしい。
ルータの型番でぐぐると、たまに設定画面がでてきたりもするこんな世の中じゃ(ry
複雑なパスワードを複数覚えられないorz (スコア:0)
Re: (スコア:0)
貧弱なウィルス対策ソフト？ (スコア:0)
タイトルの貧弱なウィルス対策ソフト(本家：Poor Antivirus)って何だろう？重くてPCに異常おこして肝心のウィルスは見逃し三振するようなヤツかしら？と思ってリンク先を読んでみたら...
「定義ファイルを更新してない」「更新期限切れで放置」「ウィルス対策ソフトを入れてない」のことでした。「Antivirus softwareそのもの」が貧弱なんじゃなくて、「Antivirus行為全般」とか「Antivirus softwareの使い方」がなんですね。
そしてそんなのが1/3以上居るよ。怖いだろう？でももっと怖いのはパスワードが...と続く。
「ウィルス対策がなってないのも問題だが、破られやすいパスワードはもっと深刻な問題である。」
という論調でしたとさ。
Re:直接的なパスワードを使わない認証方式に (スコア:1)
他人がそのカードを入手しても正答率が上がらないようにする仕組みが必要ですが
そこが一番肝心な部分じゃないですか…
それを実現できなかったら、デバイス云々は単に複雑なだけで安全性を確保しているとはいえません。
うじゃうじゃ
Re:直接的なパスワードを使わない認証方式に (スコア:1)
Re:日本語でおｋ (スコア:1)
内容を要約すると、暗黒卿っぽい格好のメガネの人がエレベータのドアに挟まるという内容でした。
ドウシテオレハ、ココニイルンダ！