Expirace hesel + pamatování a zamezení opakovaného zadání hesla rubrika: Návrh

13 rmaslo
položil/-a 23.8. 13:49
 
upravil/-a 23.8. 13:50

Mám tady poptávku / požadavek, abych nějaký svůj informační systém doplnil o následující funkčnost:

  • Každé heslo se může být platné max 180 dní. Pokud si jej uživatel v této lhůtě nezmění, tak přestane platit. Plus k tomu samozřejmě naprogramovat nějaké varování ve smyslu "změňte si heslo brzo expiruje", atd...
  • Systém si bude pamatovat posledních 6 hesel a nedovolí je použít jako heslo nově zadávané.

Jak to naprogramovat (i v rámci bcrypt) je mi snad jasné (nemůžu porovnávat hashe, ale při zadaní nového pro kontrolu musím použít password_verify proti každém uloženému starému hashi)...

Ale chtěl bych se zeptat, jestli toto je z hlediska bezpečnosti vůbec podle dnešních trendů ještě správné? Jestli to spíš bezpečnost nesníží? Protože mně osobně to střídání hesel přijde spíš jako buzerace, která ve finále vede k tomu, že heslo skončí nalepené na papírku na okraji monitoru.
A to pamatování si hesel je podle mne úplně k ničemu, protože když mermomocí budu chtít stejné heslo, tak to prostě při změně změním 7x a pak si tam mohu dát zase to samé heslo.
Takže jestli to nemám zákazníkovi spíše zkusit rozmluvit...

Ale nejsem bezpečák a třeba se mýlím a je to naopak správná cesta.

odkaz Vyřešeno
8 ondrakoupil
odpověděl/-a 24.8. 9:25

Nemýlíš se. Omezovat platnost hesla a nutit uživatele měnit si je a používat pokaždé nové se dnes již považuje za přežitek a za antipattern. Důvodů je více, článků k tomu dost. Podobná praxe totiž mírně zvýší "technickou" bezpečnost hesla, ale výrazně sníží tu "lidskou" bezpečnost a vede uživatele k používání snadno zapamatovatelných a tedy i snadno uhodnutelných hesel, která si pak nějak nevhodně poznamenávají, anebo točí pořád to samé heslo, jen s malou variací, apod.

Předpokládám, že budeš chtít nějakou argumentační munici na klienta, tak třeba:

Chce-li klient zvýšit zabezpečení účtů uživatelů, doporuč mu spíš:

  • používat dvoufaktorovou autentizaci (e-mailem, SMSkou nebo nějakým autentizátorem na one-time hesla, jak to udělat v PHP sepsal třeba Jakub Vrána na https://php.vrana.cz/jednorazove-heslo.php)
  • vynucování komplexity hesel je složitější než jen "alespoň 8 znaků, velké a malé písmeno". S oblibou používám knihovnu ZXCVBN - https://github.com/dropbox/zxcvbn - kromě jiného vypočítá prolomitelnost hesla hrubou silou a vyhodnotí ji na stupnici od 0 do 4, tak dej minimum třeba 3.
  • znemožnit brute-force hádání (nějaký throttlingem nebo zablokováním na minutu po X neúspěšných pokusech)

Komentáře

  • rmaslo : Dík moc za tu "argumentační munici" přesně něco takového jsme potřeboval. 25.8. 0:39
  • dominios : Vsetko samozrejme spravne (aj som dal pacik), len by som chcel este podotknut jednu vec k poslednemu bodu. Taketo riesenie vyrazne znizi sancu, ze sa ten-ktory ucet hackne v realnom beziacom systeme, avsak nechrani heslo ako take. V pripade, ze heslo z nejakeho dovodu unikne (napr. export z databazy), tak utocnik ho vie uz potom prelamovat na svojom HW kde ziadny throttling nebude mat. Samozrejme, neznamena to, ze ho tam netreba mat :) Naopak, throttling je skvely, nakolko okrem kratkeho timeoutu sa da napr. poslat mail/SMS a dat sancu majitelovi uctu na rychle zablokovanie a bezpecnost to zvysi. Najlepsie je to este skombinovat s pomalou hashovacou funkciou, ktora zase vyrazne zvysi cas na prelomenie hesla v pripade, ze utocnik pouziva vlastne technicke prostriedky. 25.8. 8:40
  • Michal Kleiner : Skvělý příspěvek, díky! Ještě bych doplnil, pokud klient ještě nepoužívá, doporučit zavedení nějakého password manažera, který odstraní potřebu pamatovat si hesla, tudíž můžou být delší a komplexnější. 26.8. 5:24

Pro zobrazení všech 3 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.