Van értelme a jelszónak?

Fórumok

Sziasztok

Jelszó nélküli web készítésén gondolkodom. (Linuxon, bár ez mindegy)

Bejelentkezésnél vagy regisztrációnál kiküldök egy linket a felhasználónak, ami tartalmaz egy egykulcsos titkosítással és időbélyeggel ellátott tokent. 
A felhasználó erre kattintva eljön az oldalra, és automatikusan beléptetem, nem zaklatom tovább jelszóval. Továbbá kiírom, hogy használhat kétlépcsős azonosítást, ha szeretne.

A kulcsot, amit a szerveren tárolok, természetesen ugyan olyan biztonsággal tárolom, mint a shadow fájlt, vagy egyéb privát kulcsokat, jelszavakat, stb.

A titkosszolgálatok, szuperkémek, gigacreckerek ha jelszó van is megoldják hogy hozzáférjenek az adatokhoz, egyéb nem ebbe a kategóriába tartozó ellenérvek amik foglalkoztatnak.

Van valami hátulütője ennek a megoldásnak?

Köszönöm.

Hozzászólások

Szerkesztve: 2021. 09. 24., p – 11:44

En azon gondolkozom, hogy ha egy site-hoz pl. google auth-ot hasznal valaki oda miert kell 3 dolgot beirni?
Altalaban a felallas a kovetkezo:
email v. usernev beir
jelszo beir
OTP beir

Ide eleg lenne egy "jelszo" (nem jelenne meg begepeles kozben), ha sikerult jol beirni akkor irhatja utana a OTP-t.

Kozben rajottem, hogy az email azert kell hogy tuti benne legyen az adatbazisban valami kontakt. Ha a user elfelejti a jelszot legyen hova kuldeni, de mondjuk lehetne ra opcio, hogy az email-t ne kerje mindig csak a jelszot es mondjuk 6 havonta 1x  email cimre kuldott linkkel engedje csak belepni (es OTP ha kell esetleg).

"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."

Jelszót nem kérnék soha. Ha aktivitás van az oldalon és azt érzékelem hogy ~1 hétig érvényes a belépése, automatikusan meghosszabbítom. Ha lejárt meg kiírom hogy lejárt és kattintson az emailben kapott linkre.

OTP helyett meg 2FA-t használok, ha valaki nagyobb biztonságot szeretne.

Ez lenne a terv.

2FA/MFA = 2/tobb lepcsos azonositas, vagyis az azonositasi metodusokbol legalabb kettot vagy tobbet hasznalsz.

  • jelszo
  • One Time Password (SMS, authenticator, mailben kapott, stb)
  • biometrikus azonositas
  • private key
  • magic link
  • stb.

Szoval siman lehet magic link + OTP egy 2FA, bar olyan szempontbol rossz, hogy altalaban az szokott lenni, hogy az egyik amit tudsz (jelszo), a masik amit birtokolsz (mailcim, telefonszam, authenticator, kulcs).

Szerkesztve: 2021. 09. 24., p – 12:15

Van valami hátulütője ennek a megoldásnak?

Szerintem a legnagyobb problema vele az, hogy nem tudod, hogy a user milyen csatornan tolti le a leveleit. Mondok egy extrem helyzetet: titkositatlan POP3-at hasznal

Itt minidg az a kerdes, hogy az adott kornyezetben valami elegseges-e. Ezt te tudod felmerni. Mi a legnagyobb kar ami keletkezhet, ha egy illetektelen szemely belep?

nem kell ennyire elrugaszkodni... elég ha a leveleézse egy másik eszközön van, mint amin a böngészője.

Minden ilyen esetben durván megszivatod a felhasználót, és kényszeríted hogy adjon lejjeb az esetlegesen  eddigre megmaradt privacy-ból.

 

Sőt tovább megyek, ez a megoldás csak annyira biztonságos, (és privát) mint amennyire a levelezésed  = semennyire.

pl

- más is elolvashatja, használhatja, vagy akár módosíthatja is a linkedet...

és nem utolsó sorban ha ez az agymenés elterjedne, így  elég egyszerű belőle működő phishing levelet készíteni...

Mindeközben az IT security 20+ éve azt szajkózza, hogy nem kattintunk random linkekre ;)

A feltételezett rosszindulatú egyén valahol valamilyen módon módosítja az emailt amit kiküldök, erre a felhasználó rákattint, majd elitányítja egy adathalász oldalra, ami lemásolta az oldalam kinézetét.

Ez idáig bármelyik weboldalra elmondható.

Ezek szerint az internetem működő regisztráció és elfelejtett jelszó email megerősítéssel egy agymenés?

Majd ha kérnék jelszót, és a felhasználó beírja a jelszavát az adathalász oldalon. Ez nem agymenés?

Te ezt tartod biztonságosnak?

Ez nem agymenés?

De az. különösképpen, ha ez az egyetlen hitelesítési csatorna.

Ki is használják rendesn ahol csak lehet. Így eshet meg, hogy egy szimpla email account "meghekkelésével", az összes ilyen módon működö szolgátlatás felett elveszti az irányátást a szerencsétlen (l)user.

 

Nem utolsó sorban vannak működő, kipróbált alternatívák a jelszóhasználat "elkerülésére". az sem véletlen, hogy egytől egyik többfaktoros hitelesítésen alapulnak - ahogy ezekre hoztak is már példát többen.

zrubi kollega mar leirta kb mire gondolok, azt az esetet emelnem ki, hogy ha interceptalato a level valahol akkor az mar eleg ahhoz, hogy valaki be tudjon lepni a rendszerbe.

Mondjuk ez esetben mondjuk elvarnam, hogy az oldalon egyszerre csak egy session-t lehessen hasznalni, azaz ha kerek egy uj kodot akkor rugja ki azt aki egy elozo-t hasznal. Esetleg figyelmeztessen, hogy valaki egy masik cimrol aktivan hasznalta es az a session le lett gyilkolva.

Btw, ha az alaklamazas altalt tarolt adat nem szenzitiv, akkor ez a modszer lehet elegseges. Peldaul nem erdekel, ha barki hozzafer a teveclub-os tevemhez (ha letezik meg olyan) xD

Pár hónapja volt ugyanez a téma, keress rá, szerintem felejtsd el.

OAuth lehet a jelszó nélküliség alternatívája. Hobbi oldalon csináltam már ilyet, hogy google email címmel be lehet lépni az én oldalamra. A jelszó beírását a google oldalán kell megtenni, ha be van lépve a böngészője, akkor csak le kell okézni, hogy az én oldalamon is belép. Én nem tárolok jelszót, csak egy email->user, szerepek listát, ami alapján az én oldalamon megkapják a jogaikat az emberek.

Ha már egy szolgáltatónál megcsináltad, akkor hozzá lehet adni másokat is, amikkel elfogadsz OAuth azonosítást (pl github, stb).

Nagyobb forgamúnak és átlag usereknek tervezett szolgáltatás esetén persze probléma, ha lesz olyan usered, aki nem hajlandó (vagy nem tud) OAuthot providert választani a lehetséges választékból.

egyszerű felhasználóként alapvetően mindenhova google/facebook account-tal lépek be, ahova csak lehet

Kivancsi vagyok mi lesz akkor ha a FB valami okbol letiltja az accountot (mert ugye barmikor megteheti). Google szinten megteheti, bar ott erre kisebb eselyt latok.

"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."

Pont ilyennel szívatta meg magát egyik ismerősöm.

Gondolta majd Ő profi lesz adatvédelemből, és kreált magának egy hamis facebook fiókot, hogy azzal lépjen be. 
Oldal kért tőle valós e-mail címet, de nem olyat adott meg, mert hogy akkor tudják majd, hogy ő lépett be.

Aztán a facebook törölte a kamu profilt, neki meg nincs hozzáférése a kamu e-mail címéhez, így kizárta magát örökre.

De mondjuk a privacy nem sérült legalább... XD

Nagy Péter

Igen, jo! Megpedig 1 olyan okbol, amit meg nem lattam leirva: a password reset -et is az email cimre kuldik, ergo egy esetleges attacker, ha megvan a hozzaferes az email-hez, akkor mar tokmindegy, barmely site-on password reset-tel bejuthat (2FA eseten persze nem).

Az otlet imho teljesen jo, meg annyit, hogy a szerveren nem az email-ben kuldott (eros random-mal generalt) token-t tartanam, hanem annak sha hash-et. Esetleges dump eseten meg mindig biztonsagos.

Bocs de nem ertelek. Amit irtam szerintem tok valid ebben a temaban. Milyen lecsapolt uvegszal?

Pl. egy malware a forgalmat magan a client gepen is le tudja hallgatni. Mi van ha van hozzaferese a szerverhez amire a user kapja a levelet? stb..

Ha van MFA + jelszo akkor a jelszo cseret sem fogja tudni megcsinalni egy tamado kizarolag az email cimmel.

"mi van akkor ha mashogy jut hozza a level tartalmahoz?"

Ha nem a levelesládához fér hozzá, akkor valahol a postástól menet közben lopja el a levél tartalmát. Ez meg üvegszál, arany, réz, stb. közlekedik. Annak a tartalmának a figyelése olyan ügy, ami nemzetközi probléma.

Az is ha routereket törnek fel, és ott figyelik a forgalmat. 

Bármilyen egyéb, probléma.

Én nem olyan módszert keresek, ami "mindenki is" problémáját megoldja, hanem hogy egy email egy tokennel biztonságos-e. Fentebb írtam https://hup.hu/comment/2677274#comment-2677274 hogy a regisztráció és elfelejtett jelszó se biztonságos, ha van jelszó azért, ha nincs jelszó azért.

"ami foglalkoztat, hogy milyen biztonsági kockázata lehet."

No hard feelings. En leirtam a szakmai velemenyem, a dontes a tied :)

"nem vehetem magamra a világ pontjairól érkező felhasználók gondjait, akiknek amúgy is vírusos a gépük, vagy heckelt a telefonjuk. Ezeknek még a 3 faktoros is kockázatos"

Ha egy ilyen rendszert tervezel, velemenyem szerint, kutya kotelesseg elgondolkozni azon, hogy milyen problemak johetnek uzemeltetoi/felhasznaloi oldalon. Ha a sarki hamburgerezo rendelo oldalat irod, akkor ertem, hogy nem akarsz ezzel foglalkozni.

Ha viszont valami olyat csinalsz ahol vannak fontos adatok, akar olyan ami penzt is er, akkor javaslom alaposan gondold at, hogy mit csinalsz. Te latod at jobban, hogy mi is pontosan ez a webes alkalmazas en csak okoskodok.

De fel lehet ezt a megoldast pimpelni amit te szeretnel megvalositani, de novleni fogja a komplexitasat, szvsz nem eri meg (legalabbis attol fugg megint, hogy mi az amit vedeni hivatott).

Segíts nekem megoldani egy világot éritő (~99%) elfelejtettem a jeszavamat kérdést.

Tételezzük fel hogy email jelszó megint jelszó klasszikus módon regisztrált a felhasználó, emailben megerősítette hogy Ő regisztrált.

X idő elteltével be szeretne újra lépni, de nem emlékszik a jelszóra, mindegy miért.

Rákattint az elfelejtett jelszóra, beírja az emailt, küld, majd kap(ná) egy emailt. miközben

^/feltörték|lehallgatják|stb/$

A betörő módosítja a jelszót, belép, garázdálkodik,

a felhasználó meg vár hogy megkapja az emailt, nézi a spam-ben, sehol semmi, majd újra rákattint az elfelejtett jelszóra, beírja az emailt, küld, majd kap(ná) egy emailt. miközben... Goto ^/feltörték

 

Erre mi a megoldásod? Ez nem függ az én felvetésemtől.

Felreertesz.

Mindegy mi van az authentikáció után, ez attól független.

Ezzel nem ertek egyet.

Segíts nekem megoldani egy világot éritő (~99%) elfelejtettem a jeszavamat kérdést.

Mirol van szo? Ez egy banki alkalmazas vagy egy kutyatap webshop? Mondj valami hasonlot, nem kell pontosan leirni, hogy mit csinalsz eppen.

xD

Na hat akkor ... mondjuk akkor max a felhasznalo szemelyes adataihoz lehet hozzaferni egy ilyen linklopasi hadmuvelettel. Mondjuk esetleg a payment szolgaltatohoz elmentett kartyaval lehet rendelni. De mivel a banki szolgaltatonal legtobb esetben van 2FA es fraud protection igy nagy kar nem keletkezhet. Ha olyanok a korulmenyek, hogy atmegy es a user nem veszi eszre a fizetest, akkor max visszakerul az aru ezaltal csokken a kar.

Ugyhogy a legnagyobb kar akkor keletkezik ha valaki a user neveben rendel valamit. Tegyuk fel rendlenek 100 doboz macskakajat aminek a szallitasi dija 5 ezer forint, utanvettel. Ezt a felhasznalo nem akarja kifizetni mert nem o rendelte. Kereskedo torli az acocuntjat es benyeli a szallitasi koltseget.

Azt gondolom, hogy megfelelo policyvel el lehet kerulni meg ezt a kart is, ha egy telefonhivas be van iktatva mondjuk nagyobb erteku rendeleseknel.

Ebben az esetben szerintem kb. tomind1, hogy jelszavas vagy email-es login van -> user es kereskedo szempontjabol is alacsony a kockazat.

Ajanlom a figyelmedbe ezen az oldalon a "The security implications of magic links" es a "Magic links can provide a great customer experience" reszt.

En ezekkel pimpelnem fel egy kicsit:

* login utan kikuldenek a browsernek egy cookie-t egy megfeleloen nagy azonositoval. A magic linkre valo kattintas utan ezt is ellenoriznem, hogy a browser ezt visszakuldi-e. Ez persze problemat fog okozni ha masik browserben vagy masik eszkozon nyitja meg az oldalt, ilyenkor bekernem a jelszavat erre valo hivatkozassal.

* time limit lenne ra, ami persze megint porblemas lesz, ha valamiert kesik a level, de akkor ott a fallback password megoldas

* fallback megoldaskent mindig ott lenne a password auth

* mindenkepp megyozodnek rola, hogy az en smtp szerverem titkositott csatornan juttatja el a leveleket

* nem engednem a dupla bejelentkezest, ha megis elofordul, a felhasznalonak jeleznem, hogy volt egy eppen aktiv sessionje, amit most kizartunk a rendszerbol es lehetoseget biztositanek ra, hogy megnezhesse mikor es honnan jelentkezett be

Btw, van olyan security scanner ami kinyitogatja a levelekben levo linkeket, hogy beleturjon, hogy mi van az oldalon. A problema az, hogy igy bizony siman beenged akarkit, ugyhogy erre figyelni kelll, kell valami user interaction legyen a login-nal. Erre mondjuk jo a fent emlitett cookie-s megoldas, hisz a security sw-nel az nem lesz meg.

Mackakakjas oldalra tulzas az otp, szvsz. nem kell. Jelszoemlekezteto: Mivel alacsony a kar ami keletkezhet, erre jo egy sima jelszoemlekezteto szvsz, nothing fancy.

Kb. ezek jutottak eszembe hirtelen, remelem segit!

Ha alacsony a kár egy jelszóemlékeztetőnél, és ezt fixáltuk, a kár keletkezik.

Azt is fixáltuk hogy ez a kár csak akkor következik be ha:

  • humanoid gépét feltörték,
  • humanoid telefonját feltörték,
  • rosszindulatú humanoidok lehalgatják a routert, kábel adatforgalmát
  • stb. rosszindulatú csúnya humanoid

Ha a kár nem következik be, mennyivel kritikusabb ugyan ezt a módszert regisztrációhoz is használni? (nem banki rendszer)

Az elfelejtett jelszó problémáját üzembiztosan ÉS felhasználóbarátan még senkitől nem láttam megoldva. Próbálkozások vannak, de igazából egyik sem az igazi. Különösen vicces, amikor a 2 faktort (email + sms/totp) sikerül 1 faktorra (email cím birtoklása) visszavezetni.

Itt az a feltetelezes, hogy a tamado ismeri a celszemely email cimet. De ha nem ismeri a tamado az email cimet es mitm-be beall (valahol) akkor egyszercsak latni fog egy emailt amiben van egy belepo link ha a user titkositatlan csatornan tolti le a leveleit. Ez azert egy lenyeges kulonbseg.

 Jelszo auth eseten kerhet password reset-et, ami emailben jon, szepen elkapja es megkattintja a linket benne, bam, ove az account.

Ja, egy pizzarendelo oldalnal valoban. Komolyabb dolgoknal szokas extra infot bekerni. Pl. transferwise push notit kuld vagy sms-t a pass resethez, security question stb...

A jelszavas auth csak annyira eros, amennyire a password reset.

Ja ... kb.

Szivesen társalogtam Veled, de másnak írt ilyen problémák kizárására írtam a kérdásben hogy:

 

A titkosszolgálatok, szuperkémek, gigacreckerek ha jelszó van is megoldják hogy hozzáférjenek az adatokhoz, egyéb nem ebbe a kategóriába tartozó ellenérvek amik foglalkoztatnak.

Szóval vakvágány. Vagy humanoid.

Alapvetően mindig egy tradeoff van a használhatóság és a biztonság között. A link-el történő belépés pontosan ugyanazt a biztonságot adja, mint az elfelejtett jelszó esetén küldött email-lel való jelszócsere, ha tehát az utóbbit engedik (és viszonylag sok helyen engedik) akkor alapvetően rendben van a rendszer.

Amennyiben viszont az email-t nem tekintjük biztonságos csatornának, akkor hogyan is oldod meg a jelszócserét? Kérsz az email link mellé egy második faktort?

Nos, nézzük:

  • SMS/TOTP: elvesztette a telefonját, bukó.
  • Security kérdés és válasz: Mennyire tud emlékezni arra, hogy a Hány éves a kapitány kérdésre az a válasz hogy rántotthús?
  • Első belépéskor kapott egyszer használatos kódok: bizonyára kinyomtatta (ki nyomtat 2021-ben?) és berakta a fiókba...
  • Rendszerhasználati kérdések: mi volt a dokumentum neve amit 3 hete küldtél bm@maca.hu címre?

Őszintén, nekem még nem sikerült felhasználó barát ÉS biztonságos jelszócserés megoldást látnom, amely reális erőforrással megvalósítható, és az alapvető usecase-eket kezeli.

telefon+sms is lehet meg, de ugye ott meg azt lehet mondani, hogy mi van ha ellopjak/feltorik a telefonjat...

Ha meg mar olyat csinalsz, hogy teszem azt, elofizetsz whatsapp business-re es kuldesz neki whatsapp-en kodot, akkor meg a privacy geek-eket meg az oregembereket/remeteket is kizarod.

Szumma, ezert van mindenhol a mai napig sima email + jelszo alapu azonositas: ezt mindenki ismeri es tobbe-kevesbe kiszurhetoek a hackelesi kiserletek is; pl. egy account, ahova 10 eve egy hodmezovasarhelyi ip-vel es windows edge-el lepnek be, hirtelen ukrajnabol chrome-al lep be valaki, az red flag. Meg rengeteg hasonlo okossagot lehet csinalni meg, pl. lerakni egy biztonsagi cookie-t, 10 ev expiration-nel a bongeszobe, es ha azt latod, akkor OK, ismerjuk a uzert. Aztan ott van captcha is persze, mert a hekkerek tipikusan botokat hasznalnak, a hcaptcha-n fennakadnak. Kb ezzel a 3 modszerrel ki is szurted a hack probalgatasok 90+ szazalekat. A maradekot meg a customer service kezzel megoldja.

Szerintem reálisan minden belepéshez új kulcsot generálunk, ezt hasheljük.
És csak a legutoljára kiküldött linkben lévő kulccsal kell, hogy beengedje az usert, őt is csak a kiküldést követő 15 percen belül.

Az hatalmas sec hole lenne, ha ugyanazzal a linkkel kétszer is be lehetne lépni (már csak azért is, mert a link benne maradhat a böngésző előzményekben)

Nagy Péter

Szerintem jó a magic link, mégjobb, ha van mellette 2FA.

 

Általánosságban szerintem érdemes felírni a támadási vektorokat (én rajzolni is szeretek :) ), és eldönteni, hogy pontosan mi ellen akarsz védelmet nyújtani, és mi ellen nem. Mert pl. hiába van Google Authenticatoros TFA + magic link, ha a usernek a levelezése ott van rásyncelve a mobiljára, ahogy a Google Authenticator fut, és az van kompromittálva. Na az ilyenekre lehet szépen dokumentálni, hogy out of scope, és azt feltételezzük, hogy a user végpontjai nem kompromittálódtak. :) 

Szerkesztve: 2021. 09. 25., szo – 00:17

Hátulütők szerintem (miközben használok magciklink megoldást olyan helyen, ahol nincsenek kritikus adatok):

  • Az email szerver-szerver kommunikáció kilencvenvalahány százalékban most már titkosított, de még mindig számottevő amikor nem és útközben lehet olvasgatni.
  • Említették már, a user levelesfiókja másik eszközön van, mint ahol belépne a rendszerbe. Ez elég problémás dolog, főleg ha egyszerű lelkületű felhasználókról van szó.
  • Nagyon baj, hogy phishing szűrők egy része izgatott lesz a link láttán és blokkolja ilyen vagy olyan módon a leveledet és/vagy az oldaladat.

Az egyszerűsítés iránti igény és a jelszóutálat élő probléma, egyre inkább. Az egyik projektben a passwordless megoldásokat nézegetjük most (lásd MS Hello és barátai), de még nem vagyok ott, hogy erről pozitív dolgokat mondjak. Erősen próbálkozni fogunk, mert a 60+os főnököket nem lehet rábeszélni egyetlen komplex jelszó használatára sem, nemhogy egy MFA-ra.

Karika 1. Ez a dolog nem érdekel. Mint ahogy Téged se hogy hány gyerek halt szomjan amíg ezt leírtad.

Karika 2. Erről írtam itt, kávéházas belépéshez checkbox, PIN jöjjön ne token, de elfelejtetted mondani hogy itt a kuki az csak addig éljen ameddig a böngészőt be nem zárják.

Karika 3. Bár nem írtam, de az egyértelmű hogy form post nincs captcha nélkül publikus weben.

 

Az új dolgoktól való félelem nem azt jelenti hogy rossz. A beléd nevelt hipotézis gátol az új dolgok megértésében és elfogadásában.

Lehet hogy ez csak írási stílus, de kicsit fura a kioktató hangnem, miközben az emberek segíteni akarnak neked, ráadásul nem is írnak baromságokat.

Engem ugyan nem gátol semmi, ezek tények és kockázatok. Minden normális rendszertervezésnél kockázatokkal operálsz, van amit elfogadsz és van amivel nem lehet együttélni. Ahol egy alapvető kockázatelemzést sem csinálnak legalább józan ész alapján, abból lesznek a mindenféle módon lerohadó projektek. Nem kell keresni, minden nap teli a hírek ilyennel.

Az email leak valós kockázat, ha irdtlan pénz szer ezer az esetleges következmény, akkor az 1% kockázattal sem élsz. Ez nem hit kérdése. Van olyan hely ahol az email szóba sem jön, mint az autentikáció bármilyen forrása, eszköze vagy lépése.

Az hogy az email máshova érkezik mint ahol a user be szeretne lépni nem biztonsági kérdés hanem usability. Ha a szolgáltatásnál kiemelt fontosságú, hogy az egységsugarú user tudja használni, akkor ez is a szempontok közé tartozik.

Ha az új dolgoktól való félelemre tett megjegyzésed a passwordless login kapcsán írtad, akkor lehet hogy nem nézted meg hogy mi az, mert semmi köze a magicklink megoldáshoz.

Szerkesztve: 2021. 09. 29., sze – 17:48

Én használok ilyen szolgáltatásokat, opcionálisnak jó ötlet (begépelem a jelszavam, vagy kérek linket), de kötelezőnek zavaró lehet.

Talán eggyel jobb megoldás, amit az nVidia is csinál, hogy belépéskor olyan linket küld a levelezőbe, amit megnyitva az eredeti belépési helyen enged tovább, nem ott, ahol a linket megnyitottad. (belépek gépen, kiírja, hogy küldött egy levelet. Rákattintok a levélben lévő linkre telefonon, és a gépen megy tovább a belépés (telefonon csak kiírja, hogy sikeresen jóváhagytam a belépést))

Szerk.: Az elejét kivettem, mert azóta már olvastam a kávéházas példát.

Nagy Péter