質問

オフラインで長期間機能するWebアプリケーションを開発することが求められています。これを実現するためには、ローカルストレージに機密データ（個人データですが、ハッシュ化されて保存されるようなデータではありません）を保存しないわけにはいきません。

これは推奨されるやり方ではないことは承知していますが、選択の余地がないため、データを保護するために次のようなことをしています。

• ローカルストレージに保存されるすべてのデータを、スタンフォードのJavaScript暗号ライブラリとAES-256で暗号化します。
• ユーザーパスワードは暗号化キーであり、デバイスに保存されません。
• オンライン時に信頼できる単一のサーバーからすべてのコンテンツをsslで提供する
• owasp antisamy プロジェクトを使用して、サーバー上のローカルストレージに出入りするすべてのデータを検証する。
• を使用せず、信頼されたサーバーとの接続に必要な URI のみをリストアップします。
• 一般的には、OWASP XSS cheat sheet で提案されているガイドラインを適用してみることです。

私は、悪魔はしばしば細部に宿るということを理解していますし、一般に、ローカルストレージやJavaScriptベースのセキュリティについては懐疑的な意見が多いことも知っています。また、ローカルストレージとjavascriptベースのセキュリティ全般について、懐疑的な意見が多いことも知っています。

• 上記のアプローチに根本的な欠陥があるか？
• そのような欠点に対する可能な解決策は？
• html 5 アプリケーションが長時間オフラインで動作しなければならない場合、ローカルストレージを保護する良い方法はありますか？

よろしくお願いします。

解決方法は？

WebCrypto

クライアントサイド（ブラウザ）のjavascriptにおける暗号化に関する懸念事項を以下に詳述します。これらの懸念事項のうち1つを除いて、すべて WebCrypto API であり、現在では それなりにサポートされている .

オフラインアプリの場合、やはり安全な鍵ストアを設計し、実装する必要があります。

余談：Node.jsを使用している場合、ビルトインの クリプト APIを使用します。

ネイティブ-JavaScript 暗号 (WebCrypto以前)

コンピュータに物理的にアクセスできる人が、このファイルを読むことを一番に考えていると思います。 localStorage そのため、アクセスを防ぐために暗号を使用したいのです。

もし誰かが物理的にアクセスしたら、読書以外のもっと悪い攻撃にもさらされることになります。例えば、キーロガー、オフラインでのスクリプト変更、ローカルスクリプトインジェクション、ブラウザキャッシュポイズニング、DNSリダイレクトなどです。これらの攻撃は、侵入された後にユーザーがマシンを使用する場合にのみ機能する。とはいえ、このようなシナリオで物理的にアクセスすることは、より大きな問題を抱えることを意味します。

つまり、ローカル暗号が価値を持つのは、マシンが盗まれた場合という限られたシナリオであることを覚えておいてください。

必要な機能を実装したライブラリがあります。 Stanford Javascript Crypto Library . しかし、固有の弱点があります（@ircmaxellの回答からのリンクで言及されているように）。

1. エントロピー／乱数生成の不足。
2. 秘密鍵をローカルに保存する場合はパスワードで保護するか、サーバーに保存しなければならない（オフラインでのアクセスができない）。
3. セキュアイレーズがない
4. タイミング特性を欠く

これらの弱点は、それぞれ暗号の危殆化のカテゴリーに対応するものです。つまり、「暗号」とは名ばかりで、実際には「厳密さ」に欠けることが多いのです。

とはいえ、「Javascriptの暗号は弱いから使うな」というような些細なことではありません。これは推奨ではなく、厳密には注意事項であり、上記の弱点の露出度、直面するベクトルの頻度とコスト、失敗した場合の緩和策や保険の能力を完全に理解する必要があります。Javascript暗号は、その弱点にもかかわらず、あなたの露出を減らすことができますが、限られた技術的能力を持つ泥棒に対してのみです。Javascript暗号は、その弱点にもかかわらず、露出を減らすことができるかもしれませんが、それは技術力の低い泥棒に対してのみです。しかし、その情報を狙っている、決意と能力のある攻撃者に対しては、Javascript暗号は何の価値もないと考えるべきでしょう。実装に固有の弱点が多数あることが分かっているのに、データを「暗号化」と呼ぶのは誤解を招くと考える人もいるでしょう。言い換えれば、技術的な露出をわずかに減らすことはできますが、開示による金銭的な露出が増えるということです。もちろん、それぞれの状況は異なります。そして、技術的な露出を減らして金銭的な露出を減らすという分析は、自明なことではありません。ここで、例示的なアナロジーを紹介します。 弱いパスワードを要求する銀行もある なぜなら、弱いパスワードによって被る損失は、強いパスワードのサポートにかかるエンドユーザーのコストよりも小さいからです。

???? 最後の段落を読んで、quot;ブライアンというインターネット上の人が、Javascript crypto"を使えると言ったと思った方。 Javascriptの暗号を使用しないでください。

質問にあるような使用例では、ユーザーがローカルパーティションやホームディレクトリを暗号化し、強力なパスワードを使用する方がより理にかなっていると思われます。この種のセキュリティは一般的によくテストされ、広く信頼されており、一般的に利用可能です。