Какова лучшая модель для отключения аутентификации пользователей?

Question

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

Например, если я развернул на мобильном устройстве без доступа к Интернету, какой самый безопасный способ обработки аутентификации?

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

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

Каковы мои лучшие варианты и соображения?

Answer 1

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

Насколько я понимаю, у вас есть некоторая конфиденциальная информация, которую вы хотите синхронизировать между мобильным устройством с прерывистой связью и некоторым удаленным сервисом. Услуга доступна только для аутентифицированных пользователей, и пользователи должны аутентифицировать себя на мобильном устройстве, чтобы получить доступ к его копии информации, даже если она находится в автономном режиме.

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

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

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

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

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

Однако, если злоумышленник может увидеть хэш пароля, что мешает ему также посмотреть синхронизированные данные? Зачем им нужно восстанавливать пароль? Шифрование мобильной базы данных предотвратит это.

Answer 2

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

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

Answer 3

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

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

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

3. Сервер отправляет токен авторизации, зашифрованный открытым ключом этого пользователя.

4. Клиент отправляет обратно токен, расшифрованный его личным ключом.

5. Сервер наконец отправляет токен сеанса для продолжения дальнейших соединений (этот последний шаг может быть ненужным, может быть, можно использовать уже установленный токен аутентификации?).

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

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