Какова лучшая модель для того, чтобы вывести аутентификацию пользователя из эксплуатации?
Самый ранний и последний срок?
Select meme_altid, Min(meme_eff) As eff, Max(meme_trm) As term From #tbl
Group By meme_altid
3 ответа
Если Вы объясняете свое приложение более подробно, я мог бы найти, что я от основы здесь, но на данный момент я сделаю некоторые предположения о Вашем варианте использования и модели угрозы.
Мое понимание - то, что у Вас есть некоторая уязвимая информация, которую Вы хотите синхронизировать между мобильным устройством с неустойчивой возможностью соединения и некоторым удаленным сервисом. Сервис только доступен для аутентифицируемых пользователей, и пользователи должны аутентифицировать себя на мобильном устройстве для доступа к его копии информации, даже если это в режиме офлайн.
Если Вы хотите сильную безопасность, шифруете копию мобильного устройства с помощью основанного на пароле шифрования.
Вы могли использовать тот же пароль, используемый для аутентификации к сервису, но в целом, я постараюсь не снова использовать тот же ключ в различных целях. Лучший подход должен был бы иметь основной пароль шифрования для мобильного устройства, которое шифрует мобильную базу данных, а также "пароль" раньше аутентифицировал пользователя в сервисе синхронизации. Обратите внимание, что сервисный пароль аутентификации мог на самом деле быть закрытым ключом для аутентификации клиентского сертификата SSL или символьно-ориентированным паролем.
Необходимо будет оценить риск наличия всего одного пароля, но во многих случаях, я думаю удобство, которое это предлагает пользователю, объединенный с безопасностью, обеспеченной одним сильным основным паролем в противоположность двум weak-but-easily-remembered паролям, хороший баланс.
Обратите внимание, что этот подход позволит пользователю, сервисный доступ которого был отклонен, чтобы продолжить получать доступ к их локальной копии, но без любых новых обновлений. Вы могли включать некоторое понятие ограничения по времени, которое будет осуществлено мобильным программным обеспечением, но решительный взломщик мог обойти это.
Если Вам просто нужна игрушечная безопасность, Ваше предложение хранения корректного хеша на мобильном устройстве соответствует, и действительно не имеет значения, хешируете ли Вы действительный пароль или альтернативу, потому что при использовании правильного хеша им должны потребоваться несколько миллиардов лет для нахождения коллизии пароля, которая позволила бы им получать доступ к удаленному сервису.
Однако принятие взломщика видит хэш пароля, что мешает им смотреть на синхронизировавшие данные также? Почему они должны были бы восстановить пароль? Шифрование мобильной базы данных предотвратило бы это.
Я предполагаю, что это может зависеть от Вашей проблемной области, но для защищенного приложения, авторизация не может быть сделанной стороной клиента из-за отсутствия доверия. В простом случае Вы заявили, где вычисление хеша и сравнение являются сделанной стороной клиента, все, что кто-то должен был бы сделать для получения, доступ, поднимают трубку отладчик, шаг через код и находят, где сравнение сделано, и замените значение на стеке непосредственно перед возвратом (например). Поздравления, Вы были взломаны.
Я хотел бы знать больше информации о том, какие операции Ваше определенное приложение захочет включить, когда в "офлайновом" режиме, и чем Ваш план был бы для согласования, после того как устройство было повторно подключено, прежде чем я посмотрю на добавление частичной функциональности офлайн.
Я отправил подобный вопрос только несколько минут назад, и еще после некоторых взглядов, я, возможно, нашел приемлемый подход, с помощью общественности/закрытых ключей. Вот шаги, которые я обрисовал в общих чертах для своего приложения:
Когда пользователь идет офлайн, он может принять решение использовать пароль для обеспечения доступа к приложению в то время как офлайн (с дополнительным шифрованием для защиты от воровства).
После движения онлайн, клиент отправит идентификатор за текущим пользователем (оно могло быть похожим на хеш или что-то, что однозначно определяет того пользователя).
Сервер отправляет маркер авторизации, зашифрованный с открытым ключом того пользователя.
Клиент передает обратно маркер, дешифрованный с его закрытым ключом.
Сервер наконец отправляет маркер сессии для продолжения дальнейшей связи (этот последний шаг мог бы быть ненужным, возможно, уже установленный подлинный маркер может использоваться?).
Я не эксперт по шифрованию или безопасности, но это казалось бы мне, этот подход очень безопасен, как единственный способ, которым я могу думать для взламывания сервер, состоял бы в том, чтобы у взломщика был закрытый ключ пользователя наряду с его паролем.
В случае уязвимых данных это может быть защищено шифрованием, как я упомянул, или паролем только для аутентификации пользователя, или с самими данными, зашифрованными поэтому в случае, если устройство теряется, это не поставлено под угрозу.