Подтвердить что ты не робот

Шифрование данных на стороне клиента HTML5. Каковы мои варианты?

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

EDIT: после проверки безопасности наш клиент поднял следующую озабоченность:

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

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

Спасибо!

4b9b3361

ОТВЕТЫ

Ответ 1

Смотрите Безопасность веб-БД HTML5

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

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

Ответ 2

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

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

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

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

Ответ 3

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

Ответ 4

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

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

Ответ 5

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

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

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

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

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

Ответ 6

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

Ответ 7

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

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

Ответ 8

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