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

Support: Passwort-Wiederherstellung mit Assurance-Verfahren (WIP)

Andere Möglichkeiten, das Passwort zurückzusetzen

Informationsmaterial, Broschüren, Lehrbücher, Präsentationen gibt es in der CAcert-Bibliothek

  1. Definitionen

    • Assuree

      Person, welche sich übprüfen lässt, um das Passwort zurückzusetzen

      Assurer

      Person,die die Identität des Versicherungsnehmers verifiziert

      A-Wort

      Das A-Wort (Assurance-Keyword), das zwischen Assuree und Assurer ausgetauscht wird.

      C-Wort

      Das C-Wort (Confirmation-Keyword), das vom Assuree an den Support Engineer zurückgeschickt wird, um das Passwort zurückzusetzen.

      T-Wort

      Das T-Wort (Transaction-Keyword), das zwischen Support Engineer und Assuree ausgetauscht wird.

Teil I - Verfahren ohne Systemintegration

Teil I.1 - Verfahren für die Passwort-Wiederherstellung durch Assurance

  1. Es sollte eine Passphrase (A-Wort) zwischen Assuree und Assurer als Ergebnis einer Assurance erstellt werden, die auf dem CAP-Formular und auf einem zweiten Blatt Papier (z.B. Visitenkarte), das dem Assuree übergeben wird, aufbewahrt wird.
  2. Assurer sendet an den Support die primäre E-Mail-Adresse des Assuree, das A-Wort und ob er die Assurance in das System eingeben konnte.
  3. Support Engineer sendet eine Autorisierungsanfrage an den Assuree mit einem Bestätigungswort (C-Word), das in die Antwort aufgenommen werden soll.
  4. Wenn der Assuree das Zurücksetzen des Passworts genehmigt, sendet er eine Antwort an den Support, in der er das Zurücksetzen des Passworts bestätigt und das C-Wort enthält.
  5. Wenn der Assurer dem Assuree vorher zugesichert hat und deshalb keine andere Assurance im System eingeben konnte, fordert der Support Engineer die folgenden Daten über die Assurance vom Assurer an:
  6. Primäre Email-Adresse des Assuree
  7. Vollständiger Name des Assuree
  8. Geburtsdatum des Assuree
  9. Support Engineer prüft die Autorisierung und vergleicht die Angaben des Assurers mit den Angaben des Kontos.
  10. Bei Übereinstimmung setzt der Support Engineer das Kennwort des Assuree auf A-Wort+T-Wort (T-Wort wird vom Support Engineer gewählt).
  11. Der Support-Techniker sendet ein E-Mail an den Assuree mit dem T-Wort.

  12. Der Support-Ingenieur dokumentiert die Durchführung der Passwort-Wiederherstellung unter Arbitrations/a20100407.1].

Teil I.2 - Implementierungsdetails für jeden Schritt

  1. Zusicherung
  2. Das A-Wort sollte von beiden Parteien vereinbart werden und muss mindestens sechs Zeichen lang sein.
  3. Das A-Wort sollte nur druckbare US-ASCII-Zeichen enthalten, um Probleme mit gebrochener Zeichenkodierung zu vermeiden.
  4. Das A-Wort könnte auf einem anderen Medium als Papier aufgezeichnet werden, aber es muss offline sein.
  5. Wenn Papier verwendet wird, ist Vorsicht geboten, wenn man es aufschreibt (wie z.B. deutliche Markierung der Groß- und Kleinschreibung und ähnlich aussehende Zeichen).
  6. Es ist zu beachten, dass dieses Passwort evtl. manuell eingegeben werden muss.

  7. Assurer -> Support (A-Wort)

    • Das E-Mail sollte signiert sein und ein CARS enthalten. Es muss mindestens unterschrieben sein oder ein CARS enthalten. 

      • Beispiel:
  Von: <Email des Assurers>
  An: <Support-E-Mail>>
  Betreff: Passwort-Wiederherstellung mit Assurance
  Ich habe Assuree an <Ort, Datum> für Kennwort-Wiederherstellung mit Assurance getroffen.
  Ich habe x1) die Assurance abgeschlossen/nicht abgeschlossen, indem ich die Assurance in das Online-System eingegeben habe.
  Name: <Name assuree>
  E-Mail: <E-Mail assuree>>
  A-Wort: <A-Wort>
  <Name Assurer>
  CARS
x1) wenn nicht abgeschlossen: Warum haben Sie nicht abgeschlossen? Wahrscheinlich sollten Sie einen Streitfall einreichen.

  8. Support -> Assuree (C-Wort)

  9. Das C-Wort sollte zufällig gewählt werden.
  10. Das C-Wort sollte nur druckbare US-ASCII-Zeichen enthalten, um Probleme mit gebrochener Zeichenkodierung zu vermeiden.

  11. Assuree -> Support (C-Wort)

  12. Support <-> Assurer (Details von Assurance)

  13. Muss nicht gemacht werden, wenn der Assurer in der Lage war, die Assurance in das System einzutragen.

  14. Das E-Mail, das die Daten enthält, sollte verschlüsselt werden (Wie kann ich verschlüsselte E-Mails an den Support senden? Verwenden Sie die persönliche Adresse eines Support-Ingenieurs? Bernhard-Fröhlich)

  15. Das E-Mail muss digital unterschrieben sein.
  16. Es sollen nur die in diesem Schritt explizit aufgeführten Daten gesendet werden.
  17. Details prüfen
  18. Wenn die Assurance in das System eingegeben wurde, muss das Datum überprüft werden, wenn die Assurance zu lange zurückliegt (mehr als einen Monat), sollte der Assurer gebeten werden, zu bestätigen, dass dies die Assurance mit Passwort-Rücksetzung war, oder wenn dies nicht der Fall ist, senden Sie die Details aus dem CAP-Formular (siehe vorhergehender Schritt).
  19. Wenn die Angaben nicht übereinstimmen, kann der Support-Techniker den Assurer um einen Scan des CAP-Formulars bitten, um zu prüfen, ob bei der Umwandlung von Handschrift in E-Mail im vorherigen Schritt Fehler aufgetreten sind.
  20. * Der Scan sollte möglichst im JPG-, PNG-, BMP- oder PDF-Format erfolgen.

    • Meine Begründung, PDF nicht in diese Liste aufzunehmen, war, dass einige PDFs nicht in jedem Viewer richtig angezeigt werden und der Adobe Reader eine riesige Geschichte von Exploits hat. Außerdem handelt es sich bei Scans immer um Bitmap-Grafiken, so dass die Features des PDF-Formats (Vektorgrafiken, "echter" Text, etc.) ohnehin nicht genutzt werden. JPG, PNG und BMP haben sehr vollständige Implementierungen und Exploits waren selten. Auch diese Formulierung besagt nicht, dass unter keinen Umständen PDF verwendet werden darf, nur dass wir die anderen bevorzugen und wenn jemand wirklich nur PDF als einzige Möglichkeit hat, darf er das benutzen.

      MichaelTänzer <<<DatumZeit(2010-04-17T12:52:11Z)>>

      • Aus den Erfahrungen der Schiedsgerichtsbarkeit bei der Beantragung von CAP-Formularscans werden 5 von 6 Scans als PDFs ohne Exploits und ohne Probleme beim Lesen der Scans gesendet. Der andere war JPG. Die Frage hier: Es gibt Probleme, die Sie lösen müssen. Also, wenn Sie anfangen, irgendwelche Formate anzubieten, müssen Sie die am häufigsten verwendeten anbieten... und das sind: PDF, JPG. Bei diesem Schritt ist es besser, keine Präferenzen zu machen, um das geringste Ergebnis zu erhalten....

        UlrichSchroeter <<<DatumZeit(2010-04-18T04:36:00Z)>>

  21. Der Scan sollte per verschlüsselter E-Mail gesendet werden (Siehe oben: Wie kann man verschlüsselte E-Mails an den Support senden?)

  22. Passwort setzen
  23. Das T-Wort sollte zufällig gewählt werden.
  24. Das T-Word sollte nur druckbare US-ASCII-Zeichen enthalten, um Probleme mit gebrochener Zeichenkodierung zu vermeiden.
  25. A-Wort + T-Wort bedeutet, dass das neue Passwort erzeugt wird, indem die Zeichen des T-Wortes an die des A-Wortes angehängt werden.

  26. Support -> Assuree (T-Word)

  27. Der Support muss alle registrierten E-Mail-Adressen des Kontos benachrichtigen, dass das Zurücksetzen des Passworts stattgefunden hat.
  28. Support sollte Anweisungen geben, wie man A-Word und T-Word kombiniert, um das temporäre Passwort zu erhalten.
  29. Der Support muss dem Assuree empfehlen, das Passwort zu ändern, nachdem er den Zugang zum Konto wiedererlangt hat.
  30. Der Support sollte darauf hindeuten, dass der Assuree das neue Passwort irgendwo offline aufschreibt.
  31. Dokumentieren Sie die Ausführung
  32. Der Support muss einen Audit-Trail über alle Fälle führen, die nach diesem Verfahren bearbeitet werden.

  33. Dies geschieht durch Hinzufügen eines Eintrags, der das Ausführungsdatum und die Support-Ticket-Nummer enthält, in die Tabelle am unteren Rand von Arbitrations/a20100407.1.

Teil I.3 - Risiken

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

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

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

Part II.3 - Risks

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

(At this point CAcert Support has not even looked at the account yet.)

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 2010-06-16 10:00:00 

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

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

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 2011-07-10 10:45:44

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

Es git extra e Siite für d Schwiiz.

Support/PasswordRecoverywithAssurance/DE (last edited 2018-01-01 21:41:56 by EtienneRuedin)