HMAC გენერატორი — HMAC-SHA1, SHA256, SHA384, SHA512 ონლაინ

ეს ხელსაწყო ითვლის HMAC-ს (Hash-based Message Authentication Code) საიდუმლო გასაღებისა და შეტყობინებისგან, საბაზისო ჰეშ-ფუნქციად SHA-1, SHA-256, SHA-384 ან SHA-512-ის გამოყენებით. ჩვეულებრივი ჰეშისგან განსხვავებით, HMAC მოითხოვს გაზიარებულ საიდუმლო გასაღებს, ამიტომ ის ამტკიცებს, რომ შეტყობინება მოვიდა იმისგან, ვისაც ეს გასაღები აქვს და გადაცემისას არ შეცვლილა — სწორედ ამიტომ იყენებენ API-ები HMAC-ს მოთხოვნების ხელმოწერისთვის, ხოლო webhook-ები — გამგზავნის დასამოწმებლად. ყველაფერი ლოკალურად სრულდება თქვენი ბრაუზერის ჩაშენებული Web Crypto API-ის მეშვეობით; თქვენი საიდუმლო გასაღები და შეტყობინება არასდროს იგზავნება არცერთ სერვერზე.

რა არის ეს ხელსაწყო?

HMAC ნიშნავს Hash-based Message Authentication Code-ს. ის აერთიანებს საიდუმლო გასაღებს შეტყობინებასთან და სტანდარტულ ჰეშ-ფუნქციასთან (მაგალითად, SHA-256) ფიქსირებული სიგრძის დაიჯესტის მისაღებად. ნებისმიერს, ვისაც აქვს იგივე გასაღები და შეტყობინება, გამოთვლის ზუსტად იმავე HMAC-ს — მაგრამ გასაღების გარეშე გამოთვლითად შეუძლებელია მართებული HMAC-ის წარმოქმნა შეტყობინებისთვის, თუნდაც იცოდეთ გამოყენებული ჰეშ-ალგორითმი.

სწორედ ეს არის მთავარი განსხვავება ჩვეულებრივი ჰეშისგან: ჩვეულებრივი ჰეში (MD5, SHA-256 და სხვ.) იღებს მხოლოდ შეტყობინებას შესატანად, ამიტომ ნებისმიერს შეუძლია მისი გამოთვლა და ის არაფერს ამტკიცებს იმის შესახებ, თუ ვინ შექმნა იგი. HMAC იღებს შეტყობინებას *და* საიდუმლო გასაღებს, ამიტომ მართებული HMAC ამტკიცებს, რომ გამგზავნს ეს საიდუმლო გააჩნდა — ეს არის ავთენტიფიკაციის მექანიზმი, არა უბრალოდ მთლიანობის შემოწმება.

HMAC ოფიციალურად სტანდარტიზებულია NIST-ის მიერ FIPS 198-1-ში და განსაზღვრულია ინტერნეტ პროტოკოლებისთვის IETF RFC 2104-ში. ეს ხელსაწყო HMAC-ს ითვლის თქვენი ბრაუზერის ბუნებრივი Web Crypto API-ის მეშვეობით (`crypto.subtle.sign` HMAC ალგორითმით), რომელიც სწორად ახორციელებს RFC 2104-ს, და არა ხელით დაწერილ JavaScript ვერსიას.

რატომ გამოვიყენო ის?

ხელი მოაწერეთ API მოთხოვნებს, რათა მიმღებმა სერვერმა შეძლოს დაადასტუროს, რომ მოთხოვნა მოვიდა გაზიარებული საიდუმლოს მფლობელისგან და არ შეცვლილა.
დაამოწმეთ webhook-ის დატვირთვები (Stripe, GitHub, Shopify და მსგავსი სერვისები ყველა HMAC-SHA256-ით აწერენ ხელს webhook-ის სხეულებს).
შექმენით ავთენტიფიკაციის ტოკენები ან ერთჯერადი კოდები, რომლებიც გაზიარებულ საიდუმლოზეა დამოკიდებული.
შეადარეთ თქვენი საკუთარი HMAC იმპლემენტაციის შედეგი ცნობილ სწორ საცნობარო მნიშვნელობას.
100% ლოკალური: თქვენი საიდუმლო გასაღები და შეტყობინება არასდროს ტოვებს ბრაუზერს, ამიტომ უსაფრთხოა რეალური საიდუმლოებების ტესტირება.

როგორ გამოვიყენო

შეიყვანეთ თქვენი საიდუმლო გასაღები ველში "Secret Key".
შეიყვანეთ ის შეტყობინება, რომლის ავთენტიფიკაციაც გსურთ, ველში "Message".
HMAC-SHA1, HMAC-SHA256, HMAC-SHA384 და HMAC-SHA512 შედეგები მყისიერად გენერირდება (მონიშნეთ "Uppercase output", თუ თქვენი სამიზნე სისტემა დიდ ასოებს ელოდება).
დააჭირეთ "Copy"-ს იმ HMAC-ის გვერდით, რომელიც გჭირდებათ.

მაგალითი

შეყვანა

Secret Key: key
Message: The quick brown fox jumps over the lazy dog

შედეგი

HMAC-SHA256: f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8
HMAC-SHA1: de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9

ეს არის სტანდარტული გამოქვეყნებული ტესტ-ვექტორი: გასაღებით "key" და ამ ზუსტი შეტყობინებით, HMAC-SHA256 და HMAC-SHA1 ყოველთვის აწარმოებენ ამ მნიშვნელობებს ნებისმიერ სწორ იმპლემენტაციაში, ამიტომ შეგიძლიათ დამოუკიდებლად გადაამოწმოთ ამ ხელსაწყოს შედეგი.

HMAC vs ჩვეულებრივი ჰეში: როდის გჭირდებათ გასაღები

გადამწყვეტი კითხვაა: გჭირდებათ იმის დამტკიცება, თუ ვინ შექმნა ეს დაიჯესტი, თუ უბრალოდ, რომ შინაარსი არ შეცვლილა? თუ საკმარისია საჯარო საკონტროლო ჯამი — ჩამოტვირთული ფაილის დამთხვევის შემოწმება გამომცემლის მიერ მითითებულთან, ჩანაწერების დუბლირების თავიდან აცილება — ჩვეულებრივი ჰეში საკმარისია და ნებისმიერს შეუძლია მისი შემოწმება, გასაღების გარეშე. თუ საჭიროა იმის დამტკიცება, რომ დაიჯესტი მხოლოდ კონკრეტული საიდუმლოს მფლობელს შეეძლო შეექმნა — API-ის გამომძახებლის ავთენტიფიკაცია, webhook-ის გამგზავნის ნდობა — გჭირდებათ HMAC, რადგან ჩვეულებრივი ჰეში საიდუმლოს არმქონე თავდამსხმელს იმავე შესაძლებლობას აძლევს, გააყალბოს მართებული დაიჯესტი, რაც აქვს ნამდვილ გამგზავნს.

→

ოთხი HMAC ალგორითმის შედარება

ოთხივე იყენებს იმავე HMAC კონსტრუქციას RFC 2104-დან, განსხვავდება მხოლოდ საბაზისო ჰეშ-ფუნქციით და, შესაბამისად, გამოსავალის სიგრძით.

ალგორითმი	გამოსავლის ზომა	ტიპური გამოყენება
HMAC-SHA1	160-ბიტიანი (40 თექვსმეტობითი სიმბოლო)	მემკვიდრეობითი API-ები, ძველი OAuth 1.0a ხელმოწერები
HMAC-SHA256	256-ბიტიანი (64 თექვსმეტობითი სიმბოლო)	API მოთხოვნის ხელმოწერა, JWT HS256, webhook-ის დამოწმება
HMAC-SHA384	384-ბიტიანი (96 თექვსმეტობითი სიმბოლო)	მაღალი უსაფრთხოების ხელმოწერები, სადაც საჭიროა უფრო გრძელი გამოსავალი
HMAC-SHA512	512-ბიტიანი (128 თექვსმეტობითი სიმბოლო)	მაქსიმალური სიგრძის დაიჯესტები მაღალი უსაფრთხოების აპლიკაციებისთვის

საერთო გამოყენების შემთხვევები

გამავალი API მოთხოვნების ხელმოწერა გაზიარებული საიდუმლოთი, რათა სერვერმა დაადასტუროს გამომძახებლის ვინაობა.
შემომავალი webhook დატვირთვების დამოწმება (Stripe-Signature, GitHub X-Hub-Signature-256 და მსგავსი სათაურები ყველა HMAC-SHA256-ს იყენებს).
HS256/HS384/HS512-ით ხელმოწერილი JWT-ის ხელმოწერის ნაწილის გენერირება და ვალიდაცია.
თქვენი სერვერის ან კლიენტის მხარის HMAC იმპლემენტაციის შემოწმება მოსალოდნელ შედეგთან შესატყვისობაზე მისი დანერგვამდე.

ხშირად დასმული კითხვები

რა არის HMAC?

HMAC (Hash-based Message Authentication Code) აერთიანებს საიდუმლო გასაღებს შეტყობინებასთან ჰეშ-ფუნქციის გამოყენებით, რათა შექმნას დაიჯესტი, რომელიც ამტკიცებს როგორც შეტყობინების მთლიანობას, ისე გამგზავნის მიერ გასაღების ფლობას. ის განსაზღვრულია NIST FIPS 198-1-სა და IETF RFC 2104-ში.

რა განსხვავებაა HMAC-სა და ჩვეულებრივ ჰეშს შორის?

ჩვეულებრივი ჰეში (SHA-256, MD5 და სხვ.) იღებს მხოლოდ შეტყობინებას შესატანად — ნებისმიერს შეუძლია მისი გამოთვლა, ამიტომ ის მხოლოდ ამტკიცებს, რომ შეტყობინება არ დაზიანებულა, და არა თუ ვინ გამოაგზავნა. HMAC იღებს შეტყობინებას პლუს საიდუმლო გასაღებს: თუ საჭიროა იმის დამტკიცება, რომ შეტყობინება მოვიდა კონკრეტული საიდუმლოს მფლობელისგან (API ხელმოწერა, webhook-ის გამგზავნი), გჭირდებათ HMAC. თუ საჭიროა მხოლოდ იმის შემოწმება, რომ ფაილი ან შეტყობინება არ შეცვლილა და არ გაინტერესებთ ავტორობის დამტკიცება, საკმარისია ჩვეულებრივი ჰეში.

იგზავნება ჩემი საიდუმლო გასაღები სერვერზე?

არა. ეს ხელსაწყო HMAC-ს მთლიანად თქვენს ბრაუზერში ითვლის Web Crypto API-ის გამოყენებით. თქვენი გასაღები და შეტყობინება არასდროს გადაიცემა არსად — შეგიძლიათ უსაფრთხოდ გამოსცადოთ რეალური საწარმოო საიდუმლოებები.

რომელი ალგორითმი გამოვიყენო — SHA-1, SHA-256, SHA-384 თუ SHA-512?

გამოიყენეთ HMAC-SHA256, თუ კონკრეტული სისტემა სხვას არ მოითხოვს — ეს არის API ხელმოწერის ფაქტობრივი სტანდარტი (გამოიყენება AWS-ის, Stripe-ის, GitHub-ის webhook-ების და უმეტესი თანამედროვე API-ების მიერ) და გთავაზობთ ძლიერ უსაფრთხოების ზღვარს. HMAC-SHA1 კვლავ გავრცელებულია მემკვიდრეობით მიღებულ სისტემებში (მაგალითად, ძველი OAuth 1.0a იმპლემენტაციები), მაგრამ SHA-1-ის საბაზისო ჰეში სუსტად ითვლება; HMAC-SHA384/512 გამოიყენება იქ, სადაც კონკრეტულად საჭიროა უფრო გრძელი შედეგი ან დამატებითი უსაფრთხოების ზღვარი.

არის თუ არა HMAC-SHA1 არასაიმედო, რადგან უბრალო SHA-1 გატეხილია?

2017 წლის კოლიზიის შეტევებმა გატეხეს SHA-1 როგორც ჩვეულებრივი ჰეშ-ფუნქცია, მაგრამ HMAC-SHA1 კვლავ კრიპტოგრაფიულად საიმედოდ ითვლება, რადგან HMAC-ის უსაფრთხოება არ არის დამოკიდებული კოლიზიისადმი მდგრადობაზე იმავე გზით. მიუხედავად ამისა, ახალი სისტემებისთვის ურჩევენ HMAC-SHA256-ს ან უფრო მაღალს — პრაქტიკული ნაკლი არ არსებობს და ეს საკითხს მთლიანად აშორებს.

რა არის HMAC-ის საერთო რეალურ ცხოვრებისეული გამოყენებები?

REST API მოთხოვნების ხელმოწერა, რათა სერვერმა შეძლოს დაადასტუროს, რომ გამომძახებელს გაზიარებული API საიდუმლო აქვს; webhook-ის დატვირთვების დამოწმება ისეთი სერვისებიდან, როგორიცაა Stripe, GitHub და Shopify, რათა იცოდეთ, რომ მოთხოვნა ნამდვილად მათგან მოვიდა და არ გაყალბებულა; დროზე დაფუძნებული ერთჯერადი პაროლების (TOTP/HOTP) გენერირება ორფაქტორიანი ავთენტიფიკაციისთვის; და JWT ტოკენების ხელმოწერა HS256/HS384/HS512 ალგორითმებით.