LLM’lerin ürettiği parolalar neden tehlikeli: 100 bit gibi görünüyor ama gerçekte 27 bit

Güvenlik şirketi Irregular’ın araştırmasına dayanarak, Claude, ChatGPT, Gemini gibi güncel LLM’lerin (büyük dil modelleri) ürettiği parolaların dışarıdan çok güçlü görünmesine rağmen gerçekte son derece zayıf olduğuna dikkat çekiliyor.

Temel deney sonuçları

• Her modele “bana bir parola üret” isteği 50 kez tekrarlandı
• Claude Opus 4.6: 50 denemenin 18’inde aynı parola G7$kL9#mQ2&xP4!w üretildi (%36 aynı); benzersiz parola sayısı yalnızca 30’du
• Modellere göre belirgin desen tercihleri görüldü
  • Claude → 'G' ile başlama + ikinci karakterin '7' olması
  • ChatGPT → 'v' ile başlama
  • Gemini → 'k' veya 'K' ile başlama
• Sıcaklık (temperature) 0.0~1.0 arasında değiştirilse de büyük fark oluşmadı (0.0’da 50 denemenin tamamı aynı parolaydı)

Entropi (rastgelelik) yanılsaması

• KeePass gibi araçlarda “yaklaşık 100 bit entropi, çok güçlü” olarak değerlendiriliyor
  → Süper bilgisayarla bile milyarlarca yıl sürecekmiş gibi görünüyor
• Ancak gerçek Shannon entropisi hesabına göre Claude’un ürettiği parolalar 27 bit seviyesinde
  → Sıradan bir bilgisayarla birkaç saniye içinde kırılabilecek zayıf parolalar
• GPT-5.2 örneği: 15. karakterin '2' rakamı olma olasılığı %99,7 (neredeyse sabit)

LLM’ler neden parola üretimi için uygun değil?

• Gerçekten güçlü parolalarda CSPRNG (kriptografik olarak güvenli rastgele sayı üreteci) kullanılır ve tüm karakterlerin eşit olasılıkla gelmesi gerekir
• LLM’ler ise bunun tersine, en olası bir sonraki token’ı tahmin edecek şekilde eğitilir → öngörülebilirlik en üst düzeye çıkar
• → Bu yüzden istemi iyi yazmak ya da sıcaklığı ayarlamak temel sorunu çözmez (Irregular’ın vardığı sonuç)

Daha büyük sorun: yapay zeka kodlama ajanlarının riski

• Claude Code, Gemini-CLI, Codex vb. araçlar koda zayıf parolaları sabit olarak gömüyor
  Örnek: MariaDB, PostgreSQL, FastAPI API anahtarları vb.
• “Bana parola üret” denince → openssl rand gibi güvenli yöntemler öneriliyor
  “Bana parola öner” denince → LLM’in ürettiği desen tabanlı parola doğrudan ekleniyor
• GitHub’da K7#mP9, k9#vL gibi desenler aranırsa gerçek depolarda çok sayıda örnek bulunuyor

Sonuç

• LLM’ler “güçlü görünen” parolalar üretmekte başarılı olabilir, ancak gerçek güvenlik görünüşe değil gerçek entropi ve rastgeleliğe bağlıdır.
• LLM’lerin tahmin odaklı tasarımı nedeniyle parola üretimi için yapısal olarak uygun değiller; özellikle yapay zeka kodlama araçları bunları koda gömerse, güvenlik açıkları otomatik geliştirme sürecine fark edilmeden yayılabilir.

https://aisparkup.com/posts/9480

[click]

openssl rand -hex 64 çalıştırsa gayet iyi olurdu; illa LLM'in doğrudan parola üretmesini sağlamak mı gerekiyor...?
İnsana bile parola oluştur deseniz, kendisinin hatırlamasını kolaylaştıran belirli bir örüntü içeren bir şekilde yapıyor zaten.

[davespark]

Geliştiriciler için pek sorun olmayabilir. Ama bugünlerde vibe coding yüzünden sıradan insanlar da çok kod yazdığı için, kodun içine otomatik olarak gömülen varsayılan değerler daha büyük sorun olacak gibi görünüyor. Örneğin DB bağlantı şifresi gibi..

[click]

Kesinlikle web servisi dağıtılmış olmasına rağmen .env gibi hassas dosyaların dış ağdan erişilebilir bırakıldığı birçok örnek gördüğümü düşününce...
Ne yaptığını tam bilmeden OpenClaw ile bir web servisi yapıp anahtarı doğrudan HTML kaynağına gömmek yüzünden anahtarın çalındığı ve bir anda fatura geldiği vakalar da ortaya çıkabilir gibi görünüyor

[holywork]

İnsanlar da rastgele seçim yapmakta pek iyi değildir. Ortada bir desen olmaması gerekir, ama deseni bilinçli olarak kaçınmak da başlı başına bir desen sayılabilir.

[roxie]

> Claude Opus 4.6: 50 denemede 18 kez

Benim asıl çok merak ettiğim, Claude code’un neden rastgele bir dize üretmediği.

[mammal]

Ah... Birinci sınıf mühendislik öğrencilerine kalkülüsü yeniden anlatan profesörlerin neden o ifadeyle baktığını şimdi anladım.

[jayhanx]

Üzücü ya, bu biraz fazla olmuş