ہنگاہ اور گنٹ ؟ شہر ہچ قیمت ہے ، ہچس کی گہری کیا ہے ؟

ہیش بمقابلہ خفیہ کاری

ایک عام غلط فہمی ہے کہ ہیش اور خفیہ کاری ایک ہی چیز ہیں۔ وہ نہیں ہیں. ہیش ناقابل واپسی ہے. مثال کے طور پر درج ذیل مثال لیں:

$ echo -n Password123 | md5sum
42f749ade7f9e195bf475f37a44cafcb -

ہم سٹرنگ "Password123" کو پاس کرتے ہیں۔ MD5 الگورتھم (algo)، جو ریاضیاتی کارروائیاں کرتا ہے اور تیار کردہ ہیکساڈیسیمل انکوڈڈ ہیش کو واپس کرتا ہے۔ اسی ہیش آؤٹ پٹ ویلیو حاصل کرنے کا واحد طریقہ algo کو اصل میں داخل کرنا ہے۔ ایک تنازعہ ہے ، لیکن ہم اس پر بعد میں بات کر سکتے ہیں.

زیادہ تر ہیش الگورتھم ہیکساڈیسیمل انکوڈڈ فکسڈ لمبائی بائنری سٹرنگ کو آؤٹ پٹ کرتے ہیں۔ دوسرے ، جیسے اس مثال میں ، آؤٹ پٹ کے طور پر base64 انکوڈڈ سٹرنگ استعمال کرتے ہیں۔ براہ کرم نوٹ کریں کہ لمبائی ہمیشہ ایک جیسی ہے:

{SHA} uNF8eZRJ8jmr8WTjyocRJPVpe7w=
{SHA}lqdu/Zr6o2dgIER8Up1/7lcUtgw=
{SHA}qYUOwLMlDEuukA5HCT4LR1kQzco=
{SHA}MXZBCpyWJ7TTs1w2kgGJslwNwTg=
{SHA}2sAPLaUh9Mz0bI+XxKEg7qyABe8=

TL ؛ پی ایچ ڈی

خفیہ کاری الٹنے والی ہے ، ہیش نہیں ہے

میں خفیہ کاری کے بارے میں زیادہ بات نہیں کرنا چاہتا (کیونکہ وہ چیزیں کتابوں کے لئے ہیں) ، لیکن یہ ضروری ہے کہ ہیش سٹرنگ اور خفیہ کردہ سٹرنگ میں فرق کرنے کے قابل ہو. خفیہ کاری عام طور پر سٹرنگ کو بھرتی ہے خفیہ کاری ہونے سے پہلے ایک مخصوص لمبائی کو پورا کرتی ہے۔ اسے ڈکرپٹ کرنے کے لیے کلید (یا پاس ورڈ) کی بھی ضرورت ہوتی ہے۔ اگر ایک خفیہ کردہ پاس ورڈ استعمال کیا جا رہا ہے تو ، سٹرنگ ان پٹ کی لمبائی کے لحاظ سے مختلف ہو جائے گا. اگر آپ سائفر ٹیکسٹ پاس ورڈز کا ایک گچھا دیکھتے ہیں جو لمبائی میں مختلف ہوتے ہیں ، تو ہو سکتا ہے کہ آپ ہیش کے بجائے خفیہ کاری کے ساتھ کام کر رہے ہوں۔ AES-256-CBC مثال انکرپٹڈ سٹرنگ اور وابستہ سادہ متن (کلید "ASDF" کے ساتھ):

foobar             | U2FsdGVkX19G+KtytNHdj6yH2AVvX26pEmtunS/PRnU= 
foobarfoobar       | U2FsdGVkX18sPpIvN6nVh68lOUCcb3gR2fKbCCnBxog= 
foobarfoobarfoobar | U2FsdGVkX1/EOnUt57TCW4Rh0EdNnWX+lDatuQv2xEXXeAeowW0XG/EXJUe9aSUz 

$ cat خفیہ کردہ_پاس ورڈز 
U2FsdGVkX19G KtytNHdj6yH2AVvX26pEmtunS/PRnU= 
U2FsdGVkX18sPpIvN6nVh68lOUCcb3gR2fKbCCnBxog= 
U2FsdGVkX1/EOnUt57TCW4Rh0EdNnWX lDatuQv2xEXXeAeowW0XG/EXJUe9aSUz 

$ for i in `cat encrypted_passwords`;  do echo $i | openssl enc -base64 -d -aes-256-cbc -پاس پاس:asdf;  بازگشت ؛  ہو گیا 
فوبار 
foobarfoobar 
اب آپ سوچ سکتے ہیں: شاید آپ صحیح ہیں. تاہم ، کلیدی مواد کو سسٹم تک رسائی کے لیے دستیاب ہونا چاہیے جس کا مطلب ہے کہ بنیادی طور پر ایک سادہ متن ماسٹر پاس ورڈ کہیں واقع ہے - چاہے وہ RSA کلید یا پاس ورڈ کے طور پر ہو یا فائل میں ، ڈیٹا بیس میں سرایت شدہ ، کسی ایپلیکیشن میں ہارڈ کوڈ شدہ ، یا میموری میں کسی جگہ کا پاس ورڈ۔ pfft ، کوئی بھی' اپنے صارفین' پاس ورڈز
 کو خفیہ کرنے کے لیے asdf کو کلید کے طور پر استعمال نہیں کرے گا۔ MD5 کے لیے وہی سٹرنگ استعمال کریں: 
foobar             | 3858f62230ac3c915f300c664312c63f 
foobarfoobar       | 59faa421729e846dd800dce59943bfc0 
foobarfoobarfoobar | 1352aadab322d1a033c27964be0965db
ہیش پاس ورڈ کامل سے بہت دور ہے ، حقیقت میں یہ تھوڑا سا برا ہے ، لیکن یہ خفیہ کاری سے بھی بدتر ہے کیونکہ یہ حاصل کرنے کی کوشش کرتا ہے۔ صارفین مطلق کم از کم ضروریات کو زیادہ کثرت سے نہیں منتخب کرتے ہیں ، اور یہ بھی ایک سے زیادہ سائٹس پر استعمال کیا جا سکتا ہے. بہت سے "ہیکس" دراصل اسناد کے دوبارہ استعمال کے حملوں سے زیادہ کچھ نہیں ہیں۔ اگر ابتدائی سمجھوتہ خفیہ کاری کا استعمال کرنا تھا ، تو حملہ آور کو صرف ایک ہی کوشش کرنا پڑتی ہے جو تمام پاس ورڈز کو ڈکرپٹ کرنے والی کلید تلاش کرتی ہے۔ ہیش کے لیے ، انہیں کم از کم ان کو توڑنے کے لیے کوشش کرنے کی ضرورت ہے۔ جب جدید الگورتھم جیسے sha512crypt ، bcrypt ، scrypt ، یا argon2 کے ساتھ استعمال کیا جاتا ہے ، تو ہیش کو توڑنے کے لیے کافی محنت کی ضرورت پڑ سکتی ہے۔ 
 
 
 
 
 
 نمکین 
 
 نمکین ہیش سے پہلے پاس ورڈ میں ایک تار شامل کرنا ہے۔ ہر ہیش کا نمک منفرد ہونا چاہیے ، عام طور پر تصادفی طور پر منتخب کیا جاتا ہے ، کیونکہ توجہ ایک ہی سادہ متن "پاس ورڈ" ہیش ویلیو کو ہر بار مختلف کرنے پر ہے۔ اس سے پاس ورڈ کریکرز کے لیے زندگی مشکل ہو جاتی ہے کیونکہ 1,000 صارفین میں سے ہر ایک کے لیے لفظ "پاس ورڈ" کی جانچ پڑتال کرنے کے لیے ، ہر صارف کے پاس ایک منفرد نمک ہوتا ہے جو انہیں 1,000 بار کرنا ہوتا ہے - فی صارف/نمک ایک بار۔ اس کا مطلب یہ بھی ہے کہ وہ پہلے سے مرتب کردہ لغات یا رینبو ٹیبلز (عام طور پر...) کو مؤثر طریقے سے استعمال نہیں کر سکتے کیونکہ انہیں اپنی مرضی کے مطابق فی نمک کی ضرورت ہوتی ہے۔ 
ویب سائٹ کبھی کبھی اس کو گڑبڑ کرتی ہے اور تمام صارفین کے لیے یونیورسل نمک استعمال کرتی ہے۔ یہ مقصد کے خلاف ہے. 
ذیل میں نمکین SHA1 ہیش ویلیو ہے: 

b353977827f67a4ae0318f3a9447fae1c13d9d90:b8d18ca 
|___________________________________________| 
                  ہیش                  |  نمک 
                                        | 
                                    الگ کرنے والا
 اس ہیش کا سادہ متن "پاس ورڈ" ہے۔ اس کی نمک کی قدر "b8d18ca" ہے اور یہ SHA1 ($salt.$pass) کے API کا استعمال کرتا ہے۔ اس کا مطلب ہے کہ الگورتھم پاس ورڈ کا سادہ متن حاصل کرتا ہے ، نمک پیدا کرتا ہے ، اور اسے سادہ متن کے سامنے شامل کرتا ہے۔ جب ویب سائٹ یا ایپلیکیشن مستقبل میں آپ کے پاس ورڈ کی تصدیق کرنے کی کوشش کرتی ہے ، تو یہ آپ کے سادہ متن کے پاس ورڈ کو ان پٹ کے طور پر لے گی ، ذخیرہ شدہ ہیش میں نمک کی قدر کو پڑھے گی ، اسے آپ کے منتخب کردہ پاس ورڈ کے سامنے شامل کرے گی ، اور نتیجے میں آنے والی ہیش ویلیو کا موازنہ کرے گی۔ ذخیرہ شدہ ہیش ویلیو کے ساتھ۔ کریکنگ اگر یہ معلوم نہ ہو کہ اس کا ایک حصہ نمک ہے ، تو ہیش درج ذیل سادہ متن تیار کرے گا: 
b8d18capassword

 چونکہ الگورتھم سادہ متن ان پٹ کرتا ہے ، نمک اور پیدا شدہ ہیش ویلیو کو صارف کے لیے شفاف رکھا جا سکتا ہے۔ کریکنگ کے دوران ، اگر الگورتھم نمک ہے ، تو ہمیں نمک کو جاننے کی ضرورت ہے تاکہ امیدوار سادہ متن تیار کرتے وقت ہم اسے فراہم کر سکیں۔ 
اگر مناسب طریقے سے لاگو کیا جائے تو نمکین کریکنگ زیادہ وقت طلب کر سکتی ہے۔ بے ترتیب نمک کا استعمال کرتے ہوئے ، آپ کریکر کو نمک کی مماثل ہیش ویلیو کو توڑنے کی کوشش میں وقت ضائع کرنے پر مجبور کرتے ہیں۔ یہ تقریباً ڈیوائس_اسپیڈ / نمکیات کی تعداد کے لیے درکار کوششوں کو پورا کرتا ہے کیونکہ ہمیں ہر نمک کے لیے ایک امیدوار تیار کرنے کی ضرورت ہے۔ اگر نمک جامد ہے ، تو ریاضی ایک ہی ہے... آلے_کی رفتار / 1. اسے دیکھنے کا دوسرا طریقہ: 
ہمارا GTX 980 cracks SHA1($salt.$pass) at 3576.8 MH/s or 3.5 بلین امیدوار فی سیکنڈ 
ہماری   ہیش لسٹ   میں   1000   منفرد   نمکیات ہیں 

3,500,000,000 / 1000 = 3,500,000 امیدوار فی سیکنڈ
 یہ شدت کے تین حکم سست ہے ، 99.9 فیصد نقصان۔ جامد نمک کا استعمال کرتے ہوئے ، یہ اس طرح نظر آتا ہے: 
Our GTX 980 cracks SHA1($salt.$pass) at 3576.8 MH/s یا 3.5 بلین امیدوار فی سیکنڈ 
ہماری ہیش لسٹ میں 1 منفرد نمک شامل ہے 
               
3,500,000,000 / 1 = 3,500,000,000 امیدوار فی سیکنڈ
اگر اس کا کوئی مطلب نہیں ہے تو پڑھیں اور ہمارے پاس بعد میں ایک خوبصورت چارٹ ہوگا...

 تکرار 
 صرف "اس سادہ متن کو ہیش کریں" کے مقابلے میں ایک اور عام بہتری یہ ہے کہ "اس سادہ متن کو ہیش کریں ، پھر اس نتیجے کو ہیش کریں ، پھر اس نتیجے کو ہیش کریں" ہزاروں بار دہرایا جاتا ہے۔ اس طرح ایک امیدوار پاس ورڈ کی کوشش کرتے وقت پاس ورڈ کریکر کو ہزاروں بار کرنا پڑتا ہے۔ اسے تکرار ، لوپ یا متغیر لاگت کہا جاتا ہے۔ کچھ پاس ورڈ ہیش الگورتھم سخت کوڈ شدہ تکرار راؤنڈ استعمال کرتے ہیں۔ دیگر گٹ. اسے خود ہیش کے ایک حصے میں قابل ترتیب بناتا ہے۔ مثال کے طور پر ، md5crypt() MD5 کا استعمال کرتا ہے ، بشمول نمک ، اور بالکل 1000 بار لوپ کرتا ہے۔ sha512crypt() sha512 کا استعمال کرتا ہے ، جس میں نمک شامل ہے ، اور قابل ترتیب بار لوپ کرتا ہے (پہلے سے طے شدہ 5,000 ہے)۔ 
 تکرار بنیادی طور پر ہیش الگورتھم کی کمپیوٹیشنل سائیکل لاگت کو متاثر کرتی ہے ، نہ کہ اس کی میموری کے استعمال یا دیگر عوامل۔ یہ حملوں میں بھی اہم ہیں جب ڈیزائن کو کچھ قسم کے ہیش اقسام کے خلاف مزاحمت کے لیے بہتر بنایا گیا ہے ، لیکن یہ یہاں بحث کرنے کے لیے بہت گھاس ہے۔ 

کریکنگ کی رفتار پر ہیش کی اقسام کا اثر
آئیے ہیش الگورتھم کے انتخاب کے اثرات کو ظاہر کرنے کے لیے کچھ مثالیں دیکھتے ہیں ، چاہے وہ نمکین ہو ، متعدد تکرار کا استعمال کریں ، وغیرہ۔ فرض کریں کہ ایک حملہ آور نے 1,000 صارفین کی ہیش اکٹھی کی۔ کسی متاثرہ ویب سائٹ سے ، وہ صرف ایک سادہ حملہ کرنا چاہتے ہیں ، ہر پاس ورڈ کی جانچ کرتے ہیش - 143 ملین امیدوار پاس ورڈ۔ 
 
 متاثرہ ویب سائٹ کی طرف سے استعمال کیا جاتا ہے ہیش کی قسم اس حملے کے ذریعے ایک حملہ آور کی ضرورت کے وقت پر بہت بڑا اثر پڑے گا. یہ ایک چارٹ ہے کہ (نسبتاً ، تقریباً) اس حملے کو مکمل کرنے میں کتنے سیکنڈ لگتے ہیں ، استعمال شدہ ہیش کی قسم پر منحصر ہے ، جہاں معیاری گرافکس کارڈ: 
 ٹھیک ہے ، یہ کام نہیں کرے گا! سب سے مضبوط ہیش کی قسم بہت سست ہے ، لیکن تیز تر قسم صرف اس وقت تک کچل دی جاتی ہے جب تک کہ کچھ بھی نہ ہو۔ آئیے لوگارتھمک ایکس ایکسس ٹائم کا استعمال کرتے ہوئے اسی ڈیٹا پیمانے پر دوبارہ کوشش کریں۔ جب سلاخوں کو بائیں سے دائیں طرف منتقل کیا جاتا ہے ، تو وہ 10 کی طاقت میں اضافہ کریں گے: 
 تو کچھ اہم نکات یہ ہیں: جب آپ کچھ پاس ورڈ ہیش کو توڑنا چاہتے ہیں ، تو سنگل راؤنڈ ایک سے زیادہ راؤنڈ سے زیادہ ہے اور نمک کے بغیر نمک شامل کرنے سے زیادہ آسان ہے۔ اس کے برعکس ، جب کچھ کمپنیاں یا ویب سائٹس صارف کے ڈیٹا پر مشتمل ڈیٹا کی خلاف ورزی کا اعلان کرتی ہیں ، a) پاس ورڈ کو ترجیحی طور پر ہیش کیا گیا ہے ، نہ کہ صرف سادہ متن ؛ ب) وہ بہتر طور پر نمکین ہیں ، نہ کہ صرف ہیش ؛ c) ان کے پاس صرف ایک راؤنڈ کے بجائے طاقتور ملٹی راؤنڈ نمکین ہیش کا استعمال کرنا بہتر ہے۔ 

 
 ہیش کی قسم کی شناخت کریں 
 
 دیئے گئے پاس ورڈ ہیش کو توڑنے کی کوشش کرنے سے پہلے ، یہ کریکر پر منحصر ہے کہ اس کو لاگو کرنے کے لئے کون سا ہیش الگورتھم استعمال کیا گیا ہے. ہیش کی اقسام کی شناخت عام طور پر آسان ہے ، لیکن ہمیشہ نہیں. کریکرز عام طور پر سراغ کی بنیاد پر قائم کردہ اندازے لگاتے ہیں ، جیسے ہیش کی لمبائی اور فارمیٹ۔ حتمی تجزیہ میں ، اس بات کا یقین کرنے کا واحد طریقہ ہے کہ ہیش کی قسم کا اندازہ درست ہے کہ آیا ہیش ٹوٹ گیا ہے. 
 
 یہاں اور یہاں اس کام کے لئے کچھ بہترین وسائل فراہم کیے گئے ہیں ، اور وہ سب یہ ظاہر کرتے ہیں کہ عام ہیش اقدار کیسی نظر آتی ہیں۔ 
کالی لینکس میں "hash-identifier" سافٹ ویئر پیکج (یہاں دستیاب) دستیاب ہے جو نامعلوم ہیش اقسام کی شناخت میں مدد کرتا ہے۔ 

 تصادم 
 تصادم اس وقت ہوتا ہے جب دو مختلف ان پٹ ایک ہی ہیش آؤٹ پٹ کا باعث بنتے ہیں۔ یہ برا ہے (واضح) پاس ورڈ کے لئے ، اس کا مطلب یہ ہوسکتا ہے کہ میں نے آپ کا اصل پاس ورڈ نہیں توڑا ہوسکتا ہے ، لیکن چونکہ مجھے ایک ان پٹ ملا ہے جو اسی ہیش ویلیو پیدا کرتا ہے ، میں سسٹم کو دھوکہ دینے کے لئے سادہ ٹیکسٹ ویلیو کا استعمال کرسکتا ہوں تاکہ پاس ورڈ جائز ہو۔ 
مائیکروسافٹ آفس نے اپنے دستاویز کے تحفظ میں ایک الگورتھم کا استعمال کیا ہے جو کئی سالوں سے تنازعات کا شکار ہے۔ یہ ایک ہی ہیش کے لئے ایک سے زیادہ تنازعات کو تلاش کرنے کے لئے غیر معمولی نہیں ہے ، اور یہ سب دستاویز کو غیر مقفل کر دیتے ہیں. 
 ایک بار جب تنازعات کا پتہ چلا جاتا ہے ، تو الگورتھم اصل میں تباہ ہوجاتا ہے. اگر یہ ایک بار ہوتا ہے تو ، اعداد و شمار کے لحاظ سے ، یہ دوبارہ ہونے کا امکان ہے. صرف ایک چیز جو ہمیں روکتی ہے وہ وقت اور پروسیسنگ کی طاقت ہے. جیسے جیسے الگورتھم زیادہ مضبوط ہوتے جاتے ہیں ، امیدوار الگورتھم تیار کرنے اور ان کو تلاش کرنے کے لیے ہیش آؤٹ پٹ کا موازنہ کرنے میں زیادہ صلاحیت اور وقت درکار ہوتا ہے۔ نتیجے کے طور پر ، ڈیزائنرز ایسے الگورتھم بنانے میں تیزی سے اچھے ہو رہے ہیں جو تنازعات کا شکار نہیں ہوتے ہیں۔