Как мне безопасно хранить зашифрованные пользовательские данные на моем сервере и предоставлять их только нужному пользователю?

Question

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

• Шифрование (необязательно) должно выполняться с парольной фразой пользователя .
• Вход в систему пользователя (необязательно) должен осуществляться с использованием пароля пользователя .

Примечания:
Простой текстовый пароль не сохраняется на сервере и не передается по сети.

Мои опции и их недостатки:

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

2. Аутентификация на стороне сервера, без авторизации:
Сервер хранит пароль пользователя для доступа к данным и предоставляет данные только тому пользователю, который может предоставить правильный пароль.
Пользователи не доверяют сети для передачи своих данных без шифрования .

3. Аутентификация и авторизация:
Сервер хранит пароль пользователя для доступа к зашифрованным данным, шифрование выполняется с использованием ключевой фразы, которая отличается от пароля пользователя.
Хорошая безопасность, но пользователи не хотят запоминать два пароля .

4. Аутентификация против авторизации: Сервер хранит пароль пользователя для доступа к зашифрованным данным, шифрование выполняется с использованием того же пароля.
Пользователи счастливы. Некоторые проблемы безопасности.

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

Некоторые мысли:

• Используйте разные алгоритмы шифрования для пароля и данных.
• Добавить фиксированную строку в конец пароля пользователя перед шифрованием.
• Пароль пользователя Pad на определенную длину.

---

EDIT:

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

Он должен быть основан на сети, поэтому человек в средней атаке должен быть предотвращен с помощью HTTPS.

Чтобы серверные хаки не могли раскрыть данные, данные шифруются на стороне клиента.

Чтобы предотвратить вмешательство клиентского шифрования, доступ к данным должен быть защищен на стороне сервера с помощью некоторого логина и пароля или токена (может быть уникальным URL).

Answer 1

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

Authentication - процесс доказательства того, кем вы являетесь (точнее, тем, что вы являетесь владельцем личности, на которую претендуете).
Authorization - механизм, используемый для ограничения, контроля и предоставления доступа.
Encryption - механизм защиты данных даже от тех, кто имеет к ним доступ.

Теперь позвольте мне перефразировать ваши варианты, а затем я предложу кое-что еще:

1. Нет аутентификации, нет авторизации, шифрование на стороне клиента
2. Аутентификация на стороне сервера, Авторизация на стороне сервера, Шифрование на стороне сервера
3. Аутентификация на стороне сервера, Авторизация на стороне сервера, Шифрование на стороне клиента
4. Аутентификация на стороне сервера, Авторизация на стороне сервера, Шифрование на стороне клиента с использованием учетных данных сервера.

Теперь, я думаю, может быть яснее, где каждый из них стоит.
В общем, вы действительно хотите следовать принципу «наилучшей практики» (не начинайте с меня) «глубокой защиты», то есть не используйте только шифрование или только контроль доступа, вместо этого используйте оба! Но, как вы указали, это может противоречить (если пользователю необходимо запомнить TWO пароли) другому принципу: «Keep Security Simple».

Не пытаясь быть СЛИШКОМ раздражающим, вы не давали много информации в отношении вашей среды. Например, это, например, веб-приложение? Если так, почему SSL / TLS недостаточно шифрования для вас? Или это вопрос пользователей, загружающих личные данные, которые вы (и ваша система) тоже не должны видеть (например, служба резервного копирования)? В этом случае будет необходимо шифрование на стороне клиента ...

Итак, (наконец) мои предложенные варианты, в зависимости от вашей среды / требований:

1. Если вы можете, используйте для шифрования защищенные протоколы (например, SSL / TLS). Использовать аутентификацию на стороне сервера + авторизация, шифрование протокола.
2. Если вашей системе требуется дополнительная защита этих данных, например, кредитные карты (обратите внимание, что в настоящее время я не являюсь PCI: QSA;)), используйте предыдущую опцию и, кроме того, шифрование на стороне сервера, используя сгенерированный сервером ключ шифрования (НЕ пароль) (и, конечно, защитите его).
3. Если данные должны быть защищены ИЗ вашей системы, вам нужно будет выполнить шифрование на стороне клиента ДОПОЛНИТЕЛЬНО к аутентификации + авторизации на стороне сервера (ваш вариант 3, как я его переформулировал).
   Однако вам не обязательно заставлять пользователя запоминать дополнительный пароль / фразу. Опять же, в зависимости от вашей среды, вы можете рассмотреть некоторую форму ключа, хранящегося на клиенте, например, сертификат в хранилище сертификатов / хранилище ключей пользователя или даже хранится в защищенном файле конфигурации; ключ, основанный на биометрических данных (нелегко, но я видел, что это было сделано успешно, хотя у него есть свой собственный набор проблем), распределение ключей вне полосы (например, через мобильный телефон) и т. д. Это позволит вам обоим использовать сильные клавиши предотвратить доступ сервера к этим ключам, не требовать от пользователя запоминания двух ключей и не использовать повторно один пароль для разных целей в разных контекстах.

Answer 2

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

Answer 3

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

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

Безопасность, основанная на возможностях проще в выборе, более гибкой и более понятной для пользователей. Есть действительно превосходное видео на YouTube о безопасности на основе возможностей и хороший сайт с некоторыми эссе об этом .