Android Authenticator ХРАНИТ КРИПТОГРАФИЧЕСКИ ЗАЩИЩЕННЫЙ ТОКЕН

Я аутентифицируюсь с помощью CSR губчатого замка PKCS10CertificationRequest в центре сертификации RESTful. Я рассматриваю возможность использования Android Authenticator.

Согласно: https://stuff.mit.edu/afs/sipb/project/android/docs/training/id-auth/custom_auth.html#Security

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

Имея это в виду, вы не должны передавать фактический пароль пользователя в AccountManager.addAccountExplicitly(). Вместо этого вы должны ХРАНИТЬ КРИПТОГРАФИЧЕСКИ ЗАЩИЩЕННЫЙ ТОКЕН, который будет иметь ограниченное применение для злоумышленника.

Мои вопросы: я не уверен, что имеется в виду под ХРАНЕНИЕМ КРИПТОГРАФИЧЕСКИ ЗАЩИЩЕННОГО ТОКЕНА в этом контексте. Как выглядит этот токен (его тип?) в Android Java? И где его хранить? в брелке?? Используется ли этот токен в каком-либо другом контексте, кроме pw в addAccountExplicitly()?


android csr authenticator spongycastle
person JDOaktown    schedule 29.03.2016    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Если ваше устройство имеет широкие возможности ввода (поэтому пользователь может вводить имя пользователя\пароль), вы можете рассмотреть возможность использования чего-то вроде JWT auth . В этом случае ваше приложение никогда не хранит фактический пароль пользователя, а отправляет его на сервер только один раз за сеанс аутентификации и возвращает JWT (веб-токен JSON). Это токен с некоторой информацией (например, со ссылкой на пользовательский ресурс — id или uuid) и параметром TTL, надежно подписанный секретным ключом. Этот секретный ключ хранится только на сервере, поэтому никто за пределами вашего сервера не может сгенерировать действительный токен.

Таким образом, после запроса аутентификации вы сохраняете JWT локально и используете его в заголовке «Авторизация» или в качестве поля запроса (первый вариант лучше, потому что тело запроса может отображаться в журналах) с каждым запросом API. Вы должны обновить этот токен до истечения срока его действия, а если он истек, то попросить пользователя снова ввести свои учетные данные. Со стороны сервера вы получаете запрос, проверяете токен (подписан ли он секретным ключом сервера и не истек ли срок его действия?) и в случае действительного токена обслуживаете запрос. Вам даже не нужно хранить токены на сервере, но вы можете сделать это, если хотите больше контролировать аутентификацию — например, если вы хотите отозвать токены из-за пределов рабочего процесса приложения.

На сайте JWT есть список с множеством библиотек для JWT для разных языков. Например, для использования с Elixir\Phoenix вы можете использовать Guardian. Со стороны Android в простом случае вам даже не нужно иметь специальные инструменты для работы с JWT — просто поместите токен в виде простой текстовой строки в заголовок «Авторизация» и отправьте запрос на сервер. Но если вы хотите получить (декодировать) информацию, которую ваш сервер поместил в токен со стороны приложения, или проверить время истечения срока действия токена, вам нужно будет использовать одну из библиотек, представленных на сайте jwt.

person heathen    schedule 19.05.2016