OTP bank, jelszó szabályok 2019

A tranzakció a titkos egyedi jelszó megváltoztatására szolgál. Kérjük, hogy az új jelszó megadásánál az alábbi szempontokat szíveskedjen figyelembe venni:

  • hossza 6-8 karakterig terjedhet,
  • ne használjon ékezetes, és különleges karaktereket,
  • új jelszava legalább 3 karakterben különbözzön régi jelszavától,
  • javasoljuk, hogy jelszava vegyesen tartalmazzon kis- és nagybetűket, valamint számokat.

Hozzászólások

Legalább 5,68e10 jelszó lehet. Ehhez hozzájön az azonosító és a felhasználónév meg az sms. Aztán pár nap múlva még további lehetőségek is lesznek.
És ez még mind semmi!
Komolyabb támadás esetén az (egy kávé + egy cigi)/utalás fícsör felkapcsolásával abszolút atombiztossá válik!
Tehát a karakterek száma nem elegendő egy tisztességes védelemhez!

Az ékezetes karakterek sem jelentenek komolyabb problémát, hiszen használatukat igen gyakran még az oly magasan képzett hupperek sem tudják megoldani. Nekem inkább a SPACE karakter okoz gondot, mert az nem is különleges, meg ékezet sincs rajta. Így aztán felmerül a kédés, hogy lehet-e használni, és csak a jelszó megváltoztatásakor, vagy más esetben is?
;) - De csak a gyengébbek kedvéért.

"új jelszava legalább 3 karakterben különbözzön régi jelszavától"
Ezt könnyen ki lehet kerülni. Tegyük fel, hogy nem tárolják plain text-ben (vagy visszafejthető titkosítással) a jelszavakat, akkor max az utolsó jelszóval tudják összehasonlítani (amit gondolom meg kell adni változtatáskor) => Másodjára meg lehet változtatni olyanra, aminél már csak 1 karakterben különbözik az előzőtől... (És ha nem tárolják az előző hasheket, akkor akár ugyanarra is mint korábban volt)

Legyen olyan jó, és hasonlítsa össze a kliensoldalon. Ha meghaladja a fejlesztő képességeit, csinálja meg szerveroldalon úgy, hogy egyszerre kéri be a régit és az újat.
Plaintext jelszavakat nem tárolunk szerveren – egy session idejéig sem. Mi ebben olyan nehezen érthető?!

Mert a kliens behazudja, hogy istenbizony 3-nál több karakternél többen tér el a két string -> értelmét vesziti a szabály.
Kliensen nemhogy jelszavak biztonságát, de kb semmilyen kicsit is fontos dolgot nem ellenőrzünk. Vagy ha mégis, mert az UI megköveteli, akkor ugyanazt az ellenőrzést el kell végezni szerver oldalon, ez teljesen triviális.

Én a tárolást úgy értem, hogy addig tárolja memóriában amig össze hasonlitja, majd eldobja. Szerintem senki sem azt mondta, hogy letárolja bárhová is cleartextben bármelyik jelszót is. De bizony fel kell küldeni mindkét jelszót cleartextben és ott meghozni a döntést, hogy betartotta-e a complexity restrictiont vagy sem. Ennek nincs helye kliens oldalon.

Password complexity restriction és kliens oldali ellenőrzés egy mondatban nevetséges. Pont.
Hogy a konkrét szabály mennyire értelmes azon lehet vitatkozni. De ilyet nem ellenőrzünk kliens oldalon és kész. Aki ellenkezőjét állitja azt az isten óvja, hogy akár közelébe is kerüljön hasonló rendszerek fejlesztéséhez.

Nyilván egy banknál, ahol pénzről van szó, meg a banknak felelősségvállalása van millió okból, más.

De ha a HUP csinálna ilyen ellenőrzést, és csak a frontenden csinálná, akkor full el tudnám fogadni, hogy "öcsém, ha ezt ki tudod játszani, tessék, lehet ugyanaz a jelszavad, mint legutóbb".

"Mert a kliens behazudja, hogy istenbizony 3-nál több karakternél többen tér el a két string -> értelmét vesziti a szabály."
Bármilyen szabály, ami korábbi jelszavakhoz hasonlít (kivéve a teljes azonosságot, az pedig a szerveren hashből is tesztelhető), számomra teljesen értelmetlen, mivel ha nem áll rendelkezésre gyakorlatilag végtelen számítási kapacitás, nincs más megoldás, mint a cleartext password tárolása, szóval nincs miből veszíteni.

"Szerintem senki sem azt mondta, hogy letárolja bárhová is cleartextben bármelyik jelszót is"
vs.
"adott sessionben tudjak tarolni a belepett user jelszavat, hiszen o adta meg belepeskor."

Nem tudom miért nem érted még mindig, hogy nem kell letárolni cleartextben semmit. De be kell kérni (és kb mindenhol be is kérik) a jelenlegi jelszót, ahhoz lehet realtime hasonlitani az új jelszót, hogy megfelel-e a követleményeknek. Ha igen, akkor lehet hashelni és azt letárolni, ha nem akkor vissza van utasitva.

Szerintem itt valami félreértés van a session tárolás kapcsán. Az nem tárolás, user belép, rámegy a jelszómódositó funkcióra, beadja a régi és új jelszavát, régit lehasheled, ellenörződ, hogy jó régit adott-e meg, ha igen új jelszót összehasonlitod a régivel, hiszen ott van mindkettő a memóriában cleartext-ként, lefuttatod az ellenőrzéseket és letárolod, ha megfelel, stringeket eldobod. (ill. eleve secure stringként tárolod memóriában is)
Nincs letárolva semmi.

"Nem mindegy? Tárolod. Memória, fájl,"

Nem mindegy. Másik szálban már eljutottál oda, hogy ja de mégiscsak kéne szerver oldalon is lefuttatni az ellenőrzést. (nyilván)
Ahhoz pedig, hogy két stringet össze tudjál hasonlitani szerver oldalon bizony tárolni kell. Egy változóban. Ami a memóriában van. Ott tárolod. Az összehasonlitás után pedig eldobod. Ilyen egyszerű.
És mivel ért hozzá, aki ezt irja, ezért nem sima stringben tárolja, hanem secure string-ben, ezért eldobás után tényleg törlődik.

Ha pedig megtörik a szervert és amiatt aggódsz, hogy de ott van a memóriában, ahonnan ellophatják akkor megnyugtatlak, hogy még ha nincs semmi ilyen ellenőrzés, de a hackernek full hozzáférése van a memóriához, akkor még a hashelés előtt is ugyanúgy ellopja a cleartext jelszót, ez ellen nem tudsz mit tenni.

Te nem olvastad el, hogy kliens oldali password restriction ellenözrésekről meg szerver oldalon nincs cleartext-ekről beszélt a kolléga.
Hogy mit is ért a session-ben tárolásban arra direkt rákérdeztem, de sajnos megint csak azt a marhaságot kaptam, hogy sehogy nem tárolunk szerveren cleartext password-öt, még memóriában sem.

Szerintem hagyjuk. Aki szeretne az ellenőrizzen password restriction-t kliens oldalon és a többi hülyeséget, csak ne találkozzak ilyen oldalakkal :)

Tudom, nehéz, sok az országban a funkcionális analfabéta, de ez az oldal azért mégsem azok gyűjtőhelye, de ha nem megy, akkor megpróbálom újrafogalmazni:
Arról volt szó, hogy Elbandi kolléga azt javasolta, hogy tárolják a sessionadatok között a jelszót, és változtatáskor azzal hasonlítsák össze. Erre javasoltam, igaz slendriánul fogalmaztam, bővítések zárójelben, hogy akkor már inkább a kliensoldalon hasonlítsa össze (mármint a kliensoldalon belépéskor letárolt jelszóval), ha pedig nem megy (vagy nem elég) a kliensoldalon, akkor szerveroldalon tegye úgy, hogy mindkét jelszót bekéri, ne a szerveren tárolja cleartext a sessionadatok között.

Hát, a fenti vitától függetlenül kliensoldalon tárolni a jelszót a session alatt bármilyen formában plaintextként még talán nagyobb hiba, mint ugyanez szerveren. A szerverre csak akkor jutnak be, ha betörnek, a kliens oldali sütiben tárolt jelszó pedig egy netkávézóban megmaradhat az idők végezetéig is.

A leg-biztonságosabb természetesen, ha bekéred a régi és az új jelszót, szerver oldalon ellenőrzöd, majd ha megfelel az új, eltárolod.

Egy karakternyi változás figyelésére még könnyű olyan algoritmust írni, ami kevés erőforrás igénnyel le tudná vizsgálni a korábbi jelszavakhoz való hasonlóságot.

3 karakterre viszont már célszerű tárolni valahogy a korábbi jelszavakat visszaállítható formában is, pl hogy a korábbi jelszavakat eltárolod egy olyan szimmetrikus kulccsal titkosítva, amelynek a jelszava mindig az aktuális jelszó. Ahányszor változik a jelszó, annyiszor dekódolod a korábbi jelszavakat a régi kulccsal, hozzáfűzöd az aktuális jelszót, majd kódolod az új kulcs segítségével.
Ilyenkor persze egy elfelejtett jelszó funkció máris elvesztené a korábbi jelszavakat, és persze az a hátránya, hogy ha kiderül az aktuális jelszó, akkor minden korábban tárolt is.
Így nyilván rosszabb megoldás, mint ha csak a legutolsó jelszóhoz viszonyítanád.

Nem cookie, sessionstorage. De mindegy, sehol nem kell tárolni, tök felesleges. Ha csak egyezést kell nézni, akkor az hashből úgyis kideríthető a szerveroldalon.

"és persze az a hátránya"
És konkrétan mi az előnye annak, ha x időre visszamenőleg tudom ellenőrizni, hogy nem túl hasonló-e a jelszó?

A hasonlóság ellenőrzésének előnye max. annyi, hogy valahol a szabályzat megköveteli. Szerintem a gyakorlatban ez felesleges, de megértem a szabályzat létezését is. Sok helyen megkövetelik az alkalmazottaktól, hogy mondjuk 4 hetente váltsanak jelszót. És ezt azzal szokták megoldani, hogy a "Panda01" után a "Panda02" jön, és így tovább. Így pedig nem sokat ér a jelszó csere, mert ha egyszer kikerül egy a sorozatból, utána nagyjából ki lehet számolni az aktuálisat.

Annak összehasonlítása kliensoldalon, hogy ne akarja új jelszóként újra felküldeni a régit, nem biztonsági művelet, hanem megspórol egy requestet a szerveroldalon. Szóval nem írtam, hogy ez legyen a validálás alapja, tisztában vagyok vele, hogy minden kliensoldali ellenőrzést újra végre kell hajtani a szerveroldalon is. De olyat nem csinálunk, hogy tároljuk a bejelentkezett user jelszavát szerveroldalon cleartext azért, hogy ha netán jelszót szeretne változtatni, akkor azzal majd összehasonlítsuk.

vagy esetleg az új jelszóban változtatnak 1-2 karaktereket, elhashelik, és újrapróbálják ;)

akinek ilyet magyarázni kell, hogy 3 karakterben térj el, az az angol ABC betűiből, meg max számokból választ. 52+10 karaktert kell kipróbálni, nyolc karakteres jelszónál mennyi, 64 lehetséges helyen (nyolc alatt az egy az egy változtatáshoz plusz nyolc alatt a kettő, ha kettőt változtatnak)? Ha nem vagyok segghülye az ilyen dolgokhoz (az vagyok), akkor is ~4000 lehetséges korábbi jelszó, tippre pillanatok alatt megvan.

OTP esetén szerintem a jelszó jelentősége némileg csökkent (hiszen minden tranzakcióhoz kell másodlagos azonosítás, pl. sms -ben kapott kód vagy qr beolvasás).

--
arch,ubuntu,windows,android
zbook/elitebook/rpi3/nexus5_hammerhead

Nekem azért kellett bemennem mert hosszú évek óta nem jártam bent, és már a régi tokenes alkalmazást is elvesztettem, meg a jelszót is, meg a mindent :) Viszont initial app installkor kidob egy app reset kódot, azt ha felírod, később pillanatok alatt telepíthetsz új eszközre (ekkor az előző inaktiválódik).

--
arch,ubuntu,windows,android
zbook/elitebook/rpi3/nexus5_hammerhead