75 % の人が SNS とメールのパスワードを同一にしている 54
ストーリー by reo
まままままさかそそそそんな 部門より
まままままさかそそそそんな 部門より
ある Anonymous Coward 曰く、
インターネットセキュリティ企業 BitDefender の調査によると、75 % の人が SNS とメールのパスワードを同じにしているとのこと (SecurityWeek の記事、本家 /. 記事より) 。
BitDefender が 1 週間に渡り調査したところ、SNS サイトで使用されている合計 250,000 ユーザのユーザネームやメールアドレス、そしてパスワードを入手できたとのこと。データはブログやトレント、オンラインコラボレーションサービスやその他のソースから入手したという。
これらのデータを分析したところ、SNS のアカウント用のパスワードとメールのパスワードを同一にしているユーザは 75 % にも上るということが明らかになったとのことだ。なお、入手されたユーザデータの漏洩元は、43 % がオンラインのコラボレーションツール、21 % がブログエントリ、ソーシャルハブが 18 %、トレントが 10 % であったとのことだ。
どうやってパスワードを収集したんだろう (スコア:3, 興味深い)
Re:どうやってパスワードを収集したんだろう (スコア:1)
ブラウザが上手いこと隠蔽して、相手には平文パスワードが渡らないようにしてくれる規格とか出来たら嬉しいんだけど。 例えば、こんな感じに。
ブラウザに「漏洩防止パスフレーズ」を設定できるようにしておく。 ブラウザは、typeがpasswordなinputに対しては、submitをするときに送る内容を【『「ユーザがテキストボックスに入力した文字列」+「漏洩防止パスフレーズ」+「送り先ホスト名」』のハッシュ】に自動的に書き換えて送信。
・・・FireFoxのプラグインにあるよ、とか言われそうな気がするな。
Re:どうやってパスワードを収集したんだろう (スコア:1)
SNS流行ったときにVIP専用とか乱立していて考えたのは
まさにそれなんですよね。
E-MAILとパスワードがログインに使用されていて
メールアドレスとパスワードの(入力ミスも含めて)リストがあれば・・・と。
Re:どうやってパスワードを収集したんだろう (スコア:1)
その方式だと受け取り手に元の文字列をデコードできる仕組みが無いとダメでは？
プラグイン単独では実装できないので利用範囲がOpenIDとさして変わらない気がします。
デフォルトでつかえるマスターパスワード機能ではダメですか?
初回、充てられたパスでログインしてランダムな文字列のパスに変更。
その文字列をブラウザに記憶させ、以後はマスターパスワードで一元管理。
＃つい先日、自分にとって意味のある文字列とソルトをcryptに食わせる
＃perlスクリプトを書いてSNS等のパスワードを統一したので、
＃この話題はある意味タイムリー。
Youthの半分はバファリンでできています。
Re:どうやってパスワードを収集したんだろう (スコア:1)
で、書き方が曖昧でした。最初から、暗号化された文字列をパスワードとしてユーザアカウント作っておいたら良いんじゃないか? という発想です。 受け取り手がデコード出来ない、他のことに流用できない、という所を徹底したいので。 要するに、「サイト毎にパスワードを変える」と言うところを手動で頑張るとどうやっても間違うので、ブラウザに自動でやらせようというだけですね。
例えば、A社サイト用のパスワードを「AAA」、B社サイト用のパスワードを「BBB」にしよう、と考えたとします。 このまま、AAA、BBBで登録すると、A社のサイトで「BBB」と入力する間違いを犯した際に、A社サイトの管理者に悪い奴が居たら「ああこいつ、どっかのサイトでBBBってパスワード使ってるんだな」とバレます。「同じメアドで登録してないか、有名サイトを順番に見ていこう」とかやられると、せっかく別々のパスワードを使ってるのが台無しになります。
そこで適当なハッシュ関数を使ってそれぞれのパスワードをhash(AAA)、hash(BBB)としておけば、入力ミスしても少なくとも平文の「BBB」はバレずに済みます。ただ、これだけだと、「サイト毎に違うパスワードを使ってる」のとなんら違いがないので、もう一工夫必要です。 パスワードを、hash(A社ホスト名 + AAA)、hash(B社ホスト名 + BBB)としてユーザ登録します。 そして、「x社ホスト名」を追加するのがユーザの手作業だと結局、同じミスに対して同じダメージになるので、ここをブラウザに任せて自動化します。 すると、パスワードを入れ間違えても、A社には「hash(A社のホスト名 + BBB)」という何の意味もない文字列が送られるだけになるので、 A社に悪い奴が居ても全くダメージは受けません。
ついでに、元コメに書いた、「漏洩防止パスフレーズ」は見直してみると意味ないですね。何となく無いとセキュアにならなさそうな気がしたんですが・・・どう考えて導入したか思い出せませんorz
Re: (スコア:0)
残念ながらスクリプトは公開されていませんが、ちょっとした bookmarklet でもできるみたいですよ。
Re: (スコア:0)
生体認証 (スコア:2)
個別にパスを変えて覚えておくのは厳しいでしょう。
それこそデスクトップに付箋紙でパスを貼り付ける事態が増えそう。
やっぱり生体認証あたりに移行したほうがいいんじゃなかろうか。
Re: (スコア:0)
Windowsオンリーとか追加ハードウェア必要とかが解消されていかない限り無理かも...
# まず iPhone5 あたりに載れば解消かもだけど
まあ意味のとれない難読パスとかだと、さすがに数十のパスを記憶している私でも覚えるの大変。生体認証ありかもなぁとは思うけれど。
Re: (スコア:0)
・生体認証だと一個しかないからもっとやばいんじゃ。
・生体認証は使えなくなることがあるので、常に代替手段が必要。たとえばパスワードとか。
普通にそういうパスワードを管理するソフトか何かを使えば良いだけだと思う。
Re: (スコア:0)
驚くような話ではない (スコア:1)
前世紀から足掛け苦節ン十年、啓蒙の甲斐あってようやく
「idとパスワードは違う文字列にしとけ」
という警告が受け入れられつつある所なのです。
複数のサービスでパスワードの使いまわしがあったとしても、
何を驚く事がありましょうか。
// パスワードのサービス毎の切り替えが浸透したら、
// 今度は類推しやすいパスワードの排除が待っています
// http://srad.jp/security/article.pl?sid=10/01/26/118234 [srad.jp]
// セキュリティ：漏えいした3200万のパスワードを米企業が分析、
// 最も使われていたのは「123456」
//// 俺たちはまだ登り始めたばかりだからな
//// この果てしの無いセキュリティ坂をよ！！！ 未完？
Re:驚くような話ではない (スコア:1)
------------
惑星ケイロンまであと何マイル？
Re:驚くような話ではない (スコア:1)
ニュースサイトのIDなんかで他のIDが設定できるものについては
ツールで”tj7iz4463ziq3hBzdktT9H0ysn” みたいな感じの文字列を
生成してIDにしてる。
でも本当に変えたい時には 「メアド＝ID」な奴が多いので意味がなかったり。
Re:驚くような話ではない (スコア:1)
同意。
一体何％の人が銀行口座およびクレジットカードの暗証番号を会社ごとに管理してるんでしょうか？
その数字と比較しないと多いかどうか判断ができません。
Youthの半分はバファリンでできています。
サイト管理者の自己防衛の側面 (スコア:2, 興味深い)
別件ですがここにぶら下げます。
細々とゲームサイトを運営してますが、
登録にメールアドレスを必須にしているスクリプトの場合、
パスワードをcryptしてから保存し、その旨を通知してパスワードの問い合わせには応じていません。
SNS等のパスワードに統一している可能性を考慮すると、何かあったときに変な嫌疑が掛かるのは嫌ですからね。
とはいえ、生パスワードは受け取っていますので保存をすることは原理的に可能であり、
クローズドソースで運営する以上釈明として不十分であるという認識でいますがね。
生パスワードを受け取らずにログインを実装するにはOpenID対応ぐらいしか思いつきません。
目下サーバー移転作業中なので移転が完了したら勉強しようかと。
Youthの半分はバファリンでできています。
Re:サイト管理者の自己防衛の側面 (スコア:1)
> 生パスワードを受け取らずにログインを実装するにはOpenID対応ぐらいしか思いつきません。
JavaScript必須でよければ、クライアント側で暗号化して送信すればいいんじゃないかな。
APOPみたいな古典的チャレンジレスポンスだとサーバ側に生パスワードが必要ですが、
HTTPのダイジェスト認証みたいに、二重にハッシュ処理すれば、生パスワードは保管不要です。
JavaScriptのMD5ライブラリとかも世に出回っているので、結構簡単に実現できます。
Re:サイト管理者の自己防衛の側面 (スコア:1)
ありがとうございます。
以下の部分がよく分かってないので的外れなことを言っているかもしれませんが。
あらかじめ.jsにcryptさせたものをperlで受けとって処理するには、
.jsとperlの双方の暗号化において同じソルトを使用する必要があると思います。
当時は「javascriptデフォルトでオフにせよ」がWebの主流になると思っていたので
「ソルトになる文字列が固有で、.jsのソースに残るようでは甘い」と考え、
javascript必須をユーザーに要求するほどの実装ではないと思いました。
なんかうまい方法で解決できるもんですかね?
Youthの半分はバファリンでできています。
Re:サイト管理者の自己防衛の側面 (スコア:1)
当時考えたことを思い出しながらそのまま書いたんですけど、なんか変ですね。
初回生成時に.jsに作らせた暗号化文字列を受け取る何らかの機構が用意できれば
perl側にcryptは必要なく、ソルトもランダム値をとり得ますね。
仮登録結果の表示ページからpostさせるとか？
あれ？自己解決?してる？
Youthの半分はバファリンでできています。
Re:サイト管理者の自己防衛の側面 (スコア:1)
チャレンジ・レスポンス認証では、昔ながらのcryptにおける「ソルト」に相当するものはありません。
以下、digest認証のおおざっぱな説明です。
HTTPのdigest認証では、
サーバ側では、「文字列1(realm)+パスワード」をハッシュ化した文字列を保存しています。
この文字列1は、ランダムではなく、サイト固有の文字列にします。
そうすることで、サーバが保管している『「文字列1+パスワード」のハッシュ』は
他のサイトに流用することはない、ということを保証できます。
認証時には、サーバからはクライアントにこの「文字列1(realm)」と、認証ごとにランダムに生成する「文字列2(nounce)」を送ります。
クライアント側でも、ランダムに「文字列3(cnounce)」を生成し、受け取った文字列1と入力されたパスワードから
「文字列1+パスワード」のハッシュを計算し、さらに文字列2と文字列3から
『「文字列1+パスワード」のハッシュ+文字列2+文字列3』のハッシュを計算し、
このハッシュを文字列3と共にサーバに送ります。
サーバ側では、受け取った文字列3と自身が持っている情報から
『「文字列1+パスワード」のハッシュ+文字列2+文字列3』のハッシュを計算し、
クライアントから送られてきたハッシュ文字列と比較して認証します。
このように、通常の認証過程では、
生パスワードやパスワードから一意に定まるような文字列は、まったく流れませんし、
サーバ側でも生パスワードの保存は不要になります。
また、クライアント側で「固定のソルト」のようなマジックナンバーは不要です。
オフトピ）Re:サイト管理者の自己防衛の側面 (スコア:1)
度々丁寧なレス、ありがとうございます。
digest認証のに関する無知の件はおかげさまで解消致しました。
ユーザーがパスワードを任意のものに変更することを許容する場合はどうなりますでしょう？
ユーザーからみてrealmが秘匿されている前提で、希望のパスワードに対して同様の認証を実現する方法が思い当たりません。
Ajaxの隆盛の産物でそういうことを想定したライブラリが既にあるんじゃないかと思って検索をしてみましたが見つからず。
＃いい検索ワードが思い当たらないせいだと思いますが。
連結の順番を入れ替えて
『「realm+パスワード」のハッシュ+cnounce+nounce』のハッシュと
『realm+「パスワード+cnounce」のハッシュ+nounce』のハッシュが
等価になるようなハッシュ関数が存在する、なんてことはまずなさそうだし・・・。
もしかしたらすごいバカなことを聞いているんでしょうか？
Youthの半分はバファリンでできています。
Re:オフトピ）Re:サイト管理者の自己防衛の側面 (スコア:1)
ん？ん？
固有のrealmを諦めて、ハッシュとペアで保存するようにし、
変更時はクライアント側でランダムなrealmを生成し、realmとハッシュのペアを受け取ればいいんですかね？
ちょっと眠くて検証する脳力が・・・。
書き置きだけして明日考えます・・・。
Youthの半分はバファリンでできています。
Re:サイト管理者の自己防衛の側面 (スコア:1)
遅くなりまして申し訳ありません。
＃待っていただいていたかどうかは別として
暗号に関する技術資料やらWikipediaやらを読み漁って大いに脱線をしておりました。
結論から申し上げると、私が実装したい「生パスワードは一切受け取っていませんよ」と客観的に主張できるライブラリは見当たりませんでした。
既存のライブラリの応用から上記のライブラリを作ることは（taka2さんに頂いたヒントを元にすれば）それほど難しくないだろうとは思いましたが、
・javascript必須を回避しうる
・ログインスキームの一元化（OpenID採用サイトとの統一）
・ユーザーに対する説得の手間
などの点でやはり素直にOpenIDのAPIを勉強して採用することのほうがコストが低いであろうとの結論に達しました。
謝意が伝わるように、taka2さんのコメントへのレストして投稿させていただきます。ありがとうございました。
なお、このオフトピ気味のツリーでも何かの役に立つかもしれませんので関連リンクを以下にまとめます。
javascriptによるmd５の実装ライブラリ
1.世界標準? http://pajhome.org.uk/crypt/md5/ [pajhome.org.uk]
2.日本人による実装では最速らしい http://labs.cybozu.co.jp/blog/mitsunari/2007/07/md5js_1.html [cybozu.co.jp]
成果物はsourceforge.jpにいくつか見つかりました。
1. http://osdn.jp/projects/freshmeat_perl-md5-login/ [osdn.jp]
上記の1.を含んだajaxライブラリ
2. http://osdn.jp/projects/sfnet_clean-ajax/ [osdn.jp]
perlスクリプトが出力するHTMLの中に上記の1.を含んでいます。
ソースを読む限りではユーザ側で任意のパスワードに変更する例は直接示されておらず、パスワードの生成はサーバー側で行うことのみを想定しているようです。
Youthの半分はバファリンでできています。
＞部門名 (スコア:1)
ぶっちゃけこんなのインターネットが民間に浸透し始めたころからずっと変わってませんよね？
ネットリテラシーの低さに注目するにしても正直なところ今更だと思いますし。
#なにかのネタなのかな。もしそうだったら野暮天な書き込みとしてマイナスモデお願いします。
Re:＞部門名 (スコア:2)
同じパスワードを使うという結果に、
「ほらネットリテラシ－低いダメ－。全アカウント違うパスワードを脳内記憶以外認めませんよ。」
って言うからいつまでも改善されないということがわからんの？
Re: (スコア:0)
で、いったいどうしろと?
不正アクセス禁止法を廃止してパスワードが盗まれたことによる不利益はすべて自己責任の弱肉強食な世の中にするとか?
Re: (スコア:0)
>なんでそんなに驚いているのか
まさしく自分がそうだから、ってネタじゃね？
Re: (スコア:0)
メールアカウントも危険になりますが、この危険がそれほど認識されてないということに対する驚きではないでしょうか
Re: (スコア:0)
POPメールのパスワードは平文で送られるから、
途中でパケットをキャプチャすれば誰にでも見られる。
紙にメモして鍵のない引き出しに入れてるようなもの。
そんなものを他のサービスで使うなんて・・・てことでは？
みんな (スコア:1, おもしろおかしい)
はい、は～い (スコア:0)
勘違い (スコア:1, おもしろおかしい)
もはや人間の限界っ！ (スコア:0)
プライベートでのメールアカウントで６つ。
通販その他のWebサービスも入れれば、常用しているアカウントだけでも２０や３０は軽くある。
たまにしか使わないアカウントなんて、登録時にどのメールアドレスを使ってたかさえ記憶が怪しいのに。
メモするな、ＰＣに保存するな、類推されそうな文字列は使うな・・・・って。
無理だってば。
Re: (スコア:0)
Re:もはや人間の限界っ！ (スコア:1)
そしてクライアントが変わる頃には完全に忘れていると
Re: (スコア:0)
２．忘れても復旧手段が用意されている
３．あきらめても問題ない／別アカウントを取る
大事なパスワードは携帯の中に紛れ込ませてます。
携帯より大事なパスワードは暗記してます。
忘れたくないパスワードはメモしてます。
ここのパスワードもメールアドレス変るまでには復旧しときます。
Re: (スコア:0)
全部やろうと思うから人間の限界が来るのであって、
セキュリティリスクにもランクがあるのでどこか緩めればいいんですよ。
例えばですけど、家なら家のノートにメモっておけばいい。会社なら印章入れと同じ引き出しに入れて鍵をかけておけばいいんです。
これでパスワード類推やネット流出よりは強くて物理的侵入には弱いレベルのセキュリティになります。
下手に忘れてしまうよりも強いですよ。
物理的侵入されるのが嫌ならPCのパスワード管理ツールを使うとか、指紋認証付きUSBメモリに入れて持ち運ぶとかですね。やり方はいくらでも。
Re: (スコア:0)
その2は「自分のアカウント全てに同一のパスワードを使用している人が20%居る」という記事だけど、感覚としてもっと高いんじゃないかという気がしていたのでこのストーリーの元記事には納得。
全部同一なのが20%で、何種類か使っているけどSNSとメールが同じなのが75%、と言うことかもしれないけど。
個人的には紙と1Passwordを使用中。
なんか技術革新を (スコア:0)
こうあちこちに暗証番号やパスワードが必要になると
全部違うものなんか管理できなくて無理です。
ここまでくると、RFID を身体に埋め込んで「ピッ」で
終わるならそれの方がいいと思ってしまう。
# 献血も手帳からカードになって暗証番号毎回求められます。
# 免許証は来年の更新で電子化です。
# パスポートはパスワードあったけ？ 市役所の印鑑証明カードは？
# PHS は契約の暗証番号と端末の暗証番号が・・・。
Re: (スコア:0)
Facebookとかいろんなのに対応してるけど、日本のあれやこれやはそういうのまだまだない。
Webサーバとブラウザに何か標準で載せないといかんのじゃないか。
Re: (スコア:0)
むしろ危険。RFIDの番号をスキミングされてリプレイ攻撃されるだけ。
Re: (スコア:0)
オレ、キャッシュカードとクレカで10枚、さらにモバイルバンキングも、携帯の機器暗証とネット暗証も、全て違う番号。
ついでにPOPメール9個とWEBメール15個くらい、全部別のパスだけど、意外と忘れないもんだよ。
#数えてちょっと驚いた。何でこんなにあるんだｗ
じゃあ、何個くらいのパスワードを使い分けてるの？ (スコア:0)
Re:じゃあ、何個くらいのパスワードを使い分けてるの？ (スコア:1)
事実上使っているのは 5 つで、使い回しは極めて多いです。使い回し不可なんて幻想だと思っています。
Hiroki (REO) Kashiwazaki
Re:じゃあ、何個くらいのパスワードを使い分けてるの？ (スコア:1)
使い回しになるのかどうかわからないけど、基本文字列の２カ所の数字を変えて登録している。
会社内だと、その数字の前の方を0,1,2,3 、メールだと3,4 、販売系のサイトだと5,6,7とかね。
うしろの数字は、カードなんかに書いておくとね。
暗証番号はどこか１カ所だけ違うってなパターン。
ということで、それなりに変える様にしているのだけど、先日、某所でパスワード変更しようとしたら「前のと似てるからだめ」とか言われてしまった。
Re:じゃあ、何個くらいのパスワードを使い分けてるの？ (スコア:1)
>「前のと似てるからだめ」とか言われてしまった。
前のパスワードを平文で記録しているサイトは、使ってはダメです。
Re:じゃあ、何個くらいのパスワードを使い分けてるの？ (スコア:1)
>前のパスワードを平文で記録しているサイトは、使ってはダメです。
ま、どうでもよいサービスだからね。
ところで、平文で記録していないという確証はどこにあるのかな？
確証ないけど、やってないそうだから、オッケーといった程度かな？
別にいいんじゃね？ (スコア:0)
SNSやメールのパスワードなんて一緒でいいんじゃないの？
っていう現実データを報告しているだけじゃないの？この調査は。
驚くような事じゃないよ。
それよりも漏洩している率が高いってのが驚きポイント、気をつけるポイントじゃないの？
Re: (スコア:0)
Re: (スコア:0)
＞SNSやメールのパスワードなんて一緒でいいんじゃないの？
と思ってる人は多いかも知れないけど、セキュリティ意識低すぎ。
特に最近はパスワードの送り先にE-mail指定することも多いので、
セキュリティ設定を同レベルにするのは間違いだと思う。