OTP bank, jelszó szabályok 2019

Közösségi kerekasztal

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.
  • 4014 megtekintés

( bucko | 2019. 09. 08., v – 07:45 )

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.

( zgabi | 2019. 09. 08., v – 13:27 )

"ú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ő?!

Szerintem ez minden normális helyen így van. Ezért is írtam, hogy max az utolsó jelszóval tudják összehasonlítani. A többiek túlkomplikálják feljebb kliens oldai validációval meg sessiönökkel... Egyikre sincs szükség, simán elvégzi szerver odlalon az adott requesten belül.

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.

( ak0sh | 2019. 09. 08., v – 14:15 )

Password123); DROP TABLES Passwords;--

( uid_4263 v | 2019. 09. 09., h – 09:47 )

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

( hendrick v | 2020. 05. 09., szo – 10:47 )

Szerkesztve: 2020. 05. 09., szo – 10:47

Az akadémikusi vita kapcsán kérdezem, hogy mit lehet tenni azzal a webshoppal,a melyik cleartextben tárolja a jelszót? Ütközik-e ez bármilyen jogszabályba, hatósági előírásba, adatvédelmi irányelvbe? Vagy ez kizárólag a tájékozott programozó "jóérzését" zavarja, és semmivel nem lehet ösztökélni azt, aki ezt a "best practice-t" űzi (cleartext pwd - a jelszóemlékeztető A jelszót küldi)?

Koronavírus miatt boldog-boldogtalan webshopüzemeltetőnek csapott fel, és úgy látom ennek "vannak áldozatai".

Alkalmazásoknál, weblapoknál, stb. a bejelentkezés azonosításához a felhasználók azonosító adatait el kell menteni. Ehhez semmiképp sem szabad szövegesen elmenteni a jelszavakat, hanem modern eljárásokat kell használni mint például az Argon2. A nem megfelelően mentett jelszavak a GDPR 32. cikkének megsértését jelentik és bírsággal fenyegetnek.

https://www.adatvédelem.hu/2019/03/utmutato-biztonsagos-jelszokezeleshe…

The German supervisory authority LfDI Baden-Württemberg imposed the first fine in Germany under the GDPR. Due to a violation of Art. 32 GDPR (Security of Processing), a German social network operator was fined EUR 20.000 in September 2018.

The company had notified a data breach from July 2018 to the supervisory authority in accordance with Art. 33 GDPR, reporting that personal data of 330.000 users, such as e-mail addresses and passwords, had been hacked. The company fully cooperated and gave insights on internal structures, which showed that passwords had been stored unencrypted. The company thereby failed to grant data security according to Art. 32 (1) (a) GDPR. Due to its exemplary cooperation and readiness to follow all recommendations of the supervisory authority – also taking into account the total financial burden of the additional costs of implementation and the fine – the company was not fined higher.

https://edpb.europa.eu/news/national-news/2018/baden-wuerttemberg-super…

Igen, látom a Baden-Württembergi Adatvédelmi Biztos ott van a szeren, de ez itthon nem jó semmire, mert itthon nem érvényes a B-W adatvédelmi biztos határozata.

Ismerős cége nyitott webshopot és véletlenül rátévedtem az oldalra. Valakit megbízott, az megcsinálta, regisztráltam, kiderült. A kérdés az, hogy a lelkes szaki jóérzése az egyetlen kritérium vagy tudok neki mondani valami előírást, amiért nem jó az a webshop ami plaintextben tárolja a jelszavakat és a jelszóemlékeztetőnél visszaküldi A jelszót?

Mert ha nem tudok neki mondani előírást, akkor neki mint laikusnak, ez az egész az én "fontoskodásom" lesz, és ha úgy vesszük az is, mert ha nem tiltja semmi azt, hogy a webshop így üzemeljen, akkor az de iure így jó, horrible dictu.

Máshogy megfogalmazva: Mondhatja-e ismerős a vállalkozónak bármi alapján, hogy hibásan teljesítette a megrendelt webshop kivitelezését, mert az cleartextben tárolja a jelszavakat, vagy az lazán széttárhatja a karját, mert ezt az "extra szolgáltatást" nem kérte a megrendelő (nem ért hozzá) és egyébként sem írja ezt elő semmi itthon. A GDPR meg az üzemeltetőt érinti, hacsak nincs delegálva valahogy a vállalkozási szerződésben.

Egyszer kértem jelszó emlékeztetőt valahol és megjött a jelszavam cleartext-ben.

Elkezdtem az akkori regisztrációkról emlékeztetőt kérni és egy gyors keresésre tíz év távlatából ezek az oldalak jöttek elő:

  • DID World Wide
  • divido.hu
  • Ulead
  • JustVoip
  • Netrisk.hu
  • VMware
  • CsomagterTalca.Com
  • Habanero Chili Bolt
  • legoaruhaz.hu
  • molehillempire.com
  • Haldorádó
  • CodeWeavers
  • Rextra
  • Green Aqua
  • Futanet
  • Laptopszaki.hu
  • Avplanet.hu
  • tarhely.eu
  • padlasnyelviskola

4-5 jelszót kombináltam akkor, ez csak az egyik volt.

Ezek 8+ évvel ezelőtti regek voltak, nem jelenti, hogy most is így van.

Az oldalak egy része a reg igazolásban is visszaküldte a megadott jelszavamat, ez nekem egyenértékű azzal, hogy megismerhette kódolatlanul.

" Az oldalak egy része a reg igazolásban is visszaküldte a megadott jelszavamat,  ez nekem egyenértékű azzal, hogy megismerhette kódolatlanul. "

Mindenképpen megismerte kódolatlanul, amikor HTTP protokollon megkapta tőled.

Más kérdés, hogy miként tárolja, ez a lényeg.

A regisztráció visszaküldésében lévő plain text jelszóból nem következik, hogy plain textben tárolják. Ugyanis teljesen elképzelhető az alábbi flow:

  1. Megkapja a jelszavadat, mert elküldöd neki.
  2. Készít egy e-mail sablon alapján egy e-mailt.
  3. Eltárolja titkosítva a jelszavadat.
  4. Kiküldi neked az e-mailt, benne a jelszavaddal.

Nem szép megoldás, sőt, de teljesen lehetséges. Nem lehet abból következtetni abból, hogy megkaptad regisztrációkor a jelszavadat e-mailben, arra, hogy nem titkosítva tárolják.

Sőt, a tárolása lehet titkosított és nem hashelt, emiatt visszafejthető, így a szükséges privát kulcs ismeretében megfejthető. Ez sem szép megoldás, de nem jelenti azt, hogy titkosítatlanul tárolnák a jelszót.