Magic/Tragic ईमेल लिंक को एकमात्र लॉगिन विकल्प नहीं बनाना चाहिए
(recyclebin.zip)- ईमेल से लॉगिन लिंक भेजने वाले Magic Links पासवर्ड फ़िशिंग और reused password लीक के जोखिम को कम कर सकते हैं, लेकिन जब इन्हें एकमात्र विकल्प बना दिया जाता है तो लॉगिन का घर्षण उपयोगकर्ता पर डाल दिया जाता है
- जो उपयोगकर्ता कई कंप्यूटर इस्तेमाल करते हैं या काम और निजी डिवाइस अलग रखते हैं, उनके लिए ईमेल पाने वाला डिवाइस और लॉगिन करने वाला ब्राउज़र अलग होने से फ़्लो आसानी से टूट जाता है
- SMTP delay और लिंक पहुँचाने की प्रक्रिया के कारण लॉगिन 2 सेकंड से लेकर कई मिनट तक देर से हो सकता है, और in-app browser व RSS reader apps में मोबाइल usability भी टूट सकती है
- ईमेल या SMS से मिले OTP को सीधे दर्ज करने का तरीका भी असुविधाजनक है, लेकिन जब ईमेल client और browser के बीच लिंक ले जाना मुश्किल हो, तब यह Magic Link से बेहतर हो सकता है
- भले ही Magic Link को default रखा जाए, फिर भी तकनीकी और privacy को महत्व देने वाले उपयोगकर्ताओं के लिए passkeys जैसे मज़बूत विकल्प साथ में देने चाहिए
Magic Link कब असुविधाजनक हो जाते हैं
- “Magic Links” कभी भविष्यवादी PDA के लिए इस्तेमाल होने वाला शब्द था, लेकिन अब यह Auth0 जैसी कंपनियों द्वारा ईमेल में शामिल लॉगिन लिंक के लिए इस्तेमाल किया जाता है
- 404 Media ने “We Don’t Want Your Password” में Magic Link का समर्थन करते हुए कहा कि ईमेल लिंक, पासवर्ड की तुलना में फ़िशिंग करना कठिन बनाते हैं, पासवर्ड लीक की ओर नहीं ले जाते, और लीक हुए पासवर्ड के पुन: उपयोग का जोखिम भी कम करते हैं
- एकल laptop और mobile device पर केंद्रित जीवनशैली में यह आसान लग सकता है, लेकिन जो उपयोगकर्ता कई डिवाइस और browser इस्तेमाल करते हैं, उनके लिए जटिलता जस की तस उपयोगकर्ता पर आ जाती है
- असुविधा के उदाहरण:
- कई डिवाइस: जो उपयोगकर्ता gaming PC या work laptop पर निजी ईमेल नहीं रखते, उनके लिए लॉगिन लिंक तुरंत खोलना मुश्किल होता है
- गति: SMTP delay और लिंक को सही browser तक ले जाने की प्रक्रिया के कारण इसमें 2 सेकंड से कई मिनट तक लग सकते हैं
- मोबाइल: in-app browser का उपयोग बाधित हो जाता है, जिससे RSS reader apps में local links संभालना असुविधाजनक हो जाता है
- सुरक्षा: निजी ईमेल को work device पर खोलने या इसका उलटा करने के लिए प्रेरित करने वाला फ़्लो सुरक्षा की दृष्टि से लाभ नहीं देता
विकल्प और न्यूनतम सुधार
- ईमेल या SMS से मिले OTP को सीधे दर्ज करने वाला passwordless तरीका भी असुविधाजनक है, लेकिन जब ईमेल client से लॉगिन वाले browser तक लिंक आसानी से ले जाना संभव न हो, तब यह अधिक व्यावहारिक हो सकता है
- Stratechery Passport के माध्यम से लिंक क्लिक या OTP इनपुट का विकल्प देता है; इसमें passkeys implementation के बिना असुविधा उपयोगकर्ता पर डालने की सीमा बनी रहती है, लेकिन केवल Magic Link देने की तुलना में यह उपयोगकर्ता की स्थिति को अधिक ध्यान में रखता है
- भले ही Magic/Tragic Link को default के रूप में रखने पर ज़ोर दिया जाए, passkeys जैसे मज़बूत विकल्प साथ में देना बेहतर है
- Ricky Mondello का Magic Links Have Rough Edges, but Passkeys Can Smooth Them Over इस समस्या को passkeys से कम करने के तरीकों पर आधारित एक संदर्भ लेख है
1 टिप्पणियां
Hacker News की राय
Magic link से ऐप बनाते समय आई समस्याएँ: यूज़र को ऐसे device पर login करना पड़ सकता है जहाँ email access करना असुविधाजनक हो, इसलिए magic link में वैकल्पिक login code शामिल होना चाहिए
साथ ही उन मामलों को भी handle करना होगा जहाँ email client preview screenshot बनाने के लिए link अपने आप खोल देता है, और ऐसे email clients को भी ध्यान में रखना होगा जो यूज़र के पसंदीदा browser की जगह in-app browser में link खोलते हैं
उदाहरण के लिए, iOS यूज़र Firefox mobile पसंद करे तब भी email app link को Safari-based in-app browser में जबरन खोल सकता है
मेरे हिसाब से one-time code input page पर ले जाने वाला तरीका ऐसी कई समस्याओं से बचा सकता है
हाल ही में हमें ऐसी समस्या हुई कि नए mail account अपने-आप verify हो गए, और जब यूज़र ने click किया तो magic link पहले ही invalid हो चुका था, क्योंकि Microsoft ने inspection के दौरान उस link से पहले login कर लिया था
McDonald's ने email/password से magic link पर switch किया, उसके बाद McD app में link को काम करवाना वाकई मुश्किल था, और आमतौर पर सिर्फ McD website ही खुलती थी
जब मैं McD खाता हूँ, तो लगभग 98% मामलों में अगर app से order नहीं कर सकता तो नहीं खाता, इसलिए यह काफी irritating था, और आखिर में “Sign in With Apple”(SIWA) पर switch कर लिया
मौजूदा McD account में SIWA जोड़ने का तरीका नहीं मिला, इसलिए मुझे ऐसा SIWA इस्तेमाल करना पड़ा जो मेरा असली email McD से छिपाता है; नया account बन गया और पुराने account के reward points खो गए, लेकिन कम-से-कम फिर से McD app इस्तेमाल कर सका
app में हर शुक्रवार $1 या उससे अधिक order पर “Free Medium Fries on Friday” deal होती है, इसलिए शुक्रवार lunch में घर पर sandwich बनाकर McD से cookie और free fries लेकर साथ खा लेता हूँ
इसलिए company computer पर magic link मिला और QR code बनाया, लेकिन email quarantine system ने पूरा link बदल दिया था, इसलिए original निकालना पड़ा
बात वहीं खत्म नहीं हुई; Slack पर वापस जाने वाला redirect URL, URL encoding की वजह से broken था, इसलिए उसे हाथ से ठीक करके फिर QR code बनाना पड़ा
असल magic link email में बस QR code या code साथ में डाल देना चाहिए था
code डालते ही वह फायदा पूरी तरह खत्म हो जाता है, और attacker को बस code माँगने वाली fake website बनानी होती है
magic link पर जिस device से click किया गया है, login उसी device पर होना चाहिए; उस device पर नहीं जिसने login session request किया था
बाकी तरीके थोड़े कम परेशान करने वाले हो सकते हैं, लेकिन वे security problem हैं और उन्हें उसी तरह treat करना चाहिए
कई सालों से magic link इस्तेमाल कर रहा हूँ, और MVP stage में यूज़र passwords store करने के security burden से बचना भी एक वजह थी। सबसे बड़ी समस्या यह है कि कुछ यूज़र, करीब 0.1%, email बिल्कुल receive नहीं कर पाते
अपना IP, MailGun, PostMark, कई transactional mail tools को क्रम से retry करने वाला तरीका—सब आज़मा लिया, फिर भी कुछ लोग हैं जो कभी login नहीं कर पाते
लोग 6 महीने पुराने magic link पर click करके “काम नहीं कर रहा” कहते हुए frustrate होते हैं, इसलिए error message की जगह Docusign की तरह situation समझाने और link फिर से भेजने वाला page दिखाने का फैसला किया
लोग अक्सर email address गलत type कर देते हैं और code न मिलने पर system को दोष देते हैं
फिर भी email+password तरीके की तुलना में support tickets काफी कम लगते हैं, इसलिए अब भी magic link पसंद करता हूँ
मैंने magic link कभी इस्तेमाल नहीं किया, लेकिन कुछ महीने पहले SaaS में Google Sign in जोड़ा तो नए signups में उसका हिस्सा 90% से ज्यादा हो गया
यूज़र base developers का है, इसलिए technical understanding और privacy sensitivity अपेक्षाकृत ज्यादा है, फिर भी ऐसा है; अब मुझे नहीं लगता कि कोई दूसरा तरीका priority है। हाँ, email/password अब भी बनाए रखा है
password manager के साथ इस्तेमाल किया गया username+password या passkey, शायद HTTPS पर आम लोगों को अच्छा user experience देते हुए credentials को end-to-end encrypted तरीके से exchange करने के लगभग इकलौते तरीके हैं
password manager यह ensure करता है कि credentials केवल सही domain पर ही इस्तेमाल हों
Mercury का वफादार ग्राहक था, लेकिन सुरक्षित password, password manager और valid TOTP पास करने के बाद भी हर बार IP address बदलने पर तीसरे authentication factor के रूप में magic link मजबूर किया जाता है, जिससे company bank को कहीं और ले जाने तक का मन होने लगा
अगर पिछले 5 सालों से इस्तेमाल की जा रही location या ISP से अलग जगह से login कर रहा होता तो समझ आता, लेकिन अगर कल login करने की तुलना में सिर्फ DHCP address का आखिरी octet बदला है, तो यह बात समझ नहीं आती
Email मैं web browsing से अलग computer पर SSH के जरिए पढ़ता हूं, इसलिए सैकड़ों अक्षरों वाले login link को copy-paste करना सचमुच बहुत तकलीफदेह है
Emacs में यह कई lines में दिखता है, इसलिए line boundaries पर मौजूद
\भी खुद हटाने पड़ते हैंहर login पर friction जोड़ने से app में आगे होने वाली हर interaction का impression खराब हो जाता है, और उसे इस्तेमाल करने का मन नहीं करता
अगर device पहले इस्तेमाल किया जा चुका है, तो device verification की मांग नहीं दिखनी चाहिए. इसे जांचने के लिए हम persistent cookie store कर रहे हैं, और same IP पर भी मांग नहीं करते. सोच रहा हूं कि कहीं आपकी cookies समय-समय पर clear तो नहीं हो रहीं
यह feature हमने तब जोड़ा जब attackers ने http://mercury.com की replica sites बनाईं और Google ads तक चलाए
जब customer phishing site पर password और TOTP डालता था, तो phisher उन credentials से login करके virtual cards बनाता और cryptocurrency, gold आदि खरीदता था, और user को असली Mercury पर redirect कर देता था ताकि उसे लगे कि कोई temporary error था
हम जो यह device verification link भेजते हैं, वह link खोलने वाले IP/device को approve करता है, और इस तरीके से हमने phishers को लगभग पूरी तरह रोक दिया
WebAuthn ऐसे phishing attacks से immune है, इसलिए WebAuthn इस्तेमाल करने पर हम device verification नहीं मांगते
अगर संभव हो, तो TouchID/FaceID या device-specific WebAuthn की जोरदार सिफारिश करूंगा. यह ज्यादा सुविधाजनक और ज्यादा सुरक्षित है, और इसे यहां add किया जा सकता है: https://app.mercury.com/settings/security
हालांकि internally हम इस लेख पर चर्चा कर रहे हैं, और यह भी समझते हैं कि IPv6 के और फैलने पर IP कहीं ज्यादा बार बदलेगा. same IP matching restriction को ढीला करना चाहिए या नहीं, इस पर विचार करूंगा
पिछले हफ्ते के 404 लेख पर प्रतिक्रिया के तौर पर यह बहुत अच्छा लगा. 404 पसंद है, लेकिन लेखक ने जिन वजहों का जिक्र किया है, उन्हीं वजहों से magic links परेशान करते हैं
Ricky Mondello ने पिछले हफ्ते जो लेख[1] लिखा था, वह अच्छी तरह समझाता है कि passkeys को magic links के साथ इस्तेमाल किया जा सकता है, जैसा कि लेख के अंत में संकेत दिया गया है, इसलिए पढ़ने लायक है
[1]: https://rmondello.com/2025/01/02/magic-links-and-passkeys/
Store में login करने पर email से भेजा गया two-factor code डालने को कहता था, और कई मिनट तक mail नहीं आता था; नया code मांगने पर भी नहीं आता, और जब हार मानकर कुछ और करने लगते, तो 30 मिनट बाद दोनों codes आ जाते थे
सच तो यह है कि email सबसे अच्छे समय में भी भरोसेमंद मानना मुश्किल है. वह spam folder में जा सकता है, company spam filter link रोक सकता है, या inbox भर सकता है
निजी तौर पर मेरा email सिर्फ iPhone पर है, और company laptop या gaming PC पर देखने के लिए icloud.com में login करना पड़ता है, जो झंझट है
काश password डालने देते, या embedded device की तरह QR code scan करने देते, या कम से कम कोई और option तो देते
Magic links passkeys तक access दिलाते हैं, और passkeys मूल रूप से “इस computer को याद रखें” का मजबूत version हैं
अभी भी उस दौर की आदत है जब Apple के लोग publicly लगभग दिखते ही नहीं थे
पता नहीं मैं कुछ गलत समझ रहा हूँ या नहीं, लेकिन passkey असल में magic link का विकल्प नहीं लगती
अब तक देखे गए हर passkey implementation में, किसी दूसरे तरीके से पहले से login करने के बाद passkey बनाने का सुझाव दिया गया था
मैंने बहुत गहराई से नहीं देखा, लेकिन user experience के लिहाज़ से passkey कुल मिलाकर password के विकल्प से ज़्यादा “इस computer को याद रखें” button के विकल्प जैसी लगती है
किसी न किसी तरह service को यह पता होना चाहिए कि यह नया device approve हो चुका है
provider के हिसाब से passkey sync होता है, लेकिन पहला authentication कैसे किया जाए, यह उससे हल नहीं होता
magic link की मुख्य insight यह है कि security system अपने recovery mechanism से ज़्यादा मजबूत नहीं हो सकता
ऐसी दुनिया नहीं आएगी जहाँ सिर्फ passkey को ही अकेला authentication साधन माना जाए; recovery mechanism हमेशा रहेगा, और ज़्यादातर मामलों में वह email के ज़रिए automatic recovery होगा
तो इस मायने में magic link ईमानदार है कि वह यह दिखावा नहीं करता कि उसके ऊपर कोई और ज़्यादा सुरक्षित layer है, बल्कि चीज़ों को सरल करता है
recovery mechanism को authentication flow में interaction का मुख्य तरीका बना देने से, authentication system की वास्तविक security level को लेकर हम ज़्यादा ईमानदार हो जाते हैं
Edit: filmgirlcw ने एक बेहतर लेख का link छोड़ा है, जो बताता है कि दोनों तरीके असल में कैसे एक-दूसरे को complement करते हैं: https://news.ycombinator.com/item?id=42628226
magic link के अपने फायदे हैं, लेकिन email को और ज्यादा शक्तिशाली attack vector बनाना फायदा है या नहीं, यह मुझे नहीं पता
password manager इस्तेमाल करने वालों के लिए magic link साफ तौर पर friction point है, और passkey इसे निश्चित रूप से कम कर सकती है
passkey की user experience समस्याओं में भी सुधार की गुंजाइश है, और export संभव हो जाने पर systems के बीच sync काफी बेहतर हो जाएगा
1Password को अपना default password और passkey system इस्तेमाल करने की एक वजह devices के बीच passkey का उपयोग भी है; हमारी company भी 1Password इस्तेमाल करती है, इसलिए मैं personal account और enterprise account में login रहता हूँ और जरूरत पड़ने पर personal या work device से authenticate कर सकता हूँ
हालांकि अगर 404 ने जिस समस्या को define किया है वह यह है कि वे password या authentication control को store करने की जिम्मेदारी नहीं लेना चाहते, तो कुछ users के लिए passkey magic link से बेहतर है
फिर भी Ricky की तरह मुझे लगता है कि यह दोनों में से एक नहीं, बल्कि दोनों होना चाहिए
[1]: https://rmondello.com/2025/01/02/magic-links-and-passkeys/
passkey इस्तेमाल करने का मतलब यह नहीं कि कोई वैकल्पिक login method होना ही चाहिए, लेकिन अभी तक किसी service ने passkey-only पर switch नहीं किया है
पुराने OS या Linux users अभी passkey बना और store नहीं कर पाते होंगे, और बहुत से users cross-platform credential manager इस्तेमाल नहीं करते
उदाहरण के लिए अगर आपने iCloud Passwords से passkey बनाई है, तो फिलहाल Linux से login करने का कोई तरीका नहीं है
मुझे लगता है कि कुछ और सालों में हम ऐसे flows देखने लगेंगे जहाँ service शुरुआत से ही passkey बनवाएगी और password बिल्कुल collect नहीं करेगी
उम्मीद है passkey portability spec implement होगा, और Gnome/KDE भी passkey support implement करेंगे
अगर work PC पर website visit करते समय phone का OTP इस्तेमाल करना या phone से link copy करना तकलीफदेह है, तो work computer को laptop जैसी जगह पर मौजूद personal passkey से जोड़ना कितना आसान और बेहतर होगा, इस पर मुझे शक है
ऐसी service इस्तेमाल नहीं करता जो authentication के लिए सिर्फ magic link support करती हो। यह users के प्रति बहुत hostile है, और security के नजरिए से भी password manager के साथ इस्तेमाल होने वाले password से साफ तौर पर खराब है
सबसे घातक बात यह है कि मेरी personal setup में यह बिल्कुल काम नहीं करता
security और account safety के लिए जिन devices से मैं login करता हूँ, उन पर email account access नहीं करता
सिर्फ Anthropic को exception रखा है क्योंकि Claude सबसे अच्छा LLM है, लेकिन हर बार दोबारा login करना पड़ता है तो भारी तकलीफ होती है और मैंने कई बार complaint भेजी है
जब भी magic link देखता हूँ, हमेशा यही सोचता हूँ, “क्या हमें शुरुआत से ही email link click नहीं करना चाहिए था?”
email link का ख्याल आते ही phishing भी याद आता है
मुझे magic link सच में बहुत नापसंद है
मुख्य बात यह है कि suspicious link click न करें। अगर आपको पता है कि magic link भेजा गया है, तो वह suspicious link नहीं है
फिर भी delay की वजह से मुझे magic link पसंद नहीं है
Apple का email privacy protection तरीका दिलचस्प लगता है। Apple हमेशा सभी images load करता है, लेकिन इसके downsides हैं या नहीं, पता नहीं
मैंने जो सबसे बेहतर implementation देखा है, उसमें ईमेल जिस device पर मिला है, उसी पर link क्लिक करना होता है, लेकिन session को उस device पर ले जाया नहीं जाता; login उसी device पर पूरा होता है जहां शुरुआत में login प्रक्रिया शुरू की गई थी
बेहतर समाधान यह है कि login सिर्फ उसी device पर हो जहां link खोला गया है, और devices के बीच उपयोग के लिए एक OTP code भी दिया जाए जिसे receiving device पर पढ़कर original device में आसानी से डाला जा सके
या फिर link के बिना सिर्फ OTP code भी दिया जा सकता है
एक browser में काम कर रहे हों और ईमेल खोलने पर default browser में authentication हो जाए, या उससे भी बुरा, किसी दूसरे device पर authentication हो जाए और फिर link को वहां forward करके दोबारा खोलना पड़े—इससे बुरा कुछ नहीं
कुछ devices पर कुछ खास emails access न करना चाहना भी संभव है, इसलिए यह कोई अजीब scenario नहीं है
अगर original request को authenticate करने वाला link implementation बहुत कठिन हो, तो site द्वारा
crazy-pink-horse-3837जैसा OTP भेजना ताकि उसे copy-paste किया जा सके, एक अच्छा बीच का रास्ता हैलेकिन implementation की समस्या यह थी कि भेजा गया magic link click tracker में wrap था, और वह domain pihole जैसे tools से block हो जाता था
इसलिए असली authentication URL तक पहुंचकर login प्रक्रिया पूरी नहीं की जा सकती थी
in-app browser खत्म हो जाने चाहिए। खासकर वे in-app browsers जिनमें “normal browser में खोलें” चुनने का option नहीं होता; और अगर RSS reader है तो उसे तो यह option देना ही चाहिए
users पर in-app browser थोपने वाले सभी product managers को जेल भेज देना चाहिए
इससे कहीं बेहतर विकल्प है ईमेल से भेजे गए OTP code और Conditional Mediation UI के साथ passkeys का उपयोग
अगर user किसी ऐसे device से login कर रहा है जहां पहले से passkey है, तो CM UI उसे तुरंत चुनने देगा और वह तुरंत login कर सकेगा
अगर device पर passkey नहीं है, तो user से email code दर्ज करवाया जा सकता है, और सफल होने पर तुरंत passkey set up करवाई जा सकती है ताकि अगली बार सीधे login हो सके
इससे मौजूदा devices पर passkey की security मिलती है, और नए devices पर passwordless setup और account recovery मिलती है
बोनस के तौर पर, cloud provider के पास सभी passkeys होने वाली vendor lock-in स्थिति से भी बचा जा सकता है