HMAC üreteci ve imza denetleyici

Bu araç ne yapar

HMAC, bir mesajı ve paylaşılan bir sırrı kısa bir imzaya dönüştürür. Aynı sırra sahip herkes onu yeniden hesaplayabilir ve mesajın değişmeden geldiğini ve sırrı da bilen birinden geldiğini görebilir. Bu araç dört yaygın varyantı aynı anda hesaplar ve — size gönderilen bir imza verildiğinde — onu hangisinin ürettiğini söyler.

O ikinci yön genellikle insanların geldiği nedendir. Bir webhook doğrulamada başarısız oluyordur ve soru gerçekte «bu imza geçerli mi» değil, «gönderenden farklı yaptığım birkaç makul şeyden hangisi» sorusudur.

Bunun ters gittiği yer anahtardır

HMAC baytları baytlarla imzalar. Mesaj genellikle apaçıktır — ham istek gövdesi — ama anahtar neredeyse hiçbir zaman değildir, çünkü bir sır bir dize olarak gelir ve bir dize, onu nasıl okuyacağınıza karar verene dek bayt değildir:

a3f2   as text     4 bytes   61 33 66 32
a3f2   as hex      2 bytes   a3 f2

Her iki okuma da meşrudur, her ikisi de kusursuzca iyi biçimli bir imza üretir ve iki imzanın hiçbir ortak yanı yoktur. Sizi hiçbir şey uyarmaz: hata yok, uzunluk şikâyeti yok, yalnızca gönderenin hesapladığıyla eşleşmeyen bir değer. Buradaki anahtar kodlamasının bir tahmin değil, görünür bir seçim olmasının nedeni budur — bir imza eşleşmediğinde çevrilecek ilk şey budur.

Kaba bir kılavuz olarak: whsec_ gibi bir öneki ya da karışık büyük/küçük harf ve rakam dizisi olan bir sır normalde metin olarak düşünülür; yalnızca 0-9 ve a-f kullanan tam olarak 32 ya da 64 karakterlik bir dize genellikle hex'tir; ve = ile biten biri neredeyse kesinlikle Base64'tür. Ama biçime değil, gönderenin belgelerine bakın, çünkü biçim kanıt değildir.

Mesaj tam baytlar olmalıdır

Bir uyumsuzluğun diğer yarısı mesajdır. HMAC baytlar üzerinden tanımlanır; bu yüzden baytları değiştiren her şey imzayı tümüyle değiştirir — kısmi puan ve ıskalanmış yakın yoktur.

• JSON'u yeniden serileştirmek. Bir gövdeyi ayrıştırıp yeniden dizeye çevirmek anahtarları yeniden sıralayabilir, boşluğu değiştirebilir ya da sayıları normalleştirebilir. Ham gövdeyi aldığınız gibi imzalayın ve doğrulayın, asla onun gidip gelmiş bir kopyasını değil.
• Sondaki bir satır sonu. Bazı araçlar gövdeyi bir dosyaya kaydettiğinizde bir tane ekler; o bir bayttır ve her şeyi değiştirir.
• Karakter kodlaması. ASCII olmayan metin içeren bir gövdenin, iki tarafın da kullandığı aynı kodlamayla okunması gerekir — pratikte UTF-8.
• Sıkıştırma ya da ara katman. İşleyicinizin önünde bir şey gövdeyi açıyor ya da yeniden yazıyorsa, bu olduktan sonra değil, önce doğrulayın.

Birçok sağlayıcı gövdeyi de yalnız başına imzalamaz. Stripe, bir nokta ile birleştirilmiş bir zaman damgasını ve gövdeyi imzalar; AWS, yöntem, yol, başlıklar ve yükün bir hash'inden kurulan kanonik bir isteği imzalar. Doğrulama düz gövdeye karşı başarısız olursa, imzalanan dize muhtemelen düz gövde değildir — bu, gönderen tarafında belgelenir ve daha ileri hata ayıklamadan önce okumaya değer.

SHA-1 neden burada sunuluyor da hash aracında sunulmuyor

Hash aracı SHA-1'i bozuk olarak işaretler. Bu araç, HMAC-SHA-1'i uyarısız listeler ve bu bir gözden kaçma değil, bilinçlidir.

SHA-1, imzalar ve sertifikalar için kullanılamaz, çünkü çakışmalar oluşturulabilir: iki farklı belge bir özeti paylaşacak şekilde yapılabilir. HMAC bu özelliğe bağlı değildir. Güvenliği gizli anahtara dayanır ve yapı — mesajı iki kez, anahtar her ikisinde de karıştırılmış olarak hash'lemek — altta yatan hash çakışmaya zayıf olduğunda bile ayakta kalır. HMAC-SHA-1 sağlam kalır ve hâlâ OAuth 1.0a ile eski AWS imzalamasının kullandığı şeydir; bu yüzden onu hesaplamayı reddeden bir araç yalnızca daha az yararlı olurdu, daha güvenli olmadan.

Yeni herhangi bir şey için SHA-256 mantıklı varsayılandır. Daha uzun özetler burada anlamlı biçimde daha güçlü değildir — güvenlik tavanı özet uzunluğu değil, anahtardır — bu yüzden SHA-384 ve SHA-512, yalnızca birlikte çalışmanız gereken bir şey onları istediğinde seçmeye değer.

İmzaları güvenle karşılaştırma

Bu sayfa sıradan bir dize karşılaştırmasıyla karşılaştırır; bu burada sorun değildir: anahtarı kendiniz tutuyorsunuz, dolayısıyla sızacak bir şey yoktur. Gelen bir isteği doğrulayan bir sunucuda ise sorunludur. Sıradan bir karşılaştırma ilk farklı baytta durur; böylece aldığı süre bir tahminin ne kadarının doğru olduğunu açığa çıkarır ve çok istek gönderebilen bir saldırgan geçerli bir imzayı bayt bayt geri elde edebilir.

Platformunuzun sağladığı sabit-zamanlı karşılaştırmayı — Node'da crypto.timingSafeEqual, Python'da hmac.compare_digest, PHP'de hash_equals — hex dizeleri üzerinde değil, ham baytlar üzerinde kullanın. Bununla birlikte, istekte adlandırılmış bir algoritmaya güvenmek yerine kendi hesapladığınız bir imzaya karşı karşılaştırın ve zaman damgası şimdiye çok uzak olan bir mesajı reddedin; böylece eski geçerli bir imza yeniden oynatılamaz.

HMAC bir hash değildir ve bir imza değildir

Burada üç şey karıştırılır ve fark, sonradan neyi öne sürebileceğiniz için önemlidir:

• Bir hash bir mesaj alır ve bir özet üretir. Herkes onu hesaplayabilir; bu yüzden mesajın kazara değişmediğini kanıtlar — belirli birinden geldiğini değil.
• Bir HMAC bir mesaj ve paylaşılan bir sır alır. Her iki taraf da aynı anahtarı tutar; bu yüzden gönderenin sırrı bildiğini kanıtlar. Hangi tarafın gönderdiğini kanıtlayamaz, çünkü ikisi de onu üretmiş olabilir.
• Bir imza, yalnızca gönderenin tuttuğu bir özel anahtar ve herkesin doğrulayabileceği bir genel anahtar kullanır. İnkâr edilemezliği veren budur: gönderen sonradan onu inkâr edemez.

Yani HMAC, zaten bir sır paylaşan iki sistem arasında doğru araçtır — webhook'lar, dahili API'ler, oturum token'ları — ve bir şeyi kimin gönderdiğini üçüncü bir tarafa kanıtlamanız gerektiğinde yanlış olandır. Ayrıca unutmayın ki kimlik doğrular ama gizlemez: mesaj açık olarak yolculuk eder ve HMAC gizlilik hakkında hiçbir şey söylemez.