Fórumok
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.
Egy idő után leszokik a 3D secureról? Kb a tizedik revolut feltöltés óta nem irányít sehova , hogy autholjam a tranzakciót.
"ú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)
Így születnek a Lilike190908, Lilike191015, etc kaliberű jelszavak. ;)
Pont ez kapta meg a szemem, hogy ezt csak úgy tudják ellenőrizni, ha tárolják a régi jelszót....
adott sessionben tudjak tarolni a belepett user jelszavat, hiszen o adta meg belepeskor.
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Tudni tudják, csak nem illik…
Hogy nem illik jelszóváltoztatáskor bekérni a jelenlegi és új jelszót és összehasonlitani a sessionben a kettőt, hogy hány karakterben tér el? Mi a frász???
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ő?!
> egyszerre kéri be a régit és az újat.
Az OTP-nel emlekeim szerint ilyen.
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.
Jelszószabály ellenőrzés kliens oldalon, LOL :)
Esetleg azt is ellenőrizhetné kliens oldalon, hogy van-e az utaláshoz elegendő pénz a számlán :)
"egyszerre kéri be a régit és az újat"
nyilván úgy kéri be, hogy máshogy kérné be? Nem kell letárolja egyiket sem, string.equals()
Egyrészt: miért ördögtől való a kliens oldalon két input mező összehasonlítása?
Másrészt: ha visszaolvasnál a szálban, erre reagáltam: "adott sessionben tudjak tarolni a belepett user jelszavat, hiszen o adta meg belepeskor."
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.
Mondjuk ez az ellenőrzés szerintem pont elférne frontenden, ha nem pénzről lenne szó. Aki ki tudja játszani, úgysem adja meg ugyanazt a jelszót mindig, aki meg a célközönsége egy ilyen ellenőrzésnek, az nem játssza ki.
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.
Ez mondjuk igaz, de a többi megadott adat validálása pedig pont fordítva van, ezek (illetve mi) miatt(unk) kell szerver odlalon:) És akkor már mért nem ellenőrizzük ott (is) a jelszót is?
> Aki ki tudja játszani, úgysem adja meg ugyanazt a jelszót mindig,
Erre ne fogadj nagy osszegben :)
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.
Többször nem idézem be, mire válaszoltam. Tessék megtanulni értően olvasni!
"adott sessionben tudjak tarolni a belepett user jelszavat, hiszen o adta meg belepeskor.
A session neked mit jelent? Hol tárolódik, ha beleraksz/tárolsz benne valamit?
De értő olvasás ide, session elképzelés oda, kliens oldalon password restrictiont validálni marhaság.
"A session neked mit jelent? Hol tárolódik, ha beleraksz/tárolsz benne valamit?"
1. Nem én írtam le a fent idézett baromságot.
2. Nem mindegy? Tárolod. Memória, fájl, adatbázis – teljesen mindegy, ha éppen megtörik a szervert, ott van.
"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.
Tényleg ilyen kurva nehéz? Az eredeti hozzászóló nem pillanatnyi tárolásról beszélt, hanem amíg él a session. Tehát akkor dobná el, ha kilogolok vagy lejár a session timeoutja.
https://hup.hu/comment/reply/165686/2385228
Ja, hogy most meg már arról beszélgetünk, hogy mennyi ideig is tároljuk cleartextben szerver oldalon a jelszót? Egyre jobb ez a történet, ahogy terelődik terelődik a realitás irányába :)
te tényleg nem olvastad el ezt a hozzászólást: https://snipboard.io/cYbrV0.jpg
?
Még ki is fényképeztem, mert fentebb linkelték, meg idéték neked, de nem jött össze.
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 :)
bárhogy nézem, a szálindító kolléga egyszer szólt hozzá eddig, ahol le van írva, hogy loginkor megadott jelszót tárol.
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.
Aztán meg csodálkoznak a Post-Iten a monitor sarkán… :D
Esetleg azt is ellenőrizhetné kliens oldalon, hogy van-e az utaláshoz elegendő pénz a számlán
BKK webshop lájkolja a kliensoldali bérlet-ár meghatározás feature-t.
--
LOL :)
Elég jelentős különbség van a kettő között: a jelszó szabályt kikerülésével csak neked lesz rosszabb (már ha gyengébb jelszót használsz, mint a szabály megenged), míg a bankszámla egyenleg manipulációjával a banknak lesz rossz.
> a jelszó szabályt kikerülésével csak neked lesz rosszabb
Nope
https://hup.hu/node/165025
"Legyen olyan jó, és hasonlítsa össze a kliensoldalon."
Aki a kliensoldalon végez biztonsági műveletet, az más galádságra is képes.
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.
Ugye algoritmus függő a sebesség. Ha nem MD5-ről beszélünk (remélem :) ), a 4000 lehetőség csak CPU-n számolva már jelentős lassulást okoz. Akinek 16 karakter a jelszava, az meg elmehet kávézni vagy rögtön bankot váltani :)
Szerkesztve: max 8 karakter lehet :)
A 6-8 karakter limit arra enged következtetni, hogy nem hasht tárolnak...
--
Desktop: Windows10 | Server: CentOS
Kliensen is validálhatják. :)
Password123); DROP TABLES Passwords;--
Lehet ezért van a 8 karakteres limit. :)
--
https://naszta.hu
:-)
KeepassX -el bonyolultabb jelszót generálok...
--
-- Tégy jót a fogyatékkal élőkért Alapítvány
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
Némileg. Szerintem 3-4-5 éve nem írtam be OTP-nél jelszót.
--
trey @ gépház
+1, amikor uj telefonra kellett az appot telepiteni, azonnal a telebanknal kezdtem, hogy jelszo reset kell, mert fogalmam sincs, hogy mi az
Telebank ? Advanced level. Legutobb CIB eseteben szemelyesen kellett bebandukolni.
Jelszó resetért biztos nem. Telefonos téma, még személyesen is odaültetnek.
--
arch,ubuntu,windows,android
zbook/elitebook/rpi3/nexus5_hammerhead
Aha, amig csak jelszo reset van, de uj telefon uj install, akkor az irany be, majd a jelszo ahogy irtad. Csinaltam mar 2x.
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
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".
https://www.adatvédelem.hu/2019/03/utmutato-biztonsagos-jelszokezeleshe…
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.
Ez egy GDPR szabályozás, ami az egész EU-ra érvényes. (lásd: első része a kommentnek)
Igazad van, ez a GDPR 32-es cikk szerencsére jól lett megírva és rá lehet ezt is húzni. Kíváncsi lennék itthon kikényszeríthető-e az érintett webshopokkal szemben... ld szilárd megjegyzését is.
Igen, lehet rá hivatkozni. Ez a hiányosság általában csak akkor derül ki, ha valami ok folytán kiszivárognak az adatok, szivárgás nélkül nem tudom milyen esetben indít vizsgálatot a hatóság. (persze ha emailben visszaküldi az elfelejtett jelszót az is egyértelmű)
Nem tudsz magánemberként hatóságot játszani, nincs betekintési jogod a kovácséstsa kóklerkft webshopjának kódjába. Mi alapján tudod h. cleartext-ben tárolják a jelszavadat, az emlékeztetőben el tudják neked küldeni?
Na akkor mégegyszer kiemelés abból amire válaszoltál: cleartext pwd - a jelszóemlékeztető A jelszót küldi
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ő:
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:
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.