Saya diminta untuk mengembangkan aplikasi web yang akan berfungsi offline untuk jangka waktu lama. Agar hal ini dapat dilakukan, saya tidak dapat menghindari menyimpan data sensitif (data pribadi tetapi bukan jenis data yang Anda hanya akan menyimpan hash) di penyimpanan lokal.

Saya menerima bahwa ini bukan praktik yang disarankan, tetapi diberi sedikit pilihan, saya melakukan yang berikut untuk mengamankan data:

• encyrypting semuanya masuk ke penyimpanan lokal menggunakan perpustakaan cryptto javascript stanford dan AES-256
• kata sandi pengguna adalah kunci enkripsi dan tidak disimpan pada perangkat
• melayani semua konten (saat daring) dari satu server tepercaya melalui ssl
• memvalidasi semua data yang masuk dan dari penyimpanan lokal di server menggunakan proyek antisami owasp
• di bagian jaringan appcache, tidak menggunakan *, dan sebaliknya hanya mencantumkan URI yang diperlukan untuk koneksi dengan server tepercaya
• secara umum mencoba menerapkan pedoman yang disarankan dalam lembar contekan OWASP XSS

Saya menghargai bahwa iblis sering dalam detail, dan tahu ada banyak keraguan tentang penyimpanan lokal dan keamanan berbasis javascript secara umum. Adakah yang bisa berkomentar apakah ada:

• kelemahan mendasar dalam pendekatan di atas?
• ada solusi yang mungkin untuk kelemahan seperti itu?
• ada cara yang lebih baik untuk mengamankan penyimpanan lokal ketika aplikasi html 5 harus berfungsi offline untuk jangka waktu lama?

Terima kasih atas bantuannya.

WebKripto

Kekhawatiran dengan kriptografi di javascript sisi-klien (peramban) dirinci di bawah ini. Semua kecuali satu dari masalah ini tidak berlaku untuk WebCrypto API , yang sekarang didukung dengan cukup baik .

Untuk aplikasi offline, Anda masih harus merancang dan menerapkan keystore yang aman.

Selain: Jika Anda menggunakan Node.js, gunakan API crypto bawaan .

Kriptografi Asli-Javascript (pra-WebKripto)

Saya kira perhatian utama adalah seseorang dengan akses fisik ke komputer membaca localStorageuntuk situs Anda, dan Anda ingin kriptografi untuk membantu mencegah akses itu.

Jika seseorang memiliki akses fisik Anda juga terbuka terhadap serangan selain dan lebih buruk daripada membaca. Ini termasuk (tetapi tidak terbatas pada): keyloggers, modifikasi skrip luring, injeksi skrip lokal, keracunan cache browser, dan pengalihan DNS. Serangan-serangan itu hanya berfungsi jika pengguna menggunakan mesin setelah kompromi. Namun demikian, akses fisik dalam skenario seperti itu berarti Anda memiliki masalah yang lebih besar.

Jadi perlu diingat bahwa skenario terbatas di mana kripto lokal bernilai adalah jika mesin dicuri.

Ada perpustakaan yang menerapkan fungsionalitas yang diinginkan, misalnya Perpustakaan Stanford Javascript Crypto . Meskipun demikian, ada kelemahan bawaan (sebagaimana dimaksud dalam tautan dari jawaban @ ircmaxell):

1. Kurangnya entropi / angka nomor acak;
2. Kurangnya keystore aman yaitu kunci pribadi harus dilindungi kata sandi jika disimpan secara lokal, atau disimpan di server (yang melarang akses luring);
3. Kurangnya penghapusan aman;
4. Kurangnya karakteristik waktu.

Masing-masing kelemahan ini sesuai dengan kategori kompromi kriptografi. Dengan kata lain, walaupun Anda mungkin memiliki nama "crypto", itu akan jauh di bawah kerasnya yang dicita-citakan dalam praktik.

Semua yang dikatakan, penilaian aktuaria tidak sepele seperti "Javascript kripto lemah, jangan gunakan itu". Ini bukan endorsemen, hanya peringatan dan mengharuskan Anda untuk sepenuhnya memahami paparan kelemahan di atas, frekuensi dan biaya vektor yang Anda hadapi, dan kapasitas Anda untuk mitigasi atau asuransi jika terjadi kegagalan: Javascript crypto, di Terlepas dari kelemahannya, dapat mengurangi eksposur Anda tetapi hanya terhadap pencuri dengan kapasitas teknis terbatas. Namun, Anda harus menganggap Javascript crypto tidak memiliki nilai terhadap penyerang yang ditentukan dan mampu yang menargetkan informasi itu. Beberapa akan menganggap itu menyesatkan untuk menyebut data "dienkripsi" ketika begitu banyak kelemahan diketahui melekat pada implementasi. Dengan kata lain, Anda sedikit dapat mengurangi eksposur teknis Anda tetapi Anda meningkatkan eksposur keuangan Anda dari pengungkapan. Setiap situasi berbeda, tentu saja - dan analisis untuk mengurangi eksposur teknis terhadap eksposur keuangan adalah non-sepele. Berikut ini adalah analogi ilustrasi:Beberapa bank memerlukan kata sandi yang lemah , terlepas dari risiko yang melekat, karena paparan mereka terhadap kata sandi yang lemah lebih kecil daripada biaya pengguna akhir untuk mendukung kata sandi yang kuat.

🔥 Jika Anda membaca paragraf terakhir dan berpikir "Seseorang di Internet bernama Brian bilang saya bisa menggunakan Javascript crypto", jangan gunakan Javascript crypto.

Untuk kasus penggunaan yang dijelaskan dalam pertanyaan, tampaknya lebih masuk akal bagi pengguna untuk mengenkripsi partisi lokal atau direktori home mereka dan menggunakan kata sandi yang kuat. Jenis keamanan itu umumnya diuji dengan baik, dipercaya luas, dan umumnya tersedia.

Nah, premis dasar di sini adalah: tidak, belum aman.

Pada dasarnya, Anda tidak dapat menjalankan crypto di JavaScript: JavaScript Crypto Dianggap Berbahaya .

Masalahnya adalah Anda tidak bisa mendapatkan kode kripto ke dalam browser dengan andal, dan bahkan jika Anda bisa, JS tidak dirancang untuk membiarkan Anda menjalankannya dengan aman. Jadi sampai browser memiliki wadah kriptografi (yang disediakan oleh Ekstensi Media Terenkripsi, tetapi sedang digalakkan untuk tujuan DRM mereka), itu tidak mungkin dilakukan dengan aman.

Sejauh "Cara yang lebih baik", tidak ada satu pun saat ini. Satu-satunya alternatif Anda adalah menyimpan data dalam teks biasa, dan berharap yang terbaik. Atau jangan menyimpan informasi sama sekali. Either way.

Entah itu, atau jika Anda memerlukan keamanan semacam itu, dan Anda memerlukan penyimpanan lokal, buat aplikasi khusus ...

Sebagai eksplorasi topik ini, saya memiliki presentasi berjudul "Mengamankan TodoMVC Menggunakan API Kriptografi Web" ( video , kode ).

Ia menggunakan API Kriptografi Web untuk menyimpan daftar todo yang dienkripsi dalam penyimpanan lokal dengan kata sandi melindungi aplikasi dan menggunakan kunci turunan kata sandi untuk enkripsi. Jika Anda lupa atau kehilangan kata sandi, tidak ada pemulihan. ( Penafian - itu adalah POC dan tidak dimaksudkan untuk penggunaan produksi. )

Sebagai jawaban lain menyatakan, ini masih rentan terhadap XSS atau malware yang diinstal pada komputer klien. Namun, data sensitif apa pun juga akan berada di memori ketika data disimpan di server dan aplikasi sedang digunakan. Saya menyarankan bahwa dukungan offline mungkin merupakan use case yang meyakinkan.

Pada akhirnya, mengenkripsi localStorage mungkin hanya melindungi data dari penyerang yang hanya membaca akses ke sistem atau cadangannya. Ini menambahkan sejumlah kecil pertahanan mendalam untuk OWASP 10 item A6-Sensitive Data Exposure , dan memungkinkan Anda untuk menjawab "Apakah ada dari data ini yang disimpan dalam teks yang jelas dalam jangka panjang?" benar.

Ini adalah artikel yang sangat menarik di sini. Saya sedang mempertimbangkan menerapkan enkripsi JS untuk menawarkan keamanan saat menggunakan penyimpanan lokal. Sangat jelas bahwa ini hanya akan menawarkan perlindungan jika perangkat dicuri (dan diterapkan dengan benar). Itu tidak akan menawarkan perlindungan terhadap keylogger dll. Namun ini bukan masalah JS karena ancaman keylogger adalah masalah semua aplikasi, terlepas dari platform eksekusi mereka (browser, asli). Mengenai artikel "JavaScript Crypto Dianggap Berbahaya" yang dirujuk dalam jawaban pertama, saya punya satu kritik; itu menyatakan "Anda bisa menggunakan SSL / TLS untuk menyelesaikan masalah ini, tapi itu mahal dan rumit". Saya pikir ini adalah klaim yang sangat ambisius (dan mungkin agak bias). Ya, SSL memiliki biaya,

Kesimpulan saya - Ada tempat untuk kode enkripsi sisi klien, namun seperti halnya semua aplikasi, pengembang harus mengenali keterbatasannya dan menerapkannya jika sesuai dengan kebutuhan mereka, dan memastikan ada cara untuk mengurangi risiko itu.

Tidak dapat diakses ke halaman web mana pun (benar) tetapi mudah diakses dan mudah diedit melalui alat dev, seperti chrome (ctl-shift-J). Karenanya, custom crypto diperlukan sebelum menyimpan nilai.

Tetapi, jika javascript perlu mendekripsi (untuk memvalidasi) maka algoritma dekripsi terbuka dan dapat dimanipulasi.

Javascript membutuhkan wadah yang sepenuhnya aman dan kemampuan untuk mengimplementasikan variabel dan fungsi pribadi dengan benar yang hanya tersedia untuk juru bahasa js. Namun, ini melanggar keamanan pengguna - karena melacak data dapat digunakan tanpa impunitas.

Akibatnya, javascript tidak akan pernah sepenuhnya aman.

Tidak.

localStorage dapat diakses oleh halaman web mana pun, dan jika Anda memiliki kuncinya, Anda dapat mengubah data apa pun yang Anda inginkan.

Yang sedang berkata, jika Anda dapat menemukan cara untuk mengenkripsi kunci dengan aman, tidak masalah bagaimana Anda mentransfer data, jika Anda dapat berisi data dalam penutupan, maka data (agak) aman.