Question: is it ok to store passphrases as string on Android?

[IvanPizhenko]

Normally in Java this is bad practice, reasons are explained, for example, here, but I can see everywhere in the application passphrase is String.

[tomholub]

I think there may be some merit to refactoring this, although not an easy task - starting from database, all the way throughout the app as you noted. Probably the same for armored private keys..

[DenBond7]

@IvanPizhenko
I've looked at your link. Android is an interesting OS that has a lot of difference if we will try to compare it with desktop OS. Without root access, you have some sort of safety. But if a device will be rooted that's only a time question when data will be stolen.

Anyway, that's a good question, and thank you for the feedback.

@tomholub

I think there may be some merit to refactoring this, although not an easy task - starting from database, all the way throughout the app as you noted. Probably the same for armored private keys.

In the local database, we store all sensitive info encrypted. For passphrases, we have TEXT data type. For keys, we use BLOB. Of course, we can update a table to use BLOB for passphrases(not sure that is really important due to storing that encrypted). What we can improve? We can migrate to use byte array instead of String when we fetching key details from the local database. Then in the RAM, we will not store passphrase as String. it shouldn't take a lot of time (I hope). But I think all of that we should do after dropping Node and NodeKeyDetails

[tomholub]

I'm moving this to "later" - I think this is a well defined task that Ivan could attempt even though he's new to the codebase. In this iteration, I would not be changing the database type, only handling in code once loaded from database. Once this is done, then we can revisit the database. Encrypted string seems fine to me for the db storage, as long as it's a CharArray the moment we decrypt it.