HTML5 клиентское шифрование данных - какие у меня варианты?

Question

Я работаю над EDIT: мобильным веб-приложением , которое отображает некоторую конфиденциальную информацию и требует входа в систему, который хранит имя пользователя и пароль участника в сеансе HTML5. В настоящее время имя пользователя и пароль хранятся в незашифрованном состоянии, поскольку нам необходимо использовать это имя пользователя и пароль на каждой странице загрузки для доступа к удаленному веб-сервису клиентов.

РЕДАКТИРОВАТЬ: После проверки безопасности наш клиент поднял следующую проблему:

"Существует вероятность того, что информация о хранилище сеансов может быть сохранена на диске (например, при сбое браузера). По этой причине конфиденциальная информация не должна храниться в незашифрованном виде в хранилище сеансов. Идентификаторы пользователей и токены сеансов могут храниться, поскольку время ожидания сеансов реализованы, однако хранение паролей / ПИН-кодов не рекомендуется. "

Какой самый лучший / самый безопасный метод шифрования и дешифрования конфиденциальных данных, хранящихся на стороне клиента?

Спасибо!

Answer 1

Привет, вместо того, чтобы хранить имя пользователя и пароль, вы не можете создать своего рода «сеанс» с удаленным сервером и вместо этого передать токен аутентификации?

Хранение имени пользователя и пароля в любом месте на стороне клиента даетменя дрожит.

Возможно, изыскивая способы безопасного хранения имени пользователя / пароля, ищите способы избавления от необходимости хранить их вообще.

Однако, конечно, я говорю это, не зная полного фона ... Я предполагаю, что есть веская причина для необходимости хранить имя пользователя / пароль.

Answer 2

Для любого, кто наткнулся на этот вопрос, у Стэнфорда есть крипто-проект на http://crypto.stanford.edu/sjcl/.. Я сам не использовал его в производстве, но занят его исследованием, и пока он выглядит многообещающим.Надеюсь, это кому-нибудь поможет.

Answer 3

Дэвид Даль, инженер Firefox, имеет прототип расширения Firefox, domcrypt ( репозиторий на github ), который обеспечивает доступ Javascript к API-интерфейсам Firefox NSS (Network Security Services).Так как Chrome также использует NSS, предоставление того же API, вероятно, также просто для него.

Он толкает Mozilla , чтобы развить его немного больше для возможного включения в Firefox;посмотрим что получится.

Answer 4

Более поздние версии браузера должны поддерживать Web Crypto API.

1. Смотрите тестовую страницу, если ваш браузер работает
2. Описание API w3c Webcrypto
3. Информация о сети разработчиков Mozilla для API WebCrypto

Answer 5

Недавно изучал эту тему сам.Я думаю, что к настоящему времени у нас есть несколько проверенных библиотек шифрования JS, которые видят здесь и здесь .

Теперь вопрос в том, где хранить ключ.Хранить его на стороне клиента - это то же самое, что хранить данные вообще без шифрования.И если пользователь будет постоянно вводить ключ, это будет препятствовать достижению цели.

Возможно, вы могли бы попросить сервер генерировать новый ключ всякий раз, когда вы создаете новый сеанс.(Обязательно используйте HTTPS при выполнении этого запроса).Если сеанс истекает, пользователь должен снова ввести имя пользователя / пароль, и он будет зашифрован с использованием нового токена.Чтобы расшифровать ключ, вы должны сделать (безопасный) запрос к вашему серверу (передавая идентификатор сеанса), чтобы запросить ключ, который затем можно использовать для расшифровки имени пользователя и пароля.

Теперь это все еще остается открытымобычные уязвимости, такие как межсайтовый скриптинг или перехват сеанса, но, по крайней мере, пароль пользователя не сохраняется в виде открытого текста на стороне клиента.

Как вы думаете?

---

Answer 6

См. Безопасность HTML5 Web DB

клиентские библиотеки шифрования не зрелые или недостаточно хорошо протестированные

... но это был год назад, так что это может быть уже ложным

Answer 7

Хранение конфиденциальных учетных данных пользователя не очень хороший дизайн. Вместо этого создайте аутентифицированный токен с сервера, используя, скажем, среду спринта. Затем его можно сохранить в локальном хранилище с помощью модуля безопасности Web DB.

Answer 8

Я работаю над приложением , которое сталкивается с той же проблемой. Безопасность важна для этого приложения, поскольку оно позволяет пользователям создавать личные деревья (или вложенные списки) и хранить их в облаке.

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

Answer 9

Я должен сказать, что если вы создаете данные сеанса 1, что это не так, - хранятся на сервере, а не на стороне клиента, таким образом, никто не видит данные сеанса, или, по крайней мере, это должно быть сделано таким образом через asp, или php, и т. Д. чтобы приложение требовало подключения к Интернету, получало информацию с веб-сервера и не сохраняло ее на стороне клиента. 2, если это касается клиентской стороны, например потоковой передачи видео или изображений, или вам нужно создать некоторые файлы на клиентской стороне, то хранение ключа на клиентском мобильном устройстве - единственный способ. Таким образом, у вас есть либо ключ с коротким ttl для расшифровки данных, либо ключ, выданный с помощью какой-либо формы аутентификации или сертификата, либо ключ, установленный в вашем главном офисе, и шифрование устройства на случай его потери. Я не нашел и не зашифровал функцию, которую я хотел бы предложить для вас.