Biometric authentication - Why do we need it?

Summary

Grab addressed the vulnerabilities and costs associated with SMS one-time passwords and PINs by implementing device-level biometric authentication. The architecture pairs device biometric sensors with hardware secure enclaves to protect private keys separately from the main operating system. During enrollment, Grab generates a public-private key pair using SHA512withECDSA, authenticates the user locally, and stores reference identifiers in encrypted device storage. HellfireSDK verifies that the device is not rooted, ensuring raw biometric data never leaves the handset. Early experimental runs indicate an adoption rate exceeding 90% and a login success rate near 90%.

Context

Grab relied on PINs and SMS one-time passwords that were susceptible to social engineering, caused high user friction, posed fraud risks from shared driver accounts, and incurred SMS costs of $0.03 per message.

Approach / What changed

Grab implemented client-server biometric authentication leveraging device biometric sensors, hardware secure enclaves, SHA512withECDSA key pairs, and HellfireSDK root detection to sign payloads locally without transmitting raw biometric data.

Takeaways

• Secure enclaves invalidate existing private key access whenever device security configurations change, such as adding another fingerprint or modifying a PIN.
• The implementation verifies device integrity with HellfireSDK and stores reference identifiers in encrypted shared preferences or keychain while retaining all raw biometric data locally.
• Early experiment runs demonstrated an estimated adoption rate exceeding 90% and a login success rate of nearly 90%.

Related reading

• Grab · Sep 23, 2020

  Our Journey to Continuous Delivery at Grab (Part 1)

  Around the end of 2018, Grab's backend architecture consisted of roughly 270 services managed through fragmented, manual deployment workflows. Engineers copied release parameters between build logs, wiki pages, Slack bots, and multiple Jenkins jobs, leading to high operational friction and an average of 10 business days between production updates for a service. To streamline delivery, Grab built Conveyor, an internal automation platform built on top of open-source Spinnaker. Conveyor introduced a custom user interface focused on pipeline visibility and a pipeline-as-code DSL called Artificer using Jsonnet files in the monorepository. The platform automatically registers build artifacts with commit metadata to eliminate manual parameter entry and automatically provisions integration, staging, and production pipelines.

  Sylvain Bougerel

• Grab · Jun 29, 2020

  How We Built Our In-house Chat Platform for the Web

  Grab extended its in-house chat platform to the web to support its internal Customer Support portal. Because the existing TCP gateway only supports unicast connections with one active connection per user, opening multiple browser tabs would repeatedly disconnect previous tabs. Rather than undertaking a complex migration to multicast connections on the server, the team adopted a hybrid client-side strategy using SharedWorker and BroadcastChannel APIs. The implementation uses a SharedWorker to maintain a single WebSocket connection per domain while a BroadcastChannel syncs events across all open tabs. A custom wrapper over the worker manages version transitions during deployments to avoid race conditions across tabs.

  Vasu Krishnamoorthy

• Grab · Mar 1, 2022

  Abacus - Issuing points for multiple sources

  Grab needed a centralised points management architecture to issue loyalty points across a growing catalog of products, membership tiers, and external partner exchanges. To address this, the engineering team built Abacus, an issuance platform designed to process millions of daily transactions with high availability. The system ingests completed transaction streams or API calls, dynamically computes points via configured multipliers, and passes calculations through Amazon Simple Queue Service queues. Once the Point Awarding module updates a persistent ledger, Abacus notifies consumers, emits events to Kafka for downstream consumers, and recalculates rolling point expiration dates.

  Chandrakanth

• Grab · Oct 30, 2020

  Keeping 170 Libraries Up to Date on a Large Scale Android App

  Grab's passenger Android superapp relies on more than 170 in-house and open-source libraries, incorporating five to ten library bumps into each weekly release. Although developers often avoided updates due to the fear of leaking defects or crashes into production, the engineering team established a risk-assessment framework based on codebase usage and the volume of incoming changes. To minimize update diffs and avoid accumulating large issues, libraries are updated incrementally on a weekly cadence matching upstream release schedules. Automated UI test cases written in Gherkin syntax execute on CI for every merge request, while high-risk bumps trigger targeted QA manual testing. This structured updating process prevents defect leakage while keeping the application compliant with evolving Google Play target API requirements.

  Lucas Nelaupe