[messaging] Password reset mechanisms with an SRP authentication framework

[Peter Gutmann]

Dave Baggett <dmb at arcode.com> writes:

>So I'm soliciting clever ideas for ways to improve the usability without
>changing the fundamental security properties.

Force users to print out recovery information (e.g. a two-part key share) as
part of the sign-up process, and tell them to treat it like they're treat
their passport (this is assuming it's web-based, so you generate a printable
web page that contains the information they need).  Allow them to skip it, but
only with the direst warnings.  To quote the book I'm working on:

  To protect against lost passwords you can either advise them to write down a
  second copy and keep it with other long-term important documents like their
  birth certificate and insurance paperwork (as with the earlier credit-
  card/passport metaphor these are familiar things that people inherently know
  how to deal with) or you can make the whole process explicit and have them
  print out a form containing their main password and a backup recovery
  password that you assign to them in the same way as the main password.

  You’re going to have to be pretty forceful with this, for example by
  building the operation into the workflow of setting up a password, otherwise
  people won’t do it.  This is exactly what Microsoft found out with their
  Bitlocker recovery keys, which people are encouraged to print out and store
  somewhere safe when they’re setting up the encryption.  No-one does [ ].

  The printed form contains instructions to cut it in half and store the two
  parts as appropriate, a type of procedure that’s standard operating practice
  for many businesses where availability is as important or even more
  important than security.  To guard against business-continuity problems the
  business records a backup copy of passwords used by employees and stores
  them in a safe location where they can be accessed in case of an emergency.

  Another situation in which this type of paper-based backup is useful is in
  the case of the incapacity or death of the original password holder.  Before
  the widespread use of computers, taking care of someone’s estate used to
  involve little more than dealing with a will and possibly figuring out which
  safety deposit box the unlabelled key belonged to, but today it can involve
  tracking down arbitrary numbers of accounts, passwords, and encryption keys
  .  By recording key backup data in hardcopy form and storing it in a safe
  place (or split across several places), it’s possible to provide for
  recovery and continuity if something ever happens to you.

  If you assign a recovery password in this manner, make it a true recovery
  password rather than just an alternative to the main one.  When the user
  logs on with the recovery password they’re assigned a new primary and
  recovery password as they were when they signed up, and the previous
  passwords are disabled.  If you’re the sort of organisation that sends out a
  monthly printed statement, record the details of the password change (or
  changes) on the statement.  Printed statements are the single most effective
  account audit mechanism that there is (see the discussion in “Password
  Lifetimes” on page 542) and if there’s a problem then you want to give your
  users every chance of noticing it and reporting it.

  In addition if there’s payment information like credit card details stored
  with the account data, delete it when the password is reset so that an
  attacker who compromises the password reset mechanism doesn’t gain much from
  the newly-acquired account, and let the user know why they’re being asked to
  re-enter their payment details (some sites already enforce similar security
  measures when you do things like change your shipping address, requiring
  that you re-enter your credit card information as an additional
  authentication step).

Peter.