## 20210626 AK ---- [[Support/PasswordRecoverywithAssurance/CZ|česky]] | [[Support/PasswordRecoverywithAssurance/DE|deutsch]] | '''english''' | [[Support/PasswordRecoverywithAssurance/FR|français]] | [[Support/PasswordRecoverywithAssurance/IT|italiano]] | [[Support/PasswordRecoverywithAssurance/NL|nederlands]] | [[Support/PasswordRecoverywithAssurance/PL|polski]] ---- = Support: Password Recovery with Assurance Procedure (WIP) = '''[[FAQ/LostPasswordOrAccount|Other possibilities to recover your password]]''' 0. 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 === {{{#!wiki note ||<#FFFF00> This modified method is used in practice now (2021): || 1. The character sequence (A-word) will be jointly created by an Assurer and Assuree as a result of assurance or re-assurance, and will be written to the CAP form and forwarded to the Assuree on a piece of paper (such as a working business card). 1. The Assurer sends to the Support the primary e-mail address of the Assuree, the entire A-word and the message whether or not s/he was able to enter the assurance into the system. 1. The Support Engineer (SE) sends to the Assuree a call for authorization and selects a part of the A-words of 3-6 characters, from the beginning or end. We will refer this part as A1, and the rest of the A-word as A2. SE is allowed to choose any part of 3-6 characters from the A-word as A1, if s/he wants to do so. 1. If the Assuree approves the password recovery/reset, s/he sends the reply with a confirmation of password recovery/reset to the Support. 1. If the Assurer have assured that Assuree anytime before, s/he cannot enter another assurance to the system, then support engineer asks the Assurer the following information about the Assuree: * Primary e-mail address * Full name * Date of birth 1. The support engineer shall compare data sent by the Assurer with the Assuree's account data. 1. A2 is generally disjunctive with A1, but if the A-word is too short, some characters of A1 can be included in the resulting password. However, the easiest way is to divide the A-word with "one cut" into two parts. 1. SE sends an e-mail containing the T-word (he has created) and connection order (A2 + T or T + A2) to the Assuree. It does not send A2, but A1 with the instructions on how to assemble the password. The Assuree knows A2, gets the T-word, and s/he has got instructions how to assemble the new temporary password. 1. Support Engineer documents password recovery to the [[Arbitration/A20100407.1]]] Advantages of this procedure: 1. The new password is fully assembled only by the SE and by the Assuree. The whole new password does not transfer anywhere. 1. Even the Assurer doesn't know the resulting new password. 1. The assurance excludes the possibility that someone changes the password of another user. 1. The encrypted communication is not required. 1. If someone redirects or controls anybody's account including the corresponding primary address, that person does not receive the new password. Only the Assuree gets it, and thus only s/he is able to get his/her account back. It is recommended that the Assuree should change the account password again, immediately after the first login. }}} 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 1. 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 1. Support Engineer sends an authorisation request to the Assuree with a confirmation word (C-Word) which should be included into the reply 1. If Assuree approves the password reset, she/he sends a reply to Support confirming the password reset and including the C-Word 1. 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 1. Support Engineer checks authorisation and details from Assurer against details from Account 1. On match the Support Engineer sets the password of the Assuree to A-Word+T-Word (T-Word is chosen by the Support Engineer) 1. The Support Engineer sends an email to the Assuree containing T-word 1. The Support Engineer documents the execution of the Password Recovery at [[Arbitrations/a20100407.1]] === Part I.2 - Implementation Details for Each Step === {{{#!Wiki note * 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 1. Assurer -> Support (A-Word) * The email should be signed and include a [[AssuranceHandbook2#CAcert Assurer Reliable Statement - CARS|CARS]]. It must be at least signed or include a CARS. {{{ Sample: From: To: Subj: Password Recovery with Assurance I've met Assuree at for Password Recovery with Assurance. I've finished/didn't pass x1) the Assurance by entering the Assurance into the Online system. Name: Email: A-word: CARS x1) if didn't pass: why you didn't pass? Probably you should file a dispute }}} 1. 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 1. Assuree -> Support (C-Word) 1. 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 1. 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 {{{#!wiki note 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 <>}}} {{{#!wiki note 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 <>}}} * The scan should be sent by encrypted email (''See above: how to send encrypted mail to Support?'') 1. 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 1. 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'''. 1. 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 1. 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 1. 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 1. Assuree -> Support (C-Word) * Belongs to the process of confirmation started in the step before 1. 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 1. 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 1. 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 1. 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 ==== a. Mallory is able to forge unsigned mails in a way that they seem to be from a different person (very likely) a. 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 1. Support sends C-Word to Mallory 1. Mallory replies C-Word 1. Support Engineer checks whether there are Assurances from Bob on Mallory's account a. There are none -> '''Caught''' a. There is one but it is older than one month -> Support Engineer asks Bob if the Assurance was done with password reset -> '''Caught''' a. There is one and it is within the last month 1. Support Engineer sets the password to A-Word + T-Word 1. Support sends T-Word to Mallory 1. Mallory knows A-Word (chosen by herself) and T-Word and can access her account again a. 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) * 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) * 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) * 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 {{{#!wiki note The Assurer should send the user data per signed email to Support using [[#template|this template text]] -- MichaelTänzer <>}}} {{{#!wiki note only after request by SE. Default: Assurer sends only A-word and primary Email address of Assuree -- UlrichSchroeter <>}}} * 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 1. Support generates T-Word 1. Support sets Alice's password to A-Word+T-Word 1. Support sends T-Word to Alice 1. 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 1. 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. * {{{#!Wiki note 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 <>}}} {{{#!Wiki note 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 <>}}} == 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|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. 1. Alice arranges an assurance with (optional) password reset with Bob the Assurer. 1. During assurance, Alice and Bob create A-WORD 1. (Bob could also advise Alice on how to look after her passwords...) 1. A-WORD is recorded on Bob's CAP form, and on a card given to Alice. 1. Alice keeps her A-WORD on a business card until advised that the Assurance has been done. 1. Assurer marks the A-WORD as entered (this part should work even if Bob already assured Alice.) {{{#!wiki note I can't see a reason why Bob should mark A-WORD as entered. Drop this step? -- MichaelTänzer <>}}} 1. 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.) 1. Assurer marks the A-WORD as entered on CAP form. 1. If Bob decides not to assure, he should not enter A-WORD. 1. 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. 1. T-WORD is mailed to Alice (her primary email address). 1. When Alice receives the mail, 1. Alice goes to site, enters the "Password-Recovery-With-Assurer" feature, probably by clicking on the URL. 1. Alice enters A-WORD and T-WORD in separate boxes, clicks. {{{#!Wiki note If T-WORD is the URL the T-WORD should not be filled into a box of course. -- MichaelTänzer <>}}} 1. If they match, system offers password reset. {{{#!Wiki note 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 <>}}} 1. On password reset, system: 1. Notifies all known email addresses. 1. Offers chance to reset questions? {{{#!Wiki note Maybe link to that option but no extra implementation effort needed. -- MichaelTänzer <>}}} 1. Suggests that Alice writes her password down somewhere offline and safe. {{{#!Wiki note 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 <>}}} {{{#!Wiki note 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 <>}}} 1. 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 ==== {{{#!Wiki note (At this point CAcert Support has not even looked at the account yet.) }}} {{{#!Wiki note I'd prefer if the C-keyword used is some detail in the account. So that detail only travels one way, ASSUREE->SUPPORT and is later verifiable on the account. <
>For example ask for one of the other email addresses, or one of the domains. -- JSteijlen <>}}} {{{ Hello CAcert Support has received an email stating that you requested a Password Recovery with Assurance [1] at . Could you please confirm that: 1) You would indeed like to have your password reset. 2) Please use somewhere in your reply. and 3a) That you have the A-keyword agreed upon with . (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 . (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 . (Please don't send me that keyword, the length of that string will suffice. [1] http://wiki.cacert.org/Support/PasswordRecoverywithAssurance -- Kind Regards CAcert support }}} ==== Confirmation of change ==== {{{#!Wiki note . This should be sent to ALL email addresses associated with the account. . The T-keyword should be longish and somewhat annoying, making the user '''want''' to change his password soonest. }}} {{{#!Wiki caution The T-Word should only be sent to the primary email address, all other email addresses should be notified but not sent critical information -- MichaelTänzer <> }}} For mail to primary email address use: {{{ Hello Your password has been changed. It has been set to: A-keyword by hyphen T-keyword by support: "$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$" -$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ Please regard, "" 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 CAcert support }}} For mail to additional email addresses use: {{{ Hello Your password has been changed. It has been set to: A-keyword by hyphen T-keyword by support: "xxxxx" (see mail to your primary email address) - 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 CAcert support }}} ---- . CategorySupport