کاراکتر الفبایی-عددی: تعریف، کاربرد در رمزنگاری، امنیت

شصت و دو. این تعداد کل نمادهای متمایز موجود است وقتی کسی می‌گوید «فقط از کاراکترهای الفبایی-عددی استفاده کنید». بیست و شش حرف بزرگ، بیست و شش حرف کوچک، ده رقم. اگر حساسیت به حروف کوچک و بزرگ را حذف کنید، تعداد به سی و شش کاهش می‌یابد. هر دو عدد مهم هستند، زیرا تقریباً هر شناسه دیجیتالی که تا به حال تایپ کرده‌اید - آدرس کیف پول، رمز عبور Wi-Fi، هش تراکنش، توکن GitHub - از زیرمجموعه‌ای منتخب از آن شصت و دو نماد ساخته شده است.

انتخاب اینکه کدام زیرمجموعه و چرا، بخشی است که اکثر توضیح‌دهندگان از آن صرف نظر می‌کنند. همچنین بخشی است که تعریف دانشنامه‌ای یک کاراکتر الفبایی-عددی را به امنیت عملی کیف پول رمزنگاری شما مرتبط می‌کند. این مقاله به بررسی شمارش، استاندارد پشت آن، نحوه انتخاب زیرمجموعه‌های آن توسط رمزنگاری مدرن و آنچه مرجع ملی ایالات متحده در مورد رمزهای عبور اکنون در مورد آن می‌گوید، می‌پردازد. برخی از این راهنمایی‌ها به گونه‌ای تغییر کرده‌اند که اکثر توصیه‌های امنیتی هنوز به آن نرسیده‌اند.

کاراکتر الفبایی-عددی چیست؟ تعریف و تعداد

با تعریف شروع کنید. یک کاراکتر الفبایی-عددی هر حرف A تا Z (در هر دو حالت) یا هر رقم اعشاری 0 تا 9 است. این تمام چیزی است که در مورد آن وجود دارد. از اینجا به بعد، محاسبات واضح است - بیست و شش حرف برای هر حالت به علاوه ده رقم، شصت و دو کاراکتر مجزا با حساسیت به حروف کوچک و بزرگ و سی و شش کاراکتر بدون حساسیت به حروف کوچک و بزرگ می‌دهد. هر چیز دیگری "ویژه" است. علائم نگارشی، فاصله، نمادهای ریاضی، حروف برجسته، ایموجی - هیچ یک از اینها الفبایی-عددی محسوب نمی‌شوند.

مهندسان معمولاً از طریق یکی از دو روش خلاصه‌سازی به این تعریف می‌رسند. ابزارهای POSIX مانند grep، sed و awk، `[:alnum:]` را تشخیص می‌دهند که با شصت و دو کاراکتر بالا مطابقت دارد. اکثر مدل‌های regex مدرن - پایتون، جاوا اسکریپت، جاوا، PCRE - به جای آن از `\w` استفاده می‌کنند. نکته `\w` این است که زیرخط را پنهان می‌کند. زیرخط رسماً الفبایی-عددی نیست. اکثر سینتکس‌های برنامه‌نویسی با آن به عنوان یک علامت افتخاری رفتار می‌کنند، به همین دلیل است که پیشوند کلید Stripe `sk_live_` و پیشوند کلید AWS `AKIA` زیرخط‌ها و حروف بزرگ را با اعداد ترکیب می‌کنند، بدون اینکه کسی پلک بزند.

این اصطلاح از کجا آمده است؟ کارت‌های پانچ، از همه جا. تجهیزات جدول‌بندی IBM در دهه ۱۹۳۰ به یک کلمه واحد برای کدهایی که حروف را با اعداد ترکیب می‌کردند نیاز داشتند و «الفبایی-عددی» جا افتاد. تا IBM 1401 در اوایل دهه ۱۹۶۰، این کلمه به واژگان استاندارد در محاسبات تجاری تبدیل شد. این تمایز در عمل نیز رواج داشت - فیلدی که «الفبایی-عددی» اعلام می‌شد، هر حرف یا رقمی را می‌پذیرفت؛ فیلدی که فقط عددی بود، الفبا را به طور کامل رد می‌کرد. از آنجا، این کلمه به پلاک‌های خودرو، کدهای بانک IBAN، یادآورهای صفحه کلید تلفن، SKU محصولات و صدها جای دیگر راه یافت.

تمایز حساس به حروف بزرگ و کوچک در مقابل غیر حساس به حروف بزرگ و کوچک، بیش از آنچه به نظر می‌رسد اهمیت دارد. آنتروپی رمز عبور وقتی حروف بزرگ مجاز باشند، دو برابر می‌شود. آدرس‌های Base58 بیت کوین عمداً هر دو حالت کوچک و بزرگ را حفظ می‌کنند. Bech32 عمداً حالت کوچک و بزرگ را حذف می‌کند. هر یک از این انتخاب‌ها، معامله‌ای بین رسایی و خطای انسانی است. اگر اشتباه انتخاب کنید، مردم به خاطر غلط املایی پول از دست می‌دهند.

از ASCII تا یونیکد: تاریخچه فنی مختصر

«الفبایی-عددی» امروز بازمانده‌ی جنگ استانداردها است که شصت سال طول کشید. اکثر کاربران جایی در این بین گرفتار شده بودند و هرگز متوجه آن نشدند.

ASCII اولین بار ارائه شد. این استاندارد در سال ۱۹۶۳، به لطف انجمن استانداردهای آمریکا، منتشر شد و پنج سال بعد با نام ANSI X3.4-1968 رسمیت یافت. دو ویرایش بعدی نیز انجام شد - یکی در سال ۱۹۷۷ و دیگری در سال ۱۹۸۶. نسخه ۱۹۶۸، حرف بزرگ A را در عدد ۶۵، حرف کوچک a را در عدد ۹۷ و ارقام ۰ تا ۹ را در عدد ۴۸ تا ۵۷ قرار داد. همین الان ویرایشگر خود را باز کنید: بایت «A» هنوز ۶۵ است. در طول شصت سال هیچ چیز تغییر نکرده است.

تقریباً برای چهار دهه، مجموعه الفبایی-عددی ASCII، مجموعه الفبایی-عددی بود. سپس وب جهانی از راه رسید. هفت بیت دیگر کافی نبود. حالت‌های خرابی زشت بودند. ایمیل‌های درهم‌ریخته. پایگاه‌های داده خراب. وب‌سایت‌های ژاپنی که در توکیو کاملاً کار می‌کردند و در یک لپ‌تاپ آمریکایی مانند دیوارهایی از علامت سؤال به نظر می‌رسیدند. یونی‌کد در سال ۱۹۹۱ با یک جاه‌طلبی عجیب و غریب از راه رسید: اختصاص یک شماره منحصر به فرد به هر کاراکتر در هر اسکریپتی که هر کسی تا به حال نوشته بود. UTF-8 در سال ۱۹۹۲ به عنوان کدگذاری که در واقع یونی‌کد را از طریق شبکه‌های معمولی منتقل می‌کرد، عرضه شد. ترفند آن سازگاری با نسخه‌های قبلی بود - ۱۲۸ نقطه کد اول UTF-8 دقیقاً ۱۹۶۸ بایت ASCII اصلی هستند. متن انگلیسی که قبل از سال ۱۹۹۱ ارسال شده بود، برای همیشه کار می‌کرد.

این تغییر در دسامبر ۲۰۰۷ اتفاق افتاد. در آن ماه، آمار عمومی خزش وب بالاخره نشان داد که UTF-8 از ASCII به عنوان رایج‌ترین کدگذاری آنلاین پیشی گرفته است. از آن زمان به بعد، «الفبایی-عددی» دیگر به معنای دقیق شصت و دو نماد ASCII نبود. یونیکد اکنون بلوک‌های الفبایی-عددی را برای اسکریپت‌های سیریلیک، یونانی، عربی، عبری و CJK فهرست می‌کند. هر اسکریپت حروف و ارقام خاص خود را دارد.

با این حال، در عمل، نرم‌افزاری که باید از مرزها عبور کند، همچنان به طور پیش‌فرض از زیرمجموعه اصلی ASCII استفاده می‌کند. حروف لاتین A-Z. اعداد عربی 0-9. هیچ چیز دیگری. دلیل آن پیش پا افتاده است. هر صفحه کلیدی ASCII تولید می‌کند. هر پایگاه داده‌ای آن را می‌پذیرد. هر موتور regex آن را می‌داند. اگر از این محدوده خارج شوید، مجموعه‌ای از اشکالات کدگذاری نادرست، کاراکترهای شبیه به هم و حملات فیشینگ را به ارث خواهید برد که در ادامه به آنها خواهم پرداخت.

کاراکترهای الفبایی-عددی در ارزهای دیجیتال: آدرس‌ها، هش‌ها، سیدها

اینجا بخشی است که اغلب توضیح‌دهندگان عمومی از آن صرف نظر می‌کنند. سیستم‌های ارز دیجیتال هرگز از مجموعه کامل شصت و دو کاراکتری الفبایی-عددی استفاده نمی‌کنند. آن‌ها زیرمجموعه‌هایی را با دقت انتخاب می‌کنند. هر کدام یک توافق مهندسی مستند است، نه یک زیبایی‌شناسی دلخواه.

اول بیت کوین. یک آدرس قدیمی بیت کوین (آدرسی که با ۱ یا ۳ شروع می‌شود) در Base58 کدگذاری شده است. الفبای آن توسط ساتوشی ناکاموتو با دست طراحی شده است. دستور العمل: مجموعه شصت و دو کاراکتری الفبایی-عددی را بردارید، چهار عضو را حذف کنید. رقم صفر، O بزرگ، I بزرگ، L کوچک را حذف کنید. چرا آن چهار تا را؟ آنها را با دست خط بد روی یک کاغذ چسبان بنویسید. بروید. پنج دقیقه دیگر برگردید. سعی کنید آنها را از هم تشخیص دهید. نمی‌توانید. این کل مشکلی است که Base58 برای حل آن ساخته شده است. پنجاه و هشت کاراکتر باقی مانده است. یک آدرس قدیمی معمولی در نهایت بیست و شش تا سی و پنج نماد طول دارد - به اندازه کافی کوتاه که در صورت نیاز بتوانید با دست کپی کنید.

سگویت (SegWit) در آگوست ۲۰۱۷ فعال شد. با آن، فرمت آدرس بیت‌کوین دومی هم آمد: Bech32 که در BIP-173 تعریف شده است. Bech32 شرط‌های متفاوتی می‌گذارد. حساسیت به حروف کوچک و بزرگ کاملاً از بین می‌رود - هر آدرس با حروف کوچک نوشته می‌شود. چهار کاراکتر متفاوت حذف می‌شوند: رقم ۱، به علاوه b، i، o. سی و دو حرف و رقم باقی‌مانده دارای یک جمع کنترلی داخلی هستند. این جمع کنترلی تقریباً هر غلط املایی تک کاراکتری را به طور خودکار تشخیص می‌دهد. Taproot که از نوامبر ۲۰۲۱ فعال است، پس از اینکه محققان یک نقص در حروف کوچک و بزرگ در محاسبات اصلی پیدا کردند، این فرمت را به Bech32m (BIP-350) اصلاح کرد.

اتریوم مسیر سومی را انتخاب کرد. فقط از هگز استفاده کنید. یک آدرس اتریوم `0x` است که دقیقاً چهل کاراکتر هگزادسیمال به دنبال آن می‌آید؛ در مجموع چهل و دو کاراکتر. هگز تمام حروف الفبا و عددی را به شانزده عضو محدود می‌کند. ارقام 0 تا 9، حروف a تا f، هیچ چیز دیگری. این انتخاب در سال 2015 تمیز به نظر می‌رسید. با 2026، پس از سال‌ها که کاربران به حباب‌های هگز خام در MetaMask نگاه می‌کردند، زشت به نظر می‌رسید. EIP-55 راه حل بود. حروف خاص را به صورت انتخابی با حروف بزرگ در الگویی که از هش Keccak-256 آدرس کوچک گرفته شده است، بنویسید. نتیجه، تشخیص غلط املایی رایگان است. EIP-55 غلط‌های املایی را با حدود 99.975 درصد قابلیت اطمینان تشخیص می‌دهد. نرخ خطا تقریباً 0.0247 درصد است. کوچک. صفر نیست.

هش‌ها ساده‌ترین حالت هستند. خروجی هش SHA-256، ۲۵۶ بیت است که به صورت ۶۴ کاراکتر هگز نمایش داده می‌شود. Keccak-256 اتریوم خروجی با طول یکسان تولید می‌کند. شناسه تراکنش بیت‌کوین - یک txid - هش SHA-256 خود تراکنش است، بنابراین یک txid نیز ۶۴ کاراکتر هگز الفبایی-عددی است. آن‌ها در یک مرورگر بلوک ترسناک به نظر می‌رسند. آن‌ها صرفاً الفبایی-عددی هستند.

عبارات پایه این الگو را می‌شکنند. بازیابی کیف پول BIP-39 تنها جایی است که ارزهای دیجیتال از حوزه الفبایی-عددی خارج شده و به قلمرو صرفاً الفبایی بازمی‌گردند. این استاندارد، ۱۲۸ یا ۲۵۶ بیت آنتروپی را به صورت دوازده یا بیست و چهار کلمه انگلیسی که از یک لیست ثابت ۲۰۴۸ کلمه‌ای گرفته شده‌اند، کدگذاری می‌کند. هر کلمه فقط با حروف کوچک نوشته شده است - نه رقم و نه حروف بزرگ و کوچک. چرا؟ زیرا هدف طراحی این است که شخصی ساعت ۳ صبح پس از خاموش شدن تلفن همراهش، کلمات را روی کاغذ بنویسد و ارقام ابهامی را ایجاد می‌کنند که حروف ایجاد نمی‌کنند.

هر زیرمجموعه، قطعه‌ای از طراحی انسان‌محور است که درون یک سیستم عمیقاً فنی پنهان شده است.

رمزهای عبور الفبایی-عددی: آنچه NIST در سال 2024 می‌گوید

بیشتر توصیه‌های مربوط به رمز عبور در وب عمومی چندین سال است که منسوخ شده‌اند. از حروف بزرگ و کوچک استفاده کنید، اعداد را اضافه کنید، حداقل یک کاراکتر خاص را در رمز عبور خود بگنجانید، هر نود روز یکبار آن را تغییر دهید - این قوانین به مدت دو دهه استاندارد بودند. موسسه ملی استاندارد و فناوری ایالات متحده رسماً از آنها صرف نظر کرد.

نشریه ویژه NIST 800-63B، مرجع فدرال در زمینه راهنمایی هویت دیجیتال، نسخه ۴ را در سپتامبر ۲۰۲۴ نهایی کرد. راهنمایی جدید از نظر میزان حذف موارد قابل توجه است. توصیه حداقل طول برای احراز هویت تک عاملی به پانزده کاراکتر افزایش یافته است. دستورالعمل مربوط به قوانین ترکیب کاراکتر به صورت "نباید" بیان شده است: سرویس‌ها نباید به کلاس‌های کاراکتری خاصی نیاز داشته باشند. انقضای دوره‌ای رمز عبور، آن چرخش نود روزه که همه از آن متنفر بودند، نیز حذف شد. به جای این قوانین، NIST اکنون از سرویس‌ها می‌خواهد که رمزهای عبور ارسالی را در برابر لیست سیاهی از اعتبارنامه‌های شناخته شده که در معرض خطر هستند، بررسی کنند.

این تغییر با ریاضی آنتروپی توجیه می‌شود. یک مجموعه ۶۲ کاراکتری الفبایی-عددی حدود ۵.۹۵ بیت برای هر کاراکتر تولید می‌کند. مجموعه کامل ۹۵ کاراکتری ASCII قابل چاپ - الفبایی-عددی به علاوه کاراکترهای ویژه - ۶.۵۷ بیت تولید می‌کند. با اضافه کردن مجموعه کامل کاراکترهای ویژه، ۰.۶۲ بیت به ازای هر کاراکتر افزایش می‌یابد. با اضافه کردن یک کاراکتر دیگر با طول بیشتر، ۵.۹۵ بیت کامل افزایش می‌یابد. طول به میزان زیادی بر پیچیدگی غلبه می‌کند.

گزارش بررسی‌های نقض داده ورایزن در سال ۲۰۲۵ نشان داد که اعتبارنامه‌ها ۲۲ درصد از کل نقاط ورود تأیید شده برای نقض داده‌ها را تشکیل می‌دهند. پر کردن اعتبارنامه - استفاده مجدد خودکار از فهرست‌های رمز عبور فاش شده - به طور متوسط ۱۹ درصد از تلاش‌های احراز هویت را تشکیل می‌دهد و به ۴۴ درصد می‌رسد. چهل و نه درصد از کاربران از رمزهای عبور مختلف در سرویس‌های مختلف استفاده می‌کنند. هیچ یک از این مشکلات با الزام به استفاده از حروف بزرگ حل نمی‌شود.

شکستن یک رمز عبور طولانی‌تر شامل حروف و اعداد بدون کاراکترهای خاص، سخت‌تر از شکستن یک رمز عبور کوتاه است که برای برآورده کردن یک چک لیست پیچیدگی تنظیم شده باشد. اگر بانک شما هنوز شما را مجبور به نوشتن یک رمز عبور دوازده کاراکتری با یک حرف بزرگ، یک رقم و یک کاراکتر خاص می‌کند، این سیاست اکنون رسماً با استاندارد فدرال ایالات متحده مغایرت دارد.

جاهای دیگر که کاراکترهای الفبایی-عددی ظاهر می‌شوند

از دنیای رمزنگاری خارج شوید، رمزهای عبور و رشته‌های الفبایی-عددی هنوز هم در هر جایی که سیستم به شناسه‌ای نیاز دارد که انسان‌ها بتوانند تایپ کنند و کامپیوترها بتوانند بدون ابهام آن را تجزیه و تحلیل کنند، ظاهر می‌شوند.

کدهای بانکی یک مثال ساده هستند. یک IBAN می‌تواند تا سی و چهار کاراکتر الفبایی-عددی را شامل شود و همیشه با یک کد کشور ISO دو حرفی باز می‌شود. کدهای SWIFT/BIC هشت یا یازده کاراکتر را اجرا می‌کنند. پلاک‌های خودرو در هر کشور متفاوت هستند - پلاک بریتانیا هیچ شباهتی به پلاک آلمان ندارد - اما هر دو زیرمجموعه‌های الفبایی-عددی از یک مجموعه شصت و دو نمادی هستند. شماره‌های شناسایی خودرو در سراسر جهان دقیقاً هفده کاراکتر دارند و VINها عمداً حروف I، O و Q را ممنوع می‌کنند تا از نظر بصری از اعداد متمایز باشند.

کلیدهای API نمونه‌های روزمره‌ای هستند که اکثر کاربران هرگز زحمت نگاه کردن به آنها را نمی‌کشند. یک کلید Stripe live فایل `sk_live_` را به همراه یک توکن الفبایی-عددی باز می‌کند. یک کلید دسترسی AWS فایل `AKIA` را به همراه شانزده کاراکتر الفبایی-عددی باز می‌کند. یک توکن دسترسی شخصی GitHub که پس از سال 2021 صادر شده است، فایل `ghp_` را باز می‌کند. این پیشوندها خودشان الفبایی-عددی هستند و انتخاب می‌شوند تا ارائه‌دهندگان بتوانند مخازن و گزارش‌های عمومی را برای کلیدهای فاش‌شده اسکن کنند. در بسیاری از موارد، این اسکن قبل از اینکه مهاجمی متوجه شود، یک نقص امنیتی را شناسایی می‌کند.

کدهای QR شایسته‌ی اشاره‌ی مختصری هستند. استاندارد ISO/IEC 18004 یک «حالت الفبایی-عددی» اختصاصی را تعریف می‌کند که یک مجموعه‌ی ۴۵ کاراکتری خاص - حروف بزرگ، ارقام، فاصله و تعداد انگشت‌شماری از علائم نگارشی - را با کارایی بیشتری نسبت به حالت بایت عمومی رمزگذاری می‌کند. یک QR که فقط شامل محتوای الفبایی-عددی با حروف بزرگ است، حدود ۱.۶ برابر داده‌ی بیشتری در هر مربع نسبت به همان محتوا که به صورت بایت‌های خام رمزگذاری شده است، ذخیره می‌کند.

Base32، Base58، Base64: وقتی کریپتو یک زیرمجموعه انتخاب می‌کند

تعداد انگشت‌شماری از استانداردهای کدگذاری به‌طور خاص برای نگاشت دودویی به زیرمجموعه‌ای از حروف و اعداد وجود دارد. مرجع RFC 4648 است که توسط IETF در سال ۲۰۰۶ منتشر شده است. این استاندارد سه کدگذاری را تعریف می‌کند.

هگز ساده‌ترین آنهاست. رسماً Base16. شانزده کاراکتر: 0-9، a-f. برای آدرس‌های اتریوم، هش‌های رمزنگاری و تقریباً هر اشکال‌زدایی سطح پایینی که در آن نیاز به خواندن بایت‌های خام دارید، استفاده می‌شود. Base32 جالب‌تر است. الفبای 32 کاراکتری به این دلیل انتخاب شده است که به حروف کوچک و بزرگ حساس نباشد و در برخی از انواع، ارقام 0، 1، 8 و 9 که از نظر بصری گیج‌کننده هستند را حذف کند. هر کسی که احراز هویت دو مرحله‌ای را تنظیم کرده و یک رمز را در Google Authenticator تایپ کرده باشد، Base32 را تایپ کرده است - اغلب اوقات بدون اینکه خودش بداند.

Base64 ابزار قدرتمندی است. شصت و دو کاراکتر الفبایی-عددی به علاوه دو نماد `+` و `/`. یک نوع URL-safe این کاراکترها را با `-` و `_` جایگزین می‌کند. Base64 چیزی است که پیوست‌های ایمیل شما را حمل می‌کند، URLهای داده را درون HTML کدگذاری می‌کند و توکن‌های وب JSON را برای OAuth بسته‌بندی می‌کند.

Base58 بیت کوین خارج از RFC 4648 قرار دارد. ساتوشی ناکاموتو آن را به طور مستقل ساخت. هدف متفاوت بود - تایپ مجدد آدرس‌ها توسط انسان، نه کارایی بایت به ازای هر کاراکتر - و نتیجه یک الفبای سفارشی بود که هیچ کس دیگری از آن استفاده نمی‌کند. Base85 که گاهی اوقات Ascii85 نیز نامیده می‌شود، در جهت مخالف اجرا می‌شود. این زبان چهار بایت را در پنج کاراکتر بسته‌بندی می‌کند و در فایل‌های PDF و PostScript نمایش داده می‌شود، جایی که تراکم اضافی، کاهش خوانایی را توجیه می‌کند.

مشکلات رایج: سردرگمی بصری و تصاویر مشابه

همان دلایلی که کریپتو زیرمجموعه‌هایی از حروف و اعداد را انتخاب می‌کند، دلایلی است که همه اشتباه می‌کنند. تعداد انگشت‌شماری از جفت‌های کاراکتری بیشترین مشکل را ایجاد می‌کنند.

گیج‌کننده‌های کلاسیک: صفر و O بزرگ. رقم یک، l کوچک، I بزرگ. l کوچک و I بزرگ. بیت‌کوین Base58 به همین دلیل هر چهار مورد را حذف می‌کند. سیستم‌های دیگر از روش‌های کاهش متفاوتی استفاده می‌کنند - VINها I، O و Q را حذف می‌کنند، برخی از کدهای مالی O را به طور کامل حذف می‌کنند و می‌توانید قوانین پلاک ملی را پیدا کنید که هر حرفی را که در فونت کشور بیشتر شبیه 0 باشد، ممنوع می‌کند.

یک مشکل پیچیده‌تر و جدیدتر، حملات هموگراف یونیکد است. این ایده در مقاله‌ای در سال ۲۰۰۱ توسط اوگنی گابریلوویچ و الکس گونتماخر مستند شده است. یک هموگراف، یک کاراکتر بصری یکسان را از یک خط متفاوت - به عنوان مثال، سیریلیک 'а' (U+0430) را به جای لاتین 'a' (U+0061) - جایگزین می‌کند. یک نام دامنه را با این جایگزینی ثبت کنید و می‌توانید یک صفحه فیشینگ میزبانی کنید که از بانک واقعی قابل تشخیص نیست. مرورگرهای مدرن هر زمان که یک دامنه اسکریپت‌ها را با هم ترکیب کند، نمایش خام Punycode - چیزی شبیه به `xn--80akhbyknj4f` - را نمایش می‌دهند. این دفاع اکثر حملات را متوقف می‌کند. نه همه آنها.

چگونه یک رمز عبور قوی از حروف و اعداد در 2026 بسازیم

سه قانون. همه آنها مستقیماً از ریاضیات NIST گرفته شده‌اند.

اول: طول بر کلاس کاراکتر برتری دارد. هدف شانزده کاراکتر یا بیشتر باشد. این قانون پابرجاست که آیا سیستم فقط حروف و ارقام را می‌پذیرد یا کل مجموعه ASCII قابل چاپ را.

دو: اگر مجبورید آن را حفظ کنید، از یک عبارت عبور استفاده کنید. چهار کلمه تصادفی از یک لیست بزرگ - لیست Diceware گزینه متعارف است - تقریباً از هر رمز عبور کوتاهی که یک انسان می‌نشیند و اختراع می‌کند، بهتر عمل می‌کند.

سه: برای هر چیز دیگری، از یک برنامه مدیریت رمز عبور استفاده کنید. بگذارید مدیر رمز عبور رشته‌های طولانی الفبایی-عددی تولید کند که دیگر هرگز مجبور به خواندن یا تایپ دستی آنها نباشید. وقتی یک مدیر رمز عبور خروجی را مدیریت می‌کند، خوانایی خروجی دیگر اهمیتی ندارد.

مرجع سریع: شمارش الفبایی-عددی و مثال‌ها

شصت و دو با حساسیت به حروف کوچک و بزرگ. سی و شش بدون آن. کدهای ASCII برای ارقام ۴۸ تا ۵۷. برای حروف بزرگ ۶۵ تا ۹۰. برای حروف کوچک ۹۷ تا ۱۲۲. کل مجموعه را با عبارت منظم `[A-Za-z0-9]` یا کلاس POSIX `[:alnum:]` مطابقت دهید. این مجموعه شصت و دو نمادی، زیربنای تقریباً هر شناسه دیجیتالی است که این هفته با آن مواجه خواهید شد. رمزهای عبور. کلیدهای API. IBANها. پلاک‌های خودرو. شناسه‌های تراکنش. هر آدرس کیف پولی که ایجاد می‌کنید.

Mathis Curcio

Mathis Curcio is a senior content strategist and NFT specialist at Plisio. With over 5 years of experience in the Web3 space, Mathis focuses on the evolution of NFT ecosystems, digital collectibles, and decentralized ownership models. He creates accessible, insight-driven content that bridges the gap between blockchain innovation and mainstream adoption. His expertise spans NFT market trends, use cases across art and gaming, and the infrastructure powering next-generation tokenized assets.