I have some buttons in an Android app for a password form. I'm intentionally using buttons instead of a text field because of the design (and this is a hobby app.) However, this makes me wonder if this approach could have security vulnerabilities.

I/View: PerformClick: com.google.android.material.button.MaterialButton{dabaa04 VFED..C.. ...p..ID 308,91-462,182 #7f08005d app:id/auth_btn5

I/View: MotionEvent.ACTION_UP: mPrivateFlags: -2128459728, mHasPerformedLongPress: false, mIgnoreNextUpEvent: false

As you can see, the button's ID is logged. This could result in someone with access to these logs to determine the password.

Screenshot of UI

With all of this said, I wonder:

1. Let's suppose that the numbers on the buttons are not randomized. Does this lead to a security risk from a practical standpoint (i.e. what's the likelyhood of someone gaining access to the debug logs)?
2. What is the best way to circuvent this? Additionally, will this method still allow for the same look?

CodePudding user response：

No, this is not a particularly viable security risk. When considering security threats, you need to determine who you're defending against and why:

1. The user themselves: Nope, they know their own password, so doesn't matter.
2. Other apps: Nope, they can't access your application's logs (source), so doesn't matter.
3. ISP: Nope, logs are kept locally, so doesn't matter.
4. Malicious actors with physical access to the unlocked device: This is the only actor that shouldn't have access to this information, but could.

Realistically if somebody has physical access to the device, depending on their budget it's possibly game over anyway. Regardless, for logcat specifically you are particularly safe.

This log is not a permanent thing, it has a maximum size after which it deletes older logs. This is usually a few MB (source), so your data is likely long gone. To test this, try opening your app, entering the password, then opening another app for a few minutes, then unplugging & replugging device (to avoid any caching). Your log entries will almost certainly be gone.

As such, we now get to an even more specific definition of who we're defending against: People with physical access to the unlocked device, who have gained access within a few minutes of the user entering their password.

For your use case, perhaps this risk is still unacceptable. You can mitigate it entirely by randomising which number appears on which button. You could keep track of this button to number mapping via an in-memory array (or similar) that resets every time the screen is opened. Now as soon as the screen is left (either due to login, phone lock, or app minimised), the log entries are useless.