Obnovení zapomenutého hesla

Moderátor Chamurappi: Vytrženo z md5 decrypt.

Odesílání nezašifrovaného hesla na e-mail není dobrým nápadem. Uživateli tak ukazuješ, že ti nezáleží na jeho údajích, které má u tebe uložené, neboť do schránky se mu může někdo dostat, pak do vyhledávání napíše „heslo“ a vyběhnou mu všechny registrace, kde je dotyčný zaregistrován.
Tvůj způsob zjišťování, zda je v nějakém záznamu v databázi uveden nějaký e-mail není nejekonomičtější, neboť z databáze vytahuješ všechny údaje z daného řádku (nevím teda, kolik jich obsahuje) jen proto, abys tento řádek sečetl.

Sice to do tohoto vlákna úplně nepatří...
panther:
„a jak jinak máš předat heslo? V databázi je uložen hash, ale uživatel zadává heslo v plain textu. Povídáš nesmysly (tobě někdy na mail přišel 40-místný hash?).“
Podle mne není důvod uživateli posílat jeho heslo. On ví, jaké si zvolil a překlep neudělal (proto se přece heslo zadává dvakrát).
Zapomene-li své heslo, pak se po zadání jeho e-mailové adresy na tuto pošle hash, po jehož použití je mu heslo změněno na jeho nově zvolené. Opět není nutné mu toto heslo znovu posílat na e-mail.
Má-li uživatel v e-mailové schránce vyhledávání, po vyplnění výrazu „heslo“ mu (nebo útočníkovi) se vypíší všechny české servery, na nichž je tento uživatel registrován. Pro anglické je to anglický ekvivalent tohoto slova. Nepovažuji proto tento způsob za bezpečný. Jedná se však o můj osobní názor. Což však nemusí znamenat, že „povídám nesmysly“.

Chamurappi:
„1) Všechny maily, v nichž mi je obsaženo jakékoliv nové heslo, je buď rozumné nearchivovat, nebo (raději) si heslo v nich obsažené změnit — obojí může ten zaslaný mail s doporučovat.“
Má-li si uživatel heslo stejně měnit, proč bych mu posílal to provizornní?

„2) Když budeš uživateli psát mail, že mu posíláš hash, po jehož použití si může změnit takovou tu tajnou a blíže nejmenovanou věc, pomocí které se přihlašuje, tak to část obyčejných uživatelů nepochopí. Musíš použít pojem, kterému lidi rozumí, a ten už bude vyhledatelný.“
Napíšu mu, že heslo změní kliknutím na odkaz, kde budu metodou get předávat nějaký vygenerovaný hash, abych ověřil, zda tam přichází ze své adresy.

Jde o to, že mu nebudu do e-mailu uvádět jeho heslo, abych ho tam přímo podsouval i náhodnému útočníkovi. Vždyť víte, že připojování ve školách a dalších institucích nemusí být nejbezpečnější.

Omlouvám se, uvědomuji si, že jsem se špatně vyjádřil. Uživateli po zapomenutí jeho hesla nebudu posílat hash v url, ale token, ano tak se tomu říká. Po jeho použití si heslo změní, toto se mu nebude už na e-mail posílat.

Chamurappi:
„Protože to staré zapomněl, viz první dzambova věta.“
O zapomenutém hesle přece celou dobu píšeme.

Chamurappi:
„Čímž se útočník hledající pojem ‚heslo‘ také dozví, kde je jeho oběť registrována, tam klikne na ‚zapomněl jsem heslo‘, dostane do mailu hash token a má hotovo.“
Ale nedoví se původní uživatelovo heslo, které (průměrný uživatel) má na spoustě serverů stejné.

edit: Jde totiž o to, že to provizorní heslo vůbec není potřeba.

Joker:
Při tomto postupu: Nevím své heslo, kliknu na odkaz na přihlašovací stránce, vygeneruje se mi nějaké provizorní heslo, jeho hash se uloží do speciální tabulky (není možné přepsat to původní, můj e-mail není ověřen), pošle se mi na e-mail provizorní heslo, to zkopíruji, přihlásím se na dané stránce a heslo změním.
Můj postup je takový, že na e-mail rovnou pošlu odkaz s tokenem, kde přímo heslo změní. Nepotřebuji ukládat žádná provizorní hesla.
Žádné heslo (ani po registraci, ani po změně) neposílám uživateli na email, tudíž se v jeho e-mailové schránce nedá žádné heslo najít (pochopte, to jediné heslo, kterým se uživatel přihlašuje na různé servery).

panther:
„tady se nepíše nic o posílání hesla, které by mohlo být i jinde“
V tomto případě ne. Uvedl jsem však, že na e-mail by se nemělo posílat žádné heslo, tedy ani heslo po registraci na server.

Joker:
„Jak se pozná, že to je skutečně ten správný token, tj. ten samý jako se poslal uživatelovi?“
To je pravda. Uznávám to. Neuvědomil jsem si, že uložení tokenu je totéž jako uložení provizorního hesla.

edit: Omlouvám se všem diskutujícím za způsobené zmatky.
Jen jsem chtěl upozornit na to, že registrace mohou obsahovat osobní údaje, průměrný uživatel používá stejné heslo skoro všude, kde mu to dovolí, poslání hesla (po registraci, po změně) umožňuje přístup k těmto údajům.
Což ale s původním obsahem vlákna nesouvisí, takže se znovu omlouvám za OT.

Bubák:
„Když budu mít laškovnou náladu, vlezu na stránku, vyplním cizí přihlašovací jméno a kliknu na "Nové heslo". Dotyčné osobě se změní heslo a má smůlu, dokud si nevyzvedne mail. Co kdyby nějaký útočník napsal skript, který by v pravidelných intervalech "klikal" na žádost o nové heslo?“
Nové heslo by uživatel zadal na stránce, na níž by vedla adresa s tokenem, takže útočníkovi (dá-li se mu takto říct) jeho laškovná nálada nepomůže.
Můj postup pouze neposílá uživateli provizorní heslo, které by pak musel měnit.
Jak ale správně upozornil Joker, je úplně jedno, jestli ukládám hash nebo token. Je vidět, že není moderátorem pro nic za nic. ;-)

Joker:
„Řešením by bylo nějaké dodatečné ověření (např. zadání e-mailové adresy registrované pro daného uživatele) a případně omezení množství žádostí (dvě za den, další nejdřív 24 hodin po předchozí a podobně)“
Jen detail: Zasláním tokenu na e-mail ověřím, že uživatel, který požádal o změnu hesla, skutečně má přístup do dané e-mailové schránky, není proto nutné omezovat množství žádostí a je to bezpečnější než zjistit, zda tento uživatel zná pouze adresu e-mailové schránky.

Navazuji na téma md5 decrypt, které nechci dále zaplevelovat.
Jokerova připomínka mě přivedla na myšlenku, jak nejsnáze zprovoznit obnovení zapomenutého hesla tak, abych nemusel tvořit hesla provizorní a ukládat je do samostatné tabulky do databáze, nebo riskovat zneužití funkce obnovení. Joker navrhoval toto schéma: „Nevím heslo, kliknu na „Zapomněl jsem heslo“, systém změní heslo a pošle to nové na e-mail daného uživatele. Případně je mezitím ještě nějaké další ověřování (třeba zadat stejnou e-mailovou adresu, jaká byla použitá pro registraci, a případně omezení množství žádostí - dvě za den, další nejdřív 24 hodin po předchozí a podobně), aby někdo nemohl otravovat jiné uživatele tím, že jim bude měnit hesla. “ (Spojil jsem dva jeho příspěvky do jednoho.)
To mi nepřijde jako šťastné řešení. Stačí znát pouze tvou e-mailovou adresu (nepotřebuji její heslo) a hurá, jsem na tvém účtu. Omezení, že tuto funkci mohu použít jednou za den, mi je ukradené. Za prvé mne nemůžeš identifikovat (díky proxy), za druhé mi stačí jeden jediný pokus za rok, abych se dostal na tvůj účet.

Jinou možností je po zapomenutí hesla se dotázat na e-mail či nick, vytvořit provizorní heslo, to poslat uživateli na uvedený e-mail (totožný s tím, který uvedl při registraci). Uživatel z e-mailu heslo provizorní heslo zkopíruje, přihlásí se jím a změní si jej.
Nevýhodou tohoto postupu je to, že musím ve speciální tabulce v databázi uchovávat informaci o vygenerovaných provizorních heslech.

Napadlo mne jiné schéma:
Uživatel nezná heslo, dotážu se jej na e-mail či nick, vytvořím token podobnou funkcí: md5(nick+datum+tajna_ingredience), tento token přidám do odkazu na změnu hesla, který pošlu uživateli na e-mail. Uživatel klikne na odkaz v e-mailu, z databáze vezmu jeho nick, přidám k němu aktuální datum a onu ingredienci a z toho vytvořím hash. Bude-li totožný jako token z adresy, povolím uživateli změnu hesla. Nebudu testovat jen aktuální datum, ale i to z předchozího dne. (Požádá-li uživatel o změnu před půlnocí, aby měl 24 hodin na to, aby na odkaz v e-mailu klikl.)
Výhody tohoto řešení jsou ty, že ověřím, že uživatel skutečně vlastní e-mailovou adresu, kterou uvedl při registraci, dále zajistím, že požadavek na změnu hesla není zastaralý. A navíc nebudu muset udržovat v databázi údaj o tom, kdo kdy žádal o změnu hesla, proxy nikomu nepomůže. Pokud za tajnou_ingredienci přidám například datum posledního přihlášení uživatele, zajistím tak, že pokud se uživatel mezi požadavkem na změnu hesla a kliknutím na odkaz v e-mailu přihlásí, token přestane být platný. (Uživatel jej již nepotřebuje, pouze představuje nepatrnou díru do účtu.)

Chci se zeptat, zda jsem si nevšiml nějaké bezpečnostní chyby, kterou by toto mé poměrně hodně jednoduché řešení mohlo obsahovat.