Приложение тянет данные с сайта?

Question

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

В настоящее время моя аутентификация состоит из:

• Чтобы запустить приложение, пользователь должен ввести свое имя пользователя и пароль (без действительного пользователя и пропустить приложение не работает)и нажмите «Войти».
• Учетные данные будут отправлены на мою страницу входа с использованием HTTPS , сценарий принимает только SSL-соединение и персональное имя агента пользователя.
• ЛогинСтраница проверит учетные данные и отправит обратно сеанс и некоторые исходные данные.
• Сеанс используется повторно для сбора дополнительных данных во времени или по мере необходимости.

Примечание: SSL - 256 бит, срок действия сеанса автоматически истекает через несколько минут

Для вышеуказанной базовой аутентификацииd извлечение данных вы бы порекомендовали мне что-нибудь еще для реализации?

Должен ли я что-то изменить?

2-й уровень защиты

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

• Что я должен использовать для шифрования и дешифрования данных, пара закрытых и открытых ключей, хранящихся наобе стороны или метод RIJNDAEL?

• Как правильно или какие части информации я должен оставить на клиенте и сервере или как мне сформировать знание общих паролей или ключей?

  Например, если бы я использовал пару ключей RSA, мне нужно было бы оставить 1 закрытый ключ на клиенте и 1 открытый ключ, поскольку вы не можете расшифровать любые данные с помощью открытого ключа на c #, в то время как вы можете сделать это на сервереа для Рейндаэля понадобится IV и ключ с обеих сторон.

  Как правильно обращаться с ними?

Iбудет Vочень доволен практическим материалом для чтения, комментариями, примерами, предложениями, советами:)

ОБНОВЛЕНИЕ:

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

Answer 1

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

Когда я смотрю на безопасность, я всегда смотрю на две вещи:

• Транспортная безопасность - защищены ли ваши данные во время транспортировки? Звучит так, будто вы используете достаточную длину ключа для сертификата SSL на сервере. Кроме того, вы можете заставить веб-сайт выполнять проверку сертификата клиента как часть SSL-подтверждения связи. Это гарантирует, что никто не сможет подделать клиентское приложение и убедить ваш сайт поделиться информацией.
• Безопасность полезных данных - следует ли шифровать полезные данные? Есть ли вероятность, что кто-то сможет взломать ваш веб-сервер или, что еще лучше, с помощью отравления DNS или каким-либо другим способом убедить ваше приложение подключиться к вредоносному серверу с действительным (для этого cn), но другим сертификатом HTTPs ? Если вы решите зашифровать полезную нагрузку, вы можете привязать все это к тем же сертификатам, которые вы уже используете. Просто убедитесь, что в сертификатах включены биты шифрования данных, и вы можете использовать закрытые / открытые ключи из сертификатов для шифрования полезной нагрузки. Таким образом, если злонамеренный пользователь заменил сертификат, он не только должен подделать cn и цепочку доверия, но также имеет правильный открытый ключ из приложения для дешифрования данных, которые вы шифруете с помощью своего личного ключа и подписываете с помощью сервера. открытый ключ.

Некоторые другие вопросы для размышления:

1. Вы говорите, что сеанс используется повторно? Не истекает ли это? Если нет, вы бы хотели, чтобы срок его действия истек.
2. Можете ли вы использовать сетевую безопасность? Можете ли вы использовать VPN-туннель или IP ACL для ограничения того, кто может даже получить доступ к веб-серверу?
3. А как насчет клавиатурных шпионов? Пароли могут быть перехвачены. Вторым фактором аутентификации может быть что-то, что есть у пользователя, например, карточка с ключом или отпечаток пальца, или RSA SecurId. Если вы не хотите заходить так далеко, вы можете подарить пользователю «печать сайта» - изображение, которое он должен распознать как связанный с его учетной записью. Может быть, даже представить несколько изображений и позволить им выбрать тот, который они выбрали в процессе регистрации. Вы также можете заставить их решить небольшую головоломку, которая будет отличать человека от машины (типа CAPTCHA).

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

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

Помните, что все стоит. Безопасность стоит юзабилити и циклов процессора. Правильный баланс является ключевым, но это, конечно, зависит от вас. Прежде чем строить Форт Нокс, убедитесь, что кто-то захочет там жить:)