Реализация входа в систему для Windows Mobile - PullRequest
0 голосов
/ 19 мая 2010

Что является хорошим подходом для проверки учетных данных для приложения для Windows Mobile. Зная, что это время от времени подключенное устройство.

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

Если оба не удаются, отобразить сообщение об ошибке?

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

Это хороший подход?

Ответы [ 2 ]

2 голосов
/ 19 мая 2010

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

  • Как вы будете хранить локальные учетные данные? MD5 хеш или что-то еще?
  • Вы аутентифицируетесь на чем-то похожем на сервер, где кредит должен быть NTLM, или вы просто делаете аутентификацию локального приложения?
  • Если пользователь теряет устройство, а кто-то другой находит его, как это влияет на ваши процедуры аутентификации?
  • Как они получают самую первую авторизацию, если у них нет сети?
  • Насколько безопасен ваш веб-сервис? Это вообще имеет значение?

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

1 голос
/ 20 мая 2010

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

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

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

Кстати, есть и другие вещи. Устройство подключено часто или действительно редко? Много ли разных пользователей входят в систему, когда соединение недоступно? Ответы на такие вопросы могут привести к единой реализации входа в систему.

...