Безопасность данных в разработке мобильных приложений

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

Безопасность данных в разработке мобильных приложений

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

Безопасность данных в разработке мобильных приложений

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

Безопасность данных в разработке мобильных приложений

Познавательно, спасибо! Поправил в статье этот пункт.

Безопасность данных в разработке мобильных приложений

Вариантов несколько. Первый и самый простой — соль генерируется случайно на клиенте, одноразово используется для засолки пароля при хешировании, и этот хеш идет на сервер. А серверу все равно, какая была соль, потому что ему не требуется эти данные расшифровывать, его задача — лишь сравнение, так что ему эта соль не нужна, ее клиент использует 1 раз и уничтожит. Либо второй вариант — да, применять пересылку соли и/или публичного ключа. Здесь уже нет смысла в дополнительной генерации чисел, если соль сама по себе создается серваком на основе генератора псевдослучайных чисел. Проблема тут в том, что если каким-то образом сетевой канал будет вскрыт, то и соль будет обнаружена. Однако только такой способ и получится применить, если требуется расшифровка данных на стороне сервера, тут никуда не денешься. С асимметричными там поинтереснее, перебрасываться можно хешами и, если надо, публичными ключами, но приватные ключи тогда нужно куда-то зашивать — тут уже начинаются проблемы рутованных устройств и хранения/защиты приватных ключей на устройстве/сервере.

Безопасность данных в разработке мобильных приложений

Согласен с вами. Хотя, даже имея под рукой отладчик, если по мобильному приложению гоняются только хеши (т.е. отсутствует сама процедура расшифровки) — взломщик через отладку получит пользу только в виде изучения алгоритма, а это уже требует приличной квалификации атакующего. Запрещать работу на рутованных устройствах — хороший подход, только лично я пока не находил методов по 100%-му определению факта, что устройство взломано, по крайней мере, на iOS.

Безопасность данных в разработке мобильных приложений

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

Безопасность данных в разработке мобильных приложений

Для улучшения читаемости перевел все таблицы на вложенные списки.

Безопасность данных в разработке мобильных приложений

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

Безопасность данных в разработке мобильных приложений

К сожалению, перевод Markdown-разметки поломался при перемещении из моего редактора, пока никак не получается сделать нормальные таблицы. Пока бьюсь над этим.

Архитектура сетевого ядра в iOS-приложении на Swift 3. Часть 1

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

Архитектура сетевого ядра в iOS-приложении на Swift 3. Часть 1

любопытно. А на основе чего генерите рефреш токен? Безопасно ли его хранение в приложении, если он статический?

Архитектура сетевого ядра в iOS-приложении на Swift 3. Часть 1

А))) Тогда понятно. В данном случае я не стал использовать прослойку, во-первых, для упрощения кода и упрощения объяснений, а во-вторых, потому что и стандартного URLSession нам будет более, чем достаточно, да и реализуется он очень быстро)) В реальном проекте, конечно, зачастую предпочтительнее использовать специализированное решение.

Архитектура сетевого ядра в iOS-приложении на Swift 3. Часть 1

Совершенно согласен, и поскольку в нашем случае в состав входят далеко не value-типы, я предпочел не пользоваться структурами) Так-то верно, при использовании value-типов структуры становятся куда более оптимальным решением.

Архитектура сетевого ядра в iOS-приложении на Swift 3. Часть 1

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

Архитектура сетевого ядра в iOS-приложении на Swift 3. Часть 1

Это НЕ альтернатива AFNetworking. Смысл решения из статьи совершенно другой.

Архитектура сетевого ядра в iOS-приложении на Swift 3. Часть 1

Не совсем проще. Так и происходит в проектах, как правило, и за неимением толковой структуры это обычно превращается в мусорку (сколько я успел понаблюдать).

Архитектура сетевого ядра в iOS-приложении на Swift 3. Часть 1

Я уже занимаюсь второй частью. Там я расскажу о практическом применении созданной архитектуры.

Архитектура сетевого ядра в iOS-приложении на Swift 3. Часть 1

Супер! Определенно нужно посмотреть)

Архитектура сетевого ядра в iOS-приложении на Swift 3. Часть 1

Вот это уже значительно больше похоже на то, чего я пытаюсь добиться с помощью описываемого способа) Очень любопытно, спасибо! Изучу, как только его обновят до третьей версии языка, пока что, опять-таки, не получится им воспользоваться в моих проектах. Но реализация прямо похожа на то, что нужно. Благодарю!