Don't save plaintext passwords

[DC7IA]

While taking a closer look at the app, I discovered that passwords get saved as plaintext in the sharedPref.xml.

This also means everyone who makes a backup via adb could get the password, hence this being bad practice.

Ideally the app should request a token when logging in. This way the password will not be compromised when the device gets compromised. The token can then be invalidated by terminating the session on the website (i.e. hampager.de).

This is also how the Telegram Messenger, as an example, does it.

To make phishing attacks more conspicuous and less likely to be successful, minimize the frequency of asking for user credentials. Instead use an authorization token and refresh it.

Where possible, don't store user names and passwords on the device. Instead, perform initial authentication using the user name and password supplied by the user, and then use a short-lived, service-specific authorization token.

Services that are accessible to multiple applications should be accessed using AccountManager. If possible, use the AccountManager class to invoke a cloud-based service and don't store passwords on the device.

Source: Android Dev Guide: Handle credentials https://developer.android.com/training/articles/security-tips#UserData

Stackexchange: What should I use Android AccountManager for? https://stackoverflow.com/questions/2720315/what-should-i-use-android-accountmanager-for

Luckily these passwords cannot be as dangerous as email passwords, but imagine someone sending false distress messages using someone else's call sign. This should be changed to AccountManager. While doing that, we could also think of using the SyncAdapter to get push notifications as soon as a transmitter drops off the air, but that would be a new feature already.

dc7ia

[IHFSchwarz]

Yeah, at the time, i was at the decision of either saving the password as plaintext or essentially encrypting it with a password that is also stored somewhere in the app... in plaintext.

Tokens are 100% the way to go, but the means of authorization on the server side don't (AFAIK) allow it (yet). My recommendation would be to use JWT, but this has to be done at the core software first.

Thank you for your issue, i'll probably look into the App more deeply again and check out where improvements are needed, since the user base has grown intensively since the last release.

[dh3wr]

As this APP will not work any more with V2 of DAPNET, there is no urgent need of investing time in it. But nevertheless a good recomendation.