Дважды хешируя пароли - клиент и сервер
Эй, во-первых, позвольте мне сказать, я не спрашиваю о вещах как md5 (md5 (..., уже существуют темы об этом.
Мой вопрос - это:
Мы позволяем нашим клиентам хранить свои пароли локально. Естественно, мы не хотим их сохраненный в тексте плана, таким образом, мы hmac их локально, прежде, чем сохранить и/или отправить. Теперь, это прекрасно, но если бы это - все, что мы сделали, затем сервер имел бы сохраненный hmac, и так как клиент только должен отправить hmac, не незашифрованный пароль, взломщик мог использовать сохраненные хеши с сервера для доступа к чьей-либо учетной записи (в катастрофическом сценарии, где кто-то получит такой доступ к базе данных, конечно).
Так, наша идея состояла в том, чтобы закодировать пароль на клиенте однажды через hmac, отправить его на сервер, и туда закодировать его во второй раз через hmac и соответствовать ему против сохраненного, два раза hmac'ed пароль. Это гарантировало бы что:
- Клиент может сохранить пароль локально, не имея необходимость хранить его как простой текст
- Клиент может отправить пароль, не имея необходимость волноваться (слишком много) о других сетевых сторонах
- Сервер может сохранить пароль, не имея необходимость волноваться о ком-то крадущем его из сервера и использующий его для входа в систему.
Естественно, все другие вещи (сильные пароли, двойная соль, и т.д.) применяются также, но не действительно относятся к вопросу.
Фактический вопрос: это походит на серьезный дизайн безопасности? Мы пропускали какие-либо дефекты с выполнением вещей этот путь? Существует ли, возможно, шаблон безопасности для чего-то вроде этого?
Приложение: причина мы не хотим локально хранить пароль в простом тексте на клиенте, состоит в том, потому что столь же печальный, как это, многие люди все еще используют тот же пароль для многочисленных услуг, так получение 'реального' пароля было бы большим нарушением защиты для пользователя, чем получение его украденного хеша.
7 ответов
Как уже говорили другие, изолирование клиента и вашей системы на самом деле ничего вам не дает - первый хэш просто становится паролем.
Значение приходит, если (что вполне вероятно) клиент использует тот же пароль в других системах. В этом случае, если клиентский компьютер будет скомпрометирован, по крайней мере, ваша локальная копия его хешированного пароля не позволит злоумышленнику получить доступ к другим системам. Очевидно, что злоумышленник клиента теперь сможет получить доступ к вашему серверу - в конце концов, он получил пароль.
Злоумышленник, имеющий доступ к двойному хешированному значению на сервере, ничего им не купит, так как он не может отменить это, чтобы получить единственный хеш (то есть «пароль»). Конечно, если злоумышленник может прочитать вашу базу данных безопасности, тогда я подозреваю, что у него есть другие доступные векторы атаки :)
Кроме того, как сказал другой плакат, убедитесь, что вы используете соль в обоих хэшах. Без этого реверсирование хэшей может оказаться довольно простым, если пароли не надежны.
РЕДАКТИРОВАТЬ - на самом деле, подумав об этом, поскольку вы используете хеш в качестве пароля, вам действительно не нужно использовать соль на сервере. Ни в коем случае никто не сможет создать эффективную радужную таблицу :) Тем не менее, она все еще нужна на клиенте.
Я выбегаю за дверь, но тут пингнул "Скит", а со "Скитом" не шутят.
Вы заменяете пароль другим постоянным значением. Вы ничего не получаете, единственная безопасность, которую вы имеете, это то, что пароль в открытом виде не может быть обнаружен на клиентской машине.
Что вы делаете, так это обрабатываете HMAC (вы уверены, что имеете в виду HMAC? Если да, то откуда берется и где хранится ключ?) пароля как сам пароль - вы посылаете его с клиента на сервер, где он используется для аутентификации. Второй HMAC или хэширование бессмысленны - вы сравниваете с отправленным значением - это пароль под любым другим именем. Поэтому, как злоумышленнику, вместо того, чтобы украсть пароль, мне просто нужно украсть HMAC, хранящийся на машине клиента. Здесь ничего не выигрывается.
Оговорка: я не эксперт по безопасности. Я напишу blowdart, чтобы узнать, не хочет ли он присоединиться.
Если клиент просто хранит хэш и эффективно передает что-то только на основе хэша, то он эффективно хранит его в виде обычного текста. Единственное преимущество, которое дает первый хэш, заключается в том, что если они использовали тот же пароль на другой системе, то эта другая система не будет скомпрометирована, если хэш будет раскрыт.
Другими словами: если кто-то сможет получить хэш, хранящийся на сервере, это все, что ему нужно для входа в систему... как и при хранении обычного текста.
удар попал в самую точку - вы просто меняете секет на воровство, ничего не закрепляя. То, что вы пытаетесь воспроизвести, - это старый протокол аутентификации, название которого я не могу вспомнить. Вот как это работает:
После инициализации сервер получает ваш пароль, многократно хешированный n раз, представленный F n (pass). У клиента есть пароль и номер n.
Вы идете на аутентификацию и отправляете серверу F n-1 (pass) - то есть пароль хешируется n-1 раз. Сервер хеширует его еще раз, сравнивает его с F n (пройти), и если они совпадают, вы получаете доступ. Затем сервер заменяет F n (проходит) на F n-1 (проходит), и вы уменьшаете n.
В следующий раз, когда вы идете на аутентификацию, вы отправляете F n-2 (пройти), и процесс повторяется.
Давайте исследуем безопасность:
- MITM: в протокол не встроено сопротивление, вам придется разместить его внутри SSL.
- Атаки воспроизведения: они не работают, потому что сервер уменьшил количество итераций хеширования.
- Подслушивание: следующая аутентификация будет выполняться с использованием F n-1 (пройти).У вас есть F n (пас). Переход от F n (проход) к F n-1 (проход) по определению хэш-функции невозможен
- Владение сервером: вы не знаете пароль клиента, и вы не можете аутентифицироваться как они, потому что вам снова понадобится F n-1 (пройти), когда у вас есть только F n
- Владение клиентом: поскольку вы храните F n-1 (pass) (поэтому им не нужно вводить pass) - тогда владение клиентом позволит злоумышленнику войти в систему. Если вы сохраните только n, а не пароль, этого можно будет избежать, но вы явно хотите сохранить пароль.
Это то, чего вы пытаетесь достичь. Однако есть причина, по которой этот протокол не используется - это гигантская сука для синхронизации. Если клиент и сервер рассинхронизируются из-за полузавершенного шага, вы заблокированы. Любая встроенная в вас устойчивость к внешним воздействиям, вероятно, снизит безопасность при воспроизведении или подслушивании.
Я не совсем понимаю, что это дает вам по сравнению с хранением пароля локально в виде обычного текста.
Цель локального шифрования - предотвратить возможность отправки пароля хакером на ваш сервер. Однако если вы собираетесь пересылать зашифрованную форму... что ж, вы ничего не приобрели.
Вместо этого локальная машина должна хранить пароль в двустороннем зашифрованном формате. Это означает, что он может быть расшифрован. Что вы и делаете перед передачей. БД может хранить пароль в односторонне зашифрованном формате (даже используя отдельный механизм шифрования). Перед сравнением вы шифруете то, что получили, а затем проверяете.
Какое начальное хеширование пароля предназначено для достижения? Это защитит от обнаружения текстовой версии пароля. Это не помешает использованию этого хеш-значения для вычисления дважды хешированного значения.
Нет, это небезопасно. Хешированное значение фактически является паролем. Тот факт, что пароль был получен из чего-то другого, что пользователь считает паролем, не имеет значения. Это секретное значение, которое аутентифицирует пользователя, верно? По-моему, похоже на пароль.
Я думаю, что это зависит от утверждения: "Естественно, мы не хотим хранить их в текстовом виде, поэтому мы обрабатываем их локально, перед хранением и/или отправкой". Если система изменена таким образом, что хэш-пароль теперь имеет ту же силу, что и пароль, то с хэшированным паролем следует проявлять тот же уровень осторожности".