hello, Ed!

how can I help you today?

Good Morning Mark

I've got a wild question this morning... I'll try to keep it focused. It's around security.

Looks like you Open Sourced some cool libraries. Thanks for doing that.

I don't know if I'm ready for a wild security question in the morning

lol

you're welcome!

So if I had a Flicker account app or a Google Office app on Android

and the user wanted to save those credentials

what would be the best way to do this?

in those two scenarios, you wouldn't control the server -- is that the case in the real scenario, or is it your server that the Android client is connecting to?

while true, most apps have a 'save account' option

or have the ability to 'save credit card' for later purchases option

it's so small, it is hard to justify bring a DB to the table

if your concern encompasses "save credit card", then that changes my line of thinking a bit

(BTW, hello Jovica -- I will be with you shortly!)

it's not a credit carc

but it is that type of scenario

if the user has typed in account credentials and they want to use biometric to login for example...

Hi threre. No specific agenda, just dropped by to see what's happening. :-)

Ed: well, that's completely different

let's set aside biometrics for the moment

for most things, internal storage (getFilesDir()) should be sufficient

biometrics is being used in my app. if that helps/hurts your answer

and I leveraged your RxJava example... which was excellent... by the way. :-)

thanks!

if you wanted to encrypt the data on internal storage, with an eye towards biometrics, that's fine

that might be overkill for some things, but if you're already doing it...

I'm trying to avoid someone using adb on their phone and sniffing around in the file system

really, the question is: what is the risk and what are the threat vectors?

so to encrypt so I don't have clear txt strings... is pretty easy

I used to do that at the bank

and most banks have policies about 'PAN' data that it can't sit in a DB without being encrypted

are you implying that the user is the threat, or is your concern that the user leaves the phone at the bar and an attacker gets access to the hardware?

"user is the threat" is a DRM scenario, in effect

I know someone who got hacked on Android... and I was asked to do due diligence to prevent anything like that happening

sorry, hard to be detailed when I'm in a recorded chat session... ;-)

understood, but at the same time, it is difficult to give you concrete advice with a steadily-changing scenario

I'm not trying to change it... sorry... I don't know as much as you. :-)

internal storage is the baseline for secure storage, as the only things that can access it are your app, users who root their device, or app bugs that wind up disclosing the data to malware

the fourth scenario is when an attacker gets physical access to the device

encrypted storage helps with that scenario

at least somewhat

it's really trivial to run adb

then say run-as 'app package name'

then you should be looking at device policies and forcing the user to have a secure lockscreen

and do 'ls -la'

the only people who can use adb are the people with access to the device: a user or a lost-device attacker

that isn't possible... assume your mother-in-law is using this app. ;-)

I'm just trying to use good practice for those types of scenarios

"these type of scenarios" run the gamut from script kiddies to the NSA

I mean, we can ratchet the level of paranoia up as high as you like

I'm not wasting time on the NSA or the Masad

I know who wins that one... they have bigger computers... and could brute force in feeble thing I try

if your threat vector is "attacker gets physical access to the hardware", and the data is of sufficient concern to the user, encrypted data on internal storage is a reasonable choice

who am I protecting it from? what am I protecting? how long do I need to protect it?

that's the questions that I would need answered

those are basic three I focus on

and that's a fine starting point

I'm protecting a text string of less than 30 chars

I'm protecting that string from as many people as possible, within reason.

does "as many people as possible" include the user?

I need to protect it for the life of the app.

(BTW, Jovica, if you have a question, chime in, and I can give you a turn!)

yes, if it is in reason

I'm finished after this....

then don't put it on the device

I have an app that stores username and password to our site in shared prefereces.

are SSL messages considered 'safe'

or https

Wanted to avoid it being trivially accesible so ended up using the solution descrbed here: https://www.codeproject.com/Articles/549119/Enc...

Ed: if the server is well-configured, yes, for data in transit

thanks guys!

it's hard to keep up with Android... without having to think about something as dynamic as security

You can still find the ey hardcoded in the app, but at least it's good enough for 'script kiddie' type of attacker.

I'm done... cheers

sure, and security is one of those subjects for which a semi-public chat is not great

Jovica: I think you under-rate the modern script kiddie :-)

Mark, I'm in violent agreement with you. :-)

could you be in less-violent agreement? I bruise easily

lol

cheers

Thanks Jovica for the link.

Jovica: if the key is hardcoded in the app, a script kiddie probably could get it without much problem, though this is probably sufficient for "disgruntled ex-boyfriend" scenario

Ed's approach of using biometric-based AndroidKeyStore encryption avoids the hardcoded key and would be a fair bit stronger

Well, yes, the threat profile we had in mind is definitely more of a casual snooper than a hard phisher.

in which case, what you have is probably fine, though I haven't looked at that implementation specifically

Any idea on how many Android devices in the US have the biometric reader?

It's a hard one to determine.... imho

Sure, if I had to do it again today, I'd probably go with boimetrics, too.

I'd venture that fingerprint scanners are reasonably common on Android 7.0+ hardware

Jovica, that link you sent is very close to what I did at a bank.

Hard thing about 2-tier apps is they need to connect to a DB and that requires credentials.

two-tier on mobile? I wish Campfire supported emoji, as I think there'd be a "scream" one that would be appropriate here

The banking app was 2-tier

old school

still, eek

You do realize they still have COBOL doing work... right? :-)

fortunately, not on Android in any significant degree

Ok guys, I'm off now, just wanted to check things out a bit. See you around.

that is the best way to do it imho

ssh key

and ironically... it is what GitHub and GitLab use

just don't lose your key AND your computer.... at the same time. ;-)

Jovica: have a pleasant day!

no way to issue something like that on Android

if you mean SSH-based communications, yeah, I don't recall there being a decent up-to-date client library

they keep you from knowing any traceable detail at the IP / MAC layer

because they don't want anyone leveraging Android to track people for add revenue.... they want it all to themselves...

lol

oh, somebody could create one -- it would not need to be part of the OS

not sure if anyone has tried creating a wrapper around libssh

that is an interesting thought

how are you today?

what can I help you with? Let's make is all about Mark now. lol

so, I'm not sure if any of my ramblings in this chat were useful to you

anything else that I can help you with today?

I'm good.

Thanks Mark

enjoy your day

you too!