У нас есть веб-приложение, которое предоставляет простой «универсальный Http-обработчик» (ASP.NET) для обеспечения простого способа получить сеанс для мобильного приложения.
Atm вся концепция / приложение находится в демо / альфа / тестовом состоянии - так что не поднимайте руки в ужасе ...:)
Я понял, что есть несколько проблем безопасности:
- Если мобильное устройство подключено к WLAN (так как необходимая процедура прослушивания довольно проста), вы можете просто прослушать запрос (чтобы получить значение для имени пользователя / пароля) и / или ответ (чтобы повторно использовать сеанс где-то еще )
- Мы могли бы добавить некоторое шифрование / дешифрование, но, поскольку мы находимся на Android, любой может распаковать файл
.apk и выполнить некоторый обратный инжиниринг, чтобы получить общий ключ (и соль)
- Мы могли бы использовать https: // ... но ... мне интересно, есть ли другой способ ... Еще одна причина, почему не стоит выбирать SSL: у нас нет ни одного веб-приложения, поэтому ... чем больше приложений, тем дороже это будет стоить ... и, как это типично для компаний, мы хотим сэкономить:)
Некоторые боковые узлы:
Поскольку мы планируем предоставить нашим клиентам возможность доступа к нашему веб-приложению (обработчик является лишь его частью) с помощью мобильного приложения, мы не очень хотим публиковать его на рынке ... Но, возможно, это изменится , Таким образом, план не включает «публичную раздачу» .apk.
Я уже провел некоторое исследование по вопросу «Как адаптировать ответ, чтобы его эффективно могло использовать только мобильное приложение» (например, Как защитить веб-службу .NET для использования приложением iPhone ).
Я считаю, что это должно быть более общей проблемой, о которой стоит подумать не только, если вы работаете на Android / Co ... Так что "Best Practice" может быть ограничен не только Android (у вас будет то же самое) сценарий на iphone или winforms тоже) - это больше о: как работать с удаленным компонентом для выполнения жизненно важных функций (например, login, db-access, ...)