Password managers, and numerous tools have been created to store end-user secrets over the years. This proliferation has resulted in a hazy mix of opportunities to improve security.

In short, I think this could be broken into the following groups. (alternative scenarios wanted)

  • Local Authentication (w/no implicit network rights) (semi-transferrable secret)
  • Network Authentication (with implicit network rights) (semi-transferrable secret)
  • Hardware Authentication (non-transferrable secret) for use with either above scenario

I'm trying to create a risk diagram of where authentication credentials can be stored, and what are the risks/threats of each approach.

The goal is to give an application developer, or security consultant a guide on the where an end user should store private keys and unhashed passwords should be stored for nonrepudiation purposes.


What local authentication patterns exist, and what are the relative strengths in guaranteeing nonrepudiation?

1 Answer 1


This is an compendium of authentication methods. I hope someone completes this map, and scopes it appropriately for nonrepudiation.

Most of my security knowledge is based in iOS, but input on other platforms is welcome.

Local only authentication

The key difference is that remote attacks (SSH/RDP/HTTP 401 Unauthorized) aren't possible even if the remote user has all the correct information. The benefit here is that if the person is in physical control of the device, then the device itself acts as "something they have", and less stringent security rules may apply.

In addition, sometimes this authentication credential isn't directly convertible into an authorization token.

Depending on if the private key material is hardware secured (next section) it may escalate privileges by accessing a secure storage on the device. Not sure if this distinction is worth noting since I haven't observed network authentication that leverages this security feature.


  • Windows Hello as face recognition
  • Windows Hello as pin entry
  • Windows Hello as picture unlock
  • Windows Hello as Thumbprint


  • Pattern unlock
  • Pin unlock
  • Thumbprint


  • Thumbprint
  • Pin code

Apple Watch

  • Pin Code
  • Wrist detection

Hardware Secured

This is where private keys are non-transferrable, and/or the validating algorithm is secured by hardware. Private key extraction may provide physical indications of trespass, and may risk rendering the authentication device itself inoperable.

None of these modes are usable across the network.

These authentication modes build on the previous local authentication methods.

Hardware Secured Part 2

I'm not sure how to classify smartcards, since in RDP it's possible to authenticate to a remote machine through another machine. I need to do more analysis of how a Smartcard private "proxy" works in contrast to other "proxy" solutions that could theoretically be used in the previous section

  • Smartcards

Software Secured via the OS

This is where the OS provides a measure of security. Jailbroken or rooted devices may compromise security guarantees otherwise available.

These may be conditionally transferrable outside of the trusted ecosystem (some more easily than others).


  • Private storage per application
  • Application Groups
  • iCloud synchronization of private storage
  • SMS messages (iMessage has no 3rd party hooks; Android does)
  • Browser based Same Origin policy (Bearer tokens, remember me cookies, SOP, HTML Local Storage)
  • Safari app-to-website synced password via iCloud


  • TPM-based devices?
  • LiveID / Passport authentication
  • Browser based Same Origin policy
  • Browser-based local password caching (Chrome, IE, FireFox)


  • Chrome password synchronization to passwords.google.com'


  • SMS passwords/one time codes could be intercepted by 3rd party applications

Software Secured/Password managers

In many cases a password manager either provides "an additional place to look" for these transferrable/bearer tokens, and doesn't provide the same level of integrity that the hardware secured secrets provide, and doesn't have OS level guarantees.

  • HOTP/TOTP in software, such as Google Authenticator (it keeps the key somewhere), and Facebook authorization codes (depending on where the app stores the key, and if the device is Jailbroken/rooted)
  • Lastpass, Avast, 1Password can store the password database in DropBox, which makes it pretty easy for a 3rd party dropbox application to gain access to the file, and brute force the credentials. (OAuth tokens by 3rd party clients often request full access, not scoped)


The backups can be weakly encrypted on a compromised computer, or other device which can then be used to take all bearer tokens, or non-"local only"

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .