* Case Number: a20100407.1 * Status: closed * Claimants: MichaelTänzer, Michelle K * Respondents: CAcert * Case Manager: LambertHofstra * Arbitrator: UlrichSchroeter * Date of arbitration start: 2010-04-08 * Date of ruling: 2010-06-13 * Case closed: 2010-06-13 * Complaint: Password Reset Procedure w/ Assurers * Relief: TBD Before: Arbitrator UlrichSchroeter (A), Respondent: CAcert (R), Claimant: MichaelTänzer (C1) Michelle K (C2), Case: a20100407.1 == History Log == . 2010-04-05 (issue.c.o) case [s20100405.21] . 2010-04-07 (UlrichSchroeter): added to wiki, request for CM / A . 2010-04-07 (A): Init mailing sent, requesting CCA / DRP acceptance from (C1), (C2) . 2010-04-07 (C1): I accept CCA and DRP. CARS. . 2010-04-08 (C2): sent reply, but w/o CCA/DRP acceptance . 2010-04-08 (A): rereq. acceptance of CCA / DRP from (C2) . 2010-04-08 (C2): I accept CCA and DRP. . 2010-04-12 (A): Discovery - Discussion proposal . 2010-04-12 (C1): Discussion proposals . 2010-04-17 (A): Intermediate Ruling . 2010-04-17 (A): Intermediate Ruling sent to (C1), (C2), (R), (CM) . 2010-06-11 (A): first practicle test with the procedure outlined in the intermediate ruling dated 2010-04-17 at [[events/LinuxTag2010|Linuxtag 2010, Berlin]] == Discovery == * The proposed Password Reset Procedure can be found here: http://svn.cacert.org/CAcert/Support/PasswordRecoveryWithAssurance.html * The Problem with the proposed Password Reset procedure is: a. Its not implemented in the System yet (3a Bob can enter the A-Word only into an email, so currently only option 3d is the current way) a. If the Assurer Bob has already entered an Assurance over Alice into a system, he cannot reenter an assurance into the system. So he also needs to go the way of option 3d a. Doing re-assurances can be done, but entereing the re-assurance into the system is currently blocked. Re-Assurances is also a concept of the co-Auditing program by not re-entering the assurances into the system. Maybe this will change some days. a. Step 4 needs to be advanced by a manual procedure initiated by Support until its implemented into the system. The manual procedure that support creates a T-Word. The URL part doesn't work currently as not implemented into the system. a. Step 5 doesn't work currently, as its not implemented in the system yet. This needs to be handled thru email in full. 5c needs to be handled by Support manualy. a. Based on the problem, that all steps currently needs to be handled thru email, Alice probably cannot send their responses with a signed email (otherwise the login with cert will work). Optional verification can be made thru a [[AssuranceHandbook2#CAcert_Assurer_Reliable_Statement|CARS statement]]. Also for the Assurer Bob. a. The problem to switch to the [[AssuranceHandbook2#CAcert_Assurer_Reliable_Statement|CARS statement]] as the reliability may also based on the Certs type the Assurer or User uses (PGP vs. X.509 cert) that I've often seen as a problem in arbitration cases. So switching to the [[AssuranceHandbook2#CAcert_Assurer_Reliable_Statement|CARS statement]] is the only option to circumvent this problem. [1] [[AssuranceHandbook2#CAcert_Assurer_Reliable_Statement]] CARS statement ==== Discussion ==== * (A) proposal for workaround w/o system integration, dated 2010-04-12 {{{ To symplify this procedure to get this procedure running there should following 6 definitions and as long there is no system implementation for the above proposed procedure: a. A passphrase should be created between Assuree and Assurer, emailed from Assurer to Support (A-Word), not longer than 8 chars as the result from an Assurance or re-Assurance and to be kept on the CAP form and on a business card from Assurer given to the Assuree b. A 2nd passphrase should be created by Support, emailed to Assuree (Password Reset candidate) (T-Word), not longer than 8 chars c. Support reset the Assuree's account password with passphrase A-Word + T-Word (the temporary password) not longer than 16 chars d. Assuree (Password Reset candidate) combines the two passphrases to the new password to access his account e. Support should advice Assuree to change his password after he get access to his account f. Emails should be sent by a signed email or with the CARS statement }}} * (C1) answer, dated 2010-04-12 {{{ > * The Problem with the proposed Password Reset procedure is: > a. Its not implemented in the System yet (3a Bob can enter the A-Word > only into an email, so currently only option 3d is the current way) > b. If the Assurer Bob has already entered an Assurance over Alice into > a system, he cannot reenter an assurance into the system. So he > also needs to go the way of option 3d. Yes, essentially replace enter into the system with send by email to support for all steps until this is implemented in the system. Support would be the first implementation. > c. Doing re-assurances can be done, but entereing the re-assurance > into the system is currently blocked. > Re-Assurances is also a concept of the co-Auditing program > by not re-entering the assurances into the system. > Maybe this will change some days. I would propose that the assurer makes the same statements as he would do in a normal assurance, just instead of entering it into the system he sends this by signed mail to support (until it's possible to enter via the system). We would need to provide an email template or something assurers can use (attached). > d. Step 4 needs to be advanced by a manual procedure initiated by > Support until its implemented into the system. The manual procedure > that support creates a T-Word. The URL part doesn't work currently > as not implemented into the system. > e. Step 5 doesn't work currently, as its not implemented in the system > yet. This needs to be handled thru email in full. 5c needs to be > handled by Support manualy. > f. Based on the problem, that all steps currently needs to be handled > thru email, Alice probably cannot send their responses with a signed > email (otherwise the login with cert will work). Optional > verification > can be made thru a CARS statement [1]. Also for the Assurer Bob. Alice can be a normal member (no assurer) therefore CARS might not work. The basic problem we are trying to solve through password recovery procedure is to reauthenticate Alice, so we can't solve this problem by signed emails or whatever. A normal email has to be sufficient. It's also not like we are only relying on an email ping, we have the identity checked by the assurer. One of the things I can see as a possible attack vector is if an assurer gets full control of the email account of another member, then he can make a false statement that he checked the identity, answer the mail with the T-word and make sure Alice never gets it. Also he would need to make sure that no notification email to all the registered addresses gets through to Alice as to not raise suspicions. But for Bob we need to make sure the email came from him. Either by verifying the signature on a signed email (we can accept both, PGP and S/MIME) or by asking back for confirmation because the email "From" header can be easily forged. Just checking for CARS is no good because for CARS to work we need to somehow verify the CARS really came from that person. CARS can only help to make clear that the statement can be relied upon but you still have to check by other means whether the statement itself was forged. > g. The problem to switch to the CARS statement [1] as the reliability > may > also based on the Certs type the Assurer or User uses (PGP vs. X.509 > cert) that I've often seen as a problem in arbitration cases. So > switching to the CARS statement [1] is the only option to circumvent > this problem. > > [1] The CARS statement => > https://wiki.cacert.org/AssuranceHandbook2#CAcert_Assurer_Reliable_Stateme > nt Support can check both, PGP and S/MIME signatures, so that should be no problem. And as described above, CARS can not replace authentication mechanisms. }}} * (C1) part 2 - discussion proposal implementation w/o system integration, dated 2010-04-12 {{{ > a. A passphrase should be created between Assuree and Assurer, emailed > from > Assurer to Support (A-Word), not longer than 8 chars as the result > from > an Assurance or re-Assurance and to be kept on the CAP form and on a > business card from Assurer given to the Assuree I think we shouldn't make statements about how long the words should be. Depending on the medium they are recorded on (or the paranoia of the persons involved) they may be longer than 8 characters. 8 characters is really short for current standards and I think we should restrict the minimum of characters not the maximum. So I'd make that "… (A-Word), at least six characters long as the result…" > b. A 2nd passphrase should be created by Support, emailed to Assuree > (Password Reset candidate) > (T-Word), not longer than 8 chars As the T-Word is sent by email it can be copied and pasted or directly included into a reply mail and therefore should be significantly longer than 8 characters for security reasons. I would say 16 characters or longer. As long as support is the "implementation" of the procedure Alice only has to hit reply to mail the T-Word back and once it's implemented in the system it will most certainly be a link that only has to be clicked on. > c. Support reset the Assuree's account password with passphrase A-Word + > T-Word (the temporary password) > not longer than 16 chars Support has to wait for verification of the T-Word otherwise if Alice didn't initiate the password reset (e.g. malicious Assurer although we hope that will never happen), her password is set to a word unknown to her and she really needs a password recovery. But we can say: "Once the T-Word has been confirmed by reply to the email, support sets the password of the account to A-Word + T-Word." Once it's implemented in the system Alice should click on the link in the email and enter A-word and a new password into the form presented there. > d. Assuree (Password Reset candidate) combines the two passphrases to the > new password to > access his account > e. Support should advice Assuree to change his password after he get > access to his account > f. Emails should be sent by a signed email or with the CARS statement We should include g. Support notifies all registered email addresses of the account that the password reset has happened This is vital to detect tampering early on, otherwise it could take months until Alice discovers her password doesn't work any more, then she tries her secret questions, which succeeds and the malicious password reset is never noticed. Assurers should be advised that capitalisations and such are critical for the A-Word and therefore special care should be taken when recording it on paper. E.g. zeros and "o"s should be distinguished by striking out zeros (so they look like this Ø), capitalisation could be made more clear by underlining capital letters. }}} * (A) discussion proposal implementation w/o system integration, dated 2010-04-12 {{{ >> b. A 2nd passphrase should be created by Support, emailed to Assuree >> (Password Reset candidate) >> (T-Word), not longer than 8 chars > As the T-Word is sent by email it can be copied and pasted or directly > included into a reply mail and therefore should be significantly > longer than 8 characters for security reasons. I would say 16 > characters or longer. As long as support is the "implementation" of > the procedure Alice only has to hit reply to mail the T-Word back and > once it's implemented in the system it will most certainly be a link > that only has to be clicked on. to prevent forgery you get no addtl. merits in let the Assuree reply the T-Word back to support .... But what you get in split the Reset Password into 2 parts ... one via Assurer, one via Support is the reliance, the Assuree has/received both parts the first part thru the face-2-face meeting with the Assurer, the 2nd half thru the Support email. The triangle: Assuree - Assurer - Support Engineer is complete. As the resulting string will be the temporary password, there needs to set some restrictions in the length of the resulting password. If the Assurer gives a string of 16 characters to the Assuree and Support creates a string of 16 characters the resulting string becomes 32 chars long. This needs to be kept in mind. [...] >> c. Support reset the Assuree's account password with passphrase >> A-Word + T-Word (the temporary password) >> not longer than 16 chars > Support has to wait for verification of the T-Word otherwise if Alice didn't initiate the password reset > (e.g. malicious Assurer although we hope that will never happen), her password is set to a word unknown to > her and she really needs a password recovery. the verification to the email with the T-word is by getting access to the account as the T-word is only one half of the temporary password. > But we can say: "Once the T-Word has been confirmed by reply to the > email, support sets the password of the account to A-Word + T-Word." > Once it's implemented in the system Alice should click on the link > in the email and enter A-word and a new password into the form presented there. where does this ominous link comes from ? The only system function I'm aware off is the verification link you'll receive in the account creation process, where the system generates a string, that will be stored into the systems database as a hash in table users column uniqueID and as long there is still an entry in this column, the user cannot use his account. I have not seen any menu option where you can trigger this function to create an uniqueID for verification. This can be an implementation feature of the not available Pwd-Recovery-Procedure. But this procedure should also work w/o the system implementation so it can be used right now. So therefor, this needs a workaround ... and the possible workaround is to use the 2 temporary password half segments for doing this. >> d. Assuree (Password Reset candidate) combines the two passphrases to >> the new password to >> access his account >> e. Support should advice Assuree to change his password after he get >> access to his account f. Emails should be sent by a signed email or >> with the CARS statement > We should include > g. Support notifies all registered email addresses of the account that the password reset has happened > This is vital to detect tampering early on, otherwise it could take months until > Alice discovers her password doesn't work any more, then she tries her secret questions, > which succeeds and the malicious password reset is never noticed. > Assurers should be advised that capitalisations and such are critical for the A-Word > and therefore special care should be taken when recording it on paper. E.g. zeros > and "o"s should be distinguished by striking out zeros (so they look like this Ø), > capitalisation could be made more clear by underlining capital letters. These are both implementation details, adding this to the main procedure makes them complex and unreadable and therefor understandable. Seperate this as addtl. implementation notes for support. -------------------------------------------------------- part 1 procedure for Password Recovery thru Assurance -------------------------------------------------------- part 2 implementation details for communications to Assurees and Assurers -------------------------------------------------------- part 3 risks to this procedure -------------------------------------------------------- e. should be moved to either part 2 or part 3 the same as g. Further I would split this pwd recovery procedure into Part I and II Part I w/o system implementation Part II w/ system implementation to make the implementation steps as simple readable as possible with addtl. implementation details seperated (restructuring the document) to show that 2 passphrases are needed, and when and where you have to use those 2 passphrases http://svn.cacert.org/CAcert/Support/PasswordRecoveryWithAssurance.html is close before coming to complex ... I had to reread the proposal 3 times to understand where and why there are 2 X-words ... and where they have to be used ... At the very end, the 2 keys are the opener to the account if entered into the system. So the workaround procedure w/o the systems integration uses those 2 keys as the halfs of the temporary password to be entered into the system. }}} * (C1) answer discussion proposal implementation w/o system integration, dated 2010-04-12 {{{ > to prevent forgery you get no addtl. merits in let the Assuree > reply the T-Word back to support .... No, but we need some verification from Alice that she wants her password reset before actually resetting it. More comments on this below. > But what you get in split the Reset Password into > 2 parts ... one via Assurer, one via Support > is the reliance, the Assuree has/received both parts > the first part thru the face-2-face meeting with > the Assurer, the 2nd half thru the Support email. > The triangle: Assuree - Assurer - Support Engineer > is complete. > > As the resulting string will be the temporary > password, there needs to set some restrictions > in the length of the resulting password. > If the Assurer gives a string of 16 characters > to the Assuree and Support creates a string of > 16 characters the resulting string becomes > 32 chars long. This needs to be kept in mind. Yes, but as far as I know the system can handle long passwords pretty well (I just tried by setting my own password to a 100 character password), so the only limitation is the user willing to enter that much characters which is mitigated by the fact that the T-Word can be copied and pasted because it's transferred via email and the A-Word is chosen by the Bob AND Alice together so they can choose whether they want a 40 characters long super secure password which they both have to enter manually afterwards or a 8 character safe enough password. Regulate where regulation is required but let the people decide where there's no need for regulation (not a motto we Germans follow very often but sometimes you have to try something different ;-)). >>> c. Support reset the Assuree's account password with passphrase >>> A-Word + T-Word (the temporary password) >>> not longer than 16 chars > >> Support has to wait for verification of the T-Word otherwise >> if Alice didn't initiate the password reset (e.g. malicious >> Assurer although we hope that will never happen), her password >> is set to a word unknown to her and she really needs a password > recovery. > > the verification to the email with the T-word > is by getting access to the account as the > T-word is only one half of the temporary password. Yes it doesn't add to the authentication part, that would be fine if we just set the password as proposed by you but we have to check whether Alice actually wants her password reset BEFORE we set the password to a new value. Otherwise a malicious password reset would lock Alice out of her account. Procedure: 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. >> But we can say: "Once the T-Word has been confirmed by reply to >> the email, support sets the password of the account to A-Word + T-Word." > > >> Once it's implemented in the system Alice should click on the link >> in the email and enter A-word and a new password into the form presented > there. > > where does this ominous link comes from ? As I said "Once it's implemented in the system". So the system would somehow generate a link and send it to Alice. This would work exactly like the confirmation mail we also use in other places (email/domain verification) with the exception that the target site would not say "Do you want to verify this email address" but "Do you want to reset the password for your CAcert account? If so enter A-word and new password" > The only system function I'm aware off is the > verification link you'll receive in the > account creation process, where the system generates > a string, that will be stored into the systems database > as a hash in table users column uniqueID > and as long there is still an entry in this column, > the user cannot use his account. > I have not seen any menu option where you can > trigger this function to create an uniqueID > for verification. > > This can be an implementation feature of the not > available Pwd-Recovery-Procedure. But this > procedure should also work w/o the system implementation > so it can be used right now. Yes, right now the T-Word would be verified by replying to that email. No change in the system required, all handled by humans. >>> d. Assuree (Password Reset candidate) combines the two passphrases to >>> the new password to >>> access his account >>> e. Support should advice Assuree to change his password after he get >>> access to his account f. Emails should be sent by a signed email or >>> with the CARS statement > >> We should include >> g. Support notifies all registered email addresses of the account that > the password reset has happened > >> This is vital to detect tampering early on, otherwise it could take > months until >> Alice discovers her password doesn't work any more, then she tries her > secret questions, >> which succeeds and the malicious password reset is never noticed. This part (g) should belong to the actual procedure because it's critical to the tamper-proofness. >> Assurers should be advised that capitalisations and such are critical > for the A-Word >> and therefore special care should be taken when recording it on paper. > E.g. zeros >> and "o"s should be distinguished by striking out zeros (so they look > like this Ø), >> capitalisation could be made more clear by underlining capital letters. > > These are both implementation details, adding this to the main procedure > makes them complex and unreadable and therefor understandable. OK, agreed for the capitalisation etc. part, it should be documented somewhere, but out of scope of this Arbitration case. > Seperate this as addtl. implementation notes for support. > > -------------------------------------------------------- > part 1 procedure for Password Recovery thru Assurance > -------------------------------------------------------- > part 2 implementation details for communications > to Assurees and Assurers > -------------------------------------------------------- > part 3 risks to this procedure > -------------------------------------------------------- > > e. should be moved to either part 2 or part 3 > the same as g. Agree about e., that is just detail not important to the procedure although it wouldn't exactly hurt to leave it in there, but g. is critical and should belong to part 1 > Further I would split this pwd recovery procedure > into Part I and II > Part I w/o system implementation > Part II w/ system implementation > to make the implementation steps as simple > readable as possible with addtl. implementation > details seperated (restructuring the document) > to show that 2 passphrases are needed, and when > and where you have to use those 2 passphrases > http://svn.cacert.org/CAcert/Support/PasswordRecoveryWithAssurance.html > is close before coming to complex ... > I had to reread the proposal 3 times to understand > where and why there are 2 X-words ... and where > they have to be used ... > At the very end, the 2 keys are the opener > to the account if entered into the system. > So the workaround procedure w/o the systems > integration uses those 2 keys as the halfs > of the temporary password to be entered > into the system. We could modify the original document but I have no access on SVN, also I think the Arbitration case itself should document the procedure that was actually accepted in the Arbitration. But I definitely agree on splitting it up into two parts and probably some human friendly names for the A- and T-Word would be helpful although I'm not creative enough right now to make some up ;-) }}} * New working document [[Support/PasswordRecoverywithAssurance]] == Intermediate Ruling == As long as there is no system implementation for the "Password Recovery with Assurance" procedure, the procedure outlined in [[Support/PasswordRecoverywithAssurance]] starting revision 20, Part I - Procedure w/o System integration and Part I.1 - Procedure for Password Recovery thru Assurance can be used "manualy". Parts I.2 and Parts I.3 needs some cleanup before final ruling. Frankfurt/Main 2010-04-17 == Ruling == I hereby rule, that the procedure outlined under [[Support/PasswordRecoverywithAssurance]] starting revision 20 becomes an addtl. solution for Support and community members who have lost their password, to recover their password. This ruling takes precedence for further Support cases. Further I rule: for keeping the audit trail intact, each support ticket regarding '''Password Recovery Request with Assurance''' following this ruling needs to be added to this ruling as a post arbitration case note by adding the Date of Support Execute and the Support Ticket Number onto the list. Frankfurt/Main, 2010-06-13 == Execution == 2010-06-13 (A): Ruling sent to Support (C1), (C2), (CM). Case closed. 2010-06-14 (C2): question about first step in this procedure 2010-06-14 (A): answer to (C2) about a regular Assurance, adding a A-Word (password) onto the CAP form, both Assuree and Assurer have later on to remind == Similiar Cases == || [[Arbitrations/a20100210.2|a20100210.2]] || [[Arbitrations/a20100210.2|Birthdate error (with assurance points) - Precendence case]] || == Post Arbitration Notes == '''Support Requests following this precedence procedure''' || '''Date of Support Execute''' || '''Support Ticket Number''' || || 2010-06-16 || s20100613.90 || || unsuccessful || s20100611.169 || || 2010-08-21 || s20100821.50 || || 2010-08-26 || s20100822.53 || || 2010-10-03 || s20100913.33 || || 2010-10-16 || s20101005.103 || || 2010-11-05 || s20101010.85 || || 2010-11-05 || s20101017.73 || || 2010-11-12 || s20101112.13 || || 2010-12-21 || s20101130.19 || || 2010-12-29 || s20101229.60 || || 2010-12-29 || s20101228.86 || || 2011-01-04 || s20101223.1 || || 2011-01-07 || s20101228.82 || || 2011-01-14 || s20110110.57 || || 2011-01-20 || s20110110.45 || || 2011-02-06 || s20110205.38 || || has led to [[Arbitrations/a20110228.1|a20110228.1]] || s20110228.79 || || 2011-03-01 || s20110301.10 || || 2011-03-01 || s20110228.32 || || 2011-03-09 || s20110308.3 || || 2011-04-01 || s20110319.39 || || 2011-04-05 || s20110403.30 || || 2011-04-08 || s20110407.95 || || 2011-04-20 || s20110402.103 || || 2011-05-02 || s20110430.38 || || 2011-05-17 || s20110516.89 || || 2011-06-09 || s20110608.131|| || 2011-06-14 || s20110609.105 || || 2011-06-26 || s20110623.72 || || 2011-06-27 || s20110626.9 || || 2011-06-30 || s20110627.30 || || 2011-07-10 || s20110522.51 || || still running || s20101204.48 || || 2011-11-14 || s20111113.51 || || 2012-01-15 || s20120114.35 || || 2016-06-22 || s20160424.67 || || || || || || || || || || ---- . CategoryArbitration . CategoryArbCaseSystemTasks . CategorySupportPrecentCase