The screen above shows GRC's web-based secure logon system built around the Perfect Paper Passwords system. In GRC's implementation, the presence of a secure permanent roaming authorization cookie enables the SSL display of this page and simultaneously identifies the machine's authorized user. This information is used to lookup the user's name (for prompting display on the logon page), 256-bit PPP sequence key, and the ordinal of their next passcode.

In keeping with recommended practice, the user's unchanging secret passphrase and the PPP passcode are solicited together to prevent a "divide and conquer" attack from brute forcing their passphrase if it is insufficiently strong.

• To guard against impersonation damage resulting from the theft of the authentication database, and in keeping with standard best-practice security policies, the SHA256 hash of the user's logon passphrase — never the passphrase itself — should be stored and used to authenticate user logons. This prevents an attacker who might obtain the authentication database from being able to authenticate as a valid user since the attacker would have no means for entering a passphrase that hashes to the user's stored SHA256 value.

  In other words, the authentication database for each user would consist of the following four items:

  • Account Username. (Identifies user and locates the authentication data.)
  • SHA256 hash of the user's logon passphrase.
  • 256-bit pseudo random sequence key assigned to this account.
  • 128-bit ordinal of the account's next expected passcode.
  • Highest passcard ever requested for printing.
• To thwart dictionary or brute-force logon passphrase guessing, the system should prompt the user for their next passcode even if the hash of their provided logon passphrase does not match. Although this prevents providing the helpful feedback diagnosis of "wrong passphrase" errors separate from "wrong passcode", it helps to limit the success of attacks against weak passphrases. If an attacker were able to independently confirm their guess of a user's (weak) passphrase, that could create motivation for the attacker to pursue obtaining the account's passcard and passcode list. So it's better to simply say "Account logon passphrase or current passcode were incorrect, please try again" even though the system knows which one was wrong.
• To help users remember to print out new passcards in advance of having them "run out" of passcodes, the authentication system should maintain a record of the highest numbered passcard ever requested for printing (see the simple database schema above) and warn the user any time they authenticate near the end of what might be their last printed passcard.
• Even though we have a secure one-time password system, the best policy is to always minimize the opportunity for information disclosure. So the system should only perform logon operations over secure SSL connections.