Блог

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

Я использую базовую хэш-функцию с солью, например:

 String pass = BCrypt.hashpw(rawPass, BCrypt.gensalt());
  

Я заметил зависание на одну-две минуты при регистрации и проверил отладчик, подтвердив, что за это отвечает BCrypt.

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

Вот статья, в которой перечислены времена, проведенные на ноутбуке Mac с процессором Core 2 Duo. Итак, да, Bcrypt, вероятно, будет очень медленным на мобильном устройстве.

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

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

Хеширование паролей — это средство предотвращения получения доступа злоумышленником (или, по крайней мере, замедления их), если само хранилище паролей будет скомпрометировано.

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