টেক্সট বা ফাইলের HMAC-SHA1, SHA-256, SHA-384 ও SHA-512, সঙ্গে স্বাক্ষর যাচাই
আপনার ব্রাউজারে চলে। আপনি যা লেখেন তা কোথাও পাঠানো হয় না।HMAC প্রমাণ করে যে বার্তাটি এমন কারও কাছ থেকে এসেছে যার কাছে শেয়ার করা গোপন কী আছে; webhook এভাবেই যাচাই হয়। SHA-1, SHA-256, SHA-384 ও SHA-512 সমর্থিত, টেক্সটে বা 200 MB পর্যন্ত ফাইলে। গোপন কী কখনো আপনার ব্রাউজার ছেড়ে যায় না, যা স্বাক্ষরের কী-র জন্য গুরুত্বপূর্ণ।
এই পৃষ্ঠাটি ইংরেজি মূল লেখা থেকে যন্ত্রের সাহায্যে অনুবাদ করা হয়েছে। এই অনুবাদটি এখনও কোনো মানুষ পর্যালোচনা করেননি, তাই ইংরেজি সংস্করণটিকেই নির্ভরযোগ্য ধরুন। ইংরেজি মূল লেখাটি পড়ুন
অ্যালগরিদম থেকে SHA-1, SHA-256, SHA-384 বা SHA-512 বেছে নিন।
গোপন কী লিখুন এবং ঠিক করুন সেটি টেক্সট, Hex না Base64 হিসেবে লেখা।
টেক্সট অংশে বার্তাটি পেস্ট করুন, অথবা ফাইলে গিয়ে একটি ফাইল বেছে নিন চাপুন।
কপি আইকন দিয়ে Hex, Base64 বা Base64URL ফলাফল কপি করুন; Ctrl+Enter চাপলে hex কপি হয়।
এই HMAC জেনারেটর SHA-1, SHA-256, SHA-384 বা SHA-512 দিয়ে টেক্সট বা ফাইলের কী-যুক্ত হ্যাশ হিসাব করে এবং লেখার সঙ্গে সঙ্গে ফলাফল hex, Base64 ও URL-নিরাপদ Base64-এ দেখায়। এটি যাচাইও করে: প্রত্যাশিত স্বাক্ষর পেস্ট করুন, এটি জানাবে মিলছে কি না।
HMAC দিয়ে দুটি সিস্টেম প্রমাণ করে যে বার্তাটি শেয়ার করা গোপন কী-র অধিকারীর কাছ থেকে এসেছে এবং পথে বদলায়নি। ডেভেলপাররা এটি ব্যবহার করেন যখন কোনো পেমেন্ট প্রোভাইডারের webhook যাচাইয়ে ব্যর্থ হয় আর জানতে হয় ভুলটা গোপন কী-তে, বডিতে না হেডারে, যখন স্বাক্ষরের ফাংশন লিখে জানা উত্তরের সঙ্গে মিলিয়ে দেখেন, অথবা যখন API ডকুমেন্টে পুনরায় তৈরি করার জন্য একটি উদাহরণ স্বাক্ষর থাকে।
কী টেক্সট, hex বা Base64 হিসেবে লেখা যায়, কারণ প্রোভাইডাররা তিন রূপেই গোপন কী প্রকাশ করে। প্রত্যাশিত স্বাক্ষর hex বা Base64 হতে পারে এবং হেডারের প্রিফিক্স রাখতে পারে, যেমন GitHub-এর sha256= বা Stripe-এর t=,v1= ফরম্যাট। তুলনা হয় স্থির সময়ে, যেমনটা আপনার সার্ভারেরও করা উচিত।
সবকিছু ঘটে আপনার ব্রাউজারে Web Crypto API দিয়ে। কী ও বার্তা কখনো আপলোড, লগ বা সংরক্ষণ করা হয় না, এমনকি এই ব্রাউজারেও না; কেবল আপনার বেছে নেওয়া অ্যালগরিদম ও কী-র ফরম্যাট মনে রাখা হয়। 200 MB পর্যন্ত ফাইল স্বাক্ষর করা যায়, কারণ পুরো ফাইলটি একসঙ্গে মেমরিতে থাকতে হয়।
webhook যাচাই ব্যর্থ হলে সাধারণ কারণ হলো বডি: স্বাক্ষর হুবহু কাঁচা বাইটগুলোকে ধরে, আর কোনো ফ্রেমওয়ার্ক যে JSON বডি নতুন করে সিরিয়ালাইজ করেছে তা মিলবে না। সম্পর্কিত টুল: JWT Decoder, Base64 Encoder, Bcrypt Hash and Verify।
SHA-256 বেছে নিন, গোপন কী লিখুন বা পেস্ট করুন, তারপর বার্তা লিখুন বা একটি ফাইল বেছে নিন। স্বাক্ষর সঙ্গে সঙ্গে hex ও Base64-এ দেখা যায়; আপনার API যেটি চায় তার পাশের কপি চাপুন। কী যদি টেক্সটের বদলে hex বা Base64-এ দেওয়া থাকে, আগে কী-র ফরম্যাট বদলান, কারণ একই অক্ষর ভিন্ন বাইটে ডিকোড হয়।
না। HMAC আপনার ব্রাউজারে Web Crypto API দিয়ে হিসাব হয়, আর কী ও বার্তা কখনো পেজ ছেড়ে যায় না। আপনি যা লেখেন তার কিছুই লগ বা সংরক্ষণ করা হয় না, এমনকি লোকাল স্টোরেজেও না। পরের বারের জন্য এই ডিভাইসে কেবল বেছে নেওয়া অ্যালগরিদম ও কী-র ফরম্যাট মনে রাখা হয়।
সাধারণত বডিটি প্রেরক যা স্বাক্ষর করেছে তার সঙ্গে বাইটে বাইটে মেলে না: কোনো ফ্রেমওয়ার্ক JSON পার্স করে নতুন করে সিরিয়ালাইজ করেছে, লাইনের শেষ বদলেছে বা ফাঁকা জায়গা ছেঁটেছে। কাঁচা বডি স্বাক্ষর করুন। অন্য কারণ হলো ভুল গোপন কী (টেস্ট ও লাইভ কী আলাদা), hex গোপন কীকে টেক্সট হিসেবে ধরা, বা hex-কে Base64 স্বাক্ষরের সঙ্গে তুলনা করা।
সাধারণ হ্যাশ যে কেউ হিসাব করতে পারে, তাই কে তৈরি করেছে সে বিষয়ে এটি কিছুই প্রমাণ করে না। HMAC একটি গোপন কী মিশিয়ে দেয়, তাই কেবল কী-র অধিকারীই সঠিক মান তৈরি করতে পারে। এটি দৈর্ঘ্য-বর্ধন আক্রমণ ঠেকাতেও তৈরি, যা কী-র পরে বার্তা জুড়ে হ্যাশ করার সরল পদ্ধতিকে ভেঙে দেয়।
সাধারণ স্ট্রিং তুলনা প্রথম অমিল অক্ষরেই থেমে যায়, তাই কত সময় লাগল তা থেকে বোঝা যায় অনুমান করা স্বাক্ষরের কতটা ঠিক ছিল। অনেক অনুরোধে তা মেপে একজন আক্রমণকারী বাইট ধরে ধরে একটি বৈধ স্বাক্ষর গড়তে পারে। এই টুল প্রতিবার সব বাইট তুলনা করে, আর আপনার সার্ভারের কোডেরও তা-ই করা উচিত।
যেকোনো ব্যবহারিক দৈর্ঘ্যের টেক্সট বার্তা এবং 200 MB পর্যন্ত ফাইল, কারণ Web Crypto-র পুরো বার্তাটি মেমরিতে দরকার। SHA-1, SHA-256, SHA-384 ও SHA-512 সমর্থিত; Web Crypto-তে MD5 নেই এবং নতুন স্বাক্ষরে এটি এমনিতেও ব্যবহার করা উচিত নয়। কী অন্তত এক বাইটের হতে হবে।
এখনও আটকে আছেন? HMAC জেনারেটর সম্পর্কে প্রশ্ন করুন আর যিনি জানেন তিনিই উত্তর দিতে পারেন। কোনো অ্যাকাউন্ট লাগবে না।