مدیریت اکانت (حساب کاربری)، اعتبارسنجی یا تأیید هویت کاربر (Authorization) و مدیریت پسورد روی کاغذ کاری بس آسان اما در عمل بسیار حساس و گاهی دشوار است. بسیاری از دولوپرها به خصوص آن‌هایی که در حوزهٔ توسعهٔ وب و موبایل فعالیت می‌کنند فرایند مدیریت اکانت کاربران وب‌سایت‌شان را آن‌طور که باید و شاید جدی نمی‌گیرند و همین مسئله منجر به بروز یکسری آسیب‌پذیری‌های جدی می‌شود.
خوشبختانه، Google Cloud Platform یا به اختصار GCP ابزارهای متعددی را به همراه دارد تا به شما در تصمیم‌گیری صحیح دربارهٔ ایجاد و مدیریت ایمن اکانت‌های کاربران کمک کند. آنچه در ادامه مورد بررسی قرار خواهد گرفت، یکسری اصطلاحاً Best Practice است که گوگل به دولوپرها و وب‌مسترها پیشنهاد می‌کند تا در نهایت امنیت خاطر به مراتب بیشتری برای کاربرانشان ایجاد گردد.
1. پسوردها را Hash کنید
مهمترین قاعده برای مدیریت اکانت این است که اطلاعات حساس کاربران از جمله رمزعبور آن‌ها را به صورت امن ذخیره کنید. علاوه بر این، همچنین باید با این داده‌ها مانند یک هویت مقدس رفتار کنید.
تحت هیچ شرایطی پسوردها را به صورت Plain Text (متن هَش نشده) ذخیره نکنید بلکه به جای این کار، سرویس شما باید پسورد تولید شده را توسط یک هَش رمزنگاری معکوس‌ناپذیر (غیرقابل بازگشت) قوی برای مثال PBKDF2 ،SHA3 ،Scrypt یا Bcrypt ذخیره کند. هَش باید با یک مقدار یکتا که مختص به احراز هویت کاربر باشد ترکیب یا به اصطلاح Salt شده باشد. همچنین از تکنولوژی‌های منسوخ شدهٔ هَش مانند SHA1 استفاده نکنید و تحت هیچ شرایطی نباید از رمزنگاری برگشت‌پذیر استفاده نکنید و یا سعی نکنید خودتان الگوریتم‌های هَش اختراع کنید!
فراموش نکنید که امنیت هیچ‌گاه 100% نیست و باید سیستم خود را با این فرض طراحی کنید که در نهایت به خطر خواهد افتاد. از خودتان بپرسید «اگه امروزه دیتابیس من Exfiltrated شد، آیا ایمنی و امنیت کاربران در سرویس‌هایم یا سرویس‌های دیگری که استفاده می‌کنند به خطر خواهد افتاد؟ و چه کاری برای کاهش میزان خسارت ناشی از نفوذ می‌توانم انجام دهم؟»
به خاطر داشته باشیم که منظور از اصطلاح Data Exfiltration که گاهی به آن Data Extrusion نیز گفته می‌شود، انتقال اطلاعات بدون داشتن سطح دسترسی لازم است و دولوپرها برای جلوگیری از آن باید کنترل‌های دقیقی برای امنیت فیزیکی و دیجیتال داشته باشند.
2. در صورت امکان از سرویس‌های احراز هویت به اصطلاح Third-party استفاده کنید
سرویس‌های احراز هویت Third-party شما را قادر می‌سازند تا با تکیه کردن بر یک سرویس خارجی قابل اطمینان، هویت کاربران خود را اعتبارسنجی کنید. گوگل، فیسبوک و توئیتر متداول‌ترین ارائه‌دهندگان سرویس احراز هویت به اصطلاح Third-party هستند.
به طور مثال، با استفاده از پلتفرمی همچون Firebase Auth می‌توانید سرویس‌های احراز هویت خارجی را در کنار سیستم اعتبارسنجی داخلی خودتان پیاده‌سازی کنید. استفاده از Firebase Auth مزیت‌های گوناگونی از جمله مدیریت ساده، سطح حملهٔ محدودتر و یک SDK چندپلتفرمی به همراه دارد (SDK مخفف Software Development Kit به معنی کیت توسعهٔ نرم‌افزار است).
3. مفاهیم هویت کاربری و اکانت کاربری را از یکدیگر جدا کنید
وقتی کاربری در وبسایت شما ثبت‌نام می‌کند، تحت هیچ عنوان به کاربر مد نظر به شکل یک ایمیل یا شمارهٔ موبایل یا به طور کل همچون یک ID نگاه نکنید بلکه هر کاربر متشکل از مجموعه‌ای از داده‌های شخصی و یک تجربهٔ کاربری منحصر به فرد داخل وبسایت یا اپ موبایل شما است. یک سیستم مدیریت کاربر که به خوبی طراحی شده است دارای کمترین وابستگی و بیشترین پیوستگی و انسجام بین بخش‌های مختلف پروفایل کاربر است.
جدا نگاه داشتن دیتای اکانت کاربر با چیزهای همچون پسورد و غیره (Credentials) تا حد بسیار زیادی روند پیاده‌سازی سرویس احراز هویت Third-party را ساده می‌کند و به کاربران اجازهٔ تغییر نام کاربری و لینک کردن چندین هویت (شناسه کاربری) به یک اکانت کاربری را می‌دهد. در عمل، داشتن یک شناسه (ID) داخلی کلی برای هر کاربر و لینک کردن پروفایل و شناسهٔ احراز هویت به آن احتمالاً مفیدتر از قرار دادن همه آن اطلاعات در یک رکورد دیتابیس باشد.
4. اجازهٔ لینک کردن چندین شناسه به یک اکانت کاربری منحصر به فرد را بدهید
کاربری که با استفاده از نام کاربری و پسورد خود در سیستم شما اعتبارسنجی شده است، پس از یک هفته ممکن است این بار Google Sign-In را برای ورود به اکانت خود انتخاب کند بدون اینکه بداند این کارش ممکن است منجر به ایجاد یک حساب کاربری تکراری شود! به طور مشابه، کاربری ممکن است دلیل خیلی خوبی برای لینک کردن چندین آدرس ایمیل به اکانت کاربری خود در سرویس شما داشته باشد. اگر به درستی مفاهیم هویت کاربری و اعتبارسنجی را جدا کرده باشید، لینک کردن چندین شناسه به یک اکانت کاربری منحصر به فرد فرآیندی ساده خواهد بود.
در اصل نیاز است تا به کاربر توضیح دهید در حالی که سعی دارد از طریق یکی یا همهٔ شیوه‌های احراز هویت به اکانت خود وارد شود، ممکن است فرآیند ثبت اکانت جدیدی را انجام دهد، قبل از اینکه بفهمند که از یک سرویس احراز هویت جدید استفاده می‌کند که به اکانت موجود او در سیستم شما لینک نشده است!
این کار به سادگی از طریق درخواست کردن از کاربر برای ارائه یکسری جزئیات هویتی مشترک از جمله آدرس ایمیل یا نام کاربری قابل انجام است. اگر آن داده با دادهٔ مربوط به یک کاربر موجود در سیستم مطابقت داشته باشد، آن‌ها را مجاب کنید که همچنین از طریق یک سرویس احراز هویت شناخته شده اعتبارسنجی شوند و شناسهٔ جدید را به اکانت موجود آن‌ها لینک کنید.
5. پسوردهای طولانی یا پیچیده را مسدود نکنید
NIST مخفف واژگان National Institute of Standards & Technology (مؤسسهٔ ملی تکنولوژی و استانداردها) اخیراً دستورالعمل‌های مربوط به پیچیدگی و قوی بودن پسورد را آپدیت کرده است. باتوجه به اینکه شما از یک هَش رمزنگاری قوی برای ذخیرهٔ پسورد استفاده می‌کنید، اکثر مشکلات شما حل شده است و خیلی نیازی به پسوردهای فوق‌پیچیده نیست.
هَش‌ها بدون توجه به طول ورودی، همیشه یک خروجی با طول ثابت (مثلاً برای SHA-256 هَش 256 بیتی معادل 64 کاراکتر در مبنای هگزادسیمال) تولید می‌کنند، در نتیجه کاربران شما تا هر زمانی که مایل باشند قادر به استفاده از پسوردها هستند. اگر مجبور به محدود کردن طول پسورد هستید، این کار را فقط بر اساس حداکثر اندازهٔ POST مجاز توسط سرورهای خود انجام دهید که معمولاً بیشتر از 1 مگابایت است (POST یکی از متدهای ارسال داده‌های فرم‌ها به سمت سرور است).
پسوردهای هَش شدهٔ شما حاوی یک مجموعهٔ کوچک از کاراکترهای شناخته شده اَسکی (ASCII) خواهند بود و در غیر این صورت به راحتی می‌توانید یک هَش باینری را به یک Base64 تبدیل کنید. باتوجه به این موضوع، باید به کاربرانتان اجازه دهید تا هر کاراکتری را که تمایل دارند، عیناً در پسورد خود استفاده کنند. اگر کسی می‌خواهد یک پسورد از ایموجی (Emoji) بسازد و در دو طرف کاراکترهای وایت اِسپیس به کار ببرد، شما نباید به هیچ دلیل آن را رد کنید (ASCII مخفف واژگان American Standard Code for Information Interchange است و در کامپیوترها و سایر وسایل ارتباطی که با متن سروکار دارند برای نمایش و تبادل متن‌ها استفاده می‌شود. الگوریتم کدگذاری base64 نیز یکی از روش‌های کدگذاری داده برای تبدیل داده‌ها به کاراکترهای اَسکی است).
6. قوانین غیرمنطقی و نامعقول برای نام‌های کاربری قرار ندهید
برای یک سایت یا سرویس غیرمنطقی نیست که نام کاربری را ملزم به طولانی‌تر بودن از دو یا سه کاراکتر نماید، کاراکترهای مخفی را مسدود کند و از وایت اِسپیس در ابتدا و انتهای نام‌های کاربری ممانعت کند. با این حال، برخی از سایت‌ها با الزاماتی مانند حداقل طول هشت کاراکتر یا مسدودسازی هر کاراکتری غیر از حروف و اعداد، در اعمال محدودیت‌ها زیاده‌روی می‌کنند.
یک سایت با محدودیت‌های شدید برای نام کاربری، ممکن است میانبرهایی برای دولوپرها برای رسیدن به هدف‌شان خصوصاً در مورد تأمین امنیت داشته باشد اما این کار به همان اندازه برای کاربران نتیجهٔ عکس خواهد داشت و در موارد افراطی، برخی از کاربران را فراری خواهد داد.
در برخی موارد، بهترین روش برای ثبت‌نام کاربران، تخصیص نام‌های کاربری به ایشان است. اگر این در مورد سرویس شما درست است، مطمئن شوید که نام کاربری تخصیص داده شده کاربرپسند (User-friendly) است زیرا کاربران هر دفعه که قرار است وارد سایت‌تان شوند، به آن نیاز خواهند داشت. در مورد شناسه‌هایی که دارای ترکیبی از حروف و اعداد هستند باید از علامت‌های مبهم بصری مانند «Il1O0.» جلوگیری کنید.
همچنین توصیه می‌شود بر روی هر استرینگ تولید شدهٔ رَندوم، یک اِسکن دیکشنری استفاده کنید تا مطمئن شوید که هیچ پیام جاسازی شده (Embedded) غیرعمدی در نام کاربری وجود ندارد (اِسکن دیکشنری به معنی تهیهٔ یک لیست تقریباً کامل از داده‌های مجاز یا غیرمجاز و بررسی این موضوع است که آیا یک استرینگ در این لیست وجود دارد یا خیر. مثلاً الگوریتم هَش MD5 با این که هنوز شکسته نشده است، ولی دیکشنری‌های بزرگی شامل عبارت‌های ترکیبی مختلف از حروف و اعداد وجود دارد که معادل هَش شدهٔ این عبارات را نیز به همراه دارد و در صورتی که هَش پسورد کاربری در این دیکشنری یافت شود، معادل متنی هَش نشده نیز مشخص خواهد شد).
7. به کاربران اجازهٔ تغییر نام کاربری آن‌ها را بدهید
اجازه ندادن به کاربران برای تغییر نام کاربری آن‌ها چیزی است که به طرز شگفت‌آوری در سیستم‌های قدیمی یا هر پلتفرم ارائه‌دهندهٔ اکانت ایمیل متداول است. دلایل بسیار خوبی برای عدم آزادسازی خودکار نام‌های کاربری برای استفادهٔ مجدد وجود دارد، اما کاربرانی که در بلندمدت از سیستم شما استفاده می‌کنند، بالاخره یک دلیل خوب برای استفاده از نام‌های کاربری متفاوت ارائه می‌دهند و احتمالاً نمی‌خواهند یک اکانت جدید ایجاد کنند. به طور کلی، قوانین مناسب برای پلتفرم خود انتخاب کنید اما مطمئن شوید که این قوانین به کاربران شما اجازهٔ شخصی‌سازی و تغییر منطقی را در هر زمانی می‌دهند.
8. به کاربران اجازهٔ حذف اکانت کاربری خود را بدهید
تعداد تعجب‌آوری از سرویس‌ها به کاربران خود اجازه نمی‌دهند تا اکانت و اطلاعات شخصی خود را از سیستم حذف کنند. برای بعضی از کاربران دلایل خوبی وجود دارد تا اکانت خود را برای همیشه ببندند و همهٔ اطلاعات شخصی خود را حذف کنند.
9. راجع به طول عمر سِشِن آگاهانه تصمیم بگیرید
عمر باقی ماندن سِشِن در مرورگر کاربر، یک جنبه از امنیت و اعتبارسنجی است که اغلب نادیده گرفته می‌شود (طول عمر سِشِن به مدت زمان اجرای یک اپلیکیشن تا وقتی گفته می‌شود که کاربر آن را ترک می‌کند). گوگل برای اطمینان از این که کاربران همان کسانی هستند که ادعا می‌کنند، تلاش زیادی می‌کند و بر اساس رخدادها یا رفتارهای خاص این مورد را مجدداً بازبینی می‌کند.
مدت زمانی را در نظر بگیرید اگر کاربر فعالیتی نداشت، دوباره اعتبارسنجی صورت گیرد. اگر کاربری پسورد خود را تغییر داد، در تمام سِشِن‌های فعال (در هر دستگاهی که از اکانتش خارج نشده مثلاً مرورگرهای دیوایس‌های مختلف و اپلیکیشن‌های نیتیو)، اعتبارش را مجدداً تأیید کنید. اگر کاربری قسمت‌های اصلی پروفایل خود را تغییر دهد یا وقتی یک تَسک حساس را اجرا می‌کند، درخواست احراز هویت را سریعاً اعلام کنید. همچنین این را در نظر بگیرید که آیا عدم اجازه به ورود از بیش از یک دیوایس یا مکان، به صورت هم‌زمان منطقی است یا خیر.
هنگامی که سرویس شما سِشِن کاربر را به پایان می‌رساند یا نیاز به اعتبارسنجی مجدد دارد، بلافاصله به کاربر اعلام کنید یا مکانیزمی را فراهم کنید تا کلیهٔ فعالیت‌های کاربر را از آخرین زمانی که تأیید اعتبار شده حفظ و نگهداری کند.
10. از اعتبارسنجی دو مرحله‌ای استفاده کنید
Two-factor Authorization (اعتبارسنجی دو مرحله‌ای) بدین شکل است که وقتی کاربری اقدام به لاگین در یک سرویس می‌کند، یک ایمیل یا اس‌ام‌اس برایش ارسال می‌شود و همین مسئله امنیت وی را به مراتب بالاتر خواهد برد. به طور مثال، امروزه اکثر سرویس‌های کیف‌پول #کریپتوکارنسی از این سیاست استفاده می‌کنند تا حساب کاربران خود را ایمن‌تر سازند.
11. شناسه‌های کاربر را غیرحساس به حروف بزرگ و کوچک سازید
کاربران شما به کوچک یا بزرگ بودن حروف نام کاربری خود توجهی نمی‌کنند و حتی ممکن است شکل دقیق نام کاربری خود را به یاد نیاورند. نام‌های کاربری باید کاملاً غیرحساس به حروف بزرگ و کوچک باشند (به عبارت دیگر، اصطلاحاً باید Case Insensitive باشند). بدیهی است که باید نام‌های کاربری و آدرس‌های ایمیل را تماماً با حروف کوچک ذخیره کنید و هر ورودی را نیز قبل از مقایسه، به حروف کوچک تبدیل کنید.
درصد کاربران گوشی‌های هوشمند به صورت روزافزون در حال افزایش است. در اکثر دیوایس‌های آن‌ها قابلیت‌هایی نظیر اصلاح خودکار (Autocorrect) و بزرگ‌سازی خودکار حرف اول (Capitalization) فیلدهای متنی فعال است. جلوگیری از این رفتار در سطح رابط کاربری (UI) ممکن است کاملاً مؤثر یا مطلوب نباشد و سرویس شما باید به اندازهٔ کافی قوی باشد تا یک آدرس ایمیل یا نام کاربری را که سهواً و به صورت خودکار کپیتالایز شده‌اند را هَندل کند.
12. یک سیستم تأییدهویت (اعتبارسنجی) امن بسازید
اگر از یک سرویس مانند Firebase Auth استفاده می‌کنید، بسیاری از نگرانی‌های امنیتی شما به صورت خودکار هَندل می‌شود. با این حال، سرویس شما همیشه باید به درستی برای جلوگیری از سوءاستفاده طراحی شده باشد که برخی ملاحظات در این حوزهٔ عبارتند از:
- پیاده‌سازی بازیابی رمزعبور
- ثبت لاگ (گزارش) فعالیت اکانت با ذکر جزئیات (مثلاً IP کاربران یا زمان ورود)
- محدود کردن تعداد تلاش‌ها برای ورود به سیستم
- قفل کردن اکانت پس از چندین تلاش ناموفق برای ورود
- نیاز داشتن به احراز هویت دو مرحله‌ای برای دیوایس‌های ناشناخته یا اکانت‌هایی که برای دوره‌های طولانی استفاده نشده‌اند
