Logo Logo
Yükleniyor...
Logo

HMAC Üretici

  • Kripto Hesaplayıcı
TR Türkçe EN English
Light
Dark
System

HMAC Üretici

Girdi

HMAC bir şifreleme değildir; mesajı gizlemez. Mesaj + gizli anahtar ile doğrulanabilir imza üretir.
Anahtarını mümkünse güçlü tut: uzun, rastgele, tekrar kullanılmayan ve güvenli saklanan.
Text seçersen yazdığın metin byte olarak kullanılır. Hex/Base64 seçersen önce decode edilir.
API anahtarları bazen Hex/Base64 gelir. Buradan doğru formatı seçebilirsin.
İpucu: Aynı mesaj için farklı anahtarlar tamamen farklı HMAC üretir. HMAC doğrulama için idealdir; veri gizleme için değil.

Çıktı

Byte: —
Karakter: —
Algoritma: —
Bu çıktıyı API isteklerinde imza olarak kullanabilir, karşı tarafta aynı secret ile doğrulayabilirsin. Base64-URL formatı querystring ve URL path imzaları için pratiktir.

HMAC Hakkında Detaylı Rehber

HMAC (Hash-based Message Authentication Code), bir mesajın değiştirilmediğini ve mesajı üreten tarafın gizli anahtara sahip olduğunu doğrulamak için kullanılan kriptografik bir doğrulama kodudur.
Temel fikir: HMAC = H( (K ⊕ opad) || H((K ⊕ ipad) || mesaj) ). Buradaki H seçtiğin hash fonksiyonudur (SHA-256, SHA-512, SHA3 vb.).
Not: HMAC şifreleme değildir. Mesajı saklamaz; sadece mesaj+anahtar kombinasyonuna bağlı bir imza üretir.

HMAC iki katmanlı hashing yapar: iç hash ve dış hash. Bu tasarım, bazı hash fonksiyonlarının doğasında bulunan “length extension” gibi saldırılara karşı güvenliği artırır.
Özet akış:
  1. Anahtar blok boyutuna göre hazırlanır (kısaysa pad, uzunsa hashlenir).
  2. Anahtar iki sabit padding ile XOR edilir (ipad/opad).
  3. Önce iç hash: H((K ⊕ ipad) || mesaj)
  4. Sonra dış hash: H((K ⊕ opad) || iç_hash)
Bu yüzden “yalnızca hash” ile imza üretmek yerine HMAC tercih edilir.

HMAC genelde API istek imzalama ve mesaj bütünlüğü için kullanılır.
  • REST API imzası: Timestamp + method + path + body üzerinden imza üretip header’a koyarsın.
  • Webhook doğrulama: Gelen payload’un gerçekten doğru kaynaktan geldiğini doğrularsın.
  • Token/Link imzası: “paylaşım linki” gibi şeylerde manipülasyonu engellersin.
  • Dosya/mesaj bütünlüğü: İletim sırasında değişiklik var mı kontrol edersin.
Kritik: Karşı taraf da aynı secret ile aynı kanonik veriyi (canonical string) kullanmalı.

Genel öneri: modern sistemlerde HMAC-SHA-256 çoğu iş için idealdir. Daha yüksek güvenlik marjı veya bazı uyumluluk gerekleri için HMAC-SHA-512 seçilebilir.
  • SHA-256: Çok yaygın, hızlı, iyi ekosistem desteği.
  • SHA-512: Daha uzun çıktı; bazı ortamlarda daha hızlı bile olabilir.
  • SHA3: Farklı tasarım ailesi; bazı güvenlik profillerinde tercih edilebilir.
  • MD5/SHA-1: Yeni tasarımlarda önerilmez; sadece eski sistem uyumluluğu için.
Uygulama gerçeği: “en güçlü” her zaman “en doğru” değildir; karşı taraf ne doğruluyor, o belirler.

HMAC güvenliği, hash fonksiyonundan çok anahtar yönetimine bağlıdır.
  • Secret’ı source code içine gömmek yerine environment/config ile yönet.
  • Uzun ve rastgele anahtar kullan (en az 32 byte iyi başlangıç).
  • Anahtarı loglama, URL içine koyma, istemci tarafında kalıcı saklama.
  • Döndürme (rotation) stratejisi planla: eski anahtar bir süre daha doğrulamada tutulabilir.
Bu modül anahtarını kaydetmez; sadece anlık hesaplar.

HMAC sonucu “ham byte”tır. İnsan okuyabilsin veya taşınabilsin diye kodlanır:
  • Hex (Base16): Debug için kral. Her byte iki hex karakter.
  • Base64: Daha kısa temsil; header/body taşıması kolay.
  • Base64-URL: URL safe; + ve / yerine - ve _ kullanır, genelde padding kaldırılır.
  • Binary (Base2): Eğitim/analiz için; pratikte uzun olduğu için nadir kullanılır.

  • Yanlış canonical string: Aynı alanlar farklı sırada birleşirse imza tutmaz.
  • Whitespace/encoding farkı: UTF-8 normalizasyonu, satır sonu farkı imzayı bozar.
  • Timestamp yok: Replay saldırılarına davetiye.
  • Secret sızıntısı: İmza kadar anahtar da hassas. Log, URL, frontend storage büyük risk.
Pratik: “ne imzaladığını” katı tanımla (method, path, query, body, timestamp, nonce...).

HMAC ile şifre çözülür mü?
Hayır. HMAC tek yönlü doğrulama kodudur, “decrypt” diye bir kavram yoktur.
Secret boş olabilir mi?
Teknik olarak olabilir ama pratikte güvenliği yok eder. Bu modül secret boşsa üretmez.
Neden hash(message) değil de HMAC?
HMAC, anahtarlı ve tasarımı gereği saldırılara daha dayanıklıdır.
Hangi çıktı formatı en iyi?
API header’ları için Base64, URL içi kullanım için Base64-URL, debug için Hex.

  • Versiyonla: İmza şemasına versiyon koy (v1, v2) — ileride format değiştirmen gerekebilir.
  • Replay koruması: timestamp + nonce kullan; sunucu tarafında kısa süreli nonce cache tut.
  • Scope: Yetki kapsamını imzaya dahil et (ör. kullanıcıId, tenantId, izinler).
  • Karşılaştırma: Doğrulamada mümkünse constant-time compare kullan.
  • Test vektörleri: Üretim öncesi birkaç sabit örnek ile iki tarafın aynı sonuç verdiğini doğrula.

İmza tutmuyorsa genelde sorun kriptografi değil, girdi farkıdır.
  1. İmzalanan string’i iki tarafta birebir yazdır (debug mod).
  2. Encoding’i kontrol et: UTF-8 mi? JSON minify mi? newline farkı var mı?
  3. Query parametre sırası sabit mi? URL decode/encode farkı var mı?
  4. Base64-URL padding kaldırılıyor mu? Karşı taraf ne bekliyor?
Bu modülde “Mesaj/Anahtar formatı” seçimi bu tip debug işlerini hızlandırır.
2017 - 2026© Exnek Project Infrastructure ~ Versiyon : 3.0.24
PTA : 32745 | PTC : 60