Безопасность JSON для Android

Я бы предложил использовать SSL даже после того, как вы приобрели токен. Наша компания занимается проектами с банками и безопасными данными, связанными со здоровьем, и мы обязаны использовать SSL даже после внедрения токена. Мы обнаружили, что производительность остается в разумных пределах даже после использования https.

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

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

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

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

MD5SUM или SHA1 следующее: сегодняшняя дата + некоторые знаки препинания + что-то уникальное о пользователе (возможно, электронная почта и т. д.). Это даст вам длинную строку, похожую на ajadfh28dfj2yadsfh28… Пока ваша сторона Android отправляет ее так же, как ее ожидает серверная сторона, и она уникальна для пользователей, для меня это было бы довольно безопасно.

Чтобы сделать это рекомендованным WCF/Microsoft способом, вы реализуете авторизацию WCF с использованием поставщика ролей.

Это включает в себя IPrincipal и внедрение вашего пользовательского принципала, у которого будут роли, загруженные из базы данных, LDAP и т. д.

Тогда любые методы WCF можно просто так оформить для авторизации:

[PrincipalPermission(SecurityAction.Demand, Role = "ADMIN")]
[PrincipalPermission(SecurityAction.Demand, Role = "OPERATOR")]
public void SomeServiceCall(string foo)
{
    // In your case this would be an AJAX endpoint, not a void method
}

Это защитит вызовы службы; вызывающему абоненту они даже не будут казаться существующими.

Отправные точки: http://msdn.microsoft.com/en-us/library/ff647040.aspx Microsoft предоставляет исходный код примера поставщика ролей.

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