Сохранение пользовательского API-интерфейса SHA в db

Question

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

В заголовке каждого запроса, сделанного на сервере я поставил:

"key": username 
"sign": (SHA256 of post_parameters using API secret) 

Сервер принимает post_parameters и SHA256, используя уникальный API тайну имени пользователя, отмечаемые в дб. Если результат совпадает с «знаком», то доступ предоставляется.

Мой вопрос заключается в следующем:

Как сохранить уникальный API секрет каждого пользователя безопасности на сервере БД? Если кто-то получает доступ к именам пользователей и их секретам API, он полностью контролирует учетную запись пользователя.

Answer 1

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

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

salt_value H(salt_value . secret) 

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

Для сверхсовременной безопасности вы также можете использовать хэш повторно. Вместо того, чтобы хранить

H(salt_value . secret) 

хранить

H(H(H(H(...H(salt_value . secret) ...)))) 

т.е. вы хэширования его большое число раз (скажем, 10000 раз). Когда пользователь входит в систему, хешируйте соль и секрет повторно, а затем сравните конечный результат с сохраненным значением. Это еще более безопасно, потому что требуется много времени для установки атаки с использованием грубой силы: злоумышленнику придется вычислить 10 000 хэшей, чтобы попытаться разобраться в тайне.