A
херовый бай дизайн
Size: a a a
2020 April 15
A
но решение я придумал
NK
херовый бай дизайн
Ну почему? Взлом простой - добавляешь свой отпечаток и входишь в любое приложение
A
это всё хорошо, только никак не коррелирует с жц приложения.
A
но всё же лучше, чем раньше (когда приходилось костылять поля ввода пароля и расшифровывать с помощью действий пользователя)
СП
ещё пугают фантомные сбросы кейстора при смене отпечатка пальца (или кода)
Ну...мы необязаны же привязывать код к пальцу, это факультативная вещь.
А при смене юзера префы очевидно у нового д.б. свои
А при смене юзера префы очевидно у нового д.б. свои
A
очевидно должны быть свои при смене юзера, но абсолютно плоха ситуация, когда человек ехал в метро (или находился в другом публичном месте), разблокировал телефон загагулинкой, понял, что светанул его, пошёл менять, и поломал приложения завязанные на кейстор
A
вообще когда копал эту тему глубоко, я был сильно удивлён вопиющему "болтокладству" на безопасность в андроиде апи эдак аж до 19го. Просто шок
СП
Да куча людей и пин не ставят, неудобно, заебывает вводить
СМ
очевидно должны быть свои при смене юзера, но абсолютно плоха ситуация, когда человек ехал в метро (или находился в другом публичном месте), разблокировал телефон загагулинкой, понял, что светанул его, пошёл менять, и поломал приложения завязанные на кейстор
А каким образом они ломаются?
NK
очевидно должны быть свои при смене юзера, но абсолютно плоха ситуация, когда человек ехал в метро (или находился в другом публичном месте), разблокировал телефон загагулинкой, понял, что светанул его, пошёл менять, и поломал приложения завязанные на кейстор
При смене пинкода не ломается же ничего
NK
Только при смене отпечатка
A
решение от уважаемого Fi5t я сейчас протестирую. Но вопросы конечно есть...
в данный момент я реализовал враппер над SharedPreferences, который смотрит, если api < 23 то юзает KeyPairGeneratorSpec и велосипедит свои преференсы над дефолтными, в виде делегата. Если > 23 то юзается напрямую коробочное решение от google EncryptedSharedPreferences.
Помимо этого есть ещё другие открытые префы, которые просто хранят в себе sdk, чтобы когда пользователь обновил ОС телефона (это кстати ещё один момент когда keystore может пострадать), я чекнул этот переход, и перевёл его на новые префы.
но тут много подводных камней и нюансов. Есть ситуация, когда я просто напросто не смогу восстановить префы. Это очень плохо и именно за этим я сюда написал, сталкивался ли кто либо с этим в таком ключе.
в данный момент я реализовал враппер над SharedPreferences, который смотрит, если api < 23 то юзает KeyPairGeneratorSpec и велосипедит свои преференсы над дефолтными, в виде делегата. Если > 23 то юзается напрямую коробочное решение от google EncryptedSharedPreferences.
Помимо этого есть ещё другие открытые префы, которые просто хранят в себе sdk, чтобы когда пользователь обновил ОС телефона (это кстати ещё один момент когда keystore может пострадать), я чекнул этот переход, и перевёл его на новые префы.
но тут много подводных камней и нюансов. Есть ситуация, когда я просто напросто не смогу восстановить префы. Это очень плохо и именно за этим я сюда написал, сталкивался ли кто либо с этим в таком ключе.
A
А каким образом они ломаются?
на сколько мне удалось проверить, происходит IllegalStateException при попытке взять ключ из стора, или я где-то свернул не туда?
СП
Кстати, много что обнуляет префы.
Удаление приложения или его данных, перенос на новый тлф если не настроин автобэкап
Удаление приложения или его данных, перенос на новый тлф если не настроин автобэкап
A
решение от уважаемого Fi5t я сейчас протестирую. Но вопросы конечно есть...
в данный момент я реализовал враппер над SharedPreferences, который смотрит, если api < 23 то юзает KeyPairGeneratorSpec и велосипедит свои преференсы над дефолтными, в виде делегата. Если > 23 то юзается напрямую коробочное решение от google EncryptedSharedPreferences.
Помимо этого есть ещё другие открытые префы, которые просто хранят в себе sdk, чтобы когда пользователь обновил ОС телефона (это кстати ещё один момент когда keystore может пострадать), я чекнул этот переход, и перевёл его на новые префы.
но тут много подводных камней и нюансов. Есть ситуация, когда я просто напросто не смогу восстановить префы. Это очень плохо и именно за этим я сюда написал, сталкивался ли кто либо с этим в таком ключе.
в данный момент я реализовал враппер над SharedPreferences, который смотрит, если api < 23 то юзает KeyPairGeneratorSpec и велосипедит свои преференсы над дефолтными, в виде делегата. Если > 23 то юзается напрямую коробочное решение от google EncryptedSharedPreferences.
Помимо этого есть ещё другие открытые префы, которые просто хранят в себе sdk, чтобы когда пользователь обновил ОС телефона (это кстати ещё один момент когда keystore может пострадать), я чекнул этот переход, и перевёл его на новые префы.
но тут много подводных камней и нюансов. Есть ситуация, когда я просто напросто не смогу восстановить префы. Это очень плохо и именно за этим я сюда написал, сталкивался ли кто либо с этим в таком ключе.
это всё фигня если решение от Артема такое радужное как мне показалось)
A
Кстати, много что обнуляет префы.
Удаление приложения или его данных, перенос на новый тлф если не настроин автобэкап
Удаление приложения или его данных, перенос на новый тлф если не настроин автобэкап
это не проблема по бизнес требованиям. Проблема, когда пользовать "вроде бы ничего такого не делал, но приложение поломалось"
A
я понял что это за Tink
СП
Тинк норм. Самому делать криптомодуль = оставить кучу дыр.
A
он походу тяжеловесный весьма