Before: Arbitrator UlrichSchroeter (A), Respondent: CAcert (R), Claimant: MichaelTänzer (C1) Michelle K (C2), Case: a20100407.1

History Log

Discovery

[1] AssuranceHandbook2#CAcert_Assurer_Reliable_Statement CARS statement

Discussion

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

>  * 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.

>  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.

>>  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.

> 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 ;-)

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

Similiar Cases

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 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

Arbitrations/a20100407.1 (last edited 2016-06-22 10:25:19 by dirkastrath)