アプリケーション内でのログインのセキュリティ

Question

セキュリティにはあんまり詳しくなく、曖昧な表現になっているかもしれません…

例えば、アプリ内でアカウントでログインしてデータをアップロードできるようになる、といったものを想定したとき、
ログインするためのIDパスワードとデータを一緒にしてHTTPS通信するとき、

そのアプリが改造されていて、どっか別のサーバーにいったんデータを送っているような場合が無きにしも非ずだと思うのですが…

想定される改造

想定として、Javaアプリケーションだとすると、
lunch4j等でexe化しても、

解析してリソースをデコンパイル
↓
途中でデータが盗めるように改造
↓
ダウンロードページからダウンロードしたものだと言って、
ほかの人に配る。

といった手口で簡単に仲介させられますよね。

これを防ごうと思ったとき、どうすればいいのかなーと。
SSL通信の主な役割として、

• 信頼できるフォームの受信
• 安全なリクエストの送信

だと思っているのですが、
この場合、HTTPSでコネクションを開いても、
前者が改善されないような気がします。

考えられる対策

一応考えてみたのですが、

1. リソースの段階で暗号化など
2. ダウンロードページから直接ダウンロードするように通告
3. PCを判別して、別のPCの場合はIDパスワード以外の質問をする。
4. そのPCでのみ使える仮のパスワードをサーバーで生成して、クライアントに送る

4つめに関しては、どちらにせよ一回パスワードを使用してログインしないといけないのであまり意味ないような気がします。

それと、3,4つめのPCの判別はどのようにするのがよいのでしょうか。
IPアドレスなのか、OSやUser-Agent等の判定も加えたほうがいいのか、気になります。

以上のことをいろいろ考えて、結局どういうふうに実装するのがよいのかなというふうに至りました。

追記

lunch4jでexeにして、無料の解析アプリを使ってみたのですが、わりとどうにもできませんでした。

Macの場合、appはすべてファイルが見れたような気がするのですが、どうなのでしょうか。

Answer 1

セキュリティの問題は難しいけど、気になりますよね。
とりあえずアリス本をオススメします。
http://www.amazon.co.jp/dp/4797382228
どこにどんなリスクがあり、何をどういう方法で守るか、一通り整理すると良いと思います
(私も勉強中ですが・・・

公開鍵認証基盤を前提として
適切な認証局を選択して証明書を作成すれば以下(など)が保証できます。

• SSL(TLS)通信 → 通信経路の改竄防止・通信相手の正真性
• デジタル署名 → 配布物の改竄防止・正真性

これらは、配布物(アプリ)→アプリ用サーバ の通信や
ユーザが配布物を取得する際の安全な通信のために利用します。

配布物が利用する通信では

1. アプリに埋め込んだ証明書でHTTPS
2. 内部でブラウザを利用し、通常のHTTPS通信を利用

などのやり方が考えられます。

---

さて、これらをどうやって保証するかですが、一筋縄では行かないです。
配布方法・配布物どちらも適切な技術を利用できていれば
あとは配布サーバを安全に運営さえしていればよいです (どう守るかが重要なのですが割愛します…このページで簡単に語れる話ではないので)。
万が一サーバに侵入されて配布物を改竄されれば防ぎようがないですし
最悪(サーバ以外からでも)証明書の秘密鍵が盗まれると大事です。

考えられる対策

1. リソースの段階で暗号化など
2. ダウンロードページから直接ダウンロードするように通告
3. PCを判別して、別のPCの場合はIDパスワード以外の質問をする。
4. そのPCでのみ使える仮のパスワードをサーバーで生成して、クライアントに送る

「想定される改造」にあるように、配布物を改竄された場合以降を考えると難しいと思います
通信先や埋め込み証明証を書き換えられると考えると、どのような対策も完全とは言えません。
(簡単かどうかは置いといて)配布物をクラックされたとすると

1. アプリ内のリソースを暗号化していても、アプリがリソースを利用するための復号化方法をアプリ自身に含めねばならないため、解析されると情報が盗まれるリスクは残ります。
2. これは配布元のサーバに侵入されて配布物の改竄や証明書が盗まれない限りは安全です。
   「配布物は安全な経路・配布元から取得する」というのは対策というよりも常識(前提条件)と言ってよいと思います。
3. これはアプリの改竄ではなくて、パスワード流出や認証攻撃などへの対策では？
   サーバ側でのユーザ認証のセキュリティを強化しても、改竄されたアプリからの情報流出は止められません。
4. これはユーザがパスワードを忘れた場合などのパスワードリセット方法っぽいですね。アプリ改竄対策ではなさそうです

以上のように、アプリ改竄を前提としたセキュリティは一般的には難しいです。
基本的なセキュリティを導入しつつ、配布物が改竄されないよう配布元の安全な運用が肝です

Comments

[luma]

だいぶ経ってしまいましたが、ベストアンサーに選ばせて頂こうと思います。
今もあまり変わりはありませんが、アリス本を読んだりし、
もう該当の問題の発端であるアプリの開発はしていないのですが、当時よく分からなかった回答が少しわかるようになった気がします。
二者間の安全なやり取りをする技術があり、改ざん検知もできる、ということで落ち着きました。
ありがとうございました。

Answer 2

何を作りたいのか、はっきりすればもっと有用な回答が引き出せると思いますが……
仮に、HDD上にあるファイルをUploadするDropboxのようなアプリと仮定しましょう。

この場合、アプリを改造されたらなすすべがありません。そのため、信頼できるところが出したという証明、電子署名技術が存在します。

この場合は、通信の途中で、何らかの形でアプリケーションが、改竄されたとしても、
コードサイジング証明書によって、検出することが可能です。従って、ソフトウェアの
配布元から、正式に配布されたものであるのか、途中でアプリケーションが改竄されて
いないか、電子証明書によって分かるようになっています。

従って、為す術がないと思いきや、そうでもないと言うことになります。

Answer 3

Webアプリケーションで、パスワードを入力する際に、HTTPSでSSLもしくはTLSで暗号化されていれば、その後はサーバーに暗号的ハッシュアルゴリズム（SHA-256）やUUIDもしくはGUIDで、一意にした後に暗号化されたまま、サーバーに保存されますので、仮にパケット通信を盗聴するように仕組んだたとしても、ご指摘のような事象は発生しません。

しかしながら、元のパスワードを推測する辞書型攻撃やレインボーテーブルなど、クラッキングツールを用いることで、短いパスワードであれば、パスワード解析ツールとして最も著名な「John the Ripper」を用いることで、クラッキングは可能です、というのが現実解かと思われます。

Answer 4

何を作りたいのか、はっきりすればもっと有用な回答が引き出せると思いますが……
仮に、HDD上にあるファイルをUploadするDropboxのようなアプリと仮定しましょう。

この場合、アプリを改造されたらなすすべがありません。そのため、信頼できるところが出したという証明、電子署名技術が存在します。

Comments

[luma]

ささっと調べた程度なのですが…

要するにブラウザがやっていることを、やるということなのだと思うのですが、
一応、アプリ側がフォームと送信先のURLを文字列として保持しておく、
といったようなやり方を考えていたのですが、

このURLが改竄されることは
結局ブラウザがパスワードを打つと横流しにする改造がされるのと同じものとして、

やはり2.の信頼できるサイト（自分のサイトのみ）からダウンロードすることを前提とするのが最優先ということでしょうか。