Abstract
Currently, losing a security token places the user in a dilemma: reporting the loss as soon as it is discovered involves a significant burden which is usually overkill in the common case that the token is later found behind a sofa. Not reporting the loss, on the other hand, puts the security of the protected account at risk and potentially leaves the user liable.
We propose a simple architectural solution with wide applicability that allows the user to reap the security benefit of reporting the loss early, but without paying the corresponding usability penalty if the event was later discovered to be a false alarm.
I. Goldberg—On sabbatical at the University of Cambridge Computer Laboratory while working on this topic.
This is a preview of subscription content, log in via an institution.
Buying options
Tax calculation will be finalised at checkout
Purchases are for personal use only
Learn about institutional subscriptionsNotes
- 1.
To those objecting that reporting the loss freezes the account and prevents the user from logging in, we point out that, having lost the token, the user is unable to log in whether or not they report the loss.
- 2.
The yellow button is logically a switch with two states, “alert on” and “alert off”; so the “yellow alert” state stays on until explicitly revoked. The red button, instead, is logically more akin to a “trigger” button that can be used to fire off an alert but not to say when the alert is over (it will be over when the replacement token is shipped to the user). So if the yellow button is implemented by sending an SMS, then another SMS must be sent to unpress the button. A timeout would also work but would be less secure and would remove control from the user and we therefore advise against it.
- 3.
Defined as the in-cloud servers that the yellow and red buttons respectively talk to, and that consequently issue “account freeze” or “account revocation” commands to the servers on which the user accounts are hosted. This level of indirection is necessary when one token unlocks accounts on distinct servers. We shall explore this idea further in the next section.
- 4.
- 5.
So when Alice loses her Pico and presses the yellow button, thus writing hundreds of revocations to the bulletin board, the NSA learns that Alice lost her Pico, but is none the wiser about what services she has accounts with.
References
Bonneau, J., Preibusch, S., Anderson, R.: A birthday present every eleven wallets? the security of customer-chosen banking PINs. In: Keromytis, A.D. (ed.) FC 2012. LNCS, vol. 7397, pp. 25–40. Springer, Heidelberg (2012). doi:10.1007/978-3-642-32946-3_3
The Free Software Foundation: The GNU Privacy Handbook (1999). https://www.gnupg.org/gph/en/manual/c14.html#REVOCATION
Stajano, F.: Pico: no more passwords!. In: Christianson, B., Crispo, B., Malcolm, J., Stajano, F. (eds.) Security Protocols 2011. LNCS, vol. 7114, pp. 49–81. Springer, Heidelberg (2011). doi:10.1007/978-3-642-25867-1_6
The authors with a Cambridge affiliation are grateful to the European Research Council for funding this research through grant StG 307224 (Pico). Goldberg thanks NSERC for grant RGPIN-341529. We also thank the workshop attendees for comments.
Author information
Authors and Affiliations
Corresponding author
Editor information
Editors and Affiliations
Rights and permissions
Copyright information
© 2017 Springer International Publishing AG
About this paper
Cite this paper
Goldberg, I., Jenkinson, G., Llewellyn-Jones, D., Stajano, F. (2017). Red Button and Yellow Button: Usable Security for Lost Security Tokens. In: Anderson, J., Matyáš, V., Christianson, B., Stajano, F. (eds) Security Protocols XXIV. Security Protocols 2016. Lecture Notes in Computer Science(), vol 10368. Springer, Cham. https://doi.org/10.1007/978-3-319-62033-6_19
Download citation
DOI: https://doi.org/10.1007/978-3-319-62033-6_19
Published:
Publisher Name: Springer, Cham
Print ISBN: 978-3-319-62032-9
Online ISBN: 978-3-319-62033-6
eBook Packages: Computer ScienceComputer Science (R0)