Это хорошая стратегия безопасности?

Question

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

Цель состоит не в том, чтобы позволить неавторизованным приложениям использовать какой-либо метод (кроме «GetChallenge»). Для аутентификации пользователей существует другой механизм, который проверяет имя пользователя и пароль. Я фактически объединил их, но они служат разным целям):

Итак, вот что я делаю:
Я посылаю сеансовый ключ (ASP.NET) (для всех желающих прочитать. Сеанс ASP.NET состоит из 15 случайно сгенерированных байтов, он длится 20 минут, если не продлен, и ASP.NET не получит никакого запроса без него).
В моем методе SignIn, кроме имени пользователя и пароля (который может получить каждый, поскольку он является частью общедоступного сайта), я получаю третий параметр - ключ сеанса, хэшированный по алгоритму md5 с 6 байтами в виде соли.
И только если хеш правильный (я хэширую и сравниваю его на стороне сервера) - я позволяю пользователям входить в систему.
С этого момента в каждом методе я проверяю, вошел ли пользователь в систему.

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

Насколько сильна и эффективна эта стратегия безопасности?

Спасибо.

Answer 1

Обновлено на основании ваших правок и комментариев

Это довольно безопасно и очень похоже на подход, используемый Google, Facebook и другими для их ключей API. За исключением ...

Идентификатор сеанса: потенциальная проблема с открытым текстом Я бы не рекомендовал использовать идентификатор сессии как часть механизма безопасности.

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

Из Документов Microsoft :

SessionID передается между сервером и браузером в виде открытого текста, либо в файле cookie, либо в URL. В результате нежелательный источник может получить доступ к сеансу другого пользователя, получив значение SessionID и включив его в запросы к серверу. Если вы храните личную или конфиденциальную информацию в состоянии сеанса, рекомендуется использовать SSL для шифрования любого обмена данными между браузером и сервером, который включает SessionID.

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

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

Рекомендуемое изменение

Следуйте более внимательно модели, используемой Google и тому подобное. Создайте новый GUID для каждого приложения, сохраните GUID в базе данных на сервере, передайте GUID в каждом запросе на сервер от клиента.

Benfits:

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

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

Answer 2

То, как вы это описываете, совсем не кажется безопасным.

Какой смысл позволять методу SignIn принимать хешированный ключ сеанса, если ключ сеанса является открытым («для всех, чтобы читать»)?

Плюс: «в каждом методе я проверяю, вошел ли пользователь в систему». Как это проверить?

Распространенной (и достаточно безопасной) стратегией будет генерирование (уникального, достаточно длинного и случайного) идентификатора сеанса на стороне сервера и отправка его клиенту после его аутентификации. Затем проверьте каждый клиентский запрос и принимайте его, только если он содержит идентификатор сеанса. Для этого либо вставьте идентификатор во все ссылки на каждой странице, либо установите его в виде файла cookie, в зависимости от того, что для вас проще. При выходе из системы просто удалите идентификатор сеанса на сервере.

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

Answer 3

С точки зрения веб-сервисов идеальный способ использования аутентификации или обеспечения безопасности вашего сервиса выглядит примерно так: Аутентификация веб-службы (хеширование токена и MD5 для шифрования пароля).

Answer 4

Цель шифрования - не позволить неавторизованным приложениям использовать какой-либо метод

Неверно.Целью шифрования является предотвращение понимания данных во время их передачи или хранения.Он предотвращает возможность использования данных теми, у кого нет средств для их расшифровки.

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

У вас НЕТ аутентификации, кроме имени пользователя и пароля.Также ваши данные не зашифрованы во время транспортировки.Я не вижу, как это вообще безопасно.

Я думаю, что вам лучше всего использовать SSL-сертификат (поэтому ваш веб-сервис работает по HTTPS) вместе с именем пользователя и паролем.Если вы хотите быть вдвойне защищенным, вы можете пойти по пути проверки диапазонов IP-адресов источника и местоположений входа в систему в качестве дополнительной проверки.Возможно, интервал принудительной смены пароля поможет в случае, если потребители передают учетные данные третьей стороне + аудит, как на самом деле используется веб-служба.

Как примечание, если вы хотите что-то хэшировать, неиспользуйте MD5, его сломано .