Financial Crypto and Data Security – Mar. 3, 2011
Mercury: Recovering Forgotten Passwords
Using Personal Devices

M. Mannan
NSERC PDF, University of Torontom.mannan@utoronto.ca

Collaborators: D. Barrera, C.D. Brown, D. Lie, P.C. van Oorschot
M. Mannan

Mar. 3, 2011

1/24

Why do we need password recovery?

none is immune to forgetting
recall-based authentication needs reset/recovery

M. Mannan

Mar. 3, 2011

2/24

Why recovery must be secure?
“So in war, the way is to avoid what is strong and to strike atwhat is weak.” (The art of war, 6:30)

Recovery/reset techniques are weaker than password?

M. Mannan

Mar. 3, 2011

3/24

Recovery vs. reset
In many cases users are forced to choose a new password
 lack of a secure transmission channel for passwords?
 cleartext passwords are not stored?
... but good passwords are not easy to generate
Our focus: recover the original password

M. Mannan

Mar. 3, 20114/24

‘I forgot my password’: now what?
1. Small, local env: ask the admin (secure, not scalable)
2. Large org, networked env: email, PVQ (scalable, insecure)– help desk calls are expensive

Our design goals: scalable, secure, deployable

M. Mannan

Mar. 3, 2011

5/24

State of the art
1. Password managers: in all platforms
2. Email, SMS, phone: ownership, “secure” media
3. Personal verification questions (PVQs): more secrets!
 related: Facebook social auth, Blue moon

No academic proposals for recovery?

M. Mannan

Mar. 3, 2011

6/24

Password managers
1. Online encrypted storage (LastPass)
2. Offline encrypted storage (KeePass)
3. Issues:– trust: third parties?
– password update: extra step?
– master password: weak or none?

M. Mannan

Mar. 3, 2011

7/24

Email password reset/recovery
1. Widely used
2. Issues:– trust email providers– trust ISPs, wifi providers– check spam, keep waiting...
– reset vs. recovery

M. Mannan

Mar. 3, 2011

8/24

Facebook social auth
1. Used for account verification– e.g., Captcha replacement
2. Issues:– abstract/pet images– barely known friends– privacy issues?

M. Mannan

Mar. 3, 20119/24

Blue moon: preference-based authBetter than regular PVQs?

... but no password recovery
M. Mannan

Mar. 3, 201110/24

Our proposal: Mercury
1. Key idea use end-to-end encryption for safe password retrieval
2. Mechanism
 user generates a key pair for password recovery
 shares the public key with a site during account setup
 the site sends encrypted password during recovery

M. Mannan

Mar. 3, 201111/24

Mercury: components
1. User PC (i.e., the primary login machine)
2. Remote server
3. Personal mobile device (PMD) – for portability
4. Mercury software on: PC + PMD + Server
5. Local communication channel: PC ↔ PMD

M. Mannan

Mar. 3, 201112/24

Mercury: design features and usage
1. Key design features– use familiar technologies:
smart-phones, QR codes– personal-level public keys, but no PKIs
2. Examples: online accounts, desktop password recovery

M. Mannan

Mar. 3, 201113/24

Mercury: steps
1. Key generation and backup
2. Key sharing
3. Password recovery

M. Mannan

Mar. 3, 2011

14/24

Key generation: personal objects

see also: Object-based password (HotSec’08)
M. Mannan

Mar. 3, 2011

15/24

Key generation: random seed1. Same seed ⇒ same keys
2. Save offline: print the QR coded seed

M. Mannan

Mar. 3, 2011

16/24

Key sharing with remote parties
1. Users can upload the public key from the primary PC unique key per site, or one key for all sites
2. Keys can be sent directly from the PMD

M. Mannan

Mar. 3, 201117/24

Password recovery steps
User (U )IDU , “forgot my password”

Server (S)/m = encode({P }EpubU )Retrieves P , pubUoU transfers m to PMD,
retrieves P = {decode(m)}DprivU

What if: the server does not store cleartext password?
M. Mannan

Mar. 3, 2011

18/24

Server-side password storage
1. Original password (plaintext or encrypted)
2. Hashed password
 store public-key encrypted password
 use reset password

M. Mannan

Mar. 3, 201119/24

PC-to-device channel examples
1. QR code: requires camera
2. Audio: universal availability
3. Direct email access from device

M. Mannan

Mar. 3, 2011

20/24

Features, advantages
1. Secure recovery: allows users to keep the same password
2. No third parties: user↔password↔server
3. Password update remains the same (for the primary mode of Mercury)
4. Key restoration after device update: usability?
5. Cheap two-factor auth (sort of)

M. Mannan

Mar. 3, 201121/24

Limitations
1. Require: server-side assistance +personal device (optional)
2. Device issues: compromised, lost, stolen
3. User level key management
 leaked keys, key-gen objects

M. Mannan

Mar. 3, 201122/24

Mercury Android app and test website(a) startup(b) web-based recovery(c) decrypted passwd

M. Mannan

Mar. 3, 201123/24

Open issues
1. How to bring service providers on-board?
 trusted third parties – Google/Firefox Sync?
2. What more can we do with user-level public keys?
 pk-based auth?

Android app and test site:
http://www.ccsl.carleton.ca/software/mercury/

M. Mannan

Mar. 3, 201124/24