パスワードを忘れた? アカウント作成
13574185 story
暗号

T-Mobile Austria、ユーザーのパスワードを平文で保存しているとツイートして騒動に 28

ストーリー by hylom
漏れたときの被害は大きいですよ 部門より
headless曰く、

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)が別途ツイートしている。また、セキュリティ基準について真剣に議論し、必要があればさらに保護を強めていくとも述べている。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • こんなサポート要員がTwitterで情報発信しているなんて…。
    顧客情報を簡単に漏らしそう。

  • by Anonymous Coward on 2018年04月12日 16時23分 (#3392378)

    「退職したエンジニアが顧客のパスワードを復号できないと嘘をついて困っている、どうしたら懲らしめられるか」みたいなスレ。
    住民総出で「それはハッシュだ、ハッシュは復号しなくてよい、顧客が忘れたなら案内ではなく再設定させろ」と説得して、納得しないながら事なきを得ていたと思う。

  • by Anonymous Coward on 2018年04月12日 16時30分 (#3392380)

    暗号化とハッシュ化で混乱が起こっている。
    それに伴い「平文で保存」「復元可能な(暗号化した)保存」「復元不可能な(ハッシュ化した)保存」で混乱が起こっているように見える。
    いくらなんでも平文保存はない。
    パスワードはハッシュ化が基本だが、暗号化しているシステムも設計次第でなくはないだろう。

    • by Anonymous Coward on 2018年04月12日 16時55分 (#3392400)

      国内の ISP だって、今でもメールサーバの認証に APOP や CRAM-MD5 とか提供してれば
      一方向ハッシュということはない。これらは平文が必要だから。

      親コメント
      • by Anonymous Coward

        CRAM-MD5 は違うんじゃ?

        • by Anonymous Coward

          Challenge と生パスワードを元に Response を決めて、その Response を互いに生成してbit比較する形式の認証方法ならサーバ側に生パスワードが必須。

          CRAM-MD5 も生パスワードが必須。

    • HTTPのダイジェスト認証とかだと、確かにパスワードはハッシュ化されてサーバ上に保存される。
      でもこのハッシュが漏れたらパスワードが漏れたのと同じ危険性があるんだよなぁ。
      (Basic認証の場合はハッシュが漏れても即危険なわけじゃない)

      --
      # mishimaは本田透先生を熱烈に応援しています
      親コメント
    • by Anonymous Coward

      漏れない前提で平文保存するのは場合によっては問題ないんだよね

      • by hatenage (45165) on 2018年04月16日 15時11分 (#3394028)

        ぼくもそう思う

        DB漏れた時点で大問題だし絶対無い運用するのだから

        平文のがサポートとかしやすいならそれもありかなと

        大騒ぎするような事ではないような。

        親コメント
      • by Anonymous Coward

        正直Webサービスのパスワードだけそんな必死に守ってもらわなくてもいいんだよな。
        金銭的損失は補償されるケースもあるし諦めもつく。個人情報が一番根深い被害になる。

    • by Anonymous Coward

      復号可能だったらいくら暗号化してても無意味でしょ。パスワードの中には123456みたいなのが必ずあるんだから、パスワードが漏れた時点で1方向じゃない秘密鍵は漏れたも同然。

      • by Anonymous Coward

        鍵が固定だといつから勘違いしていた?

      • by Anonymous Coward

        Windowsとか、ハッシュ化した上に暗号化までして保存してるぞ。しかも暗号化の鍵は同じフォルダに置いてあるんだぞ、不思議だろう?

      • by Anonymous Coward

        平文と暗号文のペアから鍵を推測する攻撃に対しては、現代的なまともな暗号なら耐性を持ってるから大丈夫だよ。
        さらに普通はパスワードをそのまま暗号化するのではなく、ランダムシード+パスワードを暗号化するようになっている。
        (これはハッシュ化するときも同じ)
        だからたまたま同じパスワードを使っている人がいても、暗号化(あるいはハッシュ化)した結果は異なる。
        「こいつら同じパスワード使ってるから多分単純なパスワードなんだろうな」みたいな推測もできない。

      • by Anonymous Coward

        ・パスワード自身で暗号化する(ハッシュの衝突による誤ったログインを生じさせない)
        この場合は特に問題はない。
        ただしレインボーテーブル他の対策のためソルトは必要。

        ・パスワードの入ったデータベースと異なる場所にキーが有る(プログラム側にハードコード等)
        これは平文保存よりはマシ、と言った類の物で、データベースが何らかの方法で盗まれても、
        別途キーを盗まれない限りはパスワードの漏洩が発生しない。ソルトはあったほうが良い。
        オペレーターがパスワードを復元できる必要がある場合の次善の策といった所。
        安全を期すなら、通常のシステム内にはハッシュ化したものを保管して、
        復元用の暗号化済みパスワードはネットワークから完全に一方向に分断されたシステム内に保存するべき。
        フォトカプラとかで物理的に単方向の信号線以外オフラインなサーバ兼端末にデータ突っ込むとか良さげ。

        • by nim (10479) on 2018年04月13日 10時31分 (#3392739)

          > ・パスワード自身で暗号化する(ハッシュの衝突による誤ったログインを生じさせない)

          これはない。
          ハッシュ衝突よりもブルートフォースの1回めが偶然パスワードにドンピシャあたるほうがまだ確率が高い。

          親コメント
    • by Anonymous Coward

      > 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文字を保存しているのだとしたら、
      普通はその旨の説明を付け足すはず。

      • by Anonymous Coward

        ハッシュ化はしてないだろうが、暗号化は(多分)しているだろう。
        平文で保存とは違うんじゃないかな。
        >「データベースは暗号化して安全に保存されており、データ侵害はない」
        というのは、そういうことだと思うよ。

  • by Anonymous Coward on 2018年04月12日 20時06分 (#3392523)

    CHAPではサーバー側に平文(に復元可能な)パスワードが必要なのは常識だと何度言ったら。ログインに必要なのでパスワードを保存しているというのは完璧に事実だ。むしろ他国のT-Mobileはどうやってログインしてるんだよ。CHAPが使えないなら通信路を平文でパスワードが通ることになるわけだがそっちのほうがいいのか? CHAPが使えるなら他国の公式アカウントは無知か嘘つきか、「パスワード」に対して「ハッシュ化して安全に保存されています」と応答するだけの人工無脳ってことだ。

    今のバカ発見器上なら、「どこそこのホスティング業者はSSL証明書の秘密鍵をパスフレーズ無しで保存している!」でも火をつけられそうだな。

    • by Anonymous Coward

      TLS/SSL してれば通信路を平文パスワードが通ることにはならないと思うのだが。
      T-Mobile って TLS/SSL 使えない環境なの?

      • by Anonymous Coward

        おめーさてはCHAPわかってねーな
        というのはさておいたとしても、だれも通信路の話はしてない。

    • by Anonymous Coward

      仮に SSL 証明書の秘密鍵にパスフレーズを設定していたら、
      Web サーバ起動のたびにパスフレーズ入れなければなりませんからな。

      もっとも、そんなん自動化すればいいよね。
      さて、Web サーバ起動バッチが読む秘密鍵のパスフレーズはどこに保存しておこうかな?

  • by Anonymous Coward on 2018年04月13日 12時46分 (#3392791)

    まだcryptエンコードすら実装方法が分からんって理由で採用しなくても許された20年くらい前に書かれた
    システムを改修しながら使い続けてる場合、「ユーザ認証」みたいなコアな部分に手を付けるには
    リスクが大きすぎて何もできないという状態でね・・・ソース見てもわけわからんって事情も手伝って。

    # 200万アカウントを誇る某Webサービスで開発やってたけどそんなザマ。中途入社なので言葉を失った。

    • by Anonymous Coward

      そういう目線ってことは、今後はあなたが旗振ってそのコードの正常化を進めていくんですよね。

      大変だ。

    • by Anonymous Coward

      そうなんですよ。こういうのってみんな、自分も加担してるくせに偉そうに絶句するんですよね。

      • by Anonymous Coward

        そりゃぁ修正しても誰も評価してくれないし失敗したら叩かれるし、メンバーには煙たがられるだけだからな。
        サラリーマンの処世術としては見なかったことにするのが最適解だよ。

typodupeerror

開いた括弧は必ず閉じる -- あるプログラマー

読み込み中...