من اخیراً فرصت داشتم دوباره در مورد چگونگی عملکرد یک ویژگی بازنشانی رمز عبور ایمن فکر کنم، اولین بار که این قابلیت را در آن ایجاد کردم ، و سپس زمانی که به شخص دیگری کمک کرد تا کاری مشابه انجام دهد. در مورد دوم، می‌خواستم به او پیوندی به یک منبع متعارف با تمام جزئیات مربوط به نحوه اجرای ایمن عملکرد تنظیم مجدد بدهم. با این حال، مشکل این است که چنین منبعی وجود ندارد، حداقل منبعی وجود ندارد که همه چیزهایی را که به نظر من مهم به نظر می رسد توصیف کند. بنابراین تصمیم گرفتم خودم آن را بنویسم.
می بینید، دنیای رمزهای عبور فراموش شده در واقع دنیایی کاملا مرموز است. دیدگاه‌های متفاوت، کاملاً قابل قبول و بسیاری از دیدگاه‌های کاملاً خطرناک وجود دارد. این احتمال وجود دارد که شما بارها به عنوان یک کاربر نهایی با هر یک از آنها روبرو شده باشید. بنابراین من سعی خواهم کرد از این مثال‌ها استفاده کنم تا نشان دهم چه کسی این کار را درست انجام می‌دهد، چه کسی این کار را نمی‌کند، و برای اینکه این ویژگی را در برنامه خود به درستی انجام دهید، باید روی چه مواردی تمرکز کنید.
ذخیره سازی رمز عبور: هش کردن، رمزگذاری و متن ساده (نفس!).
ما نمی‌توانیم قبل از اینکه درباره نحوه ذخیره گذرواژه‌های فراموش شده صحبت کنیم، در مورد اینکه چه کار کنیم. رمزهای عبور در یکی از سه نوع اصلی در پایگاه داده ذخیره می شوند:
- متن ساده یک ستون رمز عبور وجود دارد که به صورت متن ساده ذخیره می شود.
- رمزگذاری شده است. معمولاً از رمزگذاری متقارن استفاده می شود (یک کلید هم برای رمزگذاری و هم برای رمزگشایی استفاده می شود) و رمزهای عبور رمزگذاری شده نیز در همان ستون ذخیره می شوند.
- هش شده. فرآیند یک طرفه (رمز عبور را می توان هش کرد، اما نمی توان آن را حذف کرد). کلمه عبور، من می خواهم امیدوار باشمو به دنبال آن یک نمک و هر کدام در ستون خود قرار دارند.
بیایید مستقیماً به ساده ترین سؤال برویم: هرگز رمزهای عبور را در متن ساده ذخیره نکنید! هرگز. یک آسیب پذیری واحد به ، یک نسخه پشتیبان بی دقت، یا یکی از ده ها اشتباه ساده دیگر - و بس، بازی، تمام رمزهای عبور شما - یعنی متاسفم، رمز عبور همه مشتریان شما به مالکیت عمومی تبدیل خواهد شد. البته این به معنای احتمال بسیار زیاد است از تمام حساب های آنها در سیستم های دیگر. و تقصیر شما خواهد بود.
رمزگذاری بهتر است، اما نقاط ضعف خود را دارد. مشکل رمزگذاری رمزگشایی است. ما می‌توانیم این رمزهای دیوانه‌کننده را بگیریم و آنها را به متن ساده تبدیل کنیم، و زمانی که این اتفاق بیفتد، به وضعیت رمز عبور قابل خواندن توسط انسان برمی‌گردیم. چگونه این اتفاق می افتد؟ یک نقص کوچک به کدی وارد می شود که رمز عبور را رمزگشایی می کند و آن را در دسترس عموم قرار می دهد - این یکی از راه ها است. هکرها به دستگاهی که داده های رمزگذاری شده روی آن ذخیره می شود دسترسی پیدا می کنند - این روش دوم است. راه دیگر، دوباره، سرقت پشتیبان پایگاه داده است و کسی کلید رمزگذاری را نیز دریافت می کند، که اغلب به صورت بسیار ناامن ذخیره می شود.
و این ما را به هش می کشاند. ایده پشت هش کردن این است که یک طرفه است. تنها راه مقایسه رمز عبور وارد شده توسط کاربر با نسخه هش شده آن، هش کردن ورودی و مقایسه آنهاست. برای جلوگیری از حملات ابزارهایی مانند جداول رنگین کمان، فرآیند را به صورت تصادفی نمک می زنیم (مطالعه من در مورد ذخیره سازی رمزنگاری). در نهایت، اگر به درستی پیاده‌سازی شود، می‌توانیم مطمئن باشیم که رمزهای عبور هش شده دیگر هرگز به متن ساده تبدیل نخواهند شد (در پست دیگری در مورد مزایای الگوریتم‌های هش متفاوت صحبت خواهم کرد).
یک استدلال سریع در مورد هش در مقابل رمزگذاری: تنها دلیلی که نیاز به رمزگذاری به جای هش رمز عبور دارید، زمانی است که باید رمز عبور را در متن ساده ببینید، و شما هرگز نباید این را بخواهید، حداقل در یک موقعیت وب سایت استاندارد. اگر به این نیاز دارید، به احتمال زیاد شما کار اشتباهی انجام می دهید!
اخطار!
در زیر در متن پست بخشی از تصویری از وب سایت پورنوگرافی AlotPorn وجود دارد. به‌خوبی بریده‌شده است، بنابراین چیزی نیست که در ساحل نتوانید ببینید، اما اگر همچنان احتمال دارد مشکلی ایجاد کند، به پایین پیمایش نکنید.
همیشه رمز عبور خود را بازنشانی کنید هرگز به او یادآوری نکن
آیا تا به حال از شما خواسته شده است که یک تابع ایجاد کنید یادآوری ها کلمه عبور؟ یک قدم به عقب بردارید و به این درخواست برعکس فکر کنید: چرا این "یادآوری" ضروری است؟ زیرا کاربر رمز عبور را فراموش کرده است. واقعاً می خواهیم چه کار کنیم؟ به او کمک کنید دوباره وارد شود.
من متوجه هستم که کلمه "یادآوری" (اغلب) به معنای محاوره ای استفاده می شود، اما آنچه ما واقعاً می خواهیم انجام دهیم این است با خیال راحت به کاربر کمک کنید تا دوباره آنلاین شود. از آنجایی که ما به امنیت نیاز داریم، دو دلیل وجود دارد که یادآوری (یعنی ارسال رمز عبور کاربر) مناسب نیست:
- ایمیل یک کانال ناامن است. همانطور که ما هیچ چیز حساسی را از طریق HTTP ارسال نمی کنیم (از HTTPS استفاده می کنیم)، نباید چیز حساسی را از طریق ایمیل ارسال کنیم زیرا لایه انتقال آن ناامن است. در واقع، این بسیار بدتر از ارسال اطلاعات صرفاً از طریق یک پروتکل حمل و نقل ناامن است، زیرا ایمیل اغلب در یک دستگاه ذخیره سازی ذخیره می شود، برای مدیران سیستم قابل دسترسی است، ارسال و توزیع می شود، برای بدافزارها قابل دسترسی است و غیره. ایمیل رمزگذاری نشده یک کانال بسیار ناامن است.
- به هر حال نباید به رمز عبور دسترسی داشته باشید. بخش قبلی در مورد ذخیره سازی را دوباره بخوانید - شما باید یک رمز عبور (با نمک قوی) داشته باشید، به این معنی که به هیچ وجه نباید رمز عبور را استخراج کنید و آن را از طریق پست ارسال کنید.
بگذارید مشکل را با یک مثال نشان دهم : اینجا یک صفحه ورود معمولی است:
بدیهی است که اولین مشکل این است که صفحه ورود از طریق HTTPS بارگیری نمی شود، اما سایت همچنین از شما می خواهد که یک رمز عبور («ارسال رمز عبور») ارسال کنید. این ممکن است نمونه ای از استفاده محاوره ای از اصطلاحی باشد که در بالا ذکر شد، بنابراین بیایید آن را یک قدم جلوتر برداریم و ببینیم چه اتفاقی می افتد:
متأسفانه خیلی بهتر به نظر نمی رسد. و یک ایمیل تأیید می کند که مشکل وجود دارد:
این دو جنبه مهم usoutdoor.com را به ما می گوید:
- سایت رمزهای عبور را هش نمی کند. در بهترین حالت، آنها رمزگذاری شده اند، اما به احتمال زیاد در متن ساده ذخیره می شوند. ما هیچ مدرکی بر خلاف آن نمی بینیم.
- سایت یک رمز عبور طولانی مدت (می توانیم به عقب برگردیم و بارها و بارها از آن استفاده کنیم) از طریق یک کانال ناامن ارسال می کند.
با این کار، باید بررسی کنیم که آیا فرآیند بازنشانی به روشی امن انجام شده است یا خیر. اولین قدم برای انجام این کار این است که مطمئن شوید که درخواست کننده حق انجام بازنشانی را دارد. به عبارت دیگر، قبل از این ما نیاز به بررسی هویت داریم. بیایید نگاهی بیندازیم که چه اتفاقی می‌افتد وقتی یک هویت تأیید می‌شود بدون اینکه قبلاً تأیید شود که درخواست‌کننده واقعاً مالک حساب است.
فهرست کردن نام های کاربری و تاثیر آن بر ناشناس بودن
این مشکل به بهترین شکل به صورت بصری نشان داده می شود. مسئله:
میبینی؟ به پیام «هیچ کاربری با این آدرس ایمیل ثبت نام نشده است» توجه کنید. بدیهی است که در صورت تایید چنین سایتی مشکل به وجود می آید در دسترس بودن کاربر با چنین آدرس ایمیلی ثبت نام کرده است. یکنوع بازی شبیه لوتو - شما به تازگی فتیش پورنو شوهر/رئیس/همسایه خود را کشف کردید!
البته، پورن نمونه ای نسبتاً نمادین از اهمیت حریم خصوصی است، اما خطرات مرتبط کردن یک فرد با یک وب سایت خاص بسیار گسترده تر از وضعیت بالقوه ناخوشایند است که در بالا توضیح داده شد. یکی از خطرات مهندسی اجتماعی است. اگر مهاجم بتواند شخصی را با سرویس مطابقت دهد، اطلاعاتی در اختیار خواهد داشت که می تواند شروع به استفاده از آن کند. به عنوان مثال، او ممکن است با فردی که به عنوان نماینده یک وب سایت معرفی می شود تماس بگیرد و در تلاش برای انجام تعهد، اطلاعات بیشتری را درخواست کند .
چنین شیوه‌هایی خطر «شمارش نام کاربری» را نیز افزایش می‌دهد، که به موجب آن می‌توان وجود مجموعه کاملی از نام‌های کاربری یا آدرس‌های ایمیل در یک وب‌سایت را با انجام سؤالات گروهی و بررسی پاسخ‌ها به آنها تأیید کرد. آیا لیستی از آدرس های ایمیل همه کارمندان و چند دقیقه برای نوشتن یک اسکریپت دارید؟ بعد میبینی مشکل چیه!
جایگزین چیست؟ در واقع، بسیار ساده است و به طرز شگفت انگیزی در آن پیاده سازی شده است :
در اینجا Entropay مطلقاً چیزی در مورد وجود یک آدرس ایمیل در سیستم خود فاش نمی کند به کسی که این آدرس را ندارد... اگر شما خود این آدرس و در سیستم وجود ندارد، ایمیلی مانند این دریافت خواهید کرد:
البته ممکن است شرایط قابل قبولی وجود داشته باشد که در آن شخصی فکر می کندکه در سایت ثبت نام کرده اید. اما اینطور نیست، یا من این کار را از آدرس ایمیل دیگری انجام دادم. مثالی که در بالا نشان داده شده است هر دو موقعیت را به خوبی مدیریت می کند. بدیهی است که اگر آدرس مطابقت داشته باشد، ایمیلی دریافت خواهید کرد که تنظیم مجدد رمز عبور را آسان تر می کند.
ظرافت راه حل انتخاب شده توسط Entropay این است که تأیید هویت مطابق با آن انجام می شود ایمیل قبل از هر گونه تایید آنلاین برخی از سایت ها از کاربران برای پاسخ به یک سوال امنیتی می خواهند (در ادامه در این مورد بیشتر توضیح دهید) به چگونه تنظیم مجدد می تواند آغاز شود. با این حال، مشکل این است که شما باید ضمن ارائه نوعی شناسایی (ایمیل یا نام کاربری) به سؤال پاسخ دهید، که پس از آن تقریباً غیرممکن است که به طور مستقیم بدون افشای وجود حساب کاربر ناشناس پاسخ دهید.
با این رویکرد وجود دارد کم اهمیت قابلیت استفاده کاهش یافته است زیرا اگر سعی کنید حسابی را که وجود ندارد بازنشانی کنید، بازخورد فوری وجود ندارد. البته، این تمام هدف ارسال ایمیل است، اما از دیدگاه کاربر نهایی واقعی، اگر آدرس را اشتباه وارد کنند، تنها برای اولین بار زمانی که ایمیل را دریافت می کنند، متوجه می شوند. این ممکن است باعث ایجاد تنش از سوی او شود، اما این هزینه کمی برای چنین فرآیند نادری است.
نکته دیگر، کمی خارج از موضوع: توابع کمکی برای ورود به سیستم که نشان می دهد نام کاربری یا آدرس ایمیل صحیح است، همین مشکل را دارند. همیشه به جای تأیید صریح وجود اعتبارنامه، با پیام «نام کاربری و رمز عبور ترکیبی شما نامعتبر است» به کاربر پاسخ دهید (مثلاً «نام کاربری درست است، اما رمز عبور نادرست است»).
ارسال مجدد رمز عبور در مقابل ارسال بازنشانی URL
مفهوم بعدی که باید در مورد آن صحبت کنیم این است که چگونه رمز عبور خود را بازنشانی کنیم. دو راه حل محبوب وجود دارد:
- ایجاد رمز عبور جدید در سرور و ارسال آن از طریق ایمیل
- یک ایمیل با یک URL منحصر به فرد ارسال کنید تا فرآیند بازنشانی آسانتر شود
با وجود ، نکته اول را هرگز نباید استفاده کرد. مشکل این است که به معنای وجود دارد رمز عبور ذخیره شده، که می توانید در هر زمان به آن برگردید و دوباره از آن استفاده کنید. از طریق یک کانال ناامن ارسال شد و در صندوق ورودی شما باقی می ماند. این احتمال وجود دارد که صندوق‌های ورودی در بین دستگاه‌های تلفن همراه و سرویس گیرنده ایمیل همگام‌سازی شوند، به علاوه ممکن است برای مدت طولانی به صورت آنلاین در سرویس ایمیل وب ذخیره شوند. نکته این است که صندوق پستی را نمی توان به عنوان وسیله ای مطمئن برای ذخیره سازی طولانی مدت در نظر گرفت.
اما علاوه بر این، نکته اول یک مشکل جدی دیگر دارد - آن تا حد امکان ساده می کند مسدود کردن یک حساب کاربری با نیت مخرب اگر آدرس ایمیل شخصی را که دارای حساب کاربری در یک وب‌سایت است بدانم، می‌توانم هر زمان که بخواهم به سادگی با بازنشانی رمز عبور او را مسدود کنم. این یک حمله انکار سرویس است که در یک بشقاب نقره ای سرو می شود! به همین دلیل است که تنظیم مجدد فقط باید پس از تأیید موفقیت آمیز حقوق درخواست کننده در مورد آن انجام شود.
وقتی در مورد URL بازنشانی صحبت می کنیم، منظور ما آدرس یک وب سایت است منحصر به فرد در این مورد خاص از فرآیند بازنشانی است. البته، باید تصادفی باشد، حدس زدن آن آسان نباشد، و نباید حاوی پیوندهای خارجی به حساب باشد که بازنشانی آن را آسانتر کند. به عنوان مثال، URL تنظیم مجدد نباید به سادگی مسیری مانند "Reset/?username=JohnSmith" باشد.
ما می‌خواهیم یک رمز منحصربفرد ایجاد کنیم که می‌تواند به‌عنوان URL بازنشانی پست شود، و سپس با رکورد سرور حساب کاربر مطابقت داده شود، بنابراین تأیید می‌کنیم که مالک حساب در واقع همان شخصی است که سعی در بازنشانی رمز عبور دارد. به عنوان مثال، یک توکن می‌تواند «3ce7854015cd38c862cb9e14a1ae552b» باشد و در یک جدول به همراه شناسه کاربری که بازنشانی را انجام می‌دهد و زمان تولید توکن ذخیره شود (در ادامه در این مورد بیشتر توضیح می‌دهیم). هنگامی که ایمیل ارسال می شود، حاوی یک URL مانند "Reset/?id=3ce7854015cd38c862cb9e14a1ae552b" است و زمانی که کاربر آن را دانلود می کند، صفحه از وجود توکن درخواست می کند و پس از آن اطلاعات کاربر را تأیید می کند و به آنها اجازه می دهد تا آن را تغییر دهند. کلمه عبور.
البته، از آنجایی که فرآیند بالا (امیدواریم) به کاربر اجازه می‌دهد تا رمز عبور جدیدی ایجاد کند، باید اطمینان حاصل کنیم که URL از طریق HTTPS بارگیری می‌شود. نه، ، این URL نشانه باید از امنیت لایه انتقال استفاده کند تا به فرم رمز عبور جدید نتوان حمله کرد و رمز عبور ایجاد شده توسط کاربر از طریق یک اتصال امن منتقل شد.
همچنین برای URL بازنشانی باید یک محدودیت زمانی توکن اضافه کنید تا فرآیند بازنشانی در یک بازه زمانی مشخص، مثلاً در یک ساعت، تکمیل شود. این تضمین می کند که پنجره زمان بازنشانی به حداقل می رسد تا گیرنده URL بازنشانی فقط بتواند در آن پنجره بسیار کوچک عمل کند. البته، مهاجم می‌تواند فرآیند بازنشانی را دوباره شروع کند، اما باید URL منحصربه‌فرد دیگری را برای بازنشانی دریافت کند.
در نهایت، ما باید اطمینان حاصل کنیم که این فرآیند یکبار مصرف است. پس از تکمیل فرآیند بازنشانی، توکن باید حذف شود تا URL تنظیم مجدد دیگر کاربردی نباشد. نکته قبلی برای اطمینان از اینکه مهاجم یک پنجره بسیار کوچک دارد که در طی آن می تواند URL تنظیم مجدد را دستکاری کند ضروری است. به علاوه، البته، هنگامی که تنظیم مجدد با موفقیت انجام شد، دیگر نیازی به توکن نیست.
برخی از این مراحل ممکن است بیش از حد زائد به نظر برسند، اما با قابلیت استفاده تداخلی ندارند در واقع بهبود ایمنی، البته در شرایطی که امیدواریم نادر باشد. در 99% مواقع، کاربر در مدت زمان بسیار کوتاهی ریست را فعال می کند و در آینده نزدیک دوباره رمز عبور را بازنشانی نمی کند.
نقش CAPTCHA
اوه، CAPTCHA، ویژگی امنیتی که همه ما دوست داریم از آن متنفر باشیم! در واقع، CAPTCHA نه آنقدر که یک ابزار حفاظتی است، بلکه یک ابزار شناسایی است - چه یک شخص یا یک ربات (یا یک اسکریپت خودکار). هدف آن اجتناب از ارسال خودکار فرم است که البته می تواند به عنوان تلاشی برای شکستن امنیت استفاده شود. در زمینه بازنشانی رمز عبور، CAPTCHA به این معنی است که تابع بازنشانی را نمی‌توان به‌صورت بی‌رحمانه مجبور به اسپم کردن کاربر یا تلاش برای تعیین وجود حساب‌ها کرد (که البته اگر توصیه‌های موجود در بخش را دنبال کنید امکان‌پذیر نخواهد بود. تایید هویت).
البته خود CAPTCHA کامل نیست. سوابق زیادی برای "هک کردن" نرم افزار آن و دستیابی به میزان موفقیت کافی (60-70٪) وجود دارد. علاوه بر این، راه حلی در پست من نشان داده شده است ، که در آن می توانید کسری از سنت را برای حل هر CAPTCHA به مردم بپردازید و به نرخ موفقیت 94٪ دست پیدا کنید. یعنی آسیب پذیر است، اما (کمی) مانع ورود را بالا می برد.
بیایید نگاهی به مثال PayPal بیندازیم:
در این حالت، تا زمانی که CAPTCHA حل نشود، فرآیند بازنشانی به سادگی نمی تواند آغاز شود، بنابراین نظری خودکار کردن فرآیند غیرممکن است. در تئوری.
با این حال، برای اکثر برنامه های کاربردی وب این امر بیش از حد است و کاملا درسته نشان دهنده کاهش قابلیت استفاده است - مردم فقط CAPTCHA را دوست ندارند! علاوه بر این، CAPTCHA چیزی است که در صورت لزوم می توانید به راحتی به آن بازگردید. اگر سرویس شروع به حمله کرد (این جایی است که ورود به سیستم مفید است، اما بعداً در مورد آن بیشتر توضیح خواهیم داد)، اضافه کردن یک CAPTCHA نمی‌تواند آسانتر باشد.
پرسش و پاسخ مخفی
با تمام روش هایی که در نظر گرفتیم، فقط با دسترسی به حساب ایمیل توانستیم رمز عبور را بازنشانی کنیم. من می گویم "فقط"، اما، البته، دسترسی به حساب ایمیل شخص دیگری غیرقانونی است. باید یک فرآیند پیچیده باشد با این حال .
در واقع لینک بالا در مورد هک شدن یاهو سارا پیلین! دو هدف را دنبال می کند؛ اولاً، نشان می دهد که هک کردن (برخی) حساب های ایمیل چقدر آسان است و ثانیاً نشان می دهد که چگونه می توان از سؤالات امنیتی بد با اهداف مخرب استفاده کرد. اما بعداً به این موضوع باز خواهیم گشت.
مشکل بازنشانی XNUMX٪ رمز عبور مبتنی بر ایمیل این است که یکپارچگی حساب برای سایتی که می خواهید بازنشانی کنید، XNUMX٪ به یکپارچگی حساب ایمیل بستگی دارد. هر کسی که به ایمیل شما دسترسی دارد به هر حسابی دسترسی دارد که می توان آن را به سادگی با دریافت ایمیل بازنشانی کرد. برای چنین حساب هایی، ایمیل "کلید همه درهای" زندگی آنلاین شما است.
یکی از راه های کاهش این خطر، پیاده سازی یک الگوی پرسش و پاسخ امنیتی است. بدون شک قبلاً آنها را دیده اید: سؤالی را انتخاب کنید که فقط شما می توانید به آن پاسخ دهید باید پاسخ را بدانید و پس از تنظیم مجدد رمز عبور از شما خواسته می شود. این اطمینان را می‌افزاید که فردی که تلاش می‌کند بازنشانی کند، در واقع مالک حساب است.
بازگشت به سارا پیلین: اشتباه این بود که پاسخ به سؤال/سوالات امنیتی او به راحتی یافت می شد. به خصوص زمانی که شما یک چهره عمومی مهم هستید، اطلاعات در مورد نام مادر، سابقه تحصیلی، یا جایی که ممکن است فردی در گذشته در گذشته زندگی کرده باشد، آنقدرها راز نیست. در واقع، تقریباً هر کسی می تواند بیشتر آن را پیدا کند. این اتفاقی است که برای سارا افتاد:
هکر دیوید کرنل با یافتن جزئیاتی در مورد سوابق او، مانند دانشگاه و تاریخ تولد، و سپس استفاده از ویژگی بازیابی رمز فراموش شده یاهو، به حساب کاربری پیلین دسترسی پیدا کرد.
اول از همه، این یک خطای طراحی از طرف یاهو است! - با تعیین چنین سؤالات ساده ای، شرکت اساساً ارزش سؤال امنیتی و در نتیجه حفاظت از سیستم خود را خراب کرد. البته، بازنشانی رمزهای عبور برای حساب ایمیل همیشه دشوارتر است، زیرا نمی‌توانید با ارسال ایمیل به مالک (بدون داشتن آدرس دوم) مالکیت آن را ثابت کنید، اما خوشبختانه امروزه استفاده زیادی برای ایجاد چنین سیستمی وجود ندارد.
بیایید به سؤالات امنیتی بازگردیم - گزینه ای وجود دارد که به کاربر اجازه می دهد سؤالات خود را ایجاد کند. مشکل این است که این منجر به سوالات بسیار بدیهی خواهد شد:
آسمان چه رنگی است؟
سوالاتی که هنگام استفاده از یک سوال امنیتی برای شناسایی، افراد را ناراحت می کند فرد (به عنوان مثال، در یک مرکز تماس):
کریسمس با کی خوابیدم؟
یا رک و پوست کنده سوالات احمقانه:
چگونه "رمز عبور" را املا می کنید؟
وقتی نوبت به سوالات امنیتی می رسد، کاربران باید از دست خودشان نجات پیدا کنند! به عبارت دیگر سوال امنیتی باید توسط خود سایت تعیین شود یا بهتر است بگوییم پرسیده شود سلسله سوالات امنیتی که کاربر می تواند از بین آنها انتخاب کند. و انتخاب آن آسان نیست یک; در حالت ایده آل کاربر باید دو یا چند سوال امنیتی را انتخاب کند در زمان ثبت حساب، که سپس به عنوان کانال شناسایی دوم استفاده خواهد شد. داشتن سوالات متعدد باعث افزایش اطمینان در فرآیند تأیید می شود، و همچنین امکان اضافه کردن تصادفی (نه همیشه یک سؤال را نشان می دهد) را فراهم می کند، به علاوه در صورتی که کاربر واقعی رمز عبور را فراموش کرده باشد، مقداری افزونگی را فراهم می کند.
یک سوال امنیتی خوب چیست؟ این تحت تأثیر چندین عامل است:
- باید باشد مختصر - سوال باید واضح و بدون ابهام باشد.
- پاسخ باید باشد خاص - ما به سؤالی نیاز نداریم که یک نفر بتواند به طور متفاوت به آن پاسخ دهد
- پاسخ های ممکن باید باشد گوناگون، متنوع - پرسیدن رنگ مورد علاقه یک نفر زیرمجموعه بسیار کوچکی از پاسخ های ممکن را به دست می دهد
- جستجو پاسخ باید پیچیده باشد - اگر بتوان پاسخ را به راحتی پیدا کرد любой (افراد در مقام های بالا را به یاد آورید)، پس او بد است
- پاسخ باید باشد دائمی در زمان - اگر از فیلم مورد علاقه کسی بپرسید، یک سال بعد ممکن است پاسخ متفاوت باشد
همانطور که اتفاق می افتد، وب سایتی وجود دارد که به پرسیدن سؤالات خوب اختصاص داده شده است . برخی از سؤالات بسیار خوب به نظر می رسند، برخی دیگر در برخی از آزمون های شرح داده شده در بالا، به ویژه آزمون "سهولت جستجو" موفق نمی شوند.
اجازه دهید نشان دهم که PayPal چگونه سوالات امنیتی و به ویژه تلاشی که سایت برای احراز هویت انجام می دهد را پیاده سازی می کند. در بالا صفحه شروع فرآیند (با یک CAPTCHA) را دیدیم، و در اینجا نشان خواهیم داد که پس از وارد کردن آدرس ایمیل خود و حل CAPTCHA چه اتفاقی می افتد:
در نتیجه، کاربر نامه زیر را دریافت می کند:
تا اینجا همه چیز کاملاً عادی است، اما آنچه در پشت این URL تنظیم مجدد پنهان شده است:
بنابراین، سوالات امنیتی مطرح می شوند. در واقع، PayPal همچنین به شما امکان می دهد رمز عبور خود را با تأیید شماره کارت اعتباری خود بازنشانی کنید، بنابراین کانال دیگری وجود دارد که بسیاری از سایت ها به آن دسترسی ندارند. من فقط نمی توانم بدون پاسخ دادن رمز عبور خود را تغییر دهم هر دو سوال امنیتی (یا ندانستن شماره کارت). حتی اگر شخصی ایمیل من را ربوده باشد، نمی تواند رمز عبور حساب پی پال من را بازنشانی کند مگر اینکه اطلاعات شخصی کمی درباره من بداند. چه اطلاعاتی؟ در اینجا گزینه های سؤال امنیتی که PayPal ارائه می دهد وجود دارد:
سوال مدرسه و بیمارستان ممکن است از نظر سهولت جستجو کمی مبهم باشد، اما بقیه خیلی بد نیستند. با این حال، برای افزایش امنیت، PayPal نیاز به شناسایی اضافی برای تغییرات پاسخ به سوالات امنیتی:
پی پال یک مثال کاملا اتوپیایی از بازنشانی رمز عبور امن است: یک CAPTCHA را برای کاهش خطر حملات brute-force پیاده سازی می کند، به دو سوال امنیتی نیاز دارد، و سپس به نوع دیگری از شناسایی کاملا متفاوت فقط برای تغییر پاسخ ها نیاز دارد - و این بعد از کاربر است. قبلا وارد سیستم شده است البته این دقیقاً همان چیزی است که ما داریم انتظار می رود از پی پال؛ یک موسسه مالی است که با مبالغ هنگفتی سروکار دارد. این به این معنی نیست که هر بازنشانی رمز عبور باید این مراحل را دنبال کند - اغلب اوقات زیاد است - اما مثال خوبی برای مواردی است که امنیت یک تجارت جدی است.
راحتی سیستم سؤالات امنیتی این است که اگر آن را فوراً پیاده‌سازی نکرده‌اید، می‌توانید بعداً در صورت نیاز سطح حفاظت از منابع، آن را اضافه کنید. یک مثال خوب در این زمینه اپل است که به تازگی این مکانیسم را اجرا کرده است [مقاله نوشته شده در سال 2012]. هنگامی که من شروع به به روز رسانی برنامه در iPad خود کردم، درخواست زیر را دیدم:
سپس صفحه‌ای را دیدم که می‌توانستم چندین جفت سؤال و پاسخ امنیتی و همچنین یک آدرس ایمیل نجات را انتخاب کنم:
در مورد PayPal، سؤالات از قبل انتخاب شده اند و برخی از آنها در واقع بسیار خوب هستند:
هر یک از سه جفت سوال/پاسخ مجموعه متفاوتی از سوالات ممکن را نشان می‌دهد، بنابراین راه‌های زیادی برای پیکربندی یک حساب کاربری وجود دارد.
جنبه دیگری که در پاسخ به سؤال امنیتی خود باید در نظر بگیرید، ذخیره سازی است. وجود یک پایگاه داده متنی ساده در پایگاه داده تقریباً همان تهدیدات رمز عبور را ایجاد می کند، یعنی افشای پایگاه داده فوراً ارزش را نشان می دهد و نه تنها برنامه را در معرض خطر قرار می دهد، بلکه برنامه های بالقوه کاملاً متفاوتی را با استفاده از سؤالات امنیتی یکسانی در معرض خطر قرار می دهد. ). یکی از گزینه ها هش ایمن (یک الگوریتم قوی و یک نمک تصادفی رمزنگاری) است، اما برخلاف اکثر موارد ذخیره سازی رمز عبور، ممکن است دلیل خوبی برای مشاهده پاسخ به صورت متن ساده وجود داشته باشد. یک سناریوی معمولی تأیید هویت توسط اپراتور تلفن زنده است. البته هش در این مورد نیز قابل اجرا است (اپراتور می تواند به سادگی پاسخی را که مشتری نامگذاری کرده است وارد کند)، اما در بدترین حالت، پاسخ مخفی باید در سطحی از ذخیره سازی رمزنگاری قرار گیرد، حتی اگر فقط رمزگذاری متقارن باشد. . خلاصه کردن: با اسرار مانند راز رفتار کنید!
یکی از جنبه های نهایی سوالات و پاسخ های امنیتی این است که آنها در برابر مهندسی اجتماعی آسیب پذیرتر هستند. تلاش برای استخراج مستقیم رمز عبور به حساب شخص دیگری یک چیز است، اما شروع گفتگو در مورد شکل گیری آن (یک سوال امنیتی محبوب) کاملاً متفاوت است. در واقع، شما به خوبی می توانید با یک نفر در مورد بسیاری از جنبه های زندگی او که ممکن است یک سوال مخفیانه بدون ایجاد شک ایجاد کند، ارتباط برقرار کنید. البته، نکته اصلی یک سوال امنیتی این است که به تجربه زندگی یک نفر مربوط می شود، بنابراین به یاد ماندنی است، و مشکل اینجاست - مردم دوست دارند در مورد تجربیات زندگی خود صحبت کنند! شما نمی توانید در این مورد انجام دهید، فقط در صورتی که چنین گزینه های سؤال امنیتی را انتخاب کنید کمتر احتمالاً می تواند توسط مهندسی اجتماعی بیرون کشیده شود.
[ادامه دارد.]در حقوق تبلیغات
VDSina قابل اعتماد ارائه می دهد ، هر سرور به یک کانال اینترنتی 500 مگابیت متصل است و به صورت رایگان از حملات DDoS محافظت می شود!
منبع: www.habr.com