Přejít k navigační liště

Zdroják » Webdesign » Nezatěžujte uživatele vytvářením účtů. Váš web není výjimečný.

Nezatěžujte uživatele vytvářením účtů. Váš web není výjimečný.

Články Webdesign

Registrovat se. Registrovat se. Registrovat se. — Tohle Lenin nikdy neřekl. A váš návštěvník o to možná ani nemá zájem, na to nikdy nezapomínejte.

Nálepky:

Článek je překladem anglického originálu Your Website is not Special, Don’t Make Visitors Make Accounts, jehož autorem je Ben Burwell. Je zveřejněn se souhlasem autora a v souladu se svou původní licencí CC BY 4.0

Jedním ze strašáků použitelnosti webových stránek je nutnost vytváření zbytečných uživatelských účtů. Když jsem si naposledy kupoval vstupenky z Ticketfly, bez registrace mě web nenechal nákup dokončit. Pro uživatele, kteří nějaké vstupenky kupují každou chvíli, může mít registrace řadu výhod. Ale pro mne, jako pro někoho, kdo si kupuje vstupenky nejvýše jednou za rok, dva, je registrace na takové webové stránce nejen zbytečná, ale ještě k tomu otravná.

Neříkám, že byste svým uživatelům neměli nabídnout možnost si účet vytvořit, to by pravděpodobně také nebylo zcela na místě (samozřejmě s přihlédnutím k tomu, jaký typ webové stránky provozujete). Na každý pád vědí návštěvníci vašich stránek mnohem lépe než vy, jestli budou chtít a používat uživatelský účet. Nutit je si účet vytvořit leckteré z nich pravděpodobně odvede z vašich stránek pryč. Neexistuje žádný pádný důvod, proč byste nemohli nabídnout možnost „nakoupit bez registrace“.

A pokud už uživatelské účty nabízíte, můžete se řídit následujícími pravidly, abyste svým návštěvníkům zpříjemnili jejich vytváření:

  1. Dovolte přihlášení přes třetí stranu (OpenID, Facebook, Google atd.). Vaši návštěvníci si často nechtějí pamatovat další dvojici uživatelského jména a hesla.
  2. Nenuťte své uživatele použít přihlášení přes třetí stranu. Vždy umožněte vytvoření místního účtu. Řada návštěvníků nechce, navzdory tomu, co se píše v bodě 1, k přihlašování používat své účty na sociálních sítích. Řada z nich také účty na sociálních sítích vůbec mít nemusí.
  3. Uživatelské jméno = e-mailová adresa. Nenuťe své uživatele pamatovat si uživatelské jméno. Můžete jim umožnit zvolit si nějaké později po registraci, pokud to bude nutné – například pro URL jejich profilu.
  4. Nevymýšlejte pro hesla komplikovaná pravidla. Pokud už nějaká musíte mít, nastiňte je uživatelům ještě před tím, než začnou heslo vyplňovat. Zjistit pravidla pro heslo až z červené chybové hlášky neodeslaného registračního formuláře je frustrující.
  5. Nikdy, nikdy, neomezujte délku hesla, kterou si uživatelé mohou nastavit (samozřejmě v rozumné míře, megabytová hesla nechce od uživatelů asi nikdo). Moje banka omezuje heslo na 14 znaků, to je nesmyslné. Microsoft délku hesla u svých účtů omezuje na 16 znaků. Protože hesla stejně šifrujete, nemusíte kvůli delším heslům měnit datové typy v databázi uživatelů.
  6. Vždy nabídněte svým uživatelům zrušení účtu. Tento krok by měl z vaší databáze odstranit všechny informace o uživateli do té míry, aby nenarušil celistvost ostatních, nemazaných dat.

Jistě, jsou tu okolnosti, kterých si musíte být vědomi a nejsou tématem tohoho článku. Nechám na vás to, aby vaše technické řešení bylo bezpečné a robustní, ale poskytnu vám alespoň pár základních rad a tipů:

  • Nevymýšlejte si vlastní šifrování. To se týká protokolů, hashů hesel, čehokoliv.
  • Používejte bcrypt. Nepoužívejte SHA-1 ani MD5!
    • O ukládání hesel bez jejich zahashování doufám ani nepřemýšlíte.
  • Použití nezabezpečeného HTTP (bez SSL/TLS) je neomluvitelné.
  • Nevymýšlejte si vlastní šifrování.
  • Nevymýšlejte si vlastní šifrování.

Dobrým úvodem do problematiky je přednáška Michala Špačka Zahashovat heslo, uložit, …, profit! nebo pokročilejší anglický článek Salted Password Hashing – Doing it Right.

Komentáře

Subscribe
Upozornit na
guest
10 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Radek Miček

Používejte bcrypt.

Bcrypt je časem prověřená metoda, nicméně v dnešní době už stojí za zvážení scrypt.

Petr Jasník

Při zvažování zda přejít na scrypt doporučuji přečíst článek:
http://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scrypt.html

Není to tak černobílé jak to vypadá …

Xificurk

Moje banka omezuje heslo na 14 znaků, to je nesmyslné.

Zdravím dalšího „spokojeného“ zákazníka KB ;-)

Nikdo

Původní autor článku (ne autor překladu) asi nebude používat KB :-)

glubothemad

Co se tyce slozitosti hesel, nejjednodussi je asi sahnout po hotovem reseni, vcetne javascriptoveho ukazalete, jak si vase zadavane heslo vede, treba zxcvbn od Dropboxu.

caracho

K prekladu: cryto != sifrovani ale kryptograficke algoritmy obecne. Sifrovani je obousmerne (spravy angl. temin je encryption), zatimco v pripade hesel nas zajimaji hlavne hashe.

Je hezke tam iniciativne oproti puvodnimu clanku doplnit SHA1 – ale to nic neresi. Spravne se maji pouzivat hashe na tohle delane (scrypt, bcrypt) a vubec nepouzivat tyhle hash algoritmy delane na rychlost (SHA*) a kdyz u neni zbyti tak je potreba dukladne solit a pocitat opakovane v cyklu. Napr. aktualne ma fce crypt v PHP pro sha256 a sha512 vychozi hodnotu 5000 iteraci. Ale i to je vzhledem k tomu, ze dnes existuji zarizeni co umi 5.000.000 hash/sec nouze.

A dalsi vec je, ze neni potreba (vzhledem k exponovanosti sluzby samozrejme) uzivatele s tim heslem zas tak trapit, pokud jsou implementovany i dlasi techniky omezeni pristupu.. viz http://research.microsoft.com/apps/pubs/default.aspx?id=70445

caracho

Pripadne pokud uz se ma pouzit nejaka ta sha* fce, tak jako soucast PBKDF2

amazon

Šifrují se zprávy, nikoli hesla.

to je jedno
  • to nepouziti https je proste kravina
  • vetsi zverstvo je chtit email po anonymech jako zde.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.