Fast decisions, higher risks: Analyzing the speed–accuracy trade-off in compare-and-confirm authentication


Abstract

People routinely complete fast “compare-and-confirm” checks—approving a login notification, matching a short code to link a TV, or confirming a Bluetooth numeric comparison. The appeal is speed; the risk is habituated tapping and weak binding that can lead to false approvals. We ask whether decision time can serve as an operator-friendly, fairness-aware risk signal that complements protocol/UI hardening. Using de-identified condition summaries from N=73 participants (558 participant×condition blocks), we model correctness across Scenario×Device×CodeLen with a population-average grouped-binomial framework, then focus on attack blocks where the failure is false approval. Benign handling remains near the ceiling across devices and code lengths, and moving from 4 to 6 digits does not measurably harm benign correctness. In aggregate, the timing coefficient is modest and not universally decisive, but distributional evidence shows that very fast attack handling concentrates false approvals; exploratory moderation reveals a stronger “slower-is-safer” association for identifiable groups (e.g., older and lower self-rated security skill). Operationally, we implement a straightforward timing gate that activates only when a user’s behavior is notably faster than their established baseline. Through cross-validation, a 10th-percentile timing gate achieves TPR ≈ 0.52, FPR ≈ 0.47, PPV ≈ 0.55, and NPV ≈ 0.50, providing bounded-cost operating points with calibration diagnostics. We recommend progressive, adaptive frictio—e.g., number matching, brief holds, or re-compare—triggered only at fast, high-risk moments. Treating time as a deployable behavioral signal hardens the riskiest moments in push authentication and pairing-style confirmations without taxing everyday use.
Ask to review this manuscript

Notes for potential reviewers

  • Volunteering is not a guarantee that you will be asked to review. There are many reasons: reviewers must be qualified, there should be no conflicts of interest, a minimum of two reviewers have already accepted an invitation, etc.
  • This is NOT OPEN peer review. The review is single-blind, and all recommendations are sent privately to the Academic Editor handling the manuscript. All reviews are published and reviewers can choose to sign their reviews.
  • What happens after volunteering? It may be a few days before you receive an invitation to review with further instructions. You will need to accept the invitation to then become an official referee for the manuscript. If you do not receive an invitation it is for one of many possible reasons as noted above.

  • PeerJ Computer Science does not judge submissions based on subjective measures such as novelty, impact or degree of advance. Effectively, reviewers are asked to comment on whether or not the submission is scientifically and technically sound and therefore deserves to join the scientific literature. Our Peer Review criteria can be found on the "Editorial Criteria" page - reviewers are specifically asked to comment on 3 broad areas: "Basic Reporting", "Experimental Design" and "Validity of the Findings".
  • Reviewers are expected to comment in a timely, professional, and constructive manner.
  • Until the article is published, reviewers must regard all information relating to the submission as strictly confidential.
  • When submitting a review, reviewers are given the option to "sign" their review (i.e. to associate their name with their comments). Otherwise, all review comments remain anonymous.
  • All reviews of published articles are published. This includes manuscript files, peer review comments, author rebuttals and revised materials.
  • Each time a decision is made by the Academic Editor, each reviewer will receive a copy of the Decision Letter (which will include the comments of all reviewers).

If you have any questions about submitting your review, please email us at [email protected].