ドコモとソフトバンクに平文パスワード提示機能が存在。セキュリティ上の懸念が指摘される 75
ストーリー by nagazou
指摘 部門より
指摘 部門より
ITmediaの記事によると、携帯通信キャリアの一部が自社のアカウントサービスの利用者に対してパスワードを平文で提示する機能が用意されているとして、記事ではセキュリティ上の懸念を提示している（ITmedia）。
記事によると、この機能はユーザーがログイン画面のパスワードを忘れたときのための機能で、電話番号や契約時に設定した4桁のネットワーク暗証番号などを入力すると、パスワードが掲示されるものとなっている。記事ではこうした事業者側がパスワードを平文保持している状況は、不正アクセスなどで情報漏えいが起きた際のリスクになるとしている。
掲示されるのはドコモ系列がdアカウントはポータル内で、ソフトバンク系列はSMSでの通知となっている。KDDI（au/UQ mobile）と、楽天モバイルの会員サービスに関しては、本人確認の後にパスワードの通知を行う方法ではなく、新規パスワードの設定画面に移行する方式であるとしている。またソフトバンクにおいては、パスワードを暗号化せず平文のまま保管していることも確認できたとしている。
記事によると、この機能はユーザーがログイン画面のパスワードを忘れたときのための機能で、電話番号や契約時に設定した4桁のネットワーク暗証番号などを入力すると、パスワードが掲示されるものとなっている。記事ではこうした事業者側がパスワードを平文保持している状況は、不正アクセスなどで情報漏えいが起きた際のリスクになるとしている。
掲示されるのはドコモ系列がdアカウントはポータル内で、ソフトバンク系列はSMSでの通知となっている。KDDI（au/UQ mobile）と、楽天モバイルの会員サービスに関しては、本人確認の後にパスワードの通知を行う方法ではなく、新規パスワードの設定画面に移行する方式であるとしている。またソフトバンクにおいては、パスワードを暗号化せず平文のまま保管していることも確認できたとしている。
ハッシュなのか暗号化なのか区別して (スコア:2)
不可逆なハッシュだけ保持しているのを暗号化と（間違って）呼んでいるのか、鍵があれば管理者が復号できる可逆な暗号化なのか。
記事にするなら区別して確認してほしいところ。
Re:ハッシュなのか暗号化なのか区別して (スコア:1)
Re: (スコア:0)
え～と
「利用者に対してパスワードを平文で提示する機能が用意されている」
こう書かれているのだからわからないか？
Re: (スコア:0, おもしろおかしい)
スラドは初めてかな？
ここは技術者気取りの素人がソースを一切読まずに自分の思い込みを上から目線で叩きつけ合うサイトだよ。
Re: (スコア:0)
パスワードを平文で提示する機能って書いてる記事に対して
ハッシュなのか暗号化なのか区別できない読者は
相手にしなくてもいいのでは？
Re: (スコア:0)
なぜ区別していないと思うのか？
本文では
ソフトバンクにおいては、パスワードを暗号化せず平文のまま保管していることも確認できた
ぐらいしか暗号化の話はないし、ITmediaに関しては「ハッシュ化すべき、暗号化はハッシュ化に比べて弱い」とまで述べているのに。
Re: (スコア:0)
リンク先にハッシュ化しろと書いてます。
Re: (スコア:0)
ハッシュって、熟語でなんていえばいいの?
ちなみに、中文では、雜湊とか、散列とかいうらしい(暗号学的なのじゃないハッシュも同様)。
Re: (スコア:0)
ハッシュという言葉自体なら一方向性関数
ハッシュ化した文字列を指す言葉はないかも
Re: (スコア:1)
暗号に限らない計算機科学用語なら、要約 [wikipedia.org]ですかね。
ハッシュ関数=要約関数
ハッシュ値=要約値
完全ハッシュ関数みたいに逆変換可能なものもありますので、ハッシュ関数=一方向性関数とは限りませんが、
認証処理での利用に限定するなら、ハッシュかどうかより「一方向性関数」であることの方が重要ですね。
パスワードを平文で送ってくるっぽいサイトまとめ (スコア:1)
10年以上前からずーっと言われ続けてたから今更感凄い。
そういや「パスワードを平文で送ってくるっぽいサイトまとめ」なんてサイトもあったなと思い出したけど、今は403で繋がらなくなってた。
https://web.archive.org/web/20200314012817/https://cleartext.azurewebs... [archive.org]
アーカイブ見てみたらやっぱりdocomo IDとMy SoftBankも載ってる。2015年当時に登録された古い情報も多いとは思うけど、今はどのくらい減ったのかね？
関連リンク：
生パスワードを平文メールで送ってくる企業 | スラド セキュリティ
https://security.srad.jp/story/10/11/10/0055217/ [security.srad.jp]
ユーザーパスワードではないところで (スコア:0)
API連携の認証トークン的なものって、暗号化してます？
UIから発行するときに今しかみれないからね!!ってしてるのと、あとからいつでもみれるのといろいろな気がして
Re: (スコア:0)
API連携の認証トークン的なものって、暗号化してます？
メールに記載したURLトークンはhttpsですので大丈夫
って回答になったりして
# そこじゃねー
Re:ユーザーパスワードではないところで (スコア:2)
OAuth2.0で広く利用されている JWT 形式のトークンは、
ペイロード自体は暗号化されていません。
ペイロードに有効期限が入っており、ペイロード全体への署名が付加されています。
暗号化することもできますが、あまり実装は見たことがないです。
これと同様に、トークンはAPI利用のためのチケットであって、それ自体に秘匿すべき情報は（通常は）含まれていないなら、暗号化していなくてもちゃんと署名がされていれば安全ではないでしょうか。
（実物を見ていないのでどんな感じかわからず、一般論ですみません）
キーチェイン。 (スコア:0)
あのへんのサービスは、ネットワーク暗証番号をマスタパスワードとみなしてるから、管理画面のパスワードは副キーなんだよねきっと。
どちらかといえば、「いまからパスワードを生成してお見せします。書き写してください。弊社では(ハッシュしか)保存しません」のほうがいいかも。
Re: (スコア:0)
パスワードだけで色々できるよ。ネットワーク暗証番号はドコモ回線持ってる人しか使えないから、IDをキャリアフリーにして開放したときにその前提は崩れた。
この報道が出る少し前に、ドコモ回線経由でないと一部の手続きができないように改修したみたいだけど。
Re: (スコア:0)
ドコモ口座はまさにその考え(ネットワークで認証されるから多少適当でもかまわないよね)でやらかしたわけだが
Re: (スコア:0)
「いまからパスワードを生成してお見せします。書き写してください。弊社では(ハッシュしか)保存しません」のほうがいいかも。
スマホに付箋で貼っておけばいいのですね！(オイマテ
Re: (スコア:0)
Re:キーチェイン。 (スコア:2)
電池カバーの裏に書いとこうφ(..)
セキュリティ原則を知らない現場と経営の悪魔合体だな (スコア:0)
平文で保存しておいて表示なんてせずに、単に身元確認の上で再発行するものだけど。
顧客に手間のかかる手段は提供できないとかそんな理由で妥協案を採用したんだろうな。
スラドでもリスクと天秤でノーガードもありとか言う人は絶えないし、いつになったらセキュリティ意識が浸透するのやら…
Re:セキュリティ原則を知らない現場と経営の悪魔合体だな (スコア:1)
>いつになったらセキュリティ意識が浸透するのやら…
その考えが間違ってるんですよ。
目的はお金を稼ぐことで、セキュリティを高めることではないのです。
営利企業であれば
平文パスワードを表示することで節約できるコスト（＝金額） ＞ 平文パスワードを表示することで発生するコスト（被害の弁済額など）
なら平文パスワードを表示した方が「得」なのです。
営利企業においてセキュリティを高めるのは手段でしかありません。手段にこだわるのはエンジニアの仕事ですが
エンジニアに仕事を指示するのは経営者です。
経営者からすれば「セキュリティ意識？なにそれw？で、いくら収益が増えるの？」って感じでしょう。
経営者は現場を知らない、とでも言いたいのでしょうが、その「現場」は経営者が用意したたくさんある「現場」の一つに過ぎません。細かい話はどうでもいいんですよ。
Re:セキュリティ原則を知らない現場と経営の悪魔合体だな (スコア:2)
社会からするとそれでは都合悪いので、一定のセキュリティ基準を義務付けたり違反者に罰則を与えたりするする方向になるんでしょうね。
ドコモ口座 (スコア:0)
ドコモ口座は
平文パスワードを表示することで節約できるコスト（＝金額） ＞ 平文パスワードを表示することで発生するコスト（被害の弁済額など）
の見積もりが甘かったのでしょうね。
平文パスワードを表示することで節約できるコスト（＝金額） ＜ 平文パスワードを表示することで発生するコスト（被害の弁済額など）
平文パスワードで節約できるコストなんてパスワード再発行に比べて対して変わらないと思います。
Re:セキュリティ原則を知らない現場と経営の悪魔合体だな (スコア:1)
あぁ、コレ [srad.jp]ね
はぁ、アレから音沙汰無しだけど、ドコモのセキュリティ−意識って低いな
Re: (スコア:0)
旧・セキュリティ原則は、「絶対漏えいさせません」だったからな。
すみません、専業攻撃者がいまんとこ圧倒的有利です。って顧客に説明できないと。
っていう愚痴。
Re: (スコア:0)
Re:セキュリティ原則を知らない現場と経営の悪魔合体だな (スコア:1)
居ますね。
要求仕様策定段階ではちゃんとハッシュ保持となっていてその通りに実装したのに、運用始めたらそういうクレームが来て、
その対応のためにDBの別カラムに生パスワードも保存するように改修したことがあります。
「認証にハッシュ使うのやめて生パスワード使います」って仕様変更だとツッコミを受けやすいですが、
認証処理そのものはハッシュ使ってるまま、ということでさらりと追加仕様を通しました。意味ねー
Re: (スコア:0)
この論議では原理で言えば最もセキュリティ原則を知らなければならないのは顧客なんだけどな。「パスワードは使い回ししない」
顧客視点での問題は「平文で保持している事」ではなく「漏洩する事」。「漏洩しない事」さえ満たされればそれは問題ではない。
企業に送信した情報はいかなる状況でも確実に保護されるとは限らない。
第三者の攻撃、企業の悪意、企業内部の個人の悪意、企業の過失、企業の無知、様々な過程で漏洩は起こり得る。
顧客は企業への信頼と得られる価値とリスクを秤にかけて、その企業に与えるべき情報を顧客個人が判断しなければならない。
与える情報のいくつかはやむを得ないものだが、共用のパスワードを複数の企業に渡す意味は無い。
こういう事を言うと企業の擁護だと言う人が出てくるが、そもそも論の話だ。
データストアに平文で保持されていなければパスワード漏洩が起こらないというものではないし、
顧客個人が情報保護の行動を取っていなければ、企業の与り知らぬ場面で容易に情報を窃取されてしまう事も起こる。
Re: (スコア:0)
すべてのパスワードがユニークなら漏洩しても被害は小さい。これは確かにそう。
ただ、異なるすべてのパスワードを人間が記憶する。この運用が不可能なのよ。
管理ソフトを使えば可能だけど、利便性が著しく下がる。
問題の本質は、堅牢性と運用可能であるかの隔たりが大きすぎることだから、
漏洩リスクの担保は顧客が負うべきというあなたの主張は、現実に則してないと思う。
ユーザーがパスワードを使い回さないのは当然として、
企業側も多段認証やトークンなどより堅牢なシステムを用意すべきで、
パスワードの平文保持なんてクソ仕様はやっぱり論外。
ぶっちゃけた話 (スコア:0)
別にこれドコモ側は暗号化してるっていってるし別に問題ないでしょ
平文で送ってくるから問題、可逆であるから問題っていうけど実際問題別なパスワードを知っていて
本人が持って居ると思われるスマホに対して送るなら特に問題じゃない気がするけど
HSM使ってるんなら別に暗号化済みパスワード流出しても一定期間解けないだろうし
Re:ぶっちゃけた話 (スコア:1)
平文パスワード利用者に送信するほど、標準的なセキュリティ対策の
お作法を気にしないシステムが、HSM をちゃんと導入・利用できてるとは
にわかに想像し難いのですが。
結局HSMを使っていても、バックアップリカバリ用に鍵を外部で生成してインポートする
運用にしていて、その外部で生成した鍵データが開発者のPC内に残ってるとかしそう。
Re: (スコア:0)
平文パスワードを提示可能(=復号可能)な暗号化ではダメ
Re: (スコア:0)
なんでだめなの？
暗号化にしろハッシュ化にしろ生パスワードが漏れないことは要件に含まれないよ？
流出後一定期間生パスワードが保護できればいいんだけど・・・
もしかしてハッシュ化していれば生パスワードはばれないって思ってる？
別に総当たりでいつかばれることは変わらないよ？
最近だと同一マシン内で鍵情報を持たないでHSMなんかで暗号化するって割と普通だけど
複合化出来るからダメ！って何が問題なのか全くわからん
暗号化強度とかで問題にするなら分かるけど複合化出来るからダメは全くもってナンセンス
Re:ぶっちゃけた話 (スコア:2, 参考になる)
複合警察と復号化警察が来たぞー
○復号
×復号化
×複合
××複合化
「平文」(名詞)を、「暗号化」(動詞、encryptの訳語)したら「暗号」(名詞)になる。暗号にするから暗号化。
「暗号」(名詞)を、「復号」(動詞、decryptの訳語)したら、「平文」(名詞)になる。復号にするわけじゃないから「復号化」じゃない。
複合はcomplex。同音異義語で全然意味が違う。
暗号の複合とかプリント基盤とか書かれた文章は
その内容の信憑性を一段低くみてしまいます。複合化なら二段低い。
Re: (スコア:0)
ハッシュ化されていればアカウント毎に総当たりしないとならないから、影響範囲を狭められる
Re: (スコア:0)
論旨にはあまり関係ないだろうけど勝手に補足すると、それはソルト付きハッシュの場合だね。
Re: (スコア:0)
漏れてる時点で大して変わらんが・・・
一個でも漏れたら「その一個が複合化されるまでの時間」が強度の評価時間であって
一個解けても「次が解けるまで時間かかるから大丈夫」はハッシュ関数の強度の選択事由になりません
Re: (スコア:0)
ドコモ側で復号できるってことは、その復号鍵をどこかに持っているわけで。暗号化パスワードが復号鍵とセットで流出したら平文と同じですよ。
Re: (スコア:0)
対ダンパ性とか知らないのであればあの語らないでください
HSMがなんなのかも分かってなさそうなので・・・
Re: (スコア:0)
対ダンパ性ｗｗｗ タンパだよ、Ｔａｍｐｅｒ
技術者気取りの素人が自分の思い込みを上から目線で叩きつけ合うひどいサイトですねここは
そもそもドコモはHSM使ってるなんて言ってないし仮に使っててもHSMごと盗まれるリスクがあるんですがそれは
Re: (スコア:0)
ダンパー【damper】
１ 振動エネルギーを消散させて衝撃または振動の振幅を軽減する装置。自動車・鉄道車両などに使用。制振器。吸振器。
２ ピアノ・チェンバロなどで、弦の振動を止める装置。
ダンパーの意味や定義 Weblio辞書 [weblio.jp]
Re: (スコア:0)
これは恥ずかしい
コメントを額縁に入れて飾ってあげたいレベル
濁点を付ける方向でのtypoはあり得ないから間違って覚えてたんやろなぁ
Re: (スコア:0)
「別なパスワードを知っていて本人が持って居ると思われるスマホに対して送るなら」、「HSM使ってるんなら」みたいな前提が崩れることを想像できない時点で君はセキュリティの仕事に向いてない。
Re: (スコア:0)
前提が崩れることじゃなくってそう言う持ち方してるなら別に暗号化で保存してても問題ないよっていってるんだけど
何勝手に話し膨らませて訳の分からないこと言ってるの？
なんでドコモならっていってるのに前提がとか他社にまで適応するみたいな思考になってんだ
ハッシュ化しているからOK、暗号化だからNGがそれは問題の本質ではないよ
流出した場合に解析されるまでの時間とかそう言う物が評価指標でしかない
向いてる向いてない以前にお前は何を言ってるんだ？
妄想で語るならそもそも君IT業にすら向いて無くって小説家にでもなったほうがいいよ
Re: (スコア:0)
自分の説明能力のなさを棚に上げて後付けの言い訳を長々と垂れ流す時点で君はコミュニケーションに向いていない。
Re: (スコア:0)
こういう実例があるので駄目です。
パスワードを暗号化しちゃダメでしょ (スコア:0)
暗号化するということは復号できるということ。
漏洩時のリスクを考えるなら、復元不可能な方法でハッシュ化が必要。
パスワード紙か書かせるようなところだから・・・ (スコア:0)
だいぶ前だけど機種変更のときにドコモショップでgoogleアカウントのID/パスワードを紙に書かされた。（自分の体験談）
新しい端末にアプリをインストールするなどで必要にあるとかそんな言い訳だった。
さすがに今はそんなことはないだろうと思っていたんだけど今年になっていまだにデータコピー名目などでパスワードを書かせていると聞いた。（自分の体験談ではない）
サイトに平文保存されているのも確かに流出問題とかあるけど、人に目に触れることはないから平文保存の方がまだマシかな。
ショップの場合は記憶力よければそのまま担当がパスワードもっていけるからね。
＃帰ってからすぐにパス変更した
Re: (スコア:1)
だいたい、ショップでそこまで開通処理してくれなくていいんだよねえ。
取れるrootも取れなくなっちゃうじゃん。(←セキュリティ上、ますますややこしい話