T-Mobile Austria、ユーザーのパスワードを平文で保存しているとツイートして騒動に 28
漏れたときの被害は大きいですよ 部門より
T-Mobile Austria（オーストリア）の公式Twitterアカウント（@tmobileat）がユーザーパスワードを平文で保存しているとツイートしたことで、各国の系列会社が次々に「うちは違う」との返信を投稿する事態となった（Neowin）。
発端となったのはDeutsche Telekom（ドイツ）のユーザーパスワードに関する制約を問題視するツイートに対し、T-Mobile Austriaでは従業員がパスワードを確認できることから平文で保存しているらしいとの返信が寄せられたことだ。
この返信を引用する形でツイート主が事実関係をT-Mobile Austriaに確認すると、サービスチームの一人 （Kathe）が「カスタマーサービス担当者はパスワードの最初の4文字を見る（ことができる）。ログインに必要なのでパスワード全体を保存している」といった趣旨の回答をする。さらに、ツイート主や他のユーザーからパスワードの平文保存を問題視する返信に対し、Katheは「何が問題なのか理解できない」「パスワードは安全に保存されているので心配ない」「（同社の）従業員からの警告なのか？」などと返信している。
Katheからの返信はこれで終わっているが、T-Mobile US（米国、@TMobileHelp/@TMobile）やT-Mobile Nederland（オランダ、@tmobile_webcare）、Deutsche Telekom（@Telekom_hilft）の公式アカウントがこの問題を懸念する各国のユーザーに対し、「パスワードは暗号化して（ハッシュ化して）保存しており、従業員が平文のパスワードにアクセスすることはできない」といった内容の返信を繰り返し投稿。@TMobileでは「T-Mobile USはT-Mobile Austriaとは独立して運営されている」とまで投稿している。
T-Mobile Austriaではこの件について、「データベースは暗号化して安全に保存されており、データ侵害はない」とサービスチームの別のメンバー （Helmut）が別途ツイートしている。また、セキュリティ基準について真剣に議論し、必要があればさらに保護を強めていくとも述べている。
従業員教育が足りていない (スコア:3)
こんなサポート要員がTwitterで情報発信しているなんて…。
顧客情報を簡単に漏らしそう。
旧2chにあったな (スコア:0)
「退職したエンジニアが顧客のパスワードを復号できないと嘘をついて困っている、どうしたら懲らしめられるか」みたいなスレ。
住民総出で「それはハッシュだ、ハッシュは復号しなくてよい、顧客が忘れたなら案内ではなく再設定させろ」と説得して、納得しないながら事なきを得ていたと思う。
暗号化とハッシュ化 (スコア:0)
暗号化とハッシュ化で混乱が起こっている。
それに伴い「平文で保存」「復元可能な(暗号化した)保存」「復元不可能な(ハッシュ化した)保存」で混乱が起こっているように見える。
いくらなんでも平文保存はない。
パスワードはハッシュ化が基本だが、暗号化しているシステムも設計次第でなくはないだろう。
Re:暗号化とハッシュ化 (スコア:1)
国内の ISP だって、今でもメールサーバの認証に APOP や CRAM-MD5 とか提供してれば
一方向ハッシュということはない。これらは平文が必要だから。
Re: (スコア:0)
CRAM-MD5 は違うんじゃ？
Re: (スコア:0)
Challenge と生パスワードを元に Response を決めて、その Response を互いに生成してbit比較する形式の認証方法ならサーバ側に生パスワードが必須。
CRAM-MD5 も生パスワードが必須。
Re:暗号化とハッシュ化 (スコア:1)
HTTPのダイジェスト認証とかだと、確かにパスワードはハッシュ化されてサーバ上に保存される。
でもこのハッシュが漏れたらパスワードが漏れたのと同じ危険性があるんだよなぁ。
（Basic認証の場合はハッシュが漏れても即危険なわけじゃない）
# mishimaは本田透先生を熱烈に応援しています
Re:暗号化とハッシュ化 (スコア:1)
HTTP ダイジェスト認証はチャレンジ・レスポンス認証だから、
認証の都度ダイジェストが変更されるので、その危険はないのでは？
Re:暗号化とハッシュ化 (スコア:1)
ごめん意味わかった。
ハッシュ化したパスワードを鍵に使うから、という意味ね。
Re: (スコア:0)
漏れない前提で平文保存するのは場合によっては問題ないんだよね
Re:暗号化とハッシュ化 (スコア:1)
ぼくもそう思う
DB漏れた時点で大問題だし絶対無い運用するのだから
平文のがサポートとかしやすいならそれもありかなと
大騒ぎするような事ではないような。
Re: (スコア:0)
正直Webサービスのパスワードだけそんな必死に守ってもらわなくてもいいんだよな。
金銭的損失は補償されるケースもあるし諦めもつく。個人情報が一番根深い被害になる。
Re: (スコア:0)
復号可能だったらいくら暗号化してても無意味でしょ。パスワードの中には123456みたいなのが必ずあるんだから、パスワードが漏れた時点で1方向じゃない秘密鍵は漏れたも同然。
Re: (スコア:0)
鍵が固定だといつから勘違いしていた？
Re: (スコア:0)
Windowsとか、ハッシュ化した上に暗号化までして保存してるぞ。しかも暗号化の鍵は同じフォルダに置いてあるんだぞ、不思議だろう？
Re: (スコア:0)
平文と暗号文のペアから鍵を推測する攻撃に対しては、現代的なまともな暗号なら耐性を持ってるから大丈夫だよ。
さらに普通はパスワードをそのまま暗号化するのではなく、ランダムシード＋パスワードを暗号化するようになっている。
(これはハッシュ化するときも同じ)
だからたまたま同じパスワードを使っている人がいても、暗号化(あるいはハッシュ化)した結果は異なる。
「こいつら同じパスワード使ってるから多分単純なパスワードなんだろうな」みたいな推測もできない。
Re: (スコア:0)
・パスワード自身で暗号化する(ハッシュの衝突による誤ったログインを生じさせない)
この場合は特に問題はない。
ただしレインボーテーブル他の対策のためソルトは必要。
・パスワードの入ったデータベースと異なる場所にキーが有る(プログラム側にハードコード等)
これは平文保存よりはマシ、と言った類の物で、データベースが何らかの方法で盗まれても、
別途キーを盗まれない限りはパスワードの漏洩が発生しない。ソルトはあったほうが良い。
オペレーターがパスワードを復元できる必要がある場合の次善の策といった所。
安全を期すなら、通常のシステム内にはハッシュ化したものを保管して、
復元用の暗号化済みパスワードはネットワークから完全に一方向に分断されたシステム内に保存するべき。
フォトカプラとかで物理的に単方向の信号線以外オフラインなサーバ兼端末にデータ突っ込むとか良さげ。
Re:暗号化とハッシュ化 (スコア:1)
> ・パスワード自身で暗号化する(ハッシュの衝突による誤ったログインを生じさせない)
これはない。
ハッシュ衝突よりもブルートフォースの1回めが偶然パスワードにドンピシャあたるほうがまだ確率が高い。
Re: (スコア:0)
> Hello Claudia! The customer service agents see the first four characters of your password.
> We store the whole password, because you need it for the login for http://mein.t-mobile.at/ [t-mobile.at] ^andrea
この回答でハッシュ化していると解釈するのは難しい。
ハッシュ化しているなら、最初の4文字も分からないはず。
ハッシュとは別に最初の4文字を保存しているのだとしたら、
普通はその旨の説明を付け足すはず。
Re: (スコア:0)
ハッシュ化はしてないだろうが、暗号化は（多分）しているだろう。
平文で保存とは違うんじゃないかな。
>「データベースは暗号化して安全に保存されており、データ侵害はない」
というのは、そういうことだと思うよ。
何年か前にもスラドで見た覚えがあるぞ (スコア:0)
CHAPではサーバー側に平文(に復元可能な)パスワードが必要なのは常識だと何度言ったら。ログインに必要なのでパスワードを保存しているというのは完璧に事実だ。むしろ他国のT-Mobileはどうやってログインしてるんだよ。CHAPが使えないなら通信路を平文でパスワードが通ることになるわけだがそっちのほうがいいのか? CHAPが使えるなら他国の公式アカウントは無知か嘘つきか、「パスワード」に対して「ハッシュ化して安全に保存されています」と応答するだけの人工無脳ってことだ。
今のバカ発見器上なら、「どこそこのホスティング業者はSSL証明書の秘密鍵をパスフレーズ無しで保存している!」でも火をつけられそうだな。
Re: (スコア:0)
TLS/SSL してれば通信路を平文パスワードが通ることにはならないと思うのだが。
T-Mobile って TLS/SSL 使えない環境なの？
Re: (スコア:0)
おめーさてはCHAPわかってねーな
というのはさておいたとしても、だれも通信路の話はしてない。
Re: (スコア:0)
仮に SSL 証明書の秘密鍵にパスフレーズを設定していたら、
Web サーバ起動のたびにパスフレーズ入れなければなりませんからな。
もっとも、そんなん自動化すればいいよね。
さて、Web サーバ起動バッチが読む秘密鍵のパスフレーズはどこに保存しておこうかな？
意外と多い気がする (スコア:0)
まだcryptエンコードすら実装方法が分からんって理由で採用しなくても許された20年くらい前に書かれた
システムを改修しながら使い続けてる場合、「ユーザ認証」みたいなコアな部分に手を付けるには
リスクが大きすぎて何もできないという状態でね・・・ソース見てもわけわからんって事情も手伝って。
# 200万アカウントを誇る某Webサービスで開発やってたけどそんなザマ。中途入社なので言葉を失った。
Re: (スコア:0)
そういう目線ってことは、今後はあなたが旗振ってそのコードの正常化を進めていくんですよね。
大変だ。
Re: (スコア:0)
そうなんですよ。こういうのってみんな、自分も加担してるくせに偉そうに絶句するんですよね。
Re: (スコア:0)
そりゃぁ修正しても誰も評価してくれないし失敗したら叩かれるし、メンバーには煙たがられるだけだからな。
サラリーマンの処世術としては見なかったことにするのが最適解だよ。