Egy egyszerű weboldalról van szó, ahol azonban személyes adatok is vannak tárolva.
Ezért kíváncsi lennék a véleményekre, hogy a kitalált felhasználó bejelentkeztetési folyamat mennyire biztonságos.
Infók, hogy a felesleges dolgokat kerüljük:
- A botok ellen invisible reCaptcha fog kerülni a regisztrációhoz és a bejelentkezéshez is.
- A szerver biztonsága és hogy milyen backenden fut az oldal az is fontos, de most hagyjuk, mert más téma.
- Konténerben futó friss linux és sokak által használt, folyamatosan frissített framework van használva.
- A regisztráció során a szokásos adatokon kívül meg kell adnia 2 olyan adatot is ami már létezik a rendszerben.
- Bejelentkezés során ha ugyanarra az e-mail címre X időn belül Y sikertelen kérés érkezik, akkor Z időre tiltom az adott IP-t
Ami a kérdéses pont számomra az a bejelentkezés.
Ilyenkor meg kell adnia az e-mail címét és a születési dátumát. Nincs jelszó!
Ha van ilyen e-mail címmel felhasználó és egyezik a születési dátum akkor megy egy e-mail, amiben van a beléptető link.
A link hosszú, minden bejelentkezési kérés esetén újra generált, egyedi hash-t tartalmaz. (24 óra után lejár)
Arra kattintva pedig beléptetésre kerül a felhasználó.
Tehát így 2 faktoros, viszont nincsenek jelszavak.
Az egyik gyenge pontja, hogy a felhasználók ismerhetik egymást, tehát az egyik simán tudja a másik e-mail címét és születési dátumát.
De ugye bejelentkezni nem tud vele, mert csak az e-mail-ben lévő linkre történik meg.
Akkor van gáz, ha hozzáfér a másik gépéhez, telefonjához.
Milyen további gyenge pontjai lehetnek ennek?
Használ már valaki hasonló megoldást?
A születési év helyett mondjuk lehetne valami olyan adat bekérése amit a felhasználó mindig tudni fog,
de a munkatársa már valószínűleg nem. Pl. szülők születési dátuma
Hozzászólások
Ez hogy all elo, pontosan?
Szoval nalad a weboldalon semmi titkot nem potyog be a user (szuletesi datum nem secret), valojaban ha hozzafer valaki a levelezesehez akkor be tud lepni az oldalra. Velemenyem szerint ez igy one-factor.
Mi az oka annak, hogy nem egy meglevo megoldast hasznalsz? Mondjuk akarmilyen OTP-s megoldast (GA vagy akarmi)?
Ha nem kapja meg a levelet, mert akarmi, akkor nem tud belepni? Eleg idegesito lehet...
En user + pass + otp-t javasolnek.
Hat peldaul nem tudhatod, hogy a level milyen csatornan jut el a felhasznalohoz. Titkositott vagy sem?
Mondjuk valami ami olyat mint egy jelszo ? :)
Secret-nek hasznalni barmilyen szuletesi datumot, nem jo otlet. Gyurj ossze egy password policy-t es kerj be jelszot!
A levelezésében jó eséllyel ott lesz valahol a születési ideje, főleg ha valami cloud-os levelezést használ, ahol a dokumentumait is tárolja.
Másik oldalon viszont mindenképpen kell jelszó emlékeztető funkció, ha jelszó lenne.
Tehát, a mailbox birtokában a szolgáltatást el tudnák érni ha nincs még egy token pl.
Csak egy apró gondolat a születésnap jelszóként használatához: születésnap-paradoxon.
Nem tudom ennek mi köze ehhez.
paradoxon_eselye(userek_szama)*élő_ember_kulonozo_eletkoranak_szama()*e-mail_cím_lehetőségek()
Apró észrevételeim:
- Hogyan és mivel garantálod, hogy ugyanazzal a linkkel ne tudjon még egyszer belépni a felhasználó?
- Mi történik, ha az email késve jön meg és a felhasználó még egyszer megpróbál belépni, így 2 levelet fog majd kapni és megpróbál belépni mindkettővel? Melyik lesz érvényes?
- Ez nem 2FA. Közel sem. Gyakorlatilag a születési dátum is a felhasználói név része, mert fix. GipszJakab20000101.
Miért akarod feltalálni a spanyol viaszt? Miért nem használsz tanúsítvány alapú authentikációt?
Generál egy token-t a user_table egyik mezőjébe. Minden generálásnál ez felülíródik, felhasználásnál pedig valami olyan értekre állítódik ami érvénytelenként kezel az alkalmazás vagyis azzal az értékkel belépni nem lehet.
Szerintem feleslegesen próbálod a kereket újra feltalálni. Bonyolítod, de elérsz egy olyan rendszerhez, ami épp olyan komplex, mint egy jelszavas vagy 2FA rendszer, de cserében a biztonsága a 0-át verdesi. Az ilyen születési dátumok sose voltak jó ötlet, szülőké se, mert igaz, hogy az ilyeneket idegen lehet nem tudja, de ha tudja az illetőről, hogy hány éves, meg mi az e-mailje, onnantól azon az 1-2 éven belül 365 napos próbálkozással simán belép.
Legyen csak szépen hagyományos jelszó, az oldal használói meg tudják ezt kezelni. Egyedül arra figyelj, hogy jelszót ne tárolj, csak hash-t, ha leak lenne, akkor se kerüljenek bajba a felhasználók.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Hash-t teljesen jol lehet torni
Mindegyiket? ;-)
Kulon iparag van ra celhardverrel. Csak remenykedhet az ember, hogy ami implementalva van megoldas azt meg nem tudjak torni. A problema ott van, hogy a rendszerek 99%-ban indulas utan kb be vannak fagyasztva nem tortenik security review merthat keszen van ez mar 10 eve mi baj tortenhet?
De nem engem kell meggyozni eleg olvasgatni a torteneseket.
A nagy adatlopasoknal nem veletlenul viszik a hash-t is mert jo rajta trainingelni a feltoro algoritmust (bruteforce + dictionary)
Ha kellően erős hash, pl. SHA-256 vagy jobb, akkor max. csak brute force-szal vagy szótár alapon. De még utóbbiakat is el lehet lehetetleníteni salt-tal. MD5-öt valóban könnyű.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Kerdes, hogy meddig szamit erosnek.
Szerintem még hosszú évekig, de ha paranoid vagy, akkor használsz SHA-512-őt, vagy ráeresztesz valami extra megoldást, köztetes titkosítás, salt a hash előtt. Bár még nagyon sok idő szerintem, mikor már az SHA-256 nem lesz elég. Ne feledjük, itt webes belépésekről van szó, egyszerű oldalakhoz, nem kormánytitkok ezek, hogy 100+ évig kell tartson, mire megtörik. Eleve csak akkor fontos, ha volt valami leak, akkor is elég addig tartania, míg a szivárgásról a usereket nem értesítik, és le nem cseréltetik velük a jelszót határidővel.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Miért verdesi a nullát?
https://hup.hu/user/password
Ha hozzáférek az email fiókodhoz, hozzáférek a HUP fiókodhoz is. Jelszó, születési dátum ide vagy oda.
Igen, de ez akkor van, ha hozzáférsz az e-mailfiókomhoz. Amit a kolléga ír, hogy elég csak maga az emailcím az ő rendszerében, már ha jól értem. Meg pont ezt az e-mailfiókjához van hozzáférésem trükközést szokták elkerülni 2FA megoldásokkal.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Nem elég az e-mail cím, oda küld a rendszer egy one time linket a belépéshez.
Ja, hogy az más. Akkor viszont visszavonom, félreértettem. Ebben az esetben elég lehet csak az e-mail. Ami viszont gyengéje egy ilyen e-mailt küldözgetünk rendszernek, hogy ha nem érkezik meg valami mailtorlódás, vagy hiba miatt, vagy késve érkezik, vagy a szerver szűrője kivágja spamba, mi a fenét csinálnak? User addig nem tud belépni. Nem véletlen, hogy a mai napig az összes oldal inkább jelszót használ, és nem találják fel újra a kereket.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Ha úgyis az email-re érkező linkkel lehet csak belépni, akkor teljesen felesleges szerintem a születési dátumot elkérni az email cím mellé. A biztonságot nem növeli, csak többet kell gépelnie a felhasználónak.
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
Kevesebb e-mail egy brutefoce esetén? Szerintem nem hátrány.
OK, ezt el tudom fogadni. A kérdés akkor az, hogy mi idegesítőbb: kapni 2-3 emailt, mielőtt letiltja a rendszer az email címet Z percre, vagy minden alkalommal beírni a dátumot. Ha a böngésző kitölti az email cím mellett a dátumot is automatikusan, akkor az elég jó.
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
Rendhagyó megoldások:
- minden usernak el kell magyarázni - és még utána 10% se fogja érteni, hogyan lehet belépni (járt utat járatlanért...)
ha lassú vagy nem működik a mailserver vagy éppen a Te SMTP szervered kerül fekete listára és a google nem fogad tőled mail-t ?
Harmadik fél szolgáltatás minőségét kötni a Te rendszered használhatóságához. Nyomozni xy mail szerver miért teszi spam-be a Te leveled...
Rossz kódtáblát használó mail szerver tud fura karaktereket kavarni..
Én nem hoznám magam ilyen helyzetbe..
For Whites Only meeting room!
ha freemail.hu cimed van, akkor maris kiestel :)
Szia,
A gond itt 2 dolog:
Mi van, ha nekem am. nem Gipsz Jakab hozzáférése kell, hanem csak 1 db hozzáférés?
1., Egy link 24 óráig él, te nem mondtál semmit a deaktiválásáról, ez alapján sejthető, hogy belépés után is tudom használni. Vagyis, csak a bejelentkezési url-t kell kitalálnom, aminek a mintája véges ( n hosszú, pattern jellegű mivel valószínűleg generált, és feltehetőleg alacsony entrópiájú, sőt, azt is tudom, hogy csak ascii karakter tud benne lenni). Ha egy darab url-t kitalálok ( a nyomok alapján végtelen próbálkozásból ), akkor már be is jutottam a rendszeredbe.
2., Ha nekem mégis nagyon-nagyon Gipsz Jakab accountja kell, akkor megtudom a születésidátumát, és mitm behallgatok a levelezési forgalmadba - majd elkapom a linket, és bent vagyok.
A második probléma összesen, hogy te a felhasználó+születést autentikációnak veszed, pedig nem az. Az csak legenerál egy darab linket és tokent hozzá ( authorizál belépésre ), a tényleges authentikáció a linkre kattintva történik. Így innentől kezdve egy támadónak erre a linkre kell csak fókuszálnia, minden más mellékes.
Arról nem is beszélve, hogy a usernek nem lesz kényelmes minden alkalommal ( bárhol is van ) belépnie a mail fiókjába, hogy a linket elérje. Tegyük fel, internet kávézóban el akarja érni a tartalmat, idegen gépeken, ki tudja milyen SWk társaságában, nem biztos, hogy hajlandó lesz a linkért belépni a mail fiókjába.
A másik oldal, ha könnyen beírható linket csinálsz, vagy áttérsz one-time-pw módszerre - tekintve a userek panaszkodnak, hogy a link kényelmetlen - akkor már abszolút dobod az entrópiát.
Amúgy, attól, hogy a link hosszú, még nem bonyolult. Ez egy téveszme. Attól, hogy szavakat raksz a linkbe szótárból pl, hatalmas mértékben megugrik a link hosszú, de az entrópia ha valaki meglátja ezt a mintát, elég durván leesik.
Ugyanez kialakulhat n db random karakterrel is, mivel mintázat fedezhető fel. Neked garantált entrópia kell ebben az esetben, ami meg megnövelheti a link generálás költségét drasztikusan - persze ha 100 userre tervezel csak, ez elhanyagolható költség.
Üdv,
LuiseX
Köszönöm a hozzászólásokat és a kérdéseket, pont ilyenekre volt szükségem.
Nem akarom feltalálni a spanyol viaszt, csak a sima e-mail cím és jelszó beléptetés helyett 1-el biztonságosabbat szeretnék alkalmazni
úgy hogy a gyenge jelszavak ne jelentsenek kockázatot, de ne is kelljen cetlire felírnia, mert elfelejtené.
A lenti lista alapján azt gondolom jobb valamivel, de lehet tévedek.
"Ez hogy all elo, pontosan?"
- random string + unique id (ez nem JWT token, de a sikeres belépés után azt kap, ami x ideig megőrzésre kerül a böngészőben)
"Mi az oka annak, hogy nem egy meglevo megoldast hasznalsz?"
- nem használom, és ilyen formában biztos nem is fogom :)
"Ha nem kapja meg a levelet, mert akarmi, akkor nem tud belepni?"
- igen ez így lenne, de több nagyobb cégnél is e-mail-es a második faktor és ott is ugyanez előfordulhat
"Hogyan és mivel garantálod, hogy ugyanazzal a linkkel ne tudjon még egyszer belépni a felhasználó?"
- a belépéssel azonnal törlődik az adatbázisból az egyedi random string + unique id
"Mi történik, ha az email késve jön meg és a felhasználó még egyszer megpróbál belépni, így 2 levelet fog majd kapni és megpróbál belépni mindkettővel? Melyik lesz érvényes?"
- mindig az utolsó és igen ezzel már nekem is van tapasztalatom (regisztrációt aktiváló linkek esetében) hogy nem mindig értik
Ha az e-mailben nem egy link menne csak egy 6 számjegyű kód? (OTP)
Bár az e-mail feladójából általában ki lehet deríteni, hogy milyen oldalhoz tartozik, de "hacker" akkor sem tudná hová beírni az oldalon, mert azt az oldalt nem éri el ahol be kellene ezt írni a bejelentkezéshez.
Viszont ha a levelezést feltörik vagy minden e-mailt elkapnak akkor az erős jelszó sem ér sokat, hiszen kérnek újat.
Ha a bejelentkezési folyamatokat hasonlítom össze, akkor biztonság szempontjából ez a sorrend helyes?
Tehát a megoldásom valamivel biztonságosabb mintha csak e-mail és 8 karakteres jelszó páros lenne?
Viszont ha erős jelszavakat kényszerítek ki, akkor már az jobb?
(a próbálkozásokat mindegyik esetben letiltaná a rendszer x ideig)
(erős jelszó = 10+ karakter, kis- és nagybetű, szám, és zxcvbn password strength meter használata)
(gyenge jelszó = 8+ karakter, kis- és nagybetű, szám, de pl. "Jozsi123" engedve van)
1. email és jelszó megadása (erős jelszó*) + applikációban megjelenő OTP beírása az oldalon
2. email és jelszó megadása (erős jelszó*) + SMS-ben érkező OTP beírása az oldalon
3. email és jelszó megadása (erős jelszó*) + email-ben érkező OTP beírása az oldalon
4. email és évszám (vagy valami) megadása + email-ben érkező kód beírása az oldalon
5. email megadása + email-ben érkező kód beírása az oldalon
6. email és jelszó megadása (erős jelszó*) + nincs OTP
7. email megadása + email-ben érkező linkre kattintás
8. email és jelszó megadása (gyenge jelszó*) + nincs OTP
Lehet tényleg túlságosan rápörögtem az egészre :D
Nem tudom mit jelent az ilyen forma, de szvsz egy OTP-s megoldas mar eleg jo. Persze lehet tovabb fokozni, kerdes, hogy mennyi penz van ra...
Nagyobb. Ha jol sejtem te nem egy Steam vagy :) Kepzeld mi tortenne, ha egyszer blokkolnak a Steam leveleit? Pl. MS siman megcsinal olyat, hogy egy teljes tartomanyt blokkol es napok amig sikerul leszedetni a sajat cimedet a listarol.
Epp nemreg meselte ismeros, az egyik COVID tesztes ceg ^^ emiatt nem tudott levelezni, gyorsan megoldottak, de ez csak nyug es nem 100%-ban rajtad mulik.
Igen!
Ezen felul ahogy irtam, nem tudhatod, hogy az email a nap vegen hogyan jut el a userhez (esetelg titkositatlan csatornan) vagy mar hozzafernek a levelezesehez.
En az elsot javasolnam.
Nem! Barcsak mas is igy tenne...
Ezert volt az, hogy amikor rakerdeztek cegnel, hogy kellene rendes ceges levelezes (ami addig egy postfix alias lista volt), akkor kozoltem, hogy a sajat megoldast lehetoleg felejtsuk el, mert tobb veszodes, mint amennyi haszon. Google/Microsoft/Amazon, es akkor mar egesz jo eselyunk van arra, hogy nem kerulunk spam- / tiltolistara, valamint nem nekunk kell szivni egy 40 eve foltozgatott protokol security es egyeb cuccaival (startTLS, reverse DNS, MX, helo valasz, DKIM, SPF, port szures, antivir, spam filtering, relaying es egyeb authentikacio/authorizacio beallitasa, backup, user management, webmail, POP3/IMAP, stb.).
Nem. Az 5., a 7. és a 8. egyenértékű: e-mail cím és ismeretlen erősségű jelszót kell hozzá tudni.
Sőt, nem, az 5. és 7. még rosszabb, mint a 8., mert az e-mail messze nem secure csatorna.
Ez alapján akkor az 1. és 2. az amit nem lehet elkapni, mert applikáció és sms forgalmának figyelése jóval nehezebb.
Így viszont mindenki aki ez alatti szintűt használ jobb lenne ha cserélné?
Ezt értem, hiszen a 8-as esetben nincs e-mail amit el tudnának kapni. Így csak kb. az oldalon tudnak próbálgatni.
Kivéve ha kérnek egy elfelejtett jelszós emailt és azt elkapják.
Attól függ, mire. Netbanknál más kell, mint Ló Béla blogjában a kommenteléshez, ahhoz a 8. is elég.
szvsz az emailben küldün klinkeket típusú megoldás azért is gázos, mert feltételezi hogy a (l)user ugyan azon az eszközön képes és hajlandó is belépni a saját email fiokjába és a te szolgáltatásodban egyszerre.
Én biztosan nem átlagos felhsaználó vagyok, emiatt nálam ezek szinte soha nem esnek egybe.
szóval az OTP kód küldése emailban vagy sms-ben az még okés, mert mondjuk a telefonján olvassa a leveleit, egy random böngésző gépen pedig beírja a kódot, és mindneki örül.
De ahogy többen is írták:
a valós megoldás az a hagyományos jelszó + valamelyik nagy OTP (soft) token.
(azt megteheted, hogy mondjuk egy belépés után x ideig elég egy süti megléte is, nem kell minden alkalommal az OTP)
És akkor valóban lesz kétfaktoros authentikációd...
szerintem.
zrubi.hu
Valamilyen SSO támogatása? Pl.: Google, Apple, Microsoft és saját.
https://naszta.hu
Itt az a gond, hogy vagy sajatot csinalsz, es kotelezed a regisztraciora, vagy tobbet is be kell csatornaznod, es vagy diszkriminalsz (a.k.a. disclaimerbe kiirod, hogy az oldal csak adott account meglete eseten hasznalhato), vagy adsz egy alternativ lehetoseget azoknak, akiknek egyik sincs/nem akarnak.
Szerintem is ez a helyes, nem kell password-el bajlodnod. Ha megse sso fele akarsz haladni akkor hagyd a sajat algoritmust, biztos hogy nem tudsz annal jobbat kitalani mint akinek ez a szakmaja:
https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_She…
https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_S…
Ahogy beleasod magad es szepen minden leimplementalsz amit itt tanacsolnak akkor rajossz, hogy jobb az sso es ez legyen mas problemaja. ha megszakadsz sem tudod megkozeleiteni azt a biztonsagot amit ok nyujtanak.
Ez nagyjából annyi, mintha minden egyes alkalommal jelszóemlékeztetővel lépne be a legális felhasználó és a "támadó" is: ha viszont valaki hozzáfér a levelezésemhez, akkor bármikor képes elfelejtett jelszó feature használatával új jelszót kérni, ez így nem gyengébb, mint bármelyik 1FA azonosítás egy kis kitérővel, de ez így nem 2FA.
https://iotguru.cloud
Nos, úgy látszik más is (wolt.com) elkezdte használni ezt a "jelszómentes" beléptetést.
Ami persze jelszavas, csak egyszer használatos.
Megtehetik, hisz a google-t hasznaljak a leveleik kuldesehez. Pl. sajat SMTP-vel nem mernem ezt bevezetni.
Fontos figyelembe venni, hogy milyen adatokhoz ferhetnek hozza. Egy bank sose hasznalna ilyet.
Nem tudhatod, hogy a level milyen csatornan es hogyan jut el a cimzetthez. Ha interceptalva van menet kozben a level, akkor mi az a kar ami keletkezhet?
Itt gondolom max rendelnek a nevemben par hambit, big deal amugy is tudnak regisztalni a nevemben egy accountot...
A te esetedben mi a legnagyobb kar ami keletkezhet ha valaki hozzafer egy user accountjahoz?
Ha valami ilyesmit használsz, kb. akármivel autentikálhatod a júzert.
Ahogy már többen is megírták, érdemes valami iparági szabványos megoldást használni.