Im currently developing a framework for oAuth 1 and 2 access to webservices and my question is, how do i store sensitive data like an oAuth access key in a secure way?
the problem with this keys is that some platforms like twitter use a permanent key and if someone would get access to this key he could do whatever he wants with the users twitter account..
so is it possible to automatically encrypt the data before it is stored in the shared preferences? Or is there a better way/place to store very important data?
UPDATE - ALSO READ: What is the most appropriate way to store user settings in Android application
You can also have a look at this class I made for doing exactly this: https://github.com/sveinungkb/encrypted-userprefs
It uses AES instead of the deprecated and weak DES used in the other suggestion.
1). How to encrypt?
On Android the encryption is done via Java Cryptography Architecture (JCA). Mainly it is the javax.crypto.* package.
JCA Reference Guide
Here is an example of JCA API usage (AES alrorithm in particular).
2). Where to store?
Encryption API manipulates with byte arrays (not strings). This means you can use SharedPreferences, but you'll need to apply Base-64 encoding on the encrypted byte array before putting it into SharedPreferences (otherwise XML parser will fail to read the shared preferences file). Then to read you will need to use Base-64 decoding. Note that by default most Android OS versions do not have a built in Base-64 API (see UPDATE section). So to remove this Base-64 overhead I would recommend just to store your bytes in a private file.
UPDATE: Since API Level 8, the API has android.util.Base64.
I would recommend using Facebook Conceal for encryption on Android almost every time - it's a fast Android library that makes some really sane decisions and leaves you with a few, simple interfaces for actually doing the work.
Bonus! I have recently pieced together the puzzle of how you can use it from Xamarin - see my article on securing your C# app's data using conceal for more information.
You should take a look at Slink.
I came to realize that most of the SharedPreferences encryption tools use encryption for each action you make, meaning that each key-value pair is saved only after both key and value been encrypted, separately. This creates a big performance overhead.
So I searched for a library that will give me a more efficient encryption process and I found Slink. Slink uses Facbook's Conceal library to save the entire map of objects as a whole, making it the most efficient and fast SharedPreferences encryption solution. It also uses common Android's SharedPreferences interfaces, which makes the usage extremely easy and almost seamless.
Disclaimer: I'm part of the development team developing this library.
See duplicate: Obfuscate/Encrypt SharedPreferences file possible?
Hi, I've created a SharedPreferences implementation using AES
encryiption. The project is a maven module. If you need one, take a
look. https://github.com/kovmarci86/android-secure-preferences
Try using our https://github.com/BottleRocketStudios/Android-Vault Vault component. It will use Android's Keystore (on supported devices) or an Obfuscation technique to encrypt values in a SharedPreference file and implements the SharedPreference interface, so it is largely a drop-in replacement.
new encryption introduce by facebook - conceal Encryption.. easy to use
https://github.com/afiqiqmal/ConcealSharedPreference-Android
This article on codeproject contains a nice wrapper for the shared prefs. However the class name SecurePreferences is misleading something like ObfuscatedPreferences would be more appropriate.
There is an Android Library that uses Facebook Conceal to encrypt data.
https://github.com/rtoshiro/SecureSharedPreferences
Maven Central:
compile 'com.github.rtoshiro.securesharedpreferences:securesharedpreferences:1.0.+'
You can encrypt the data in preferences and keep the encryption key in the Android Keystore system. This way your encryption key would also be safe.
You can look into a library doing this
https://github.com/ophio/secure-preferences
Related
Good afternoon,
I need a little bit of help. I'm using QT6.4 to write an Android app that handles private keys.
I have no prior experience with QT or Android app development. This app stores an Ecdsa private key used to make signatures, the key is generated remotely. Currently I just store it in a text file but it doesn't seem like good security. I heard of Android keystore but I don't know if it's possible to use.
Any suggestions or examples?
Storing private key in plain text file seems insecure. Other apps could read it.
In Qt, there is no API to access the Android Keystore... So the best solution would be to access it in Java/Kotlin.
To add a custom Java class to an Qt Android application, and how to call it using the JNI convenience APIs in Qt, you can check the notifier example :
https://doc.qt.io/qt-6/qtcore-platform-androidnotifier-example.html
The most secure usage would be to generate the private key inside the Android Keystore, which doesn't allow to access it. To generate private keys in Keystore this is a good site to read:
https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec
If the key needs to generate remotely and you download it, then you have 2 possibilities:
Import the key into AndroidKeystore - start by reading: https://developer.android.com/reference/kotlin/android/security/keystore/KeyProtection
Generate a new private key and encrypt the key. Then store it in a file or any persistent place.
I was wondering what should be an ideal way for placing API keys, salts, or even private keys for encryption and ship them along with the APK. While doing research on this I saw a couple of methods widely used for placing some of these details:-
Place this info in gradle.properties - This is the simplest solution for placing these details but it is not secure at all. The information stored here can easily be extracted from the APK.
Store it in cpp - Create CPP files in the codebase where these details are placed and write JNIs to extract out these details when needed. This makes it harder for the attacker to extract out these details but it still is extractable
I read a couple of posts of which recommended using Keystore for securely storing this information but while seeing implementation at a couple of places I inferred that it usually stores values in runtime and I didn’t find any details on how to ship some salts or API keys along with the APK.
I wanted to know if there is any way for securely placing salts, API keys, etc along with the shipped APK. Or we can somehow use Keystore for this. Any help or suggestion will be really appreciated. Thank You!
Using this library You can easily secaure your api
https://github.com/MEiDIK/Cipher.so
Read Carefully there installation Process and still have any doubts or error i will help you
I am currently designing a secure file storage Android application as part of a group coursework. I am charged with the security side of the app.
Where can I learn about the the classes and imports that Android offers to implement password hashing, encryption of the stored files and such? I have looked on the android developers site, but it was of little use to me, as I am inexperienced with android.
Thanks.
You can find useful information about Android Security here: http://developer.android.com/training/articles/security-tips.html
Anyway, any app on Android is isolated from the other, so you're basically safe until you keep your data in the private storage (obviously if the user has root permission you cannot avoid the reading of these private files).
If you're going to write file OUTSIDE (as on the SD), you will have to implement some algorithm to enrcypt your files.
You can look for AES encyption in Java: Java 256-bit AES Password-Based Encryption
I have read through a number of posts and resources regarding AES, CommonCryptor, salt and MAC in search of a solution to a problem I am facing with the release of my mobile software library. I would like to pass an encrypted string to my iPhone and Android App via HTML and JavaScript in a WebView using custom URL Scheme, with the string as a parameter. The HTML file will be created on my site and then distributed to users to store on their web servers.
From what I have read, I would encrypt the string in the HTML file using a key before distributing it to the user. Then the same key would be stored in the library and used to decrypt the string. But if someone decompiles my App they would then have the key and be able to decrypt the string stored in the distributed HTML file. I know that the library can be easily decompiled, but providing the string along with the code is really giving it away. And the real danger it that one could use the HTML files to trigger nefarious actions in a hacked version of my library.
I really don’t want to make a call to my site to get the key or salt and I am not sure that would offer any protection. Would a random salt stored along with the key in the library work?
I am willing to put in the time to research, code and test this, but first I would like to know if this is even feasible using AES, CommonCryptor, salt or MAC. If we solve it here, it will be available to all as the solution to this problem.
Thank You
Compile your own openssl and crypro static libraries and include those two static modules into your own native .so module. Don't use internal Android SSL.
Sore the key deep inside in some protected manner (simple solution is to use an array of floats with some non trivial hashing). Decipher the encrypted messages in the native code. Decide whenever the message is OK or not also inside the native code. Don't return to Java with plain boolean values.
Whenever a hacker wants to crack your code he has to decompile ~800K of native code.
I want to know how to encrypt the external storage data (.asec).
Which algorithm is used, AES or another method?
And then what is the encryption key?
If a method to generate encryption key is open source, I think that it is going to cause a problem.
I would be grateful for any information about this.
The Android Open Source Project provides a document describing their crypto implementation.
Basically, they use AES in the Linux DM-CRYPT layer. See the document for full details, including how it interacts with vold.