⤵️⤵️⤵️ 🚧 ⚠️ WORK IN PROGRESS ⚠️ 🚧 ⤵️⤵️⤵️
Online mode (background info)
It should be noted that the usual online security also needs trusted data to be stored on one side to verify the other: e.g. TLS needs public keys of well known CAs (stored in the browser / device / OS) - the trust root.
So for offline use cases we can assume the same level of security present on the device. If the device can be unlocked by the attacker then the only user authorisation factor that remains effective is the password (any knowledge possessed by the user): push notification, push SMS OTP, email OTP are gone…
Another important idea is that many auth factors do not have “time” baked in (does not depend on time or does not use time as a security measure even if time makes a difference), so can be checked later, too. (Exception is the push based OTP but we have TOTP/HOTP which does not need initial communication but still serves as a one-time-password.)
Temporarily offline mode
Account details / history
Account details, transaction history can be shown to user (cached version, limited history). Simple offline passcode (maybe it is good to have a different one) or biometrics if it is supported by the device. (It is the same with PKI based authentication.)
Requests / commands
A. Store requests (with all data), when next online → do auth and send to cloud
simple, we just store the requests and “replay” it with auth at online time
stored data security: similar to the account details / history mode above
user saves time (typing in all the details)
need to be online for a short time only (when replaying & user auth)
B. Store requests (with all data) and do auth immediately, when next online → send to cloud
supported requests / commands may be limited
possible auth factors that can be used in offline mode:
device factor: secrets stored on the device
to use public key infrastructure and/or strong password
pre-synced strong, one time used encryption keys? (similar to recovery keys)
app factor: TOTP/HOTP (time or sequence based OTP)
user factor: passcode (maybe separate from the usual passcode) and biometrics to protect secrets on the device (device factor)
sign and encrypt the requests and store on device (in JWS format, for example)
optionally send a special (data) SMS when become online (as another factor)this can verify the phone number for added security (but add cost also)
need to be online for a very short time only (when the package is sent)
Common
usual “under the hood” data can also be sent (i.e. GPS coords, device metadata/ID, etc) for increased security - no difference to online mode
risk assessment is still in play when executing the requests - no difference to online mode
can deny request upon execution (but this is normal not just for security reasons but e.g. when there is not enough funds on the account to execute the transaction)
if we deny the offline request due to security reasons, the user just need to authenticate when online, do not need to retype the request (basically this is fallback to offline mode A)
user may need to explicitly enable the feature (not turned on by default - maybe even time and/or position restrictions (e.g. we do not allow offline mode when in dense city areas with proper cellular connectivity))
