Мобильный банкинг: мы знаем, как сделать ваше приложение безопасным!

Сфера e-commerce переживает настоящий подъём по всему миру. В частности, одной из самых востребованных сфер электронной коммерции является мобильный банкинг. В последнее время он получил ещё большую актуальность и значимость. Сейчас практически каждый является клиентом какого-либо банка, а приложение даёт возможность совершить абсолютно любую финансовую операцию, не выходя из дома.

Однако «больным» местом любого банковского приложения является вопрос его безопасности. Чтобы сделать мобильный банкинг максимально безопасным, мы придерживаемся обязательных ключевых параметров, о которых расскажем в данной статье.

Архитектура

Необходимо помнить, что безопасность должна реализуется на всех этапах жизненного цикла разработки ПО. Существуют определённые политики применения криптографических ключей и жизненного цикла. В идеале при разработке должны использоваться стандарты типа NIST SP 800-53.

Хранение данных

Конфиденциальная информация не должна быть записана в журнал приложений и показываться посредством UI, а также копироваться в бэкап. Подобная информация не должна храниться локально на мобильном устройстве. Данные должны извлекаться из удалённой конечной точки, когда это необходимо, и храниться только в памяти. Если данные необходимо хранить локально, их необходимо зашифровать с помощью ключа, полученного из хранилища, требующего аутентификацию.

Криптография

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

Аутентификация

Если приложение предоставляет пользователям доступ к удалённому серверу, на удалённой конечной точке выполняется форма аутентификации. Например, по имени пользователя или паролю. При использовании управления сеансами с сохранением состояния, удалённая конечная точка должна использовать случайно сгенерированные идентификаторы сеансов для аутентификации клиентских запросов без отправки пользовательских ID. Если используется аутентификация на основе токенов без сохранения состояния, сервер предоставляет токен, записанный с помощью безопасного алгоритма.

Пользовательское взаимодействие

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

Безусловно, наличие двухфакторной аутентификации является обязательным компонентом, чтобы сделать банковское приложение безопасным. Лишь после прохождения второго фактора пользователь сможет зайти в приложение. Второй фактор аутентификации должен реализовываться на удалённой конечной точке. При этом длина кода второго фактора (SMS) должна быть 6 и более символов.

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

Тестирование и поддержка

Необходимо использовать SAST инструменты или Composition Analysis Tools в процессе CI/CD. Инструменты статического анализа защищённости дают возможность улучшить безопасность тестируемого приложения и уменьшить влияние дефектов на его жизненный цикл. Рекомендуется подписывать SLA (Соглашение об уровне сервиса) для возможности исправления проблем в области безопасности. Данный документ определяет все права и обязанности клиента и исполнителя.

Аудит безопасности для платформы iOS

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

• Реализация безопасности на уровне API в iOS приложении должна включать в себя проверку SSL-сертификатов на наличие критичной информации (внутренние адреса, домены сервисов, тестовые стенды и т.д.). Также в приложении должны быть внедрены механизмы шифрования трафика HTTP-соединения на основании протокола TLS. Настройки TLS должны соответствовать текущим рекомендациям или быть максимально приближены к ним, если мобильная ОС не поддерживает рекомендуемые стандарты. Приложение должно проверять сертификат X. 509 удалённой конечной точки при установке защищенного канала. Принимаются только сертификаты, подписанные доверенным центром сертификации.

• Использование KeyChain для хранения критичной информации (логин-пароль, данные кредитной карты и т.д.). Эта технология позволяет сохранять учётные данные на операционных системах macOS и iOS в защищённом виде.

• В NSUserDefaults должны размещаться только неключевые настройки приложения (настройка языка, часового пояса, раскладка клавиатуры и пр.).

• Также необходимо освобождать память, выделенную под хранение критичных данных.

• Каждый раз должно быть предусмотрено полное завершение сессии приложения. После завершения сессии вся клиентская информация с устройства должна удаляться (Cookie, Keychain и пр.)

Аудит безопасности для платформы Android

• В настройках резервного копирования указывается, какая именно информация должна попадать в Google Cloud.

• Использование KeyStore для хранения критичной информации (логин-пароль, данные кредитной карты и т.д.).

• Предусмотрено полное завершение сессии приложения.

• После завершения сессии вся клиентская информация с устройства должна удаляться (Cookie, KeyStore и пр.).

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

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

Поэтому если вы хотите сделать ваше приложение и мобильный банкинг качественным и безопасным, пишите нам прямо сейчас и расскажите о своём проекте!