Comments 17
Пароли шифруют необратимо, а для шифрования других данных, нужны обратимые методы шифрования. Пароль для них придётся хранить на сервере или клиенте, он тоже может утечь.
Усложняете жизнь двум организациям из трёх букв.
Усложняете жизнь двум организациям из трёх букв.
Безопасность в интернете — вещь относительная и никогда не может быть полной, всегда найдется кто-то умнее и настойчивее и обойдет ее. Защита предназначена для того, чтобы усложнить эту задачу для страждующих.
Хранение пароля на сервере, конечно же, не вариант, теряется смысл. Ключ же стоит хранить лишь на стороне клиента. Если сервер не занимается заботливым кешированием ключей, то в случае потери базы ключи так просто не достанутся третьим лицам.
Хранение пароля на сервере, конечно же, не вариант, теряется смысл. Ключ же стоит хранить лишь на стороне клиента. Если сервер не занимается заботливым кешированием ключей, то в случае потери базы ключи так просто не достанутся третьим лицам.
Получается что зашифрованные данные и ключи для расшифровки будут храниться вместе. Так что смысла в этом нет. Если же ключ для расшифровки будет вводить пользователь при логине, то сохранность данных будет ровно до того момента пока он помнит пароль. Вот и весь сказ.
В том то и дело, ключи (не соль, ее можно оставить на сервере) для дешифрования не стоит хранить вместе с данными, ключ будет передан клиентом в тот момент, когда он взаимодействует с сервисом, и удален из памяти по окончанию работы пользователя. А то, что сохранность до тех пор, пока есть пароль — нередко такой меры будет достаточно, чтобы понизить ценность украденной базы.
Так я не понял, а что будет происходить с данными когда пользователь забыл/потерял ключ для расшифровки?
В случае шифрования данных, пользователю ничего не остается, как либо попытаться вспомнить ключ, либо проститься со своими данными. За должную безопасность придется платить соответствующим образом. Разумеется, такая мера предосторожности подходит лишь для случаев, когда человек морально готов к такому исходу.
Беда будет. Тут уж каждому нужно выбирать. Либо данные не шифруются, либо данные шифруются и, в ситуации «забыл пароль», данным кирдык.
Зачем хранить вместе?
Есть сервер базы данных, есть сервер приложений, делаем сервер шифрования, который хранит ключи к зашифрованным данным и отдаёт их (или расшифрованные данные?) серверу приложений по запросу с хэшем пользовательского пароля (отличным от того, который хранится в таблице паролей), и с задержкой (имя-фамилия-телефон-адрес-почта-кредитка нужны редко и не сразу для всех).
Это не решит проблему полностью, но затруднит взлом (нужно иметь доступ сразу к трём серверам) и может подать сигнал тревоги в случае массовой расшифровки пользовательских данных.
Есть сервер базы данных, есть сервер приложений, делаем сервер шифрования, который хранит ключи к зашифрованным данным и отдаёт их (или расшифрованные данные?) серверу приложений по запросу с хэшем пользовательского пароля (отличным от того, который хранится в таблице паролей), и с задержкой (имя-фамилия-телефон-адрес-почта-кредитка нужны редко и не сразу для всех).
Это не решит проблему полностью, но затруднит взлом (нужно иметь доступ сразу к трём серверам) и может подать сигнал тревоги в случае массовой расшифровки пользовательских данных.
Вы, наверное, в некоторых местах под шифрованием, всё-таки имеете ввиду хеширование? Особенно в месте про пароли — так как пароли надо хешировать (а ещё посолить и поперчить), а вот прочие данные можно и зашифровать :)
Хэшировать можно только что что уже не нужно будет в оригинальном виде. Например хешировать электронную почту — бред.
Все зависит от того, как она используется. Если ее используют для обратной связи — да, хешировать ее не вариант. Если для регистрации, сброса пароля, логина (т.е. в качестве идентификатора пользователя) или просто для галочки — почему бы и нет. Я мельком видел утерянную базу Adobe, и там попадались электронные адреса, которые были невалидны, а значит их никто не проверят, и что-то мне подсказывает, что таких случаев далеко не единицы. В данной ситуации, хранить лишь хеш имело смысл.
Если почта зашифрована, то использовать её для сброса пароля не получится — что бы её расшифровать, нужен тот самый пароль, который пользователь забыл.
Вовсе нет, если речь идет о первых двух случаях (поскольку в третьем случае, где используется именно шифрование данных, а не хеширование, сброс пароля просто не предусмотрен по определению). Если пользователь в какой-то момент понимает, что забыл пароль (в данном случае, пароль является лишь кодовой фразой для подтверждения владения аккаунтом), он указывает свой электронный адрес для сброса пароля в соответствующей форме, сервис берет хеш адреса, находит в базе нужную учетную запись и меняет пароль. Аналогично и для обычной авторизации — используя, допустим, пару логин/пароль, сервер возьмет хеш от обоих значений и проверит, что найденная запись с таким же хешем логина имеет такой же хеш и для пароля.
Обычно почта ещё используется для отправки каких-либо уведомлений — в этом случае придётся хранить адрес в открытом виде. Аналогично, логин обычно публичный и виден, например, на странице с данными пользователя или в записях на форуме.
Верно, я это отметил в конце второго случая, что сервис не сможет использовать хешированные данные, как например отправка уведомлений на случай хеша адреса. Все очень зависит от конкретного сервиса и того, как он использует данные. Описанные варианты не являются универсальными (ну, разве что кроме первого) на все случаи защиты данных, это лишь возможные способы для тех сервисов, где это допустимо.
И, опять же, безопасность своих данных не приходит бесплатно, за нее приходится чем-то жертвовать. С другой стороны, небрежное отношение к своей персоне однажды может выйти пользователю еще дороже, так что ему следует выбрать, что для него важнее.
И, опять же, безопасность своих данных не приходит бесплатно, за нее приходится чем-то жертвовать. С другой стороны, небрежное отношение к своей персоне однажды может выйти пользователю еще дороже, так что ему следует выбрать, что для него важнее.
Sign up to leave a comment.
Двойные стандарты в шифровании учетных записей