Как я могу зашифровать пользовательский контент на моем сайте, чтобы даже я не мог получить доступ к контенту? - PullRequest
8 голосов
/ 07 октября 2011

Мне нужно зашифровать контент в моем веб-приложении для каждого пользователя.

Я, пользователь root, не хочу иметь доступ к содержимому пользователей, точка.

Как я могу сделать так, чтобы пользователи были единственными, кто имеет доступ к своему контенту? Возможно, я смогу сделать так, чтобы хеш их пароля для входа в систему действовал как ключ шифрования и дешифрования (тогда их пароль хранится в моей базе данных с односторонним хешированием, а хеш шифрования / дешифрования генерируется из их необработанного пароля при входе в систему и сохраняется в локальный куки)? Но что если они поменяют свой пароль? Затем я должен обновить весь их контент, который может занять много вычислительной мощности.

Существует ли способ шифрования, обеспечивающий это, без необходимости повторного шифрования их содержимого в случае изменения пароля? Возможно, что-то похожее на ecryptfs в Linux? Является ли исследование ecryptfs хорошим местом для начала?

Делает ли это возможным, чтобы только пользователь мог получить доступ к своему контенту на моих серверах (и даже не мне), даже если это возможно?

Ответы [ 2 ]

11 голосов
/ 07 октября 2011

Процесс:

  1. Создание случайного секрета для шифрования их содержимого.
  2. Используя предоставленный пароль, шифруйте случайный секрет из # 1.
  3. Храните пароль в виде одностороннего хэша (с солью, может быть, с несколькими хешами).

При смене пароля:

  1. Повторно сгенерируйте значение из шага № 2.
  2. Повторно сгенерируйте хэш-кэш из шага № 3.

После входа в систему:

  1. Хеш-пароль и проверка на хеш, сгенерированный на шаге № 3.
  2. Если пароль совпадает - используйте фактический предоставленный пароль , чтобы расшифровать случайный секрет из # 2.
  3. Используйте случайный секрет из # 2, чтобы разблокировать данные, зашифрованные в # 1.

Примечания:

  • Никто не может декодировать данные, не знаяслучайный секрет (# 1).Случайный секрет может быть разблокирован только с помощью действительного пароля пользователя (# 2) (за исключением грубой силы).Действительный пароль пользователя известен только в одностороннем хешированном виде (# 3), поэтому вы можете подтвердить, что он тот же, но не может его расшифровать и восстановить # 2.
  • Процесс забытого пароля невозможен (вы можете восстановить заново).# 3, но случайный ключ в # 2 теперь потерян, так как все заблокировано в их хранилище).
  • Вам не нужно повторно шифровать все на шаге # 1 каждый раз, когда они меняют свой пароль, только(простой / быстрый) случайный секрет из # 2.
  • Если вы кешируете предоставленный им пароль, или случайный секрет, сгенерированный на шаге 1, или их (расшифрованное) содержимое где угодно, вы можете вызвать утечку данных.
0 голосов
/ 07 октября 2011

Вы точно знаете, что вам нужно использовать их пароль в качестве ключа.

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

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

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

Вы можетехранить значение соли в вашей базе данных в незашифрованном виде.

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