#encryption
#шифрование
Вопрос:
Мне нужно зашифровать контент в моем веб-приложении для каждого пользователя.
Я, пользователь root, не хочу иметь доступ к пользовательскому контенту, точка.
Как я могу сделать так, чтобы доступ к их контенту имели только пользователи? Возможно, я могу сделать так, чтобы хэш их пароля для входа действовал как ключ шифрования и дешифрования (тогда их пароль хранится в одностороннем хэше в моей базе данных, а хэш шифрования / дешифрования генерируется из их необработанного пароля при входе в систему и сохраняется в локальном файле cookie)? Но что, если они изменят свой пароль? Затем мне нужно обновить весь их контент, что может потребовать больших вычислительных мощностей.
Существует ли метод шифрования, который обеспечивал бы это без необходимости повторного шифрования их содержимого в случае изменения пароля? Возможно, что-то похожее на ecryptfs в Linux? Является ли исследование ecryptfs хорошим началом?
Возможно ли сделать так, чтобы только пользователь мог получить доступ к своему контенту на моих серверах (и даже не я)?
Комментарии:
1. Интересно, как hushmail.com делает это.
2. Вот технический документ об их шифровании: hushmail.com/public_documents /…
3. Из ответа электронной почты от Hushmail: Наша система спроектирована таким образом, что только с помощью вашей ключевой фразы зашифрованное электронное письмо в вашей учетной записи может быть расшифровано. Сама кодовая фраза хранится в зашифрованном хэше, поэтому даже наши сотрудники не могут ее увидеть. Это означает, что если ваша почта зашифрована, мы не сможем ее прочитать.
Ответ №1:
Процесс:
- Создайте случайный секрет для шифрования их содержимого.
- Используя предоставленный пароль, зашифруйте случайный секрет из # 1.
- Храните их пароль в виде одностороннего хэша (с солью, возможно, с несколькими хэшами).
При смене пароля:
- Повторно сгенерируйте значение с шага # 2.
- Повторно сгенерируйте хэш-кэш с шага # 3.
При входе в систему:
- Хэшируйте пароль и сверяйте его с хэшем, созданным на шаге # 3.
- Если пароль совпадает — используйте фактический предоставленный пароль для расшифровки случайного секрета из # 2.
- Используйте случайный секрет из # 2, чтобы разблокировать данные, зашифрованные в # 1.
Примечания:
- Никто не может расшифровать данные, не зная случайный секрет (# 1). Случайный секрет может быть разблокирован только с помощью фактического пароля пользователя (# 2) (за исключением перебора). Фактический пароль пользователя известен только в односторонней хэшированной форме (# 3), поэтому вы можете подтвердить, что он тот же, но не можете его расшифровать и восстановить # 2.
- Процесс с забытым паролем невозможен (вы можете восстановить # 3, но случайный ключ в # 2 теперь потерян, как и все, что заблокировано в их хранилище).
- Вам не нужно повторно шифровать все на шаге # 1 каждый раз, когда они меняют свой пароль, только (простой / быстрый) случайный секрет из # 2.
- Если вы кэшируете их предоставленный пароль или случайный секрет, сгенерированный на шаге 1, или их (расшифрованный) контент в любом месте, вы можете вызвать утечку данных.
Комментарии:
1. Вы сгенерировали его, но пока вы его не сохраняете — нет. Единственный способ выяснить это — получить их пароль для декодирования зашифрованной формы из # 2. Или с помощью грубой силы 😉 На этом шаге вы можете использовать хэш их пароля, но вы не можете использовать хэшированную форму, которую вы храните (в противном случае да — вы можете расшифровать ее, не зная их пароля)
2. Извините, я удалил свой комментарий, потому что задал вопрос, на который мог бы ответить, если бы прочитал ваш пост более внимательно. Мне нравится ваша идея.
3. Разве невозможно сгенерировать случайную секретную клиентскую часть? Таким образом, вы действительно гарантируете, что даже не увидите секрет
4. Вы могли бы сгенерировать его, но его нужно будет передавать на сервер для настройки контейнера и сообщать серверу каждый раз, когда кто-то хочет получить доступ к контейнеру, поэтому сервер все равно будет иногда знать об этом (без улучшения безопасности). Кроме того, в зависимости от механизма передачи вы добавляете риск того, что случайный секрет будет изучен другими пользователями Интернета (недостаточно защищенный TLS, человек посередине и т. Д.) На этапе генерации.
5. @Rudu Есть ли возможность поделиться этими зашифрованными данными с другим пользователем без системного администратора, чтобы иметь возможность расшифровать. Я думал об этом, и для этого потребуется, чтобы другой пользователь ввел логин или что-то в этом роде. Потому что мне нужен расшифрованный случайный секрет и зашифровать его паролем других пользователей. Но я не могу получить фактический пароль других пользователей. Я застрял 🙂
Ответ №2:
Вы заметили, что вам нужно использовать их пароль в качестве ключа.
Я бы не стал играть с ecryptfs, потому что зашифрованная файловая система — не лучшее решение. Вы бы не хотели, чтобы данные одного пользователя были зашифрованы тем же ключом, который использовал другой пользователь.
Когда вы шифруете данные, вы должны сгенерировать случайную строку для использования в качестве соли. Это не позволяет кому-либо использовать предварительно сгенерированный список хэшей для расшифровки ваших данных. Это также изменяет хэш двух пользователей, которые могут использовать один и тот же пароль.
Когда пользователь меняет свой пароль, вам придется повторно зашифровать данные и сгенерировать новое значение соли. Это уровень безопасности, которого я ожидаю как клиент, зная, что когда я меняю свой пароль, я повторно шифрую все свои данные, чтобы кто-то не пытался взломать мой ключ.
Вы можете сохранить значение соли в своей базе данных в незашифрованном виде.
Комментарии:
1. С eCryptfs данные каждого пользователя могут быть зашифрованы с помощью их собственных ключей.