Двойные пароли хеширования - клиент и сервер

Question

Эй, во-первых, позвольте мне сказать, я не спрашиваю о таких вещах, как md5 (md5 (..., уже есть темы по этому поводу.

Мой вопрос такой:

Мы разрешаем нашим клиентам хранить свои пароли локально. Естественно, мы не хотим, чтобы они сохранялись в тексте плана, поэтому мы создаем их локально, перед сохранением и / или отправкой. Теперь это нормально, но если это все, что мы сделалитогда на сервере будет сохранен hmac, и поскольку клиенту нужно только отправить hmac, а не пароль в виде простого текста, злоумышленник может использовать сохраненные хэши с сервера для доступа к чьей-либо учетной записи (в катастрофическом сценарии, когда кто-то получиттакой доступ к базе данных, конечно).

Итак, наша идея заключалась в том, чтобы один раз зашифровать пароль на клиенте через hmac, отправить его на сервер, а затем еще раз зашифровать его через hmac и сопоставитьэто против сохраненного, два раза hmac'ed пароля. Это гарантирует, что:

• Клиент может хранить пароль локально, не сохраняя его как обычный текстt
• Клиент может отправить пароль, не беспокоясь (слишком сильно) о других участниках сети
• Сервер может хранить пароль, не беспокоясь о том, что кто-то украл его с сервера и использовалэто для входа в систему.

Естественно, все остальные вещи (надежные пароли, двойная соль и т. д.) также применимы, но на самом деле не имеют отношения к вопросу.

актуальный вопрос: это звучит как надежный дизайн безопасности?Мы упустили из виду какие-либо недостатки в работе таким образом?Может быть есть шаблон безопасности для чего-то подобного?

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

Answer 1

Я выбегаю за дверь, но Скит пингуется, и вы не связываетесь со Скитом.

То, что вы делаете, это замена пароля другим постоянным значением.Здесь вы ничего не получаете, единственное, что у вас есть, - это то, что простой текстовый пароль не может быть обнаружен на клиентском компьютере.

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

Answer 2

Как уже говорили другие, принимая клиента и вашу систему в отдельности, это на самом деле ничего не покупает - первый хеш просто становится паролем.

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

Злоумышленник имеет доступ к значению двойного хэширования на сервере.не купит им ничего, поскольку они не могут отменить это, чтобы получить единственный хеш (т. е. «пароль»).Конечно, если злоумышленник может прочитать вашу базу данных по безопасности, то я подозреваю, что у него есть другие доступные векторы атак:)

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

РЕДАКТИРОВАТЬ - на самом деле, думая об этом, поскольку вы используете хеш в качестве пароля, который вам на самом деле не нуженсоль на сервере.Никто не сможет создать эффективный радужный стол :) Хотя он все еще нужен клиенту.

Answer 3

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

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

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

Answer 4

Нет, это не безопасно. Хешированное значение - это пароль. Тот факт, что пароль был получен из чего-то другого, что пользователь считает паролем , не имеет значения. Это секретная ценность, которая аутентифицирует пользователя, верно? Звучит как пароль для меня.

Я думаю, что это зависит от утверждения: «Естественно, мы не хотим, чтобы они сохранялись в тексте плана, поэтому мы делаем их локально, перед сохранением и / или отправкой». Если система изменена таким образом, что хэш-пароль теперь имеет ту же мощность, что и пароль, который использовался ранее, следует использовать тот же уровень осторожности с хешированным паролем.

Answer 5

Ударная волна попала в ноготь на голове - вы просто меняете сецет на кражу, ничего не обеспечивая.То, что вы пытаетесь воспроизвести, - это старый протокол аутентификации, который я не могу вспомнить, как его имя.Вот как это работает:

После инициализации сервер получает ваш пароль, итеративно хешированный n раз, представленный как F _n (проход).У клиента есть пароль и номер n.

Вы идете для аутентификации и отправляете на сервер F _n-1 (pass) - то есть пароль хэшируется n-1 раз,Сервер хеширует его еще раз, сравнивает его с F _n (pass) и, если они совпадают, вы получаете доступ.Затем сервер заменяет F _n (проход) на F _n-1 (проход), и вы уменьшаете значение n.

В следующий раз, когда вы отправляетесь для аутентификации, вы отправляете F _n-2 (проход) и процесс повторяется.

Давайте рассмотрим безопасность:

• MITM: в протокол не встроено сопротивление, вам нужноСлои внутри SSL
• Атаки воспроизведения: они не работают, потому что сервер уменьшил количество итераций хеша.
• Подслушивание: следующая аутентификация будет выполняться с использованием F _n-1 (проход).У вас есть F _n (пасс).Переход от F _n (передача) к F _n-1 (передача) по определению хэш-функции невозможен
• Владение сервером: вы неВы не можете знать пароль клиента, и вы не можете аутентифицироваться под ним, потому что вам снова понадобится F _n-1 (pass), если у вас есть только F _n
• Owningклиент: так как вы храните F _n-1 (проход) (чтобы им не нужно было вводить проход), то владение клиентом позволит злоумышленнику войти в систему.Если вы сохраните только n, а не пароль, это будет предотвращено, но вы явно захотите сохранить пароль.

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

Answer 6

Какое первоначальное хеширование пароля предназначено для достижения? Это защитит от обнаружения текстовой версии пароля. Это не помешает использованию этого хеш-значения для вычисления двоякого хеш-значения.

Answer 7

Я не совсем уверен, что это покупает вас, если вы храните пароль локально в открытом тексте.

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

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