• Support
• PasswordRecoverywithAssurance

česky | deutsch | english | français | italiano | nederlands | polski

Support: Password Recovery with Assurance Procedure (WIP)

Other possibilities to recover your password

1. Definitions

   • Assuree	person who gets assured and in this case request the password reset
     Assurer	person who is verifying the identity of the assuree

     A-Word	The A-Keyword (Assurance-Keyword) that is exchanged between Assuree and Assurer
     C-Word	The C-Keyword (Confirmation-Keyword) that is mailed back to the Support Engineer by the Assuree to confirm the password reset
     T-Word	The T-Keyword (Transaction-Keyword) that is exchanged between Support Engineer and Assuree

Part I - Procedure w/o System integration

Part I.1 - Procedure for Password Recovery through Assurance

1. A passphrase (A-Word) should be created between Assuree and Assurer as the result from an Assurance or re-Assurance and to be kept on the CAP form and on a second piece of paper (e.g. business card) given to the Assuree
2. Assurer sends to Support the primary email address of the Assuree, the A-Word and whether he was able to enter the Assurance into the system
3. Support Engineer sends an authorisation request to the Assuree with a confirmation word (C-Word) which should be included into the reply
4. If Assuree approves the password reset, she/he sends a reply to Support confirming the password reset and including the C-Word
5. If Assurer assured Assuree before and therefore couldn't enter another Assurance in the system, the Support Engineer requests the following data about the Assurance from the Assurer:
   • Primary Email Address of the Assuree
   • Full Name of the Assuree
   • Date of Birth of the Assuree
6. Support Engineer checks authorisation and details from Assurer against details from Account
7. On match the Support Engineer sets the password of the Assuree to A-Word+T-Word (T-Word is chosen by the Support Engineer)
8. The Support Engineer sends an email to the Assuree containing T-word

9. The Support Engineer documents the execution of the Password Recovery at Arbitrations/a20100407.1

Part I.2 - Implementation Details for Each Step

• • What the Assurer and Assuree should know for the Face-2-Face meeting is explained in step 1 and 2.
  • The rest is triggered by Support

    Where	Who	Tasks
    Face-2-Face Meeting	Assuree, Assurer	regular Assurance additional A-word defined between Assuree and Assurer
    @home	Assurer	finish assurance by entering the assurance into the online form send email to support@cacert.org with Subject Password Recovery with Assurance, with Assurees Name and Email, with A-word as explained under step 2

1. Assurance
   • The A-Word should be agreed upon by both parties and must be at least six characters long
   • The A-Word should only contain printable US-ASCII characters as to avoid problems with broken character encoding
   • The A-Word could be recorded on a different medium than paper but it has to be off-line
   • If paper is used care should be taken when writing it down (like clear marking capitalisation and similar looking characters)
   • It should be kept in mind that this password maybe has to be entered manually

2. Assurer -> Support (A-Word)

   • The email should be signed and include a CARS. It must be at least signed or include a CARS.

     • Sample:
         From: <assurer's email>
         To: <support email>
         Subj: Password Recovery with Assurance
         I've met Assuree at <location, date> for Password Recovery with Assurance.
         I've finished/didn't pass x1) the Assurance by entering the Assurance into the Online system.
         Name:  <name assuree>
         Email: <email assuree>
         A-word: <A-word>
         <name assurer>
         CARS
       x1) if didn't pass: why you didn't pass? Probably you should file a dispute

3. Support -> Assuree (C-Word)

   • The C-Word should be chosen by random
   • The C-Word should only contain printable US-ASCII characters as to avoid problems with broken character encoding

4. Assuree -> Support (C-Word)

5. Support <-> Assurer (details from Assurance)

   • Need not be done if the Assurer was able to enter the Assurance in the system

   • The email containing the data should be encrypted (How to send encrypted mail to Support? Use an SE's personal address? BernhardFröhlich)

   • The email must be signed
   • Only the data explicitly listed in this step should be sent
6. Check details
   • If the Assurance was entered into the system the date has to be checked, if the Assurance was too long ago (more than one month) the Assurer should be asked to confirm that this was the Assurance done with password reset or if this is not the case send the details from the CAP form (see previous step)
   • If the details don't match, the Support Engineer may ask the Assurer for a scan of the CAP form to check whether there were errors in the transformation from handwriting to email in the previous step.
     • The scan should be provided in JPG, PNG, BMP or PDF format if possible

       My rationale to not include PDF in this list was that some PDFs are not properly displayed in every viewer and the Adobe Reader has a huge history of exploits. Apart from that, scans are always bitmap graphics and thus the features of the PDF format (vector graphics, "real" text, etc.) are not used anyway. JPG, PNG and BMP have very complete implementations and exploits have been rare. Also this formulation doesn't say under no circumstances PDF may be used, just that we prefer the others and if someone really only has PDF as the only possibility he may use that.

       -- MichaelTänzer 2010-04-17 12:52:11

       • From Arbitration experiences on requesting CAP form scans 5 of 6 scans are sent as PDF's w/o exploits and w/o problems reading the scans. The other one was JPG. The question here: there are problems, you have to resolve. So if you start by offering any formats, you have to offer the most used ones ... and that are: PDF, JPG. At this step its better to make no preferences, to get the least result ...

         -- UlrichSchroeter 2010-04-18 04:36:00

     • The scan should be sent by encrypted email (See above: how to send encrypted mail to Support?)

7. Set password
   • The T-Word should be chosen by random
   • The T-Word should only contain printable US-ASCII characters as to avoid problems with broken character encoding
   • A-Word + T-Word means the new password is produced by appending the characters of the T-Word to those of the A-Word

8. Support -> Assuree (T-Word)

   • Support must notify all registered email addresses of the account that the password reset has happened
   • Support should give instructions how to combine A-Word and T-Word to get the temporary password
   • Support must advice the Assuree to change the password after regaining access to the account

   • Support should suggest that the Assuree writes the new password down somewhere off-line and safe.

9. Document the execution
   • Support must keep an audit trail of all cases handled according to this procedure

   • This is done by adding an entry containing the date of execution and the support ticket number to the table at the bottom of Arbitrations/a20100407.1

Part I.3 - Risks

Mallory

The attacker in the scenario

Risks prevented by each step

1. Assurance

   • The A-Word shared on the (Re-)Assurance is created out of band and requires reverification of the identity of the Assuree -> it should not be possible for a third person to impersonate the Assuree

   • Recording the A-Word on some medium prevents forgetting the A-Word until it is used
   • The A-Word should be long enough to prevent guessing

2. Assurer -> Support (A-Word)

   • The Assurer acts as the link from the Assuree to CAcert therefore his mail should be signed, if it's not the Assurance entered in the system serves as indication of the authenticity of the mail from the Assurer -> it should not be possible to impersonate the Assurer

3. Support -> Assuree (C-Word)

   • The confirmation ensures that the owner of the primary email address of the Assuree (which should be the Assuree himself) agrees to the password reset -> it should not be possible for the Assurer to impersonate the Assuree

   • Choosing the C-Word randomly prevents the Assurer from guessing it

4. Assuree -> Support (C-Word)

   • Belongs to the process of confirmation started in the step before

5. Support <-> Assurer (details from Assurance)

   • If the Assurer couldn't check the information of the Assuree because he already assured the Assuree before the Support Engineer has to do that step for him -> the identity which was confirmed in the Assurance really belongs to the account

   • For privacy reasons the data must not be requested if the Assurance was entered in the system
   • For privacy reasons the email containing the data of the Assurance should be encrypted
   • The email from the Assurer must be signed so the Support Engineer can verify that it was sent by him
   • For privacy reasons no more data than needed should be sent
6. Check details

   • Checking the date gives the information whether the Assurance recorded in the system was the one with the password reset -> prevents turning a normal Assurance into one with Password reset in hindsight

   • If a scan is requested it should be sent encrypted email for privacy reasons
7. Set password
   • A-Word is only set into the new password and not checked by email as to reduce the number of times it is sent "over the wire"
   • The new password contains T-Word so the Assurer is not able to log into the account of the Assuree (he doesn't know T-Word but he does know A-Word)
   • The new password contains A-Word to prevent someone who was able to read the message which contained T-Word to log into the account of the Assuree
   • T-Word is chosen randomly as to prevent the Assurer from guessing it

8. Support -> Assuree (T-Word)

   • Notifying all registered email addresses of the account prevents that someone could gain access to the primary email address and go through the password reset process unnoticed
   • The password has to be changed as soon as possible since it has been sent over email (in two parts but nevertheless, probably even unencrypted), it's known to the Support Engineer and recorded in the ticket system used by support
   • Advising the Assuree of proper password handling should prevent further password reset requests

Someone other than the real user (maybe a malicious Assurer) requests a password recovery

1. Mallory is able to forge unsigned mails in a way that they seem to be from a different person (very likely)
   1. Mallory has an account and wants to reset the password but does not want to make an assurance (e.g. because she used false documents on the previous assurances and doesn't want to risk being caught)
      1. Mallory forges the mail from the Assurer Bob containing the primary email address of her account, an A-Word of her choice and stating that the Assurance has been entered in the system
      2. Support sends C-Word to Mallory
      3. Mallory replies C-Word
      4. Support Engineer checks whether there are Assurances from Bob on Mallory's account

         1. There are none -> Caught

         2. There is one but it is older than one month -> Support Engineer asks Bob if the Assurance was done with password reset -> Caught

         3. There is one and it is within the last month
      5. Support Engineer sets the password to A-Word + T-Word
      6. Support sends T-Word to Mallory
      7. Mallory knows A-Word (chosen by herself) and T-Word and can access her account again
2. Before starting the 'Password Recovery with Assurance' procedure, there are several mail exchanges between the alleged Assuree (primary email address account holder) and Support

   • The identification of the real user is made through the Assurance by the Assurer -> this should fail

   • Verification happens at the moment, the Assurer compares the CAP form against the online account data
   • Support notifies all registered email addresses of the account that the password reset has happened (it's critical to the tamper proofness)
3. Someone other than the real user requests a Password Recovery

   • Before starting the 'Password Recovery with Assurance' procedure, there are several mail exchanges between Assuree (primary email address account holder) and Support. "Assuree" comes on a booth and requests Password-Recovery Procedure

   • The identification of the real user is made through the Assurance by the Assurer (known CAcert personal)
   • Verification happens at the moment, the Assurer compares the CAP form against the online account data
   • Support notifies all registered email addresses of the account that the password reset has happened (it's critical to the tamper proofness)
4. Someone other than the real user requests a Password Recovery

   • Before starting the 'Password Recovery with Assurance' procedure, there are several mail exchanges between Assuree (primary email address account holder) and Support. "Assurer" sends Password-Recovery Procedure to Support

   • The identification of the real user is made through the Assurance by the Assurer
   • Verification happens at the moment, the Assurer compares the CAP form against the online account data
   • Support notifies all registered email addresses of the account that the password reset has happened (it's critical to the tamper proofness)
5. Assurer had assured Assuree before

   • The account data is invisible to the Assurer. He cannot verify the online account data with the new data on the CAP form. All he gets is a warning message: You cannot assure someone twice

   • The only one who can compare the data from CAP form against the data in the online account is Support Engineer or another Assurer, who didn't assure Assuree before

     The Assurer should send the user data per signed email to Support using this template text

     -- MichaelTänzer 2010-04-15 17:56:48

     • only after request by SE. Default: Assurer sends only A-word and primary Email address of Assuree

       -- UlrichSchroeter 2010-04-16 04:52:34

6. Malicious Assurer Mallory wants to lock out Alice
   1. Mallory sends A-Word and Assurance information to support without Alice stating that she wants her password reset
   2. Support generates T-Word
   3. Support sets Alice's password to A-Word+T-Word
   4. Support sends T-Word to Alice
   5. Alice can't log in using A+T because she doesn't know the A-Word and tries to log in using her normal (i.e. the old) password and is rejected
   6. Alice has to do a password reset
      • Of course we can then track down Mallory and file an arbitration but why the effort if preventing it is so easy.

7. One who is doing ISP services (offer mailboxes to users) can possible access the users mailbox, so the request from Support can be answered from Malicious ISP admin on behalf of the real user. -- Dirk 2010-06-15 21:30:00

   • Step 1: User gets the A-word through assurance, doesn't write it through mail Step 2: Support requests info from user, that can be answered through malicious ISP admin Step 3: Support resets Password to a combination of A-word and T-word and sends only T-word to user Step 4: malicious ISP admin can read only half of the password from the receiving mail, problem solved.

     One side note: probably we should add, that more than one Assurer needs to be contacted, so later on Support Engineer can choose one of the A-words of the assurers as part of the temporary reset-Password, describing the user to use the A-word from Assurer #x -- UlrichSchroeter 2010-06-16 15:37:00

Part II - Procedure w/ System integration

• Not yet possible, as long there is no way to bring in new software patches into the system (2010-04-13)

• Software-Assessment is under deployment as of 2010-04-13

• http://svn.cacert.org/CAcert/Support/PasswordRecoveryWithAssurance.html

Loss of Authentication to Accounts -- Loss of passwords -- is the biggest drain on support. Getting account recovery efficient and scaled is a big business issue. The current strategy is to offer multiple methods (such as PasswordRecovery).

This method uses the power of highly trusted Assurers to provide the necessary security. It has the advantage that it scales with the Assurer base, and binds the Assurers more closely to the Members. Method Persona

• Persona	Role	Tradition
  Alice	Member who has lost her password	Alice is always the first party
  Bob	Assurer who can conduct the assist to recovery	Bob is the second party
  Carol	2nd Assurer if needed	Carol is the third party
  Trent	Trent is the system	Trent is the Trusted Third Party, traditionally this is the CA.

Part II.1 - Procedure for Password Recovery through Assurance

1. Member Alice loses her password. Bummer.
2. Alice arranges an assurance with (optional) password reset with Bob the Assurer.
   1. During assurance, Alice and Bob create A-WORD
   2. (Bob could also advise Alice on how to look after her passwords...)
   3. A-WORD is recorded on Bob's CAP form, and on a card given to Alice.
   4. Alice keeps her A-WORD on a business card until advised that the Assurance has been done.
   5. Assurer marks the A-WORD as entered (this part should work even if Bob already assured Alice.)

      I can't see a reason why Bob should mark A-WORD as entered. Drop this step?

      -- MichaelTänzer 2010-04-14 15:33:35

3. Bob completes the assurance on the online system:
   1. Bob enters A-WORD from his CAP form. (this part should work even if Bob already assured Alice.)
   2. Assurer marks the A-WORD as entered on CAP form.
   3. If Bob decides not to assure, he should not enter A-WORD.
4. When A-WORD is entered into the assurance system:
   1. System generates T-WORD (the Trent Word) as a random string, perhaps into a URL.
   2. T-WORD is mailed to Alice (her primary email address).
5. When Alice receives the mail,
   1. Alice goes to site, enters the "Password-Recovery-With-Assurer" feature, probably by clicking on the URL.
   2. Alice enters A-WORD and T-WORD in separate boxes, clicks.

      If T-WORD is the URL the T-WORD should not be filled into a box of course.

      -- MichaelTänzer 2010-04-14 15:33:35

   3. If they match, system offers password reset.

      Maybe the new password should be entered into a new box of the previous step to make this more stateless (i.e. what happens if Alice does 5.2 but then for some reason (e.g. system failure or session timed out) doesn't proceed to 5.3?)

      -- MichaelTänzer 2010-04-14 15:33:35

6. On password reset, system:
   1. Notifies all known email addresses.
   2. Offers chance to reset questions?

      Maybe link to that option but no extra implementation effort needed.

      -- MichaelTänzer 2010-04-14 15:33:35

   3. Suggests that Alice writes her password down somewhere offline and safe.

      Once we have such a password reset procedure (on every password reset the WoT gets stronger, yay) I think we should err on the safe side and not tell users to keep their password on paper except if it's really a secure place like a safe. The drawer of their desk even if it's locked by a small lock or hidden in the wardrobe between socks and undies is not considered safe enough but that's just my opinion.

      -- MichaelTänzer 2010-04-14 15:33:35

      • something went wrong before, so there is a need in starting this password-reset procedure. so therefore, to prevent this procedure again, something needs to be done. So support the user in remembering about a password that isn't that used as often

        -- UlrichSchroeter 2010-04-16 04:59:35

   4. Anything else we can think of?

Part II.2 - Implementation Details for Communications to Assurees and Assurers

• Support Notifies all known email addresses.
• Support Offers chance to reset questions?
• Support Suggests that the Alice write her password down somewhere offline and safe.

Part II.3 - Risks

• Which Assurer?
  • Can any Assurer do this? or only 50 point Assurers? Perhaps we should limit this, or watch it more closely for new Assurers.

  • An alternate is to require any two Assurers with any number of points. Hence, maybe Assurers <50 points are offered a box with A-WORD, and each Assurer enters his A-WORD and B-WORD for 50 points?

  • Then, a full (50 points) Assurer can be shown both boxes, so as to enter both A-WORD and B-WORD.
• Lost login email address?
  • How does this work if the Member can't recall their login email address? :-/ Is there a possibility to modify the process to cope? No, as the user cannot even see their account.
• Work-around until the system accepts this, Bob mails A-WORD to the support email address within a signed email. Then, Support initiates the recovery process manually.
  • Doesn't work, as long as Bob cannot verify the Assurance data with the online data

Appendix

Template Text for the Email from Assurer to Support

Please check the following details match against what you witnessed when
you met in person. You MUST NOT proceed unless you are sure the details
are correct.
You may be held responsible by the CAcert Arbitrator for any issues with
this Assurance.

Name of Assuree: John Doe
Date of birth (YYYY-MM-DD): 1970-01-01
Primary email address of the Assuree: john.doe@example.com

[X] I certify that the Assuree has appeared in person

[X] I believe that the assertion of identity I am making is correct,
complete and verifiable. I have seen original documentation attesting 
this identity. I accept that the CAcert Arbitrator may call upon me to
provide evidence in any dispute, and I may be held responsible.

[X] I have read and understood the Assurance Policy and the Assurance
Handbook and am making this Assurance subject to and in compliance with
the policy and handbook.

[X] I am a CAcert Community Member, have passed the Assurers Challenge,
have been assured with at least 100 Assurance Points and allow the
Support Team to check these facts.

Possible template Text for the Emails from Support to Assuree

Initial email

Hello <USER>

CAcert Support has received an email stating that you requested a
Password Recovery with Assurance [1] at <LOCATION>.

Could you please confirm that:
1) You would indeed like to have your password reset.
2) Please use <C-KEYWORD> somewhere in your reply.
and
3a) That you have the A-keyword agreed upon with <ASSURER #1>.
    (Please don't send me that keyword, the length of that string will
    suffice.)
3b) That you have a second A-keyword agreed upon with <ASSURER #2>.
    (Please don't send me that keyword, the length of that string will
    suffice.)
or
3..n) That you have an other A-keyword agreed upon with <ASSURER #n>.
    (Please don't send me that keyword, the length of that string will
    suffice.

[1] http://wiki.cacert.org/Support/PasswordRecoverywithAssurance

-- 
Kind Regards
<SUPPORT TEAM MEMBER>
CAcert support

Confirmation of change

For mail to primary email address use:

Hello <USER>

Your password has been changed.

It has been set to:
  A-keyword by <ASSURER #?>
  hyphen
  T-keyword by support: "$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$"

<A-keyword>-$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

Please regard, "<A-keyword>" means a template for the real A-keyword 
you got. It has to be taken without the angle brackets <>. 
The same way, the T-keyword is taken without quotes.

Please change your password as soon as possible to something else. 
You may decide to retain a copy of your new password in a secure 
location. (A home-safe or a bank-safe for example.)

And kindly reply to tell us whether you were successful or 
unsuccessful in regaining access to your account.

-- 
Kind Regards
<SUPPORT TEAM MEMBER>
CAcert support

For mail to additional email addresses use:

Hello <USER>

Your password has been changed.

It has been set to:
  A-keyword by <ASSURER #?>
  hyphen
  T-keyword by support: "xxxxx" (see mail to your primary email address)

<A-keyword>-<xxxxx>

Please change your password as soon as possible to something else.
You may decide to retain a copy of your new password in a secure 
location. (A home-safe or a bank-safe for example.)

And kindly reply to tell us whether you were successful or 
unsuccessful in regaining access to your account.

-- 
Kind Regards
<SUPPORT TEAM MEMBER>
CAcert support

• CategorySupport