Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sensitive data in plain text. #8

Open
wemersonrv opened this issue Apr 21, 2020 · 5 comments
Open

Sensitive data in plain text. #8

wemersonrv opened this issue Apr 21, 2020 · 5 comments

Comments

@wemersonrv
Copy link

Hello.

When adding sensitive data as tokens, keys, etc; can i add them in plain text in .env? Or need to encode or encrypt this kind of information?

In short: if i add a Google Maps Key in .env, It's possível to edit/decompile the app and recover It as a String or because using .env it's not possível?

@ghenry
Copy link

ghenry commented Jul 18, 2020

I use https://pub.dev/packages/flutter_secure_storage for that type of thing.

@marianoarga
Copy link

I use https://pub.dev/packages/flutter_secure_storage for that type of thing.

That package is for encrypting the plain text input, on runtime, as far as I understand is not applicable for what @wemersonrv asked.

@FickleLife
Copy link

Just wondering if there's an "official" answer to @wemersonrv question?

@jpeiffer
Copy link

There's no "perfect" solution. The problem is the client is deployed in an environment outside your control, and must contain all the information needed to access protected resources.

The best answer is some sort of user authentication, but that doesn't work for things like Google Maps keys and other APIs that don't have a user.

Beyond that, you can encrypt the sensitive data. Then you either need to put the encryption key in the app, or need to get it from an (intercept-able) API call.

It ultimately boils down to how frustrating do you want to make it to get the key. For Google Maps, it's probably fine as is. For something much more sensitive, you can use a "calculated" key and create the key through an algorithm to make it more difficult to find and extract. But nothing is 100% attack proof because you're always giving the attacker everything they need if it's part of your build.

There's a deeper answer in this SO thread:
https://security.stackexchange.com/questions/100129/what-to-do-when-you-can-t-protect-mobile-app-secret-keys

@java-james
Copy link
Owner

Related to #51 see discussion

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants