Yeah, what Haravikk said. Android apparently has no key store feature, so you must encrypt the key and obfuscate the means of encryption/decryption. Generate the key off of some persistent internal value (IMEI is one option) but "mangle" it somehow and "smear" the generation of that key out through a few misnamed methods (like "getStatus"). Also misname the methods that actually do the encryption/decryption of the password. (Or obfuscate the entire app.)
On Nov 3, 1:17 pm, Haravikk <[email protected]> wrote: > None of my Android development has required anything like this, but > I'm surprised Android lacks a secure storage feature for passwords and > SSL certificates. Nothing you can leverage there? > > Otherwise you probably want to look at AES/Rijndael encryption of the > password; pad it on both sides to something nice and long (maybe a 100 > characters or so) then encrypt it. The problem is the key and input > vector you use for encryption; input vector can be known so long as > it's something nice and varied, but the key should be generated on- > demand in such a way that it's not easy to guess (like device id, > username or any constant/hardcoded value etc.) but possible to > generate consistently when attempting to decrypt the file, which > usually rules out timestamps. > > If possible, you may want to add some rudimentary security token for > the user to enter, such as a 4-digit pin that can be md5 hashed and > used to encrypt the password along with username and other bits of > data to vary the key. This way you can automatically enter the > password on the user's behalf, but the encryption is still ultimately > provided by them meaning you don't have to try and find some way of > doing it without the risk of your algorithm being guessed, so you get > the best of both as while the user is still entering a form of > password to sign in, it's a much simpler one. > > On Nov 3, 1:39 pm, Kumar Bibek <[email protected]> wrote: > > > Obfuscation is for code. I guess, you are looking for encryption. > > There are several ways of achieving that. > > > On Nov 3, 9:23 pm, DulcetTone <[email protected]> wrote: > > > > I am considering adding a means by which my app can perform functions > > > over Google Voice, and the functionality would make little sense if I > > > required the user to type in a password. > > > > I'd like a reasonable plan for storing the password locally and > > > sending it (through google-voice-java) when demanded by Google Voice. > > > > Clearly, I'd like to properly represent the risks of the chosen scheme > > > honestly to the user. I'd like the storage to be based atop writing > > > it into a SharedPreferences created with flags=0 > > > > What form of obfuscation is suitable, and with what available salting > > > ingredients and such should I customize it? > > > > tone -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
