Android Question secure save for sensitive data

[ShadTech]

Hello,


I am looking for a secure method to store sensitive data, such as passwords, in my application. I want to ensure that if my APK is decompiled, this sensitive information cannot be easily exposed or extracted.
I attempted to find a solution on ChatGPT but received B4A code filled with errors.
Is there a simpler way to permanently store and retrieve sensitive data while keeping it protected from being hardcoded in the source code?
Thank you for your assistance.

 

[emexes]

Maybe something like:

Sub Process_Globals
    Dim Status1 As String
    Dim Status2 As String
    Dim Status3 As String
    Dim Status4 As String
    Dim Status5 As String
    Dim Status6 As String
    Dim Status7 As String
    Dim Status8 As String
End Sub

'start-up code
RndSeed(2025)
'more start-up code
Status1 = Chr(Rnd(49, 85))
'even more start-up code
Status2 = Chr(Rnd(54, 115))
'yet more start-up code
Status3 = Chr(Rnd(40, 75))
'too much start-up code
Status4 = Chr(Rnd(69, 105))
'never enough start-up code
Status5 = Chr(Rnd(68, 100))
'who let the start-up code out
Status6 = Chr(Rnd(72, 109))
'now is the time
Status7 = Chr(Rnd(45, 107))
'for all good start-up code
Status8 = Chr(Rnd(42, 116))
'to come to the aid of the program

Log(Status1 & Status2 & Status3 & Status4 & Status5 & Status6 & Status7 & Status8)

Waiting for debugger to connect...
Program started.
5hAdTeCh

 

[William Lancee]

@emexes
The source of the obfuscation is revealed. It is 2025. The rest is history.

 

[emexes]

@emexes
The source of the obfuscation is revealed. It is 2025. The rest is history.

The aim was to make it difficult to extract a password from a decompiled listing. Could have used regular arithmetic or math functions but Rnd has the nice feature of being practically impossible to work out without actually running the code.

Í'm still stumped as to how you'd do it at runtime without at some point having the password etc as a string somewhere, ready to use for logging-in etc. Whatever mangling is done, the decompiled code has to know how to do it. Rnd at least keeps some of the mangling out of the decompiled code.

Lol bit like the digital voting problem of how to enable people to verify their vote has been counted correctly, but without enabling vote-selling.

 

[William Lancee]

If the code is visible in any way, it is breakable. I remember spending days on trying to make Javascript user side more secure - and gave up.
Yes I could make it very difficult to find the secret - for example in an image bitmap color code - but the finding algorithm was always visible.

Make the secret invisible somehow. Store it in some secure access server. But then the problem is server availability when the user needs it.

 

[William Lancee]

But you got me thinking. The best way to hide something is to mix it with noise. If the finding algorithm is statistically based, it may be very very difficult to
find the secret. For example, if you could embed the 2025 key in a large image bitmap 'more times' then random other keys, you could find it and use it to encode the secret.

If you change 'more times' for something more subtle, it would increase the difficulty of finding quite a lot - hopefully not worth it.

And what if the image is transitory, replaced by another image that looks exactly the same but isn't.

This is what nightmares are made of.

 

[emexes]

2025 key

Hmm, I hadn't considered the 2025 to be a key, but I guess it is acting as one. Walks like a duck, talks like a duck, must be a duck.

The security lay more in using Rnd as a mangling function that doesn't look like it'd have anything to do with passwords. And keeping the password unassembled until it's needed. And the password is (near-)impossible to derive from a decompiled listing, which was the original goal.

I used 2025 as the RNG seed because I figured it could be pulled out of the copyright date or similar. But you could just as easily use any piece of information, like a tag from a layout. Actually, that'd be kinda good, because it doesn't show up in the decompiled code listing. Or use the width of a particular field of the layout. Any value will do, as long as the program has access to it when it needs to regenerate the password.

I realised on the drive home that the Rnd function could probably easily generate up to three characters per round, instead of just 1.

You could use encryption, with a key hidden in a layout, spread across fields to better disguise it. But that has the downside of: the call to the decryption routine is obvious in a decompiled listing, whereas generating random characters littered throughout the code, not so much.

 

[MicroDrie]

En

I am looking for a secure method to store sensitive data, such as passwords, in my application. I want to ensure that if my APK is decompiled, this sensitive information cannot be easily exposed or extracted.

The term like and passwords is confusing. Look most OS encrypt hashed and store this encrypted hashed given password without it ever being decrypted reversed again. The correctness of a password is determined by comparing the initial encrypted hashed password result with the result of the entered encrypted hashed password. If the two are the same, the login is allowed. Only a brute force attack with obvious passwords can achieve a successful login attempt. To make this more difficult, minimum password length and use of upper and lower case letters are required.

The good news is that Android has a piece of memory that only the application has access to. You could store the encrypted hashed password there. The condition is that the phone or tablet has the normal security measures such as recent updates and non-rooted implemented. This approach gives you an acceptable residual risk for the password.

That leaves the term 'such as'. Without a specific description, it is not possible to say more than some generalities. You may be able to use asymmetric encryption in a 'one-way' application. That works for storing collected information, but not for reading encrypted sensitive information that is included in the APK.

Edit: the wrong term encrypted password replaced with hashed password as correctly pointed out by aeric.

 

[aeric]

I think @MicroDrie means password hashing.

to ensure that if my APK is decompiled,

Don't store the password inside APK.
User data can be stored in sqlite database where the password is hashed. You can also use access token which will expired in a time period and the access can be revoked at the server side.

 

[udg]

What about the chance a pirate disassembles your app, finds the spot where there's the test go-notgo involving credentials (passwords, secret codes, whatever), modifies it (or by-passes irt) so to be always True (so the app goes on) and assembles again the app.
Eventually the modified app would not be stored on the official stores, but ends up as a perfetct clone password-free.

A consideration: why the big guys prefer to hire lawyers instead of talented programmers when it comes to defend their products?

 

[MicroDrie]

Indeed, security is a rat race where the art is to make abuse as difficult as possible against acceptable residual risk without frustrating the legitimate user too much. In other words, the higher you make a ladder, the fewer people will reach the top, but there are always those who reach the top.

 

[emexes]

Changing the Compilation Mode to "Release (Obfuscated)" does a reasonably good job of concealing string literals, stopping them from being easily and immediately obvious in a decompilation listing.