поток для отправки зашифрованного пароля с мобильных устройств на сервер

Question

Мне хотелось бы получить некоторые мнения о потоке, который я создаю для любого мобильного приложения, которому необходимо отправить комбинацию пользователя и пароля. Моя идея - зашифровать пароль с помощью AES-256, генерируя случайную кодовую фразу и IV, чтобы сгенерировать ключ. Идея заключается в том, что при первом создании пароля он отправляет на сервер зашифрованный пароль и IV. IV и зашифрованный пароль будут храниться на сервере, в redis DB и ключ, а зашифрованный пароль будет только на мобильном устройстве (IV не будет сохранен на устройстве). Таким образом, каждый раз, когда пользователю нужно входить в систему, отправляет на сервер, зашифрованный пароль и ключ, с сохраненным IV, сервер расшифровывает как зашифрованный пароль, так и тот, который сохраняется в БД, используя только что отправленный ключ и IV уже на сервере.

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

Все эти транзакции будут проходить внутри туннелирования SSL.

Считаете ли вы, что это безопасно? если не почему? любой другой вариант шифрования/дешифрования паролей безопасным способом с мобильного устройства на сервер?

С уважением.

Answer 1

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

KDFs (pbkdf2, scrypt, bcrypt), которые я перечислял ранее, занимает много времени, поэтому вы, вероятно, не хотите делать это на клиенте, а затем на сервере, если безопасность не важнее, чем обычно. KDF используется для предотвращения компрометации пароля с хеша. Это означает, что если ваша таблица, хранящая хеши пользователей, скомпрометирована, простой текст вашего пароля пользователя по-прежнему безопасен. Если, например, вы делаете KDF на клиенте и говорите, что на сервере имеется только соленый MD5 из KDF, то пароль пользователя с открытым текстом будет безопасным, но может быть легко для тех, кто смог получить доступ к сохраненный хэш (что означает, что сервер скомпрометирован) для входа в систему в качестве этого пользователя. Если ваш сайт/приложение является stackoverflow, может быть неважно, если учетная запись пользователя будет скомпрометирована, если сам сервер уже скомпрометирован. С другой стороны, если вы являетесь paypal, кто-то, кто получает доступ к учетной записи, может получить доступ к банковскому счету пользователей, который они не смогут сделать, просто получив доступ к хеш-таблице. В этом случае оптимальным будет выполнение KDF как на клиенте, так и на сервере.

Что касается использования SSL, это хорошо, если у вас есть метод проверки того, что сервер на самом деле является вашим сервером, и MITM не происходит. Если кто-либо из них скомпрометирован, то отправка пароля в виде обычного текста позволит злоумышленнику получить доступ к текстовому паролю