İstemci nonce kullanımı nedir?
Ross Anderson'ın Güvenlik Mühendisliği kitabının I. Bölümü'nü okuduktan ve Wikipedia'daki bazı konuları açıkladıktan sonra Client Nonce (cnonce) fikrine rastladım. Ross kitabında asla bahsetmedi ve kullanıcı kimlik doğrulamasında hangi amaca hizmet ettiğini anlamak için uğraşıyorum.
İmtiyazlar kazanmak için süresi dolmuş bir yanıtın kullanılmasını içeren tekrar saldırılarını önlemek için normal bir nonce kullanılır. Sunucu, istemciye, yanıtını hash etmek için kullanmak zorunda olduğu bir nonce (bir kez kullanılan sayı) sağlar; daha sonra sunucu, sağladığı nonce ve istemcinin hash değeri sunucu daha sonra isteğin geçerli ve yeni olduğunu doğrulayabilir. Tek doğruladığı bu; geçerli ve taze .
Bununla birlikte, bir müşteri nonce için bulduğum açıklamalar daha az açık ve sorgulanabilir. Dijital erişim kimlik doğrulaması için Wikipedia sayfası ve Stackoverflow'daki çeşitli yanıtlar, seçilen düz metin saldırılarından kaçınmak için istemci olmayan bir öğenin kullanıldığını düşündürmektedir. Bu fikirle ilgili birkaç problemim var:
- Bir kişi koklayabilir ve paketleri ekleyebilirse, en büyük güvenlik açığı, ne mantıksız ne de topçu aşmanın ortada bir adam saldırısıdır ve bu nedenle her ikisini de anlamsız hale getirir.
- Saldırganın ortadaki bir adam saldırısına girmek istemediğini ve kimlik doğrulama ayrıntılarını kurtarmak istediğini varsayarsak, bir ek saldırı nasıl ek koruma sağlar? Saldırgan iletişimi keserse ve kendi isteğiyle kendi isteğiyle yanıt verirse, istemciden gelen yanıt, şifrelenmemiş biçimde cnonce'a ek olarak nonce, data ve cnonce değerinin bir karması olacaktır. Artık saldırganın nonce, cnonce ve hash'e erişimi var. Saldırgan şimdi Rainbow masalarını nonce ve cnonce ile hash edebilir ve bir eşleşme bulabilir. Bu nedenle, cnonce sıfır ek koruma sağlar.
Öyleyse bir topçuğun amacı nedir?
Denklemin anlamadığım bir kısmının olduğunu varsayıyorum ama bu kısmın ne olduğuna dair henüz bir açıklama bulamadım.
EDIT Bazı cevaplar istemcinin bir nonce sağlayabileceğini ve aynı amaca hizmet edeceğini öne sürdü. Bu, meydan okuma-yanıt modelini bozar, bunun sonuçları nelerdir?
A nonce, bir protokolde bir kuruluş tarafından seçilen benzersiz bir değerdir ve bu varlığı "yeniden oynatma" nın çok büyük şemsiyesi altına giren saldırılara karşı korumak için kullanılır.
Örneğin, şuna benzer bir parola tabanlı kimlik doğrulama protokolü düşünün:
- sunucu istemciye bir "meydan okuma" (sözde rastgele bir değer c gönderir
- müşteri h (c || p) göndererek yanıt verecektir = h güvenli bir karma işlevidir (örneğin SHA-256), p kullanıcı şifresidir ve ' ||' birleştirme anlamına gelir
- sunucu kendi veritabanında şifreyi arar, beklenen müşteri yanıtını yeniden hesaplar ve istemcinin gönderdiği ile eşleşip eşleşmediğini görür
Parolalar insan beynine uyan gizli değerlerdir; bu nedenle, çok karmaşık olamazlar ve yüksek olasılıkla kullanıcı parolasını içerecek büyük bir sözlük oluşturmak mümkündür. "Büyük" demek istediğim "birkaç hafta içinde orta ölçekli bir kümeyle numaralandırılabilir". Mevcut tartışma için, bir saldırganın birkaç haftalık hesaplama yaparak tek bir şifreyi kırabileceğini kabul ediyoruz; bu elde etmek istediğimiz güvenlik seviyesidir.
Pasif bir saldırgan düşünün: saldırgan kulak misafiri olur ancak mesajları değiştirmez. c ve h (c || p) görür, böylece bir eşleşme bulunana kadar kümesini kullanarak potansiyel şifreleri numaralandırır. Bu onun için pahalı olacak. Saldırgan iki parolalara saldırmak istiyorsa iki kez işini yapmalıdır. Saldırgan ister iki saldırı örneği arasında biraz maliyet paylaşımı yapmak için önceden hesaplanmış tablolar ("Gökkuşağı tabloları" sadece bir tür önceden hesaplanmış tablodur ancak bir Gökkuşağı tablosu oluşturmak için tüm sözlüğün numaralandırılması ve her parolanın karıştırılması gerekir). Ancak, rastgele sınama saldırganı yener: her örnek yeni bir sınama içerdiğinden, hash işlevi girdisi, aynı parola kullanılsa bile her oturum için farklı olacaktır. Böylece, saldırgan önceden hesaplanmış yararlı tablolar, özellikle Rainbow tablolar oluşturamaz.
Şimdi saldırganın aktif hale geldiğini varsayalım. Sadece mesajları gözlemlemek yerine, aktif olarak mesajları değiştirecek, bazılarını bırakacak, başkalarını çoğaltacak veya kendi mesajlarını ekleyecektir. Saldırgan artık istemciden bir bağlantı girişimini kesebilir. Saldırgan kendi meydan okumasını seçer ve gönderir ( c ') ve müşteri yanıtını bekler ( h (c' || p)). Gerçek sunucuyla bağlantı kurulmadığını unutmayın; saldırgan, iyi bir ağ hatası benzetmek için istemci yanıtından hemen sonra bağlantıyı aniden bırakır. Bu saldırı modelinde, saldırgan büyük bir gelişme kaydetti: hala bir meydan okuma c ' ve karşılık gelen yanıtı var, ancak meydan okuma saldırganın uygun gördüğü gibi seçtiği bir değer. Saldırganın yapacağı her zaman sunucuya aynı meydan okumadır c '. Aynı meydan okumayı her seferinde kullanmak saldırganın ön hesaplamaları yapmasına izin verir: o özel "meydan okumayı" kullanan önceden hesaplanmış tablolar (yani Rainbow tabloları) oluşturabilir. Artık saldırgan, her biri için sözlük numaralandırma maliyetine maruz kalmadan birkaç farklı şifreye saldırabilir.
A istemci nonce bu sorunu önler. Protokol şöyle olur:
- sunucu rastgele bir meydan okuma gönderir c
- istemci bir nonce n seçer (her seferinde farklı olmalıdır)
- müşteri n || h (c || n || p)
- sunucu h (c || n || p) ( p veritabanından yeniden hesaplar) ve bu değerin istemcinin gönderdiği değerle eşleşip eşleşmediğini görür
İstemci, her oturum için karma işlev girdisine yeni bir rastgele değer ("nonce") içerdiğinden, saldırgan meydan okumayı seçse bile karma işlev girdisi her seferinde farklı olacaktır. Bu, önceden hesaplanmış (Rainbow) tabloları yener ve amaçlanan güvenlik seviyemizi geri yükler.
Benzersiz bir nonce'nin kaba bir öykünmesi kullanıcı adıdır. Aynı sistemdeki iki farklı kullanıcının farklı adları olacaktır. Ancak, kullanıcı şifresini değiştirdiğinde adını koruyacaktır; ve iki farklı kullanıcı iki farklı sistemde aynı ada sahip olabilir (örneğin, her Unix benzeri sistemde "kök" kullanıcı vardır). Bu yüzden kullanıcı adı iyi bir nonce değildir (ancak yine de hiçbir istemci nonce'ye sahip olmaktan daha iyidir).
Özetle, istemci nonce istemciyi bir tekrar saldırısından korumakla ilgilidir ("sunucu" aslında saldırmak istediği her istemciye aynı görevi gönderecek bir saldırgandır). Zorluk, güçlü sunucu kimlik doğrulaması (SSL gibi) içeren bir kanal üzerinden yürütülürse buna gerek yoktur. Parola Doğrulamalı Anahtar Değişimi , a priori güvene (SSL istemcisi SSL sunucu sertifikasının kimliğini doğruladığında "kök sertifika") gerek kalmadan istemci ve sunucu arasında karşılıklı parola tabanlı kimlik doğrulaması sağlayan gelişmiş protokollerdir. aktif ve pasif saldırganlara karşı (tek bir parola üzerinde "iki haftalık küme" saldırısı dahil, bu nedenle yukarıdaki protokolden kesinlikle daha iyi, nonce veya noce yok).
Sorunuzun etine yanıt vermeye çalışayım: "Saldırganın ortadaki bir adam saldırısına girmek istemediğini ve kimlik doğrulama ayrıntılarını kurtarmak istediğini varsayarsak, bir ek bilgi nasıl ek sağlar? koruma?"
Tipik olarak bir istemci sadece istekle bir nonce içerir, ancak işaretleri tüm istek, nonce dahil. Bu, saldırgan istemci ve sunucu arasında bir iletiyi kesse bile:
- Bir tekrar saldırısı işe yaramaz (çünkü sunucu istemci nosyonlarını takip eder).
- Saldırgan sadece yeni istemci nonce ile yeni bir mesaj oluşturamaz, çünkü sign yeni iletiyi uygun şekilde (yani istemci sırrından veya özel anahtardan yoksundur).
RFC 2617 'a göre, cnonce ve nc parametreleri seçilen düz metin saldırılarına karşı koruma sağlar. Bu, bu tür saldırılara karşı nasıl koruma sağlar?
Havva nonce'yi değiştirirse, sunucu istemciye Havva'nın ne kazandığını gönderir? Eve h(password || nonce) 'den h(password || fake_nonce) üretemez ve teorik olarak sunucunun h(password || fake_nonce) _ini kabul etmemesi gerekir, çünkü sunucu hangi nonce'nin yayınlandığını bilmelidir ve ne nonce değil.
Bence, nonce değerinin Oauth gibi bir şeyde nasıl kullanıldığını okumak iyi bir fikir olacaktır. Kısacası, OAuth kullanan bir uygulama OAuth destekli bir hizmet için istekte bulunduğunda, isteğin ikisi zaman damgası ve nonce olan bir grup alan içermesi gerekir. açıktır: sunucunun mesajın eski olup olmadığı konusunda daha iyi bir tahmin yapabilmesi için mesajın gönderildiği zaman diliminin bir göstergesidir.
Tüm OAuth üstbilgisi tüketici sırrı ile karma hale getirildiğinde, bu alanların her ikisi de dahil edilir. Ardından, isteğe eklenmiş (sorgu parametreleri veya HTTP üstbilgileri olsun) imzası vardır ve İsteğin gerçek gövdesi karma değil.
OAuth sunucusu, yeniden kullanılmadığından emin olmak için belirli bir istemcinin önceki N nonce değerleri kümesini izlemelidir. İletinin gövdesinin değişebileceği göz önüne alındığında (aslında hiç karma üzerinde etkisi) isteklerin benzersiz olduğundan emin olmak için değişecek başka bir şeye sahip olmak önemlidir (örn. nonce) HTTP'nin açık/düz metin yapısı göz önüne alındığında, bu oldukça önemlidir.
Bu amacını netleştirmeye yardımcı olur mu? (umarım :)).