Featured Blog Post:
In the world of identity management and security, fraudsters are constantly evolving their tactics, exploiting weaknesses in outdated device identification methods. For fraud, identity and digital experience teams, securing...
Earlier this month I wrote about a bug in IOS 13 that caused the authentication dialog box to not be displayed, although the Touch ID capability may have still been there. This week we’re hearing about a bug in Samsung Galaxy S10 fingerprint readers. Apparently one can unlock the device with an unregistered fingerprint after attaching an inexpensive third-party screen protector. Amazing. Let’s take a closer look at multiple security issues surrounding the latest Galaxy S10 fingerprint flaw.
Application owners that allow native fingerprint authentication on Galaxy S10 devices have to question whether the person accessing their application is the legitimate account holder. But it gets worse. Any application owner that provides access to sensitive systems or information cannot rely on several other authentication methods on Galaxy S10 devices because fingerprint flaw means the device can essentially be accessed by anybody. Supplementing fingerprint scan with email OTP, for example, won’t work because fraudulent access to the device means access to email accounts on the device. Same with SMS OTP. Same with many other authenticators.
In the background, any changes a company may contemplate while the fingerprint scan bug exists are overwhelmingly difficult to implement. If a company has a mobile app that accepts a fingerprint scan on Samsung S10 devices and decides to fall back to password authentication, how would they accomplish this? The mobile application accepts fingerprint scans and is installed on the device. The company can disable app access from S10
devices altogether or it can quickly modify the app and force customers to reload an app which does not utilize fingerprint authentication, and then, once the bug is fixed, ask customers to reload the app yet again. Not very doable and not very customer friendly.
Because authentication is hardcoded into mobile applications, even minor modifications require re-coding, recompiling and redistributing the app. While far from ideal, minor non-critical changes can always be distributed via the hundreds of monthly app updates we are now used to dealing with. But critical updates are not
so easy.
Reuters reported that KaKao Bank in South Korea told customers with S10 devices to disable fingerprint authentication to log in to its services until the issue was fixed. Imagine the complexity of this approach. Messaging customers, disabling access if fingerprint is enabled, handling confused customer calls…
Fortunately, as discussed in the IOS 13 bug blog, the way to avoid this mess is to decouple the authentication process from the application so that changes can be implemented quickly and simply without having to touch application code. This allows enterprises to react quickly to these types of issues without making any code changes to their apps and without the need to re-publish the app.
Here, the approach might be as simple as modifying the authentication journey by disabling fingerprint authentication on S10 devices, enabling password, and restricting high-risk operations until the bug is fixed. Perhaps also serve up a message explaining why this change is happening when customers invoke the application. All of these steps can be simply configured with a simple click of a button with Transmit. The user journey is instantly modified and there is no need to republish the app.
As stated in the previous blog, when it comes to authentication, authorization and fraud prevention, agility is the key. Agility in identity is the ability to react fast without waiting for development cycles or app approval and publishing cycles. If you want to learn how you can always stay ahead of the inevitable bugs in any operating system, contact Transmit Security now.
