Podpora: Obnova hesla se zaručovací procedurou (ROZPRACOVÁNO [WIP])

Další možnosti obnovy hesla

  1. Definice
    • Zaručovaný

      osoba, která se dává zaručit a v tomto případě žádá také o reset hesla

      Zaručovatel

      osoba, která ověřuje totožnost Zaručovaného

      A-Word

      A-klíč (Assurance-Keyword), který si Zaručovatel a Zaručovaný vymění

      C-Word

      C-klíč (Confirmation-Keyword), který dostane v e-mailu Inženýr podpory od Zaručovaného, aby potvrdil reset hesla

      T-Word

      T-klíč (Transaction-Keyword), který si vymění Inženýr podpory a Zaručovaný

Part I - Procedura bez systémové integrace

Část I.1 - Procedura pro obnovu hesla zaručením

  1. Heslo (A-Word) bude společně vytvořeno Zaručovaným a Zaručitelem jako výsledek zaručení nebo opakovaného zaručení, a bude zapsáno na formulář CAP a na dalším lístku (například pracovní vizitce) předáno Zaručovanému
  2. Zaručovatel pošle Podpoře primární e-mailovou adresu Zaručovaného, A-klíč a zprávu, zda byl schopen zadat zaručení do systému
  3. Inženýr podpory pošle Zaručovanému výzvu k autorizaci spolu s potvrzovacím heslem (C-klíčem), které bude vloženo do odpovědi
  4. Jestliže Zaručovaný schválí obnovu/reset hesla, pošle Podpoře odpověď potvrzující obnovu/reset hesla a připojí C-klíč
  5. Pokud už Zaručovatel zaručil Zaručovaného už někdy předtím, takže teď nemohl do systému zadat další zaručení, vyžádá si Inženýr podpory od Zaručovatele tyto údaje o Zaručovaném:
    • Primární e-mailovou adresu Zaručovaného
    • Úplné jméno Zaručovaného
    • Datum narození Zaručovaného
  6. Inženýr podpory porovná oprávnění a údaje zaslané Zaručovatelem s údaji z účtu
  7. Když údaje souhlasí, nastaví Inženýr podpory heslo Zaručovaného na A-klíč+T-klíč (T-klíč zvolí Inženýr podpory)
  8. Inženýr podpory pošle Zaručovanému e-mail obsahující T-klíč
  9. Inženýr podpory dokumentuje provedení obnovy hesla do Arbitrations/a20100407.1

Část I.2 - Implementační detaily pro každý krok

  1. Zaručení
    • A-klíč bude dohodnut oběma stranami; musí mít délku alespoň 6 znaků
    • A-klíč smí obsahovat jen tisknutelné znaky US-ASCII, čímž se vyhneme problémům s kódováním
    • A-klíč lze zapsat na odlišné médium než papír, ale musí to být médium nepřipojené k síti (off-line)
    • Je-li použit papír, dejte pozor při zápisu (např. jasně odlišit písmena malé/velké abecedy [v|V, u|U, k|K, s|S,...] a podobně vypadající znaky [l|1, s|5, O|0,...])
    • Pamatujte, že toto heslo bude pravděpodobně muset být zadáno ručně
  2. Zaručovatel -> Podpora (A-klíč)

    • E-mail musí být podepsán a obsahovat CARS (prohlášení spolehlivosti zaručovatele CAcert). Musí být přinejmenším BUĎ podepsán NEBO obsahovat CARS.

      • Příklad:
          From: <assurer's email>
          To: <support email>
          Subj: Password Recovery with Assurance
          I've met Assuree at <location, date> for Password Recovery with Assurance.
          I've finished/didn't pass*1) the Assurance by entering the Assurance into the Online system.
          Name:  <name assuree>
          Email: <email assuree>
          A-word: <A-word>
          <name assurer>
          CARS
          [Překlad:
          Odesilatel: <e-mail Zaručovatele>
          Adresát: <e-mail Podpory>
          Předmět: Obnova hesla se zaručením
          Setkal jsem se s Zaručovaným na <místo, datum> kvůli obnově hesla se zaručením.
          Zaručení jsem dokončil/nedokončil*1) zadáním do on-line systému. (Když nedokončil, už ho jednou zaručoval.)
          Jméno: <jméno Zaručovaného>
          A-klíč: <A-klíč>
          <jméno Zaručovatele>
          CARS <prohlášení spolehlivosti zaručovatele CAcert>
          ]
         *1) pokud neprojde: proč? Pravděpodobně založíte spor
  3. Podpora -> Zaručovaný (C-klíč)

    • C-klíč musí být zvolen náhodně
    • C-klíč smí obsahovat jen tisknutelné znaky US-ASCII, čímž se vyhneme problémům s kódováním
  4. Zaručovaný -> Podpora (C-klíč)

  5. Podpora <-> Zaručovatel (podrobnosti zaručení)

    • Není nutné, pokud byl Zaručovatel schopen zadat zaručení do systému
    • E-mail obsahující data musí být zašifrován (Jak poslat zašifrovanou zprávu Podpoře? Použít osobní adresu Inženýra podpory? BernhardFröhlich)

    • E-mail musí být podepsán
    • Lze posílat jen data výslovně uvedená v tomto kroku
  6. Kontrola podrobností
    • Pokud bylo zaručení zadáno úspěšně do systému, musí se zkontrolovat datum; proběhlo-li zaručení už příliš dávno (před více než měsícem), je nutno požádat zaručovatele o potvrzení, že skutečně šlo o zaručení s obnovou hesla, nebo je-li tomu jinak, poslat podrobnosti z formuláře CAP (viz předchozí krok)
    • Nesouhlasí-li podrobnosti, může Inženýr podpory požádat Zaručovatele o sken formuláře CAP ke kontrole, zda v předchozím kroku nenastaly chyby při přepisu rukou psaných údajů do e-mailu.
      • Sken by měl přijít pokud možno ve formátech: JPG, PNG, BMP nebo PDF

        Můj důvod, proč v tomto seznamu nepoužít PDF: některá PDF se v každém prohlížeči nezobrazují správně a Adobe Reader má značnou historii zneužití. Krom toho jsou skeny vždy v grafice bitové mapy a tedy možnosti formátu PDF (vektorová grafika, "reálný" text, atd.) stejně nejsou využity. Formáty JPG, PNG a BMP mají zcela dokončené implementace a byly zneužity jen výjimečně. Tato formulace také neříká, že PDF nelze za žádných okolností použít, pouze že preferujeme ostatní formáty a pokud má někdo PDF jako jedinou možnost, může ho použít.

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

        • Podle arbitrážních zkušeností s vyžadováním skenů formulářů CAP: 5 ze 6 skenů je zaslaných jako PDF bez zneužití a bez problémů s čtením skenů. Jediný zbylý byl v JPG. Zde je otázka: jsou tu problémy, musíte je řešit. Takže chcete-li nabízet nějaké formáty, musíte nabízet ty nejpoužívanější ... a to jsou: PDF, JPG. V tomto kroku je lépe žádný nepreferovat, abyste získali i nejmenší účinek ...

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

      • Sken bude zaslán zašifrovaným e-mailem (Viz výše: jak poslat Podpoře zašifrovaný e-mail?)

  7. Nastavit heslo
    • T-klíč musí být zvolen náhodně
    • T-klíč smí obsahovat jen tisknutelné znaky US-ASCII, čímž se vyhneme problémům s kódováním
    • A-klíč + T-klíč znamená, že nové heslo se tvoří připsáním znaků T-klíče za znaky A-klíče [neboli zřetězením A a T klíčů, v pořadí A,T]
  8. Podpora -> Zaručovaný (T-klíč)

    • Podpora musí oznámit na všechny registrované e-mailové adresy účtu, že došlo k resetu/obnově hesla
    • Podpora poskytne návod, jak zkombinovat A-klíč a T-klíč a dostat tak dočasné heslo
    • Podpora musí poradit Zaručovanému, aby si změnil heslo, hned jak získá přístup ke svému účtu
    • Podpora by měla navrhnout Zaručovanému, aby si někam (off-line a bezpečně) uložil nové heslo.

  9. Dokumentovat provedení
    • Podpora musí udržovat auditovatelný deník všech případů zpracovaných podle této procedury
    • Provede to tak, že přidá záznam obsahující datum provedení a číslo "lístku" podpory k tabulce uvedené na konci Arbitrations/a20100407.1

Část I.3 - Rizika

Mallory
Osoba představující útočníka v následujícím scénáři

Rizika eliminovaná v každém kroku

  1. Zaručení
    • A-klíč sdílený při (opětném) zaručení je vytvořen mimo pásmo [asi: mimo dohled] a vyžaduje nové ověření totožnosti Zaručovaného -> nemělo by být možno, aby třetí osoba předstírala [hrála] Zaručovaného

    • Zápis A-klíče na nějaké médium zajistí, že A-klíč nebude zapomenut, dokud nebude použit
    • A-klíč musí být dostatečně dlouhý, aby ho nešlo odhadnout
  2. Zaručovatel -> Podpora (A-klíč)

    • Zaručovatel působí jako spojení od Zaručovaného k CAcert, a proto by měl být jeho e-mail podepsán; není-li, pak zaručení zadané do systému slouží jako indikace autenticity e-mail od Zaručovatele -> nemělo by být možné předstírat Zaručovatele

  3. Podpora -> Zaručovaný (C-klíč)

    • Potvrzení zajistí, že majitel hlavní e-mailové adresy Zaručovaného (což by měl být sám Zaručovaný) souhlasí s obnovou hesla -> nemělo by být možné, aby Zaručovatel předstíral Zaručovaného

    • Náhodná volba C-klíče znemožní, aby ho Zaručovatel uhodl
  4. Zaručovaný -> Podpora (C-klíč)

    • Je částí procesu potvrzení započatého předešlým krokem
  5. Podpora <-> Zaručovatel (podrobnosti zaručení)

    • Nemůže-li Zaručovatel zkontrolovat údaje o Zaručovaném, protože ho již kdysi předtím zaručil, musí tento krok provést Inženýr podpory za něj -> osobě, jejíž totožnost byla potvrzena zaručením, účet skutečně patří

    • Kvůli ochraně soukromí nesmí být údaje vyžadovány, bylo-li zaručení zadáno do systému
    • Kvůli ochraně soukromí by měl být e-mail obsahující údaje ze zaručení zašifrován
    • E-mail od Zaručovatele musí být podepsán, takže Inženýr podpory může ověřit, že ho poslal
    • Kvůli ochraně soukromí se neposílá více údajů, než je třeba
  6. Kontrola podrobností
    • Kontrola data udává, zda zaručení zadané do systému je právě to s obnovou hesla -> brání podvržení normálního zaručení za to s obnovou hesla (v pozdějším pohledu)

    • Je-li vyžádán sken formuláře CAP, má být zaslán šifrovaným e-mailem, z důvodu ochrany soukromí
  7. Nastavení hesla
    • A-klíč je pouze vložen do nového hesla a není kontrolován e-mailem, což redukuje počet jeho posílání "po drátě"
    • Nové heslo obsahuje T-klíč, takže Zaručovatel se nemůže přihlásit k účtu Zaručovaného (Zaručovatel nezná T-klíč, zná pouze A-klíč)
    • Nové heslo obsahuje A-klíč, což brání komukoli, kdo byl schopen přečíst zprávu obsahující T-klíč, aby se přihlásil k účtu Zaručovaného
    • T-klíč je zvolen náhodně, což brání Zaručovateli, aby ho uhodl
  8. Podpora -> Zaručovaný (T-klíč)

    • Oznámí všem v účtu registrovaným e-mailovým adresám, což zabraňuje tomu, aby někdo získal přístup k primární e-mailové adrese a nepozorovaně prošel procesem obnovy hesla
    • Heslo se musí změnit co nejdříve, protože bylo posíláno e-mailem (sice ve dvou částech, ale asi i nezašifrovaně), zná je Inženýr podpory a je zaznamenáno lístkovým systémem používaným Podporou
    • Rada Zaručovanému, jak správně pracovat s heslem, by měla zabránit dalším požadavkům na obnovu hesel

Jiná osoba než skutečný uživatel (snad zlovolný Zaručovatel) požaduje obnovu hesla

  1. Mallory je schopen zfalšovat nešifrované e-maily tak, jako by pocházely od jiné osoby (velmi pravděpodobné)
    1. Mallory má účet a chce resetovat/obnovit heslo, ale nechce se zdržovat zaručením (protože například použil v předchozích zaručeních falešné dokumenty a nechce riskovat odhalení)
      1. Mallory zfalšuje e-mail od zaručovatele Boba, obsahující primární e-mailovou adresu svého účtu, A-klíč dle vlastní volby a prohlášení, že zaručení bylo zadáno do systému
      2. Podpora pošle Mallorymu C-klíč
      3. Mallory odpoví tímtéž C-klíčem
      4. Inženýr podpory zkontroluje, zda jsou v účtu Malloryho zaručení od Boba
        1. Nejsou tam -> Lapen

        2. Jedno tam je, ale je starší než měsíc -> Inženýr podpory se zeptá Boba, zda se konalo zaručení s obnovou hesla -> Lapen

        3. Jedno tam je a není starší než měsíc
      5. Inženýr podpory nastaví heslo na A-klíč|T-klíč
      6. Podpora zašle T-klíč Mallorymu
      7. Mallory zná A-klíč (sám si ho zvolil) a T-klíč, takže se znovu dostane ke svému účtu
  2. Před spuštěním procedury 'Obnova hesla se zaručením' si Zaručovaný (mající primární e-mailovou adresu) a Podpora vymění několik e-mailů
    • Zaručení se Zaručovatelem identifikuje skutečného uživatele -> což by mělo selhat

    • Ověření nastane v okamžiku, kdy Zaručovatel porovná formulář CAP a údaje z online účtu
    • Podpora oznámí všem registrovaným e-mailovým adresám účtu, že došlo k obnově hesla (důležitá zkouška pro důkaz, že nikdo nic nepředstíral)
  3. Někdo jiný než skutečný uživatel žádá obnovu hesla
    • Před spuštěním procedury 'Obnova hesla se zaručením' si Zaručovaný (mající primární e-mailovou adresu) a Podpora vymění několik e-mailů "Zaručovaný" 'přichází ke stánku' a žádá proceduru obnovy hesla

    • Zaručení se Zaručovatelem identifikuje skutečného uživatele (osoby známé u CAcert)
    • Ověření nastane v okamžiku, kdy Zaručovatel porovná formulář CAP a údaje z online účtu
    • Podpora oznámí všem registrovaným e-mailovým adresám účtu, že došlo k obnově hesla (důležitá zkouška pro důkaz, že nikdo nic nepředstíral)
  4. Někdo jiný než skutečný uživatel žádá obnovu hesla
    • Před spuštěním procedury 'Obnova hesla se zaručením' si Zaručovaný (mající primární e-mailovou adresu) a Podpora vymění několik e-mailů "Zaručovaný" posílá proceduru obnovy hesla Podpoře

    • Zaručení se Zaručovatelem identifikuje skutečného uživatele
    • Ověření nastane v okamžiku, kdy Zaručovatel porovná formulář CAP a údaje z online účtu
    • Podpora oznámí všem registrovaným e-mailovým adresám účtu, že došlo k obnově hesla (důležitá zkouška pro důkaz, že nikdo nic nepředstíral)
  5. Zaručovatel zaručil Zaručovaného už dříve
    • Údaje účtu nejsou Zaručovateli přístupná. Nemůže srovnat údaje on-line účtu s novými údaji z formuláře CAP. Vidí pouze varování: Nemůžete zaručit dvakrát tutéž osobu

    • Jediný, kdo může srovnat údaje z formuláře CAP s údaji on-line účtu, je Inženýr podpory nebo jiný zaručovatel, který dosud Zaručovaného nezaručil

      Zaručovatel by měl poslat údaje uživatele Podpoře podepsaným e-mailem a použít tento vzorový text

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

      • jen na výzvu Inženýra podpory. Standardně: Zaručovatel posílá pouze A-klíč a primární e-mailovou adresu Zaručovaného

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

  6. Zlovolný Zaručovatel Mallory chce zablokovat Alici
    1. Mallory pošle A-klíč a údaje o zaručení Podpoře, aniž Alice prohlásí, že chce obnovit své heslo
    2. Podpora generuje T-klíč
    3. Podpora nastaví Alicino heslo na A-Word|T-Word
    4. Podpora pošle T-klíč Alici
    5. Alice se nemůže heslem A+T přihlásit, protože nezná A-klíč a zkouší se přihlásit svým původním (starým) heslem, které je zamítnuto
    6. Alice musí provést obnovu hesla
      • Pak ovšem můžeme vysledovat Malloryho a zahájit arbitráž, ale proč se namáhat, když je prevence tak snadná.
  7. Některý poskytovatel služeb Internetu (ISP, Internet Service Provider, který nabízí uživatelům e-mailové schránky) má snad přístup do schránky uživatele, takže na výzvu Podpory může odpovědět zlovolný správce ISP za skutečného uživatele. -- Dirk 2010-06-15 21:30:00

    • Krok 1: Uživatel obdrží A-klíč při zaručení, neposílá ho e-mailem Krok 2: Podpora požaduje údaje od uživatele, na což může odpovědět zlovolný správce ISP Krok 3: Podpora nastaví heslo na kombinaci A-klíče a T-klíče, ale uživateli pošle pouze T-klíč Krok 4: Zlovolný správce ISP si může z přijaté e-mailové zprávy přečíst jen polovinu hesla, tím je problém vyřešen.

      Poznámka stranou: pravděpodobně můžeme připustit, že Zaručovaný může kontaktovat více Zaručovatelů, takže později může Inženýr podpory zvolit jeden z A-klíčů od Zaručovatelů jako část dočasného hesla obnovy a sdělí uživateli, aby použil A-klíč od Zaručovatele toho-a-toho -- UlrichSchroeter 2010-06-16 15:37:00

Part II - Procedura s integrací v systému

Ztráta identifikace pro přístup k účtu -- ztráta hesel -- je největší nápor na podporu. Účinná a důležitá obnova účtu je velkým provozním problémem. Současná strategie nabízí více metod (například obnovu hesla).

Tato metoda využívá síly vysoce důvěryhodných zaručovatelů poskytujících potřebnou bezpečnost. Má tu výhodu, že pracuje s databází zaručovatelů a sbližuje zaručovatele se členy. Metoda Osoba

Část II.1 - Procedura pro obnovu hesla zaručením

  1. Členka Alice zapomene své heslo. "K čertu!"
  2. Alice si sjedná zaručení s (volitelnou) obnovou hesla se Zaručovatelem Bobem.
    1. Během zaručení si Alice a Bob vytvoří A-klíč
    2. (Bob může Alici poradit, jak se má starat o svá hesla...)
    3. A-klíč je zapsán do Bobova formuláře CAP a na kartě, kterou dostane Alice.
    4. Alice má A-klíč na pracovní vizitce až do ukončení Zaručení [celé procedury!].
    5. Zaručovatel [Bob] označí A-klíč jako zadaný (to má smysl, i když už Bob někdy Alici zaručoval.)

      Nechápu, proč by Bob měl označit A-klíč jako zadaný. Vynechat tento krok?

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

  3. Bob dokončí zaručení na on-line systému:
    1. Bob zadá A-klíč ze svého formuláře CAP. (tato částby měla fungovat, i když už Bob někdy Alici zaručoval.)
    2. Zaručovatel [Bob] označí na formuláři CAP A-klíč jako zadaný.
    3. rozhodne-li se Bob Alici nezaručit, neměl by zadávat A-klíč.
  4. Když je A-klíč zadán do systému zaručování:
    1. Systém vygeneruje T-klíč (Trentův klíč) jako náhodný řetězec, snad do URL.
    2. T-klíč e-mailem odešle Alici (na její primární e-mailovou adresu).
  5. Když Alice dostane e-mail:
    1. Alice navštíví web, zvolí funkci "Obnova-hesla-se-zaručením", pravděpodobně kliknutím na URL.
    2. Alice zapíše A-klíč a T-klíč do dvou příslušných polí a klikne.

      Je-li T-klíčem URL, neměl by ovšem být T-klíč zapisován do pole.

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

    3. Když souhlasí, nabídne systém obnovu hesla.

      Snad by mělo být nové heslo v předchozím kroku zapsáno do nového pole, pro zvýšení "bezstavovosti" (tj. co nastane, když Alice provede 5.2, ale pak z nějakého důvodu [např. chyby systému nebo timeoutu sezení] už neprovede 5.3?)

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

  6. Při obnově hesla systém:
    1. Oznámí to všem e-mailovým adresám účtu.
    2. Nabídne možnost obnovy otázek?

      Snad dát odkaz na tuto možnost, ale není třeba vyvíjet velké implementační úsilí.

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

    3. Navrhnout, aby si Alice zapsala své heslo na bezpečné místo nedostupné on-line.

      Jakmile budeme mít takovou proceduru obnovy hesla (s každou obnovou hesla WoT posiluje, joj!), trvejme na bezpečném místě a neraďme uživatelům psát si hesla na papír, leda by byl ten papír uložen na skutečně bezpečné místo, třeba do sejfu. Zásuvka jejich stolu, i když zamčená malým klíčkem, nebo úkryt v šatníku mezi ponožkami a spodky nejsou považovány za dost bezpečné - ovšem to je jen můj názor.

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

      • Něco bylo špatně, takže je potřeba provést tuto proceduru obnovy hesla. Takže proto, jako prevence jejího opakování, se musí ještě něco udělat. A to podpořit uživatele, aby si někde pamatoval/uložil heslo, které používá jen zřídka.

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

    4. Ještě něco, co stojí za úvahu?

Část II.2 - Implementační podrobnosti komunikace se Zaručovanými a Zaručovateli

Part II.3 - Rizika

Příloha

Vzorový text e-mailové zprávy od Zaručovatele pro Podporu

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.

Prosím porovnejte následující podrobnosti se svým svědectvím z osobní schůzky.
NESMÍTE pokračovat, nevíte-li jistě, že tyto podrobnosti jsou správné.
Arbitr CAcert Vás může činit odpovědným za jakékoli potíže ohledně tohoto
zaručení.

Jméno Zaručovaného: Josef Novák
Datum narození (RRRR-MM-DD): 1970-01-01
Primární e-mailová adresa Zaručovaného: josef.novak@email.cz

[X] Potvrzuji, že se Zaručovaný dostavil osobně

[X] Věřím, že moje potvrzení totožnosti je správné,
úplné a ověřitelné. Viděl jsem původní doklady potvrzující 
tuto totožnost. Chápu, že arbitr CAcert mě může požádat
o dodání důkazů k jakémukoli sporu a může mě učinit odpovědným.

[X] Přečetl jsem si Zásady zaručování (Assurance Policy) a Příručku
zaručovatele (Assurance Handbook), rozumím jim a provádím toto zaručení
podle nich a v souladu s nimi.

[X] Jsem Členem komunity CAcert, složil jsem zkoušku Výzva zaručovatele
(Assurers Challenge), jsem zaručen nejméně 100 body zaručení (AP)
a povoluji týmu Podpory (Support Team) ověřit tato fakta.

Možný vzor textu e-mailů od Podpory Zaručovanému

Počáteční e-mail

(V této chvíli se Podpora CAcert dosud ani nepodívala na účet.)

Byl bych raději, kdyby použitý C-klíč byl nějakou podrobností [údajem] v účtu. Pak by ta podrobnost cestovala jen jedním směrem, od Zaručovaného -> Podporu a dala by se později v účtu ověřit.
Například požádat o jednu z dalších e-mailových adres, nebo jednu z domén.

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

Vážený <UŽIVATELI>!

Podpora CAcert obdržela e-mail s Vaší žádostí o
Obnovu hesla se zaručením dle [1] na <MÍSTĚ>.

Můžete laskavě potvrdit, že:
1) Skutečně si přejete obnovit své heslo,
2) Prosím, použijte <C-klíč> kdekoli ve své odpovědi
a
3a) Že jste si dohodl A-klíč se zaručovatelem <ZARUČOVATEL #1>.
    (Tento A-klíč mi prosím NEPOSÍLEJTE, bude stačit jeho délka.)
3b) Že jste si dohodl druhý A-klíč se zaručovatelem <ZARUČOVATEL #2>.
    (Tento A-klíč mi také NEPOSÍLEJTE, bude stačit jeho délka.)
nebo
3..n) Že jste si dohodl další A-klíč se zaručovatelem <ZARUČOVATEL #n>.
    (Tento A-klíč mi také NEPOSÍLEJTE, bude stačit jeho délka.)

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

-- 
S úctou
<ČLEN TÝMU PODPORY>
Podpora CAcert

Potvrzení změny

  • Toto by mělo být odesláno na VŠECHNY e-mailové adresy přidružené k účtu.
  • T-klíč má být delší a trochu nepříjemný, aby uživatel chtěl změnit své heslo co nejdříve.

T-klíč má být odeslán jen na primární e-mailovou adresu; všechny ostatní e-mailové adresy dostanou upozornění BEZ citlivých údajů -- MichaelTänzer 2011-07-10 10:45:44

Vzor e-mailu odeslaného na primární e-mailovou adresu ("ostrý" T-klíč):

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

Vážený <UŽIVATELI>!

Vaše heslo bylo změněno.

Bylo sestaveno takto:
  A-klíč od <ZARUČOVATEL #?>
  pomlčka
  T-klíč od Podpory: "$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$"

<A-klíč>-$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

Připomínám, že "<A-keyword>" zastupuje skutečný A-klíč, 
který máte. Zadejte ho bez úhlových závorek <>. 
Podobně T-klíč zadejte bez uvozovek "".

Prosím, změňte své heslo znovu, a to co nejdříve.
Je vhodné uložit kopii svého nového hesla na bezpečném
místě (například v domácím nebo bankovním trezoru)

Odpovězte laskavě na tuto zprávu, abychom věděli,
zda jste úspěšně získal(a) přístup ke svému účtu.

-- 
S úctou
<ČLEN TÝMU PODPORY>
Podpora CAcert

For mail to additional email addresses use (T-klíč je zastoupen znaky "xxxxx"):

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

Vážený <UŽIVATELI>!

Vaše heslo bylo změněno.

Bylo sestaveno takto:
  A-klíč od <ZARUČOVATEL #?>
  pomlčka
  T-klíč od Podpory: "xxxxx" (viz e-mail odeslaný na Vaši primární e-mailovou adresu)

<A-klíč>-<xxxxx>

Prosím, změňte své heslo znovu, a to co nejdříve.
Je vhodné uložit kopii svého nového hesla na bezpečném
místě (například v domácím nebo bankovním trezoru)

Odpovězte laskavě na tuto zprávu, abychom věděli,
zda jste úspěšně získal(a) přístup ke svému účtu.

-- 
S úctou
<ČLEN TÝMU PODPORY>
Podpora CAcert


Support/PasswordRecoverywithAssurance/CZ (last edited 2018-03-08 17:07:52 by AlesKastner)