Насколько безопасно местное хранилище?


33

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

Проблема в том, что хранимые данные потенциально чувствительны. Я собирался сделать следующее: когда клиент заходит на веб-сайт, возникает вопрос: «Вы на персональном или общедоступном компьютере». Если они находятся на общедоступном компьютере, сайт отказывает в доступе.

Если бы они находились на персональном компьютере, то им было бы предложено установить пароль. Все их данные будут зашифрованы с помощью этого пароля. Теперь очевидно, что это не слишком безопасно. Метод шифрования должен быть на JavaScript, а его пароль - в виде простого текста, поэтому я предполагаю, что опытный пользователь сможет найти пароль в localStorage и получить доступ к данным.

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

Так что вопрос в том, достаточно ли локального хранилища достаточно безопасно?

Дополнительный вопрос .. насколько сложно стереть ваше локальное хранилище? Я бы не хотел, чтобы пользователи случайно стирали свои данные.

Наконец - стоит ли даже шифровать / дешифровать свои данные так, как будто у вас есть пароль, к которому вы можете получить доступ к сайту ..


2
Клиентский JavaScript - не лучшее место для криптографии. Любой опытный пользователь может посмотреть на код и взломать ваш алгоритм шифрования algorthim и сделать так, чтобы он фактически ничего не делал и просто принимал зашифрованный пароль.

Ответы:


10

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


Было бы более безопасно, если бы пароль был отправлен в PHP, который затем генерировал ключ за кулисами?
JasonS

Нет. Пароль сначала дается на клиенте. Отправляя его на сервер, вы увеличиваете риск его кражи. Создание ключа в JS хранит секрет на клиенте. В любом случае вы должны забыть PW вскоре после этого. Но я думаю, что это все еще бессмысленно - см. Мой ответ.

Многие хакеры достаточно умны ... Используйте Lib bCrypt.
Эдди Б

2

Использование JavaScript с локальным хранилищем максимально безопасно (ваш сервер плюс соединение между браузером и сервером).

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

Дополнительно: поскольку данные находятся на клиенте, вы ничего не можете сделать, чтобы защитить данные. На обычном сервере вы можете, например, ограничить частоту доступа (например, для безопасного удаленного пароля: только 1 пароль читается в течение 10 минут). Все это бесполезно, если данные находятся на клиенте, а злоумышленник может манипулировать всем кодом, работающим с данными.

В конце концов, даже с локальным хранилищем вам нужно защитить ваше веб-приложение! Зачем делать что-то на (надеюсь) защищенном сервере? Если нет, то почему бы не использовать локальную программу, установленную на клиенте?


Вы не думаете, что главная проблема безопасности заключается в том, если устройство используется или украдено кем-то другим?

2

Как насчет получения ключа от сервера, который используется для расшифровки данных localStorage?

Это может работать так:

  • Когда сеанс установлен, сервер возвращает ключ.
  • Этот ключ используется для шифрования / дешифрования данных в localStorage.
  • Когда пользователь покидает страницу, ключ теряется, и другие не могут прочитать, что находится в localStorage.

Это должно разрешить доступ, только когда у пользователя установлен сеанс.


3
Это не сработало бы для доступа к данным в автономном режиме (что кажется основным вариантом использования localStorage). Чтобы использовать этот метод в автономном режиме, вам необходимо сохранить ключ.
Тимоти Ли Рассел

0

как правило, это не сложно очистить локальное хранилище, но это зависит от браузера. Тем не менее, вам нужно использовать инструменты разработчика браузеров (firebug, webkit и т. Д.).

думай об этом так же, как о куки. Вы никогда не должны хранить конфиденциальные данные в локальном хранилище. пароли, номера кредитных карт, что угодно.

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


0

Два вопроса:

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

  2. в большинстве браузеров, если люди стирают кеш, они также удаляют содержимое localStorage. Люди не ожидают потери важных данных, когда стирают свою историю и кэш.

Я думаю, что вы перегибаете то, для чего предназначен localStorage. Если вы хотите использовать локальную базу данных , которая хорошо играет с WebApps вы могли бы взглянуть на CouchDB «s couchapps .

Но не храните пароль.


0

Вы могли бы использовать javascrypt . Запросите у пользователя пароль, который станет ключом шифрования / дешифрования

Вам не нужно хранить пароль, но запрашивайте его каждый раз, когда пользователь открывает страницу.
Может быть, сохранить его, если пользователь хочет, и теперь последствия.

Но затем присоединиться к комментарию stivlo, а как насчет:

  1. доступ с нескольких устройств
  2. резервный
  3. Забыли пароль
  4. слишком простая очистка кэша

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.