Android and iOS

The risk of trusting the client clock

Code tampering, account abuse, data exposure and client manipulation.

Threats and abuse1 min readEditorial methods

A mobile device's clock is not trusted server time. Expiring authority, evidence freshness and offline entitlements must not rely unconditionally on an adjustable client clock.

Evaluation approach

Design server-based expiry, tolerance windows and retry behavior. Device clock drift can be recorded as separate telemetry.

Application example

Calculate the validity of one-time approval from server records. A visible countdown must not be the source of authorization.

Limits and considerations

Clock drift does not always indicate an attack. Incorrect settings and offline use can also cause it.

The origin of a time claim

Users or their environment can influence device time. Do not base license expiry, transaction deadlines or evidence acceptance solely on that clock. Keep the server's time assessment independent.

For offline requirements, specify the accepted uncertainty. Device-reported occurrence time and server receipt time need separate fields. Include clock changes and long periods offline in the tests.

Checks and decisions

  • Use server time
  • Define tolerances
  • Test clock changes

Separate the time displayed to users from the basis of a security decision.

Sources

The primary references above provide the technical basis. Example workflows and evaluation suggestions are this publication’s explanations, not independent test results for a particular product.