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

Question

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

Это также основная жалоба в этом обсуждениив остальном классный сервис: http://news.ycombinator.com/item?id=1549115

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

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

- ОБНОВЛЕНИЕ -

Из ответа @ Borealid я сосредоточилсяна две возможности: протоколы ответа на вызов, где данные (включая пароль) не отправляются в «чистом» режиме, и протоколы без ответа, где данные (включая пароль) отправляются в «чистом» (хотя и через HTTPS).

Протоколы вызовов-ответов (в частности, SRP: http://srp.stanford.edu/)

Похоже, что для его реализации потребуется либо полностью AJAX-сайт, либо использование веб-хранилища. Это такбраузер может сохранять данные запроса-ответа во время шифрования, а также ключ шифрования между различными «страницами». (Я предполагаю, что после завершения аутентификации яотправил бы им обратно зашифрованный ключ шифрования, который они расшифровали бы на стороне клиента, чтобы получить настоящий ключ шифрования.)

Проблема в том, что я либо:

• полностью AJAXМне это не нравится, потому что я люблю URL-адреса и не хочу, чтобы пользователь жил исключительно по одному URL-адресу, или
• Я должен хранить ключи шифрования данных в веб-хранилище, основанном на http://dev.w3.org/html5/webstorage/ будет сохраняться даже после закрытия браузера и может быть уязвимостью безопасности

Кроме того, поскольку SRP принимает более одного запроса (http://srp.stanford.edu/design.html), необходимобыть некоторой настойчивостью на стороне сервера.Это просто еще одна трудность.

Традиционно

Если я в порядке и передаю пароли и данные в открытом виде (хотя и через HTTPS), то проблемы на стороне клиента вышеотсутствуют.

При регистрации я сгенерирую случайный уникальный ключ шифрования для пользователя и зашифрую его, используя его пароль и случайную соль.

В базе данных я будухранить хэш и соль пароля пользователя (через bcrypt), зашифрованный ключ шифрования, соль ключа шифрования и шифрование iv.

После аутентификации мне также потребуется использовать их пароль для расшифровки ключа шифрования, чтобыони могут просматривать и вводить новые данные.Я храню этот ключ шифрования только временно и удаляю его, когда они явно «выходят из системы».

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

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

Существует ли лучшее хранилище данных в памяти для хранения этих ключей шифрования (и запроса данных во время аутентификации SRP)?Для этого Redis подойдет?

Answer 1

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

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

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

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

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

Этот метод используется облачным сервисом хранения Lacie. Это очень хорошо сделано.

Примечание: когда я говорю «используйте foo для шифрования», я действительно имею в виду «используйте foo для шифрования безопасного симметричного ключа, который затем используется со случайной солью для шифрования». Знай свою криптографию. Я говорю только о секрете, а не о методологии.

Answer 2

Вам следует изучить проект MIT CryptDB , который поддерживает запросы к зашифрованной базе данных с использованием подмножества SQL. (см. статью forbes , нить mefi или Гомоморфное шифрование в Википедии)

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

Answer 3

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

То, что вы хотели бы, или, точнее, лучшее решение, которое вы найдете в этом пространстве, - это не столько то, что wuala делает выше, а скорее что-то вроде hush.com. Обработка пользовательских данных всегда должна выполняться на стороне клиента - как правило, это выполняется с помощью полной клиентской Java-программы (например, загрузчик фотографий Facebook и т. Д.), Но HTML / JavaScript может помочь вам в эти дни. Шифрование JavaScript довольно слабое, поэтому лучше его игнорировать.

ОК, теперь у вас есть клиентская Java, на которой запущена служба шифрования записей журнала. Следующая функция заключалась в том, чтобы каждый вечер отправлять пользователям по электронной почте прошлые записи журнала. Ну, вы, очевидно, не получите это в незашифрованном электронном письме. Это где вам нужно изменить пользовательский опыт, так или иначе. Самое простое решение - не отправлять по электронной почте запись, а вместо этого предоставить, например, браузер записей журнала в приложении Java, который напоминает им о какой-то старой записи, когда они попадают на веб-сайт, на основе ссылки в ежедневной электронной почте. Гораздо более сложным решением было бы использовать шифрование JavaScript для расшифровки записи в виде встроенного вложения в электронном письме. Это не ракетостроение, но здесь задействовано довольно много хитростей. Это общий путь, используемый несколькими службами шифрования электронной почты, такими как IronPort. Вы можете получить демонстрационное электронное письмо, перейдя на http://www.ironport.com/securedemo/.

Как бы мне ни хотелось видеть правильно зашифрованную версию всего этого, мой последний комментарий состоял бы в том, что записи в журнале не являются государственной тайной. Принимая во внимание четкую политику конфиденциальности и хорошую семантику безопасности сайта, я уверен, что 99% ваших пользователей будут чувствовать себя прекрасно. Выполнение всего этого с истинной безопасностью потребует огромных усилий, как указано выше, и, по крайней мере, внесет некоторые изменения в дизайн / УП.

Answer 4

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

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