IS
оу... понятно. Спасибо, буду думать
Size: a a a
2018 January 22
AS
исходящий, грубо говоря кейс такой, есть двух симочный телефон, одна симка допустим разрешена другая нет и нужно задетектить с какой симки набрали номер
если про детальную инфу про симкарту говорить, а вот с какой симки набирали – никогда не интересовался апи для многосимочной работы, но уверен что понять sim1 или sim2 использовалась можно будет
IS
ну я могу дергать IccId симок (проверял на теле 2 и мегафоне)
IS
а вот отследить звонок не получается, есть чуть чуть инфы, но те подходы мне не помогают, даже слот вызывающей симки не могу определить)
IS
если про детальную инфу про симкарту говорить, а вот с какой симки набирали – никогда не интересовался апи для многосимочной работы, но уверен что понять sim1 или sim2 использовалась можно будет
AS
Гуглю сейчас по мотивам этого интересного доклада на предмет шифрования секьюрных данных и чтобы это работало начиная с minSdk=15. Есть примеры. Например вот:
https://github.com/hyperledger/iroha-android/blob/3e66f6fb4f8d91ec816239c85db2f65002cd4427/iroha-android/src/main/java/io/soramitsu/irohaandroid/security/KeyStoreManager.java#L115
Проблема в том, что KeyPairGeneratorSpec.Builder(context) added in API level 18 😢
Автор доклада предупредил, что если ты решишь пойти по этому пути, то тебя ожидает боль. Но все же хотелось бы разобраться и сделать более менее сносное шифрование данных, чтобы хотябы от школоты себя обезопасить. Может кто-то сталкивался с этим, как это решить?
https://github.com/hyperledger/iroha-android/blob/3e66f6fb4f8d91ec816239c85db2f65002cd4427/iroha-android/src/main/java/io/soramitsu/irohaandroid/security/KeyStoreManager.java#L115
Проблема в том, что KeyPairGeneratorSpec.Builder(context) added in API level 18 😢
Автор доклада предупредил, что если ты решишь пойти по этому пути, то тебя ожидает боль. Но все же хотелось бы разобраться и сделать более менее сносное шифрование данных, чтобы хотябы от школоты себя обезопасить. Может кто-то сталкивался с этим, как это решить?
KeyStore и многое апи почти всегда можно достать через рефлексию на старых API, они не описаны но часто есть. Но это костыль :]
Вы действительно хотите упарываться ради 5-6% пользователей?
Вы действительно хотите упарываться ради 5-6% пользователей?
D
KeyStore и многое апи почти всегда можно достать через рефлексию на старых API, они не описаны но часто есть. Но это костыль :]
Вы действительно хотите упарываться ради 5-6% пользователей?
Вы действительно хотите упарываться ради 5-6% пользователей?
Да не особо. Но т.е. ответ такой, что на API ниже 18 вообще не шифровать никак?
AS
технически вопрос только насколько сложно будет ну и немного менее секьюрней будет, на практике уже нет смысла упарываться если вы не банк
AS
если банк – свой криптоконтейнер
D
Я не банк. Но тут обсудили и попросили сделать шифрование в проекте.
AS
а вот отследить звонок не получается, есть чуть чуть инфы, но те подходы мне не помогают, даже слот вызывающей симки не могу определить)
написал в лс
R
Я не банк. Но тут обсудили и попросили сделать шифрование в проекте.
Ну так и сделай без кейстора. Зачем он тебе? А Chiper доступен с каких-то древних версий API насколько я помню. Если тебе не подходит, то возми внешнюю сошку
D
Ну так и сделай без кейстора. Зачем он тебе? А Chiper доступен с каких-то древних версий API насколько я помню. Если тебе не подходит, то возми внешнюю сошку
Т.е. просто в шаредах хранить ключик?
D
Для старых API
R
Т.е. просто не хранить )
D
Я думал что чтобы что-то зашивровать и потом расшифровать нужен ключ. Ключ в идеале должен хранится в каком-то защищенном сторе, доступном только приложению. На API 18 и ниже получается такого стора "из коробки" нет и ключ нужно где-то самому хранить. Как же можно не хранить совсем ключ? Как мы потом расшифруем то что сами зашифровали?
Т.е. я знаю что например вместо паролей можно хранить их md5, а потом сравнивать md5 введенного пароля с хранимым. Но в моем случае нужно именно обратимое шифрование.
Т.е. я знаю что например вместо паролей можно хранить их md5, а потом сравнивать md5 введенного пароля с хранимым. Но в моем случае нужно именно обратимое шифрование.
R
Я думал что чтобы что-то зашивровать и потом расшифровать нужен ключ. Ключ в идеале должен хранится в каком-то защищенном сторе, доступном только приложению. На API 18 и ниже получается такого стора "из коробки" нет и ключ нужно где-то самому хранить. Как же можно не хранить совсем ключ? Как мы потом расшифруем то что сами зашифровали?
Т.е. я знаю что например вместо паролей можно хранить их md5, а потом сравнивать md5 введенного пароля с хранимым. Но в моем случае нужно именно обратимое шифрование.
Т.е. я знаю что например вместо паролей можно хранить их md5, а потом сравнивать md5 введенного пароля с хранимым. Но в моем случае нужно именно обратимое шифрование.
Ключ не нужно хранить если выводить его каждый раз на базе пользовательского ввода
D
Т.е. ключ генерируется из введенного пользователем пароля? Если пароль неверный, то и ключ неверный? Такая логика?
AS
D
А если нет пользовательского ввода? Данные например какие-то в кэше надо зашифровать? Но при этом при открытии приложения никаких паролей не запрашививает, только при первом запуске, а далее уже вход по сохраненной сессии.