Android 端末では電子メールのパスワードが平文で保存されている。 49
ストーリー by reo
それはそれ、これはこれ ? 部門より
それはそれ、これはこれ ? 部門より
ある Anonymous Coward 曰く、
Android 端末ではパスワードが平文保存されているそうだ (The Hacker News の記事、本家 /. 記事より) 。
元記事によると、Android 端末では電子メールアカウントのパスワードは SQLite データベースに保存されることとなっており、最終的には端末のファイルシステムにテキストデータとしてこの情報が保存されているという。記事ではせめて SHA や MD5 でエンクリプトした状態で保存する方が良いとしているが、Android のサポートフォーラムでは「サポートされている POP3 や IMAP、SMTP、そして Exchange Active Sync などのより古いプロトコルは接続時に毎回クライアントからのパスワード提示を求めるものである。これらのプロトコルは端末でそのアカウントを利用する限り端末でパスワードを保持し続ける」として、パスワードを 1 回だけ使いトークンを生成するタイプの新しいプロトコルとの違いを説明し、単に暗号化して端末に保存するだけでは「安全」を実現することは出来ないと指摘している。
フォーラムではまた、もし「/data/data/*」から任意のデータを取得できるとすれば、それは電子メールプログラムのバグではなく、端末のセキュリティ上の問題であるとも指摘している。なお、Android サポートではユーザからの関心や懸念に考慮して、このバグレポートをクローズしないとのことで、データをの安全性をより向上させる手法を検討するとも述べている。
rootが奪われてる前提だと危険、かな？ (スコア:4, 参考になる)
Androidが一般的には個人用デバイスであることを考慮し、
UnixではユーザーIDに該当する部分が
Androiではアプリごとに個別利用されセキュリティレベルを向上させるようになっています。
ですので、EmailアプリであればEmailアプリでひとつのユーザーIDを持ち、
ファイルシステム上でのアクセス権限も(たとえば)
「Emailアプリ専用」にもすることもができます。
今回指摘されているEmailアプリのデータベースファイルは(おそらく)
ファイルシステム上の
/data/data/com.android.email/databases/.
ディレクトリ配下にある.dbファイル群と思いますが、
これらのアクセス権限は今見た限りでは「660」ですので
Emailアプリとそのグループアプリ(実質存在しない？未調査)しかアクセスできません。
ですので、この内容が平文であった場合に問題になるのは
上記ユーザーIDによるアクセス制限を突破される場合です。
突破されない限りは内容を閲覧されることもありません。
ということで、結論としては以下のようになるのかなと思います。
・非rootでアクセスできるならそれはファイルシステムのセキュリティホール。
今回のフォーラム書き込み主はこれを言っているのかは不明。
・rootでアクセスできるのはセキュリティホールではない(できて当然)。
・rootでアクセスされることまで想定してガード強化のため暗号化するか？は論議がありそう。
root奪われてる時点で多少のガードに意味があるのかどうかも含めて。
というところでしょう。
Re: (スコア:0)
スカイプも誰でもアクセスできるところにパスワードが保存されていたので、それに比べればまだましだが
でも、他のアプリも問題が多そうだな。
IDをローカルに保存するようなアプリの多くは問題ありなんじゃないのかな？
近いうちに、それらのファイル盗んでリモートにアップするマルウェアが流行りそうだ。
たとえ暗号化されていても、盗んだ後なら時間かけて解読できるしね。
Re: (スコア:0)
>Androidはセキュリティホールがあっても放置される可能性が高いから、
>出来ればもっと厳しくして欲しいところだね。
意味不明。
場違いなところに来る前に、3年勉強してから出直したらどうだろう？
そのほうがあなたにとって有益だと思うよ。
Re:rootが奪われてる前提だと危険、かな？ (スコア:1, 荒らし)
IS01のような事でしょう。＜放置される
組み込み機器共通の難点といえば難点ですが、何時までアップデートが提供され続けるか不明瞭なのは嫌らしい感じです。
Re:rootが奪われてる前提だと危険、かな？ (スコア:1, 参考になる)
>IS01のような事でしょう。＜放置される
これも勘違いしている人が多いですが、
メジャーアップデートの断念とセキュリティフィックスの提供停止はまったくの別問題です。
Googleの標準Android実装はそのまま端末に組み込まれることを想定していないため、
可能な限り互換性を重視し、セキュリティフィックスなども「以降のバージョンで」になりがちですが
実際に端末に組み込まれるAndroid実装
(=キャリアや端末メーカーが組み込む実装)では、
Googleからセキュリティ情報が展開されそれに対応してメーカーが自前でフィックスを織り込んでいます。
ですので、IS01であっても既知の多くのセキュリティフィックスは修正済みですし、
メジャーアップデートが行われないにしても、
今後の大きなセキュリティホールはフィックスされていくことになります。
Vistaが出てもXPのセキュリティパッチは提供されていくのと同じです。
これらは、利用者視点では
「Androidバージョンは同じだけどこっちの端末ではrootが取れない」であったり、
「Androidバージョンは同じだけどアップデートしたらrootが取れなくなった」などでも観測されますね。
Re:rootが奪われてる前提だと危険、かな？ (スコア:2, 興味深い)
そのセキュリティフィックスが提供されるという根拠は何処にあるの？という点が気になります。
Windowsを例に挙げてますが、アレは明確なサポートポリシーがあり、提供される期間も明確に決まっています。
対して、Mac OSやiOS、携帯電話等では、明確なサポートポリシーとサポート期間が明記されていないor不明な点があります。
「出るかもしれない」ではなく「出る」でなければ、それは「出ない」と考えなければ安全側には倒せないですよね。
周りでウィルスが流行して自分の端末が感染して初めて「アップデートが提供されなくなっていた」事が解っても後の祭り過ぎます。
Re:rootが奪われてる前提だと危険、かな？ (スコア:1, 興味深い)
パッチが提供されていることと、今後の方針の話は別だろうが。
IS01が放置されているというお前の放言に反論してるだけなのに、話題をすりかえるなよ。
アップデートポリシーはキャリアのサポートに確認したの？
そういった確認の手間を取らずに方針が不明と単純に言ってるんじゃないか？
Re: (スコア:0)
>そのセキュリティフィックスが提供されるという根拠は何処にあるの？という点が気になります。
>「出るかもしれない」ではなく「出る」でなければ、それは「出ない」と考えなければ安全側には倒せないですよね。
キャリアには端末管理義務があるため、
重大な問題であればどうしてもサポートせざるを得ません
(実際にその端末利用者がいるか、サポートを受けに来るかは別問題)。
スマホ以外を含めかなり古い端末でもときどきフィックスが出ますよね。
あれと同じです。
ここから先は生の話として、
・音声通話に直接影響するならそれこそずっと
Re: (スコア:0)
http://k-tai.impress.co.jp/docs/news/20110427_442661.html [impress.co.jp]
はい、OSアップデート無視した後にセキュリティfixしてる例。
で、セキュリティfixが今後無視されるという根拠になる話はあるの？
Re:rootが奪われてる前提だと危険、かな？ (スコア:2, 興味深い)
確かにIS01の例示は不適切でしたね。申し訳ございません。
私はSB003SHを所有してますが、こちらは2011年1月の購入前にサポート(151)に電話して確認しましたが、
「セキュリティFix等のアップデート提供期間は現時点では未定であり、お答え致しかねる」との回答でした。
其れゆえの発言でしたが、現在は異なるのかもしれませんね。
Re:rootが奪われてる前提だと危険、かな？ (スコア:1)
なるほど、参考になります。
少なくともある日突然通信・通話できなくなるとみたいなバグであれば提供は期待してよさそうです。
セキュリティホールがどの程度に位置づけされるか解らない点が心配ではありますが。
内規・内部ではしっかりフローチャートが有るのでしょうが、その具体的閾値も公開して欲しい所ですね。
何せ外部からはどんな基準でとか、内部で取り込んでるパッチが何なのかは解らないですから、簡単に検証が出来ないのですよね。
パソコン向けOSであればどのパッチが適用されているか確認可能ですし、CERT/CC辺りで脆弱性と対応フィックスバージョン等が容易に確認可能です。
その点で新たな脆弱性が発見された場合、自分の所有している機器に影響するのかしないかが解り易いのですが、現状の市販のスマートフォン少なくとも私の手持ちのSB003SHにはそういう物が無いので心配です。
例えばzlib/libpngとかはかなりスタンダードなライブラリですが稀に穴が見つかりますよね。
そういった時にそもそも含まれているのか、対策済みバージョンなのかといった情報が得られないのです。
含まれるのが解っていればそもそも使わない、電源を切っておく、データ通信をOFFにする、予め個人情報を外部に退避させる等の事も可能なのですが。
Re: (スコア:0)
http://journal.mycom.co.jp/articles/2011/05/19/android/index.html
上のようなニュースから個人的印象ではVerで置いて行かれるとある程度は脆弱性も残ると思ってました
Re:rootが奪われてる前提だと危険、かな？ (スコア:1)
根拠はまったくありません。
私が問題としているのは、あくまで将来の提供が「未定義」or「明言されていない」状況を問題としています。
未定義と定義済みの間には広くて大きな差異があります。
買い替えといった製品ライフサイクルにも影響してきます。
極論すれば過去の実績はどうでも良く、可能であれば短くても良いので更新を提供する努力目標期間と、セキュリティ問題が確認されたが更新が提供が不可能となった場合その旨を明確に発表する事です。
まだ比較的新しい製品ですから、現在は全ての既知のセキュリティ問題が影響しない事を検証・テストされ、有った場合でも修正が提供されていて、既存不具合が修正出来ていないといった事例が無くその為にそのような情報が無いだけなのかもしれません。
ですが、ソフトウェアという物は欠陥が見えにくい故に「終わり」まで見据えた計画・運用をしなければならないと思いませんか？
現状はそれが見え難い為に買うときにギャンブル的な感覚が有ります。
# 既に大分オフトピックなので次辺りから反応しないか、ACでセルフマイナスモデします・・・
Re: (スコア:0)
>私が問題としているのは、あくまで将来の提供が「未定義」or「明言されていない」状況を問題としています。
>未定義と定義済みの間には広くて大きな差異があります。
>買い替えといった製品ライフサイクルにも影響してきます。
それなら、Android機、iPhone/iPad機、BlackBerry機、フィーチャーフォンのいずれも買えませんね。
いずれも○○年までサポートを保証等とは公式には謳っていませんし。
大変だと思います。いや、選択の幅が無くて却って楽なのかな?
Re: (スコア:0)
私のiPhone3Gは2年縛りも明けないうちからセキュリティFix見放されました。
まああの会社とあの会社の組み合わせなんで別に驚きはしませんでしたが。
Re: (スコア:0)
>この辺はIS01などでももう対処されているのでしょうか？
>http://journal.mycom.co.jp/articles/2011/05/19/android/index.html
>
>上のようなニュースから個人的印象ではVerで置いて行かれるとある程度は脆弱性も残ると思ってました
その脆弱性については、Android OSではなく
アプリとしての連絡帳アプリやカレンダーアプリを更新し、
サーバー側も更新後アプリを前提とするよう設定変更することで対処されました。
「(Android)マーケット」というアプリの更新が勝手に全自動適用されるのと同じく
これらのアプリの更新も勝手に反映され
Re: (スコア:0)
買えない訳ではありませんよ。
ただ重要な情報はなるべく蓄積しないようにして、慎重に取り扱うだけです。
少なくとも、フィーチャーフォンと比較した場合国外で発見された攻撃もそのまま通用する可能性、
ノータイムで来る可能性もあるのでAndroid機、iPhone/iPadに関しては注意したいです。
BlackBerryに関してはSBMでの提供が無いのでそもそも選択肢に無いですが。
そもそもとして、結構なバグが残ってる状態で出荷されている時点でサポート期間不明というのは怖いです。
SB003SHで過去にあった、現在有る物として
・再起動（各社共通で、「まぁ、仕方ないよね・・・」で何故か
Re: (スコア:0)
＞>Androidはセキュリティホールがあっても放置される可能性が高いから、
＞>出来ればもっと厳しくして欲しいところだね。
＞
＞意味不明。
意味不明ってどこが？
実際半年から１年ぐらい放置されていたのを知らないの？普通に日経の記事に出てたのに・・・root権限奪うウイルスが先月も出てきたし、今後も増えるでしょうから問題多そうだ。
もしかして日本の一流メーカー品しか頭にないのか？Androidは日本だけではないのだよ。
既にいろいろなメーカーからいろいろなものが出ているし、実際売れているのは、高級品よりも低価格品だったりするし
それらが今後もずっとサポ
Re: (スコア:0)
> 聞いたこともないような中国メーカー品のサポート
「安物買いの～」という言葉をご存知ですか？
自力でメンテできないなら、信頼できるメーカー品を買えばいいだけ。
売った会社はメンテする*責任*はありませんよ？
Re: (スコア:0)
>意味不明ってどこが？
>実際半年から１年ぐらい放置されていたのを知らないの？
>普通に日経の記事に出てたのに・・・
>root権限奪うウイルスが先月も出てきたし、今後も増えるでしょうから問題多そうだ。
他コメでも触れられているとおり、
そのまま製品化されるとは想定していないAndroid標準実装と
実際のメーカー出荷実装は異なります。
多くの場合既知の問題はメーカーが自前でフィックス済みです。
そこにおいて、Android標準実装を前提に
製品としてのAndroid端末を語るのはそもそも筋違いですね。
>もしかして日本の一流メーカー品しか頭にないのか？Androidは日本だけでは
それでどうやって認証を通すんだ？ (スコア:4, 興味深い)
本家のコメントにもあったけど、SHA や MD5 で得られたハッシュ値から、どうやって、POP や IMAP、SMTP-AUTH の認証を通すの？
それを言うなら、鍵管理ソフトの様に、マスターパスワードの入力を要求して、そのパスワードを使って解読できる、何らかの暗号化を施した値を保存すべきだと思うなぁ。
Re: (スコア:0)
平文になってるのにも、暗号化できないにも意味があるんですけどねぇ
技術系サイトでメールサーバの挙動もわかってない人たちが
勘違いなコメントつけてるのみると残念な感じがします
Re: (スコア:0)
「マスターパスワード等によるセキュリティトークン暗号化」なら普通の発想だと思うのだが、何を残念がっているのだろう。
Re: (スコア:0)
解り辛いので自分の解釈もちょっと自信がないが、
「勘違いなコメント」と指摘しているのは多分本家のコメントの事で、
#1992322はJULY氏のコメントに同意するものなのではないかな。
Re: (スコア:0)
でもスマートフォンでは事情が違うのかなと。電源が落ちることを想定しないスマートフォンではRAMに平文を展開するだけで無防備とか。長いパスワードを期待できないスマートフォンでマスターパスワードはあまり意味はないのかとか。数分でRAMから平文を消去し再度パスワード入力させる動作もあるけど、それもスマートフォンには不向きに思える。
色々不具合はありそうだけど、まったく暗号化しないようりはどこかで暗号化したほうが安全に見えるけどね
Re: (スコア:0)
>色々不具合はありそうだけど、
>まったく暗号化しないようりはどこかで暗号化したほうが安全に見えるけどね
セキュリティは明確な目標を決めないとキリがありません。
またそれ自体に負荷もコストも運用問題も発生するものです。
個人情報保護とかでここは獄中かと思うくらい締め付けられてる人も多いでしょう。
「どこまで締め付ければ気が済むんだよ！」って。
個人的には、ファイルシステムでのガードが存在する前提であれば
「IDやパスワードは暗号化することが望ましい」くらいかなぁと思います。
「こんなこともあろうかと」「念のため」。
おかしいな DESで暗号化が普通じゃないのか (スコア:2)
当時は、DES で暗号化して保存するのが普通でした。
少し前に、新しく入ってきた業者が、
「パスワードは、平文で保存してないとだめなんだ」
と言っていたので理由を聞いたら、
「そんなの当たり前じゃないか！読み出して、String Compare するからだ！」
と、言われてしまった。
まさか、技術的問題って、それじゃないよね。
Re:おかしいな DESで暗号化が普通じゃないのか (スコア:1)
クライアント側とサーバ側の問題を混同してませんか?
今回の問題はクライアント側。
プロトコル的に、素のPOP3は生のパスワードをそのまま送信するし、
APOPはサーバから送られてくるチャレンジと生のパスワードを連結したもののMD5ハッシュを送信。
どちらも、認証の段階ではクライアント側には平文なパスワードが必要。
よくある「DESをハッシュ関数にしたパスワードのハッシュ保存」では、認証できません。
ソフトウェア的に復号可能な状態でパスワードを保存しておく必要があります。
ちなみに、サーバー側でも、素のPOPならDESなハッシュ保存で問題ありませんが、
APOPだとチェックに生パスワードが必要なのでハッシュ保存不可ですね。
httpのDigest認証だと、ハッシュのハッシュを使うことでサーバ側で生パスワードを不要にするなど、そのあたりの欠点は解消されてます。
あ、もし、「DESで暗号化して保存」というのが、本来の意味の暗号化アルゴリズムとしてのDESの利用の意味だったとしたら、ちょっと話は変わってきますね。
でも、そうなると「そんなの当たり前じゃないか！読み出して、String Compare するからだ！」って理由は的外れもいいとこですね。「読み出して復号して String Compare する」だけのことですし。
Re:おかしいな DESで暗号化が普通じゃないのか (スコア:1, すばらしい洞察)
＃暗号化しておきましたってハッシュ化されてたときの衝撃
Re: (スコア:0)
> 本来の意味の暗号化アルゴリズムとしてのDESの 利用の意味だったとしたら
DESでもなんでも、結局は鍵をローカルに保持しておかないと復号できない。
最初のほうのコメントにあったように、
rootとられてるなら鍵だって参照できるだろうし、
rootとられてないならそもそも見れないんだから平文だろうと問題ないでしょ。
rootとか関係無しにパスワードファイルだけ参照できちゃうような脆弱性があればまた別でしょうけど。
他の端末ではどうなのか (スコア:1)
他の端末では、e-mailパスワードって平文で保存じてないの？
Re:他の端末ではどうなのか (スコア:2, 参考になる)
BlackBerryの場合、端末にはメールパスワードは保存されていません。
BlackBerryのメールは基本的にRIMのサーバが設定されたメールアカウントをクロールし、新着があればそれを取得して端末に送りつける仕組みです。
したがってメールサーバのユーザーアカウントとパスワード情報はサーバ側に保存されており、端末にはありません。
Re: (スコア:0)
それは「RIMのサーバと接続するための認証が必要」という問題に転嫁されているだけですけどね
Re: (スコア:0)
RIMサーバとの間の通信の認証はIMEIやPIN、端末内部の証明書などで行い、いわゆる「パスワード」は存在しないが。
Re: (スコア:0)
>RIMサーバとの間の通信の認証はIMEIやPIN、端末内部の証明書などで行い、
>いわゆる「パスワード」は存在しないが。
原理的に言えば、根底が生体認証でない限りは
どっかでID&パスワードに行き着くってだけだと思いますよ。
そこにおいて、ブラックベリーの場合
一般にはRIMにID&パスワードで委譲しているってのは妥当なところな感じ。
Re: (スコア:0)
Re: (スコア:0)
端末じゃなくてメールアプリの問題じゃね？
ガラパゴスマホは独自カスタマイズで無関係とかいうことないの？
パスワード暗号化・・・ (スコア:1)
＞SHA や MD5 でエンクリプトした状態
いつからハッシュ関数が暗号化になったのでしょうか・・・
確かにオリジナルのPOP3だと暗号化対応してない環境だと端末内で暗号化しても、
無線AP偽装（FON_FREE_INTERNET辺りがお手軽でしょう）とかしてパケットキャプチャすれば丸見えですからね。
# 一応手持ちのSB003SHだと、POP3では、セキュリティなし/SSL/TLSが選択可能(APOPは非対応？)ではあります。
それは置いといて、確かに端末内にクリアテキストで保存されてるのも怖い話ではあります。
手持ちのアンドロイド端末は違うのですが、
内部ストレージもmicroSDな機種だとどのようになってるのかが気になります。
Re: (スコア:0)
>内部ストレージもmicroSDな機種だとどのようになってるのかが気になります。
システム領域まで完全にmicroSDという機種はあんまりないと思いますよ。
その先として、本来のApp2SDの仕様では、
取り外し可能なSDにアプリのインストールやデータの保存をする場合は
端末と紐付ける形で必ず暗号化され、
さらにSDから常駐するようなアプリの起動禁止が強制されます。
App2SDに挙がる不満の多くはこれらセキュリティに考慮してのものです。
ただし、root権限があればこれらを内部ストレージに見せかけることも可能であり、
たとえばSD上にEXT領域を作成し内部ストレージに見
Re:パスワード暗号化・・・ (スコア:1)
Galaxy S辺りを念頭に置いていましたが、改めて調べるとデータ領域のみでシステムやアプリケーションは別のようですね。
後者の起動制限は実際に有効なのを確認済みで、その点SB003SHのように内蔵領域が少ない端末だと不便ではあります。
root取ってApp2SD+extしたくなるのも解る気がします・・・
# 常駐不可は安全性以外にも電池の持ちという現実的な問題も有る気がしますが。
まぁ、現実にはメーラーにバグが有った時やroot取れちゃうバグが有った時に要注意って事ですかねぇ
後はROMチップ引っぺがして読まれた場合とか
Re: (スコア:0)
・内部メモリ(NAND)：システム、dbdataなど
・内部メモリ(MMC)：データ領域(/data)とSDカード領域(/mnt/sdcard = /sdcard)として使用
・外部SD：SDカード領域内のディレクトリ(/mnt/sdcard/external_sd)に割り当て
といった構成になっています。
なので、外部メモリ(/sdcard)にデータを置くアプリでもまだ実際は内部メモリだったりします。
そういう意味ではGalaxySはまったく逆の存在かと思います
ハッシュ化はできないが。 (スコア:1)
散々指摘されているが。
認証する側はパスワードをハッシュ化(=復元不能)して保存できるし、そうするべきだが。認証される側は、パスワードを復元する必要があるのでハッシュ化できない。
ThunderbirdやらのPCのメーラでも、それは同じだし、ハッシュ化はされていないはず。けれど、
・マスターパスワードをつけて暗号化する
・一見わからないように難読化する、あるいはハードコーディングされたキーなどで暗号化する
という方法はとることができる。
現に、Thunderbirdではマスターパスワードがつけられる(どうやら3DESが使われているらしい [passwordanalytics.com])し、つけなくてもぱっと見は分からないようになっている。
ただし、マスターパスワードは入力がめんどくさい。難読化はいずれ破られるし、一度解読法が知れ渡ると無いに等しい。そういう欠点をかかえている。
そういう欠点はあっても、平文でなく暗号化などをすべきなのか?
それとも「じゃあもうどうでもいい。しなくていい」って話なのか?
1を聞いて0を知れ!
Re: (スコア:0)
そもそもマスタパスワード等を使わずローカルストレージにある情報だけで認証を通せるようにしたい場合、ストレージの内容が丸ごと敵の手に渡る状況を想定しているのなら、鍵が同じストレージに入っているわけですから暗号化もクソもないですね。
鍵が同梱されてたらDESだろうがAESだろうが安全性は何一つ担保しておらずセキュリティとしては本質的に平文と変わらないわけで、なんとなく暗号化しているつもりになっているだけです。もはや暗号化と呼ぶのも馬鹿馬鹿しいようななんちゃって難読化。
サーバに認証通すための道具が全部ローカルにあってそれをソフトウェアで実
Re: (スコア:0)
そもそもケータイなんだか・・・ (スコア:0)
携帯電話機を悪意を持った他人が平気で触れる状態で放置するって時点で手遅れ。
メールパスワードよりも他の心配をした方が良いと思うんだけど。
そんなんじゃ海外に長時間通話されても知らんぞ。
＃本来は端末自体を自己管理とキーロックで保護するもんだろうから。
そもそも (スコア:0)
そもそもキャリア、メーカ、ＣＰはユーザのパスワードが漏れようが気にしない。
彼らが気にするのは、ユーザから彼らのプロプライエタリ情報だけだよ。
Re: (スコア:0)