Мені потрібно розробити веб-додаток, який буде функціонувати в режимі офлайн тривалий час. Для того, щоб це було життєздатним, я не можу уникнути збереження конфіденційних даних (особистих даних, але не тих, які ви б тільки зберігали хешовані) у локальному сховищі.

Я погоджуюсь, що це не рекомендується, але, маючи невеликий вибір, я роблю наступне для захисту даних:

• шифруючи все, що перебуває у локальному сховищі, використовуючи крипто-бібліотеку Stanford javascript та AES-256
• пароль користувача - це ключ шифрування і не зберігається на пристрої
• обслуговує весь вміст (у режимі онлайн) з одного надійного сервера через ssl
• перевірка всіх даних, що йдуть до локальних сховищ на сервері та за допомогою проекту antasamy
• у розділі мережі Appcache, не використовуючи *, а натомість перелічує лише URI, необхідні для з'єднання з надійним сервером
• як правило, намагаються застосувати вказівки, запропоновані в шпаргалці OWASP XSS

Я розумію, що диявол часто знаходиться в деталях, і знаю, що існує багато скептицизму щодо локального зберігання та безпеки на основі JavaScript загалом. Хтось може прокоментувати, чи є:

• основні недоліки у вищезазначеному підході?
• можливі рішення таких недоліків?
• будь-який кращий спосіб забезпечити локальне зберігання, коли програма html 5 повинна функціонувати в режимі офлайн протягом тривалого часу?

Дякуємо за будь-яку допомогу.

WebCrypto

Проблеми з криптографією в JavaScript на стороні клієнта (браузера) детально описані нижче. Усі, окрім однієї з цих проблем, не стосуються API WebCrypto , який зараз досить добре підтримується .

Для офлайн-програми потрібно все-таки розробити та впровадити захищену сховище ключів.

Убік: Якщо ви використовуєте Node.js, використовуйте вбудований крипто API.

Криптовалюта Native-Javascript (pre-WebCrypto)

Я припускаю, що головна проблема - це хтось із фізичним доступом до комп'ютера, який читає localStorageваш сайт, і ви хочете, щоб криптографія допомогла запобігти цьому доступу.

Якщо хтось має фізичний доступ, ви також відкриті для атак інших і гірших за читання. До них відносяться (але не обмежуються ними): кейлоггери, модифікація сценарію офлайн, введення локального скрипту, отруєння кешем браузера та переадресації DNS. Ці атаки спрацьовують лише у тому випадку, якщо користувач користується машиною після її злому. Тим не менш, фізичний доступ у такому сценарії означає, що у вас є більші проблеми.

Тож майте на увазі, що обмежений сценарій, коли місцева криптовалюта є цінною, була б, якщо машина викрадена.

Є бібліотеки, які реалізують потрібну функціональність, наприклад, крипто-бібліотека Stanford Javascript . Однак є властиві слабкі сторони (про що йдеться у посиланні з відповіді @ ircmaxell):

1. Відсутність ентропії / генерації випадкових чисел;
2. Відсутність захищеного сховища ключів, тобто приватний ключ повинен бути захищений паролем, якщо він зберігається локально або зберігається на сервері (який забороняє доступ в автономному режимі);
3. Відсутність безпечного стирання;
4. Відсутність часових характеристик.

Кожна з цих слабкостей відповідає категорії криптографічних компромісів. Іншими словами, хоча у вас може бути "криптовалюта" за назвою, вона буде значно нижчою жорсткості, до якої прагнемо на практиці.

Все, що говорилося, актуарна оцінка не настільки тривіальна, як "Криптовалюта Javascript слабка, не використовуйте її". Це не схвалення, суто застереження, і воно вимагає, щоб ви повністю зрозуміли викриття вищезазначених слабкостей, частоту та вартість векторів, з якими ви стикаєтеся, і вашу здатність до пом'якшення чи страхування на випадок збою: криптовалюта Javascript, в незважаючи на слабкі сторони, це може зменшити ваше опромінення, але лише проти злодіїв з обмеженими технічними можливостями. Однак, ви повинні припустити, що криптовалюта Javascript не має значення щодо рішучого та здібного зловмисника, який націлює цю інформацію. Дехто вважає оманливим називати дані "зашифрованими", коли відомо, що стільки слабких місць притаманні реалізації. Іншими словами, ви можете незначно зменшити свою технічну витримку, але ви збільшуєте свою фінансову експозицію від розкриття інформації. Кожна ситуація, звичайно, різна - і аналіз зменшення технічного впливу фінансового впливу нетривіальний. Ось наочна аналогія:Деякі банки потребують слабких паролів , незважаючи на властивий їм ризик, оскільки їх експозиція до втрат від слабких паролів менша за витрати кінцевого користувача на підтримку надійних паролів.

🔥 Якщо ви прочитали останній абзац і подумали "Хтось хлопець в Інтернеті на ім'я Брайан каже, що я можу використовувати криптовалюту Javascript", не використовуйте криптовалюту Javascript.

У випадку використання, описаному у питанні, здається, що користувачі мають більше сенсу шифрувати свій локальний розділ або домашній каталог та використовувати надійний пароль. Цей тип безпеки, як правило, добре перевірений, широко довірений і широко доступний.

Ну, основна передумова тут: ні, це ще не захищено.

В основному, ви не можете запустити криптовалюту в JavaScript: JavaScript Crypto вважається шкідливим .

Проблема полягає в тому, що ви не можете надійно занести криптовалюту в браузер, і навіть якщо б ви могли, JS не призначений для того, щоб запустити його надійно. Тому, поки у браузерів не буде криптографічного контейнера (який надають розшифровані медіа-розширення, але вони об'єднані для своїх цілей DRM), це зробити неможливо надійно.

Що стосується "Кращого шляху", то зараз його немає. Ваша єдина альтернатива - зберігати дані у простому тексті та сподіватися на найкраще. Або взагалі не зберігати інформацію. У будь-якому випадку.

Або це, або якщо вам потрібна така безпека, і вам потрібна локальна пам’ять, створіть власну програму ...

Як вивчення цієї теми, у мене є презентація під назвою "Захист TodoMVC за допомогою API веб-криптографії" ( відео , код ).

Він використовує API веб-криптографії для зберігання списку todo, зашифрованого в localStorage, захищаючи додаток паролем та використовуючи ключ, отриманий паролем для шифрування. Якщо ви забудете або втратите пароль, відновлення не буде. ( Відмова від відповідальності - це був POC і не призначений для використання у виробництві. )

Як свідчать інші відповіді, це все ще сприйнятливо для XSS або зловмисного програмного забезпечення, встановленого на клієнтському комп'ютері. Однак будь-які конфіденційні дані також будуть зберігатися в пам'яті, коли дані зберігаються на сервері і програма використовується. Я вважаю, що підтримка в режимі офлайн може бути важливим випадком використання.

Зрештою, шифрування localStorage, ймовірно, лише захищає дані від зловмисників, які читали лише доступ до системи або її резервного копіювання. Це додає невелику кількість захисту в глибину для експозиції даних A6, чутливих до A6, що відповідає 10 найпопулярнішим темам , і дозволяє відповісти "Чи зберігається будь-який із цих даних у чіткому тексті довгостроково?" правильно.

Тут справді цікава стаття. Я розглядаю можливість застосувати шифрування JS для забезпечення безпеки під час використання локального сховища. Абсолютно зрозуміло, що це забезпечить захист лише в тому випадку, якщо пристрій буде вкрадено (і реалізовано правильно). Він не забезпечить захист від кейлоггерів і т.д. Щодо статті "Криптовалюта JavaScript вважається шкідливою", згаданої у першій відповіді, у мене є одна критика; в ньому йдеться про "Ви можете використовувати SSL / TLS для вирішення цієї проблеми, але це дорого і складно". Я думаю, що це дуже амбітна претензія (і, можливо, досить упереджена). Так, SSL має вартість,

Мій висновок - Існує місце для кодування шифрувального коду на стороні клієнта, однак, як і у всіх програмах, розробники повинні визнавати його обмеження та реалізовувати, якщо вони підходять для їх потреб, і гарантуючи, що існують способи зменшення ризиків.

Не доступний для будь-якої веб-сторінки (правда), але легко доступний і легко редагується за допомогою інструментів розробника, таких як хром (ctl-shift-J). Тому перед зберіганням значення потрібна спеціальна криптовалюта.

Але, якщо javascript потрібно розшифрувати (перевірити), алгоритм розшифровки буде відкритий і ним можна керувати.

Javascript потребує повністю захищеного контейнера та можливості належним чином реалізувати приватні змінні та функції, доступні лише для js-перекладача. Але це порушує безпеку користувачів - оскільки дані відстеження можна використовувати безкарно.

Отже, JavaScript ніколи не буде повністю захищеним.

Немає.

localStorage доступний на будь-якій веб-сторінці, і якщо у вас є ключ, ви можете змінити всі потрібні дані.

При цьому, якщо ви можете придумати спосіб безпечного шифрування ключів, не має значення, як ви передаєте дані, якщо ви можете містити дані в межах закриття, то дані (дещо) безпечні.