Incerc sa dezvolt o metoda noua de passwordless auth in care utilizatorii trebuie sa trimita ei un email pentru a verifica emailul. Practic pagina de login va avea doar un buton care va deschide aplicatia de mail din sistem, cu campurile precompletare. Toata interactiunea presupune 2 clickuri (click pe login btn + click send email).
Sunt curios cum vi se pare ideea? Ati folosi o astfel de metoda in proiectele proprii?
problema e ca eu iti pot trimite email de pe orice addresa si in felul asta intru in contul altuia, from email nu e sigur, bine si in afara de asta, nu cred ca functioneaza.
Hey, e un flow interesant, și pentru film. Authenticator in felul asta - fără un program anume cred că ar găsii clienți.
Otoh email e un mediu teribil de făcut asta. Câteva motive:
Best effort delivery. Majoritatea email-urilor sunt instanțe, dar exista un long tail de latenta.
Sa trimiți email e greu la scara (și când ești mic nu e ideal). Spammerii au otrăvit puțul asta.
Nu-i chiar securizat. Securitatea e un addon care când merge când nu, și din care e ușor să ieși. Gen, daca serverul de mail al destinatarului nu are securizare, nici tu nu ai. Given the nature of the software.
@danielp principiul de functionare este la fel ca la magic links, se genereaza un cod care trebuie trimis prin email. Doar ca il loc sa il trimita sistemul catre user, il trimite userul.
Passwordless != two factor auth
Aceasta solutie nu se vrea a fi un competitor pt Microsoft/Google authenticator ci mai degraba pentru Auth0.
@serghei ca sa te autentifici pe site nu mai trebuie sa bagi mail si parola, ci apesi pe login, se deschide aplicatia de mail, trimiti, si esti logat
@konn emailul are semnatura digitala prin DKIM/DMARC. Nu se poate face spoof.
Am înţeles cum se foloseşte, dar nu înţeleg mecanismul prin care se asigură autentificarea. Înţeleg că te bazezi pe DKIM/DMARC, dar nu sunt foarte convins că în felul ăsta poţi fi sigur că userul este cel care pretinde că este. Poate nu poţi să spoofezi domeniul, dar nu sunt sigur că este valabil şi pentru user.
Este adevarat ca DKIM verifica doar domeniul, dar daca un atacator are access la serverul tau de mail astfel incat sa poata trimite un email spoof-uit catre sistemul de autentificare, deja sunt probleme mai mari :).
Dar nu e nevoie de un atacator din exterior. Daca de exemplu as avea acces la un cont de genul [email protected], as putea seta clientul email sa puna in MAIL FROM adresa [email protected]
@serghei majoritatea serverelor de mail nu te lasa sa faci asa ceva
@geosoft1 Merge si din browser, chiar acum lucram la treaba asta. Daca nu se deschide nicio aplicatie de mail (nu exista una in sistemul de operare) ti se vor afisa 3 butoane pentru gmail, outlook si yahoo. Daca apesi pe unul din ele, va deschide varianta web pe pagina de compose email
Ca idee, sistemul va oferi fallback cu magic links. Daca chiar nu iti merge nicio varianta sa trimiti mail (sau nu vrei), iti poti introduce adresa si vei primi un magic link pentru autentificare.
Well, “majoritatea” înseamnă că e o metoda unreliable. Mi se pare un lucru extrem de riscant să te bazezi pe campul “MAIL FROM” sau “FROM:” (sunt lucruri diferite astea) pentru o chestie ca autentificarea.
Din pacate nici mie nu mi se pare reliable. In primul rand astfel de mecanisme de autentificare trebuie gandite ca o tehnologie si nu ca un produs finit adica oferi cel mult un api care sa poata fi folosit de oriunde si nu o aplicatie care foloseste alte aplicatii.
In al doilea rand nu imi inspira incredere trimiterea unui mail catre server cand idea e exact invers tocmai ca sa poti dovedi exact cine esti. Nici ca alternativa la un sistem de autorizare, care functioneaza altfel, nu il vad.
Practic doar din adresa de mail si ceva headere nu poti sa iti dovedesti identitatea. Daca ai trimite insa un cod dupa o regula comuna cu serverul sa zicem ca ar functiona dar nu ar fi necesar sa faci asta.
In plus fata de asta mailurile sunt decriptabile si vizibile in fel si fel de masini de tip firewall (eg Barracuda Networks). Cineva va putea sigur sa vada si sa foloseasca o astfel de optiune.
Well, “majoritatea” înseamnă că e o metoda unreliable .
Da, nu este 100% safe. Solutiile comerciale nu permit asa ceva, ci doar daca ai fi intr-un domeniu cu un custom mail server. Si chiar si acolo, depinde cum a configurat sysadminul MTA-ul.
Dar da, ai dreptate, nu este 100% sigur. Dar aici as vrea sa discutam putina filosofie :). Multe aplicatii au nevoie de unique identity, nu neaparat security. Adica au nevoie de o metoda prin care sa identifice unic un utilizator, nu neaparat ca se asigure ca acel cont de utilizator nu poate fi spart.Aici ma refer la site-uri/aplicatii precum 9gag, diverse bloguri, site-uri de joburi etc. Nu aplicatii unde securitatea contului este esentiala cum ar fi cele care au carduri bancare salvate.
Mi se pare un tradeof bun in acele cazuri, simplifici autentificarea, dar renunti la 1% din securitate. Stiu ca pare absurd la prima vedere, dar puneti-va urmatoarea intrebare. De ce ar vrea cineva sa depuna efortul sa va sparga contul pe un site gen 9gag? Mai ales ca nu e chiar simplu de spart, ci doar in anumite conditii, etc. Pe langa asta, as putea merge un pas mai departe si sa spun ca un sistem bazat pe mail+parola e mai vulnerabil decat metoda aceasta. Sunt multe articole pe tema asta, de ce sistemele bazate pe parola nu sunt safe, mai ales in site-urile acestea unde utilizatorii folosesc parole simple, pentru ca nu ii intereseaza prea tare ce se intampla cu acel cont.
Anyway, un punct de vedere foarte bun, iti multumesc. O sa trebuiasca sa ma gandesc bine cum voi prezenta acest aspect in produs.
Nu imi dau seama exact ce intelegi tu prin produs finit? Poate nu am dat suficiente detalii, dar sistemul va functiona similar cu autentificarea cu Facebook (OAuth). Adica dai redirect catre nova-authenticator.com unde userul va trimite emailul si se va autentifica, si apoi site-ul va redirecta inapoi catre site-ul tau si va trimite in query param un cod de autorizare. Mai mult, sistemul va pune la dispozitie si un API daca nu vrei sa folosesti UI-ul default ci vrei sa faci totul la tine in site. Dar asta presupune ceva munca din partea developerului. Ideea in prima faza este sa fac integrarea cat mai simpla. Si este, adica nu ai nevoie sa instalezi absolut nimic, sistemul va intoarce un jwt pe care il poti decoda folosind un appSecret generat doar pt site-ul tau.
In al doilea rand nu imi inspira incredere trimiterea unui mail catre server cand idea e exact invers tocmai ca sa poti dovedi exact cine esti
De ce? Pentru 99% din cazuri va functiona. Mai mult, aceasta metoda elimina una dintre problemele majore in primirea de emailuri: phishing.
Practic doar din adresa de mail si ceva headere nu poti sa iti dovedesti identitatea. Daca ai trimite insa un cod dupa o regula comuna cu serverul sa zicem ca ar functiona dar nu ar fi necesar sa faci asta.
Ba poti, tocmai asta e ideea produsului. Iar mecanismul este o combinatie a ceea ce ai spus tu. Se genereaza un cod pe server care este pasat catre front end (via HTTPS) care este trimis ca subject in mail.
In plus fata de asta mailurile sunt decriptabile si vizibile in fel si fel de masini de tip firewall
Pai si nu e valabil si daca primesti un mail?
Din nou, produsul incearca sa rezolve problema in proportie de 90%. Pentru cateva edge case-uri se poate merge pe alt sistem.
cred ca ai pus mai mult efort in prezentare si-n oferta decat in aplicabilittate.
acu, intrebare. de ce as vrea sa-ti platesc tie pt un numar limitat de autentificari cand pot folosi alte sisteme care fac acelasi lucru, gratuit si nelimitat?
Mi se pare ca esti putin troll.
Ai vrea sa folosesti asa ceva daca ti se pare ca o solutie passwordless care functioneaza pe principiul descris mai sus ti-ar face produsul mai user friendly.
Flow-ul „normal” de passwordless: site-ul trimite link pe mail -> userul face click pe linkul din mail
Flow-ul tău: userul (care primește un popup mailto) trimite codul spre site.
Eu nu aș folosi acest flow inversat dintr-un simplu motiv: UX. Tu pleci de la o premisă (posibil) greșită: că toți userii au client de mail configurat pe sistem. Ceea ce nu e neapărat adevărat.
Iar de aici apar două probleme:
un mailto: nu va face decât să deschidă un ecran de configurare unde trebuie să se autentifice (în cel mai bun caz) sau să bage servere smtp, porturi și alte minuni.
cum procedez dacă folosesc pc-ul unui prieten care are clientul de mail configurat?
chiar nu trolez, da-mi un motiv pentru care as renunta la autentificare prin facebook/google (ca sa numesc doua servicii foarte folosite) si as folosi metoda ta.
ah… ca uitasem sa intreb, cu datele alea care ajung in serverul tau ce faci?
Pai nu renunti la fb, google. E o metoda complementara, asa cum este si acum. Toate site-urile care au autentificare prin fb/google ofera si signup/login normal cu email si parola. Asta se poate inlocui folosind o solutie passwordless.
ah… ca uitasem sa intreb, cu datele alea care ajung in serverul tau ce faci?
nimic. Asta e intrebare de baraj. Vezi de ce zic ca esti trol/hater. Eu incerc sa adun niste feedback constructiv sa vad daca ar folosi lumea o solutie care e radical diferita fata de ce avem acum. Si tu ma intrebi cat costa halatu` …
pentru film. Authenticator in felul asta - fără un program anume cred că ar găsii clienți.