API Kimlik Doğrulaması, Bir kerelik belirteç VS Dinamik belirteçleri


13

Yeni bir proje üzerinde çalışıyoruz, iki lider geliştiriciyiz ve sunucu ile istemci arasındaki iletişimi sağlamak için bir token nasıl kullanılacağına dair bir yol ayrıyoruz.

İlk Öneri: (Bir kerelik AKA Statik Jetonu)

  1. istemci, kullanıcı adını ve parolayı ve geçerli_adı (bu değişken sunucunun veritabanına ve istemci tarafına da kaydedilecek) API'ye göndererek birincil jeton ister, sunucu girişi yorumlar ve karma bir jeton oluşturur (örn:: 58f52c075aca5d3e07869598c4d66648) veritabanına kaydeder ve istemciye döndürür.

  2. İstemci artık birincil jetonu kaydediyor ve birincil jetonu + kimlik doğrulama isteğinde gönderilen current_time değişkenini kullanarak yeni karma jeton oluşturuyor (bu yeni jeton, main_token diyelim) ayrıca sunucu aynı şeyi yapıyor ve aynı jetonu kullanarak aynı jetonu oluşturuyor .

  3. İstemci sunucu API'sını her sorguladığında, main_token'i sunucuya gönderir, şimdi sunucu içinde oluşturulan belirteci karşılaştırır, istemci tarafından gönderilen main_token ile eşleşirse, kullanıcının gerçek olduğu anlamına gelir

İkinci Öneri: (Dinamik Simge)

  1. İstemci iki rastgele anahtar oluşturur ($ key1 = rand (10000,90000); $ key2 = rand (10000,90000);) API üzerindeki her istekte, istemci sorgu türünü kullanarak bir karma oluşturur ve iki anahtar karmaşık bir algoritmadır ve bu iki anahtarı + karmayı sunucuya gönderir

  2. İstemcide kullanılan aynı Algoritmayı kullanan sunucu, bir karma oluşturur ve istemci tarafından gönderilen ile karşılaştırır, eşleşirse, sunucu sorguyla ilgilenmeye devam eder


Şimdi soru şu: Hangisi API isteklerini korumak için en mantıklı ve güvenli yol?


2
İkincisi bir kimlik doğrulama aracı nasıl? Orada gereken yetkilendirme tekniğindeki müşteri kullanımları aksi istemci sadece anahtarı uydurduysam bilmenin bir yolu yoktur sunucudan şey menşeli olması. İkinci teknikte, giriş istemcinin istemciye verdiği ile aynı olduğunu garanti etmek için istemciye verdiği sunucu ne tür bir kaynak oluşturur?
Jimmy Hoffa

1
Belki bir şey eksik ... ama neden kimlik doğrulama mekanizması olarak OAuth kullanmıyorsunuz? Bu standarttır ve müşterilerinizin hemen hemen her dilde kullanmaları için kütüphaneler olacaktır.
Icode4food

Yanıtlar:


14

Genel olarak ilk yaklaşımı gerçekten seviyorum.

  • anlamak ve uygulamak basit
  • güvenli (bilgime göre)
  • geçmişte kullanıldığını gördüğüm nadir olmayan bir yaklaşım

Aklınızda bulundurmanız gereken ilk şey hakkında bahsetmediğim bir şey, jetonu hash etmek için kullanılan zaman damgasının son derece kısa (1 saniye gibi) bir TTL süresinin dolması gerekiyor, böylece mesajın gönderilmediğini doğrulayın 12 saat önceki mesajdan aynı zaman damgası ve jeton; açıkçası yasal olarak hesaplanacaktır ancak bu durumda değildir.

Eğer bunlar düşündüğünüz tek seçenekse, diğer yaklaşımlara da baktığınızdan emin olmak istiyorum, çünkü çok fazla var. Aslında listelediğimden daha fazlası. Bunlar, sadece amacınıza daha uygun olup olmadıklarını görmek için çalışmaya değer bazı ortak kimlik doğrulama yaklaşımlarıdır ve bunları anlayan başka bir şey size hangi yaklaşımı uygularsanız sıkılaştırmanıza yardımcı olacak bazı fikirler verebilir.

Notu yap, ben değil bir güvenlik uzmanı.


OAuth / Federe

Bu yaklaşımda, tüketen kodun jeton / sertifika / onlardan ne istediğini ve size ilettiği bir 3. taraf garantiniz var, bu noktada yapmanız gereken tek şey size verilen anahtarın 3. tarafa sorulmasıdır. okunaklı.

Pro:

  • Standartlara dayalı
  • Sorunlar başkaları tarafından başkalarının sistemlerinde bulunacak, böylece güvensizliğin olup olmadığını öğreneceksiniz
  • Çok daha az yetkilendirme çalışmasına ihtiyacınız olacak

con:

  • Bir üçüncü taraf hizmet sağlayıcısı ve API'larıyla ilgilenmeniz veya yetkilendirmeyi ana hizmetinizden ayırmak için kendi "3. taraf" ınızı oluşturup barındırmanız gerekir.
  • Birçok hizmet için aşırı, ancak kavramsal olarak dikkate değer

Eşzamansız Sertifikalar

Burada müşterilerinize iletişim kurduklarında, kullanıcı oluşturduklarında onlarla paylaştığınız herkese açık bir sertifika ile şifreleme yaparsınız. Yanınızda, o kullanıcı ile ilişkili özel anahtarın şifresini çözersiniz. Genellikle iletişimi, kim olduğunu iddia ettikleri gibi tanımlamayı beklediğiniz gibi şifreleyebileceğini / şifresini çözebileceğini göstermek için bir meydan okuma yanıtıyla başlatacaksınız. Zorlu yanıtı kullanmayan "eşzamanlı" yaklaşımlar mümkün olsa da, biraz daha az güvenlik ve onları daha zor hale getirebilecek bazı zaman senkronizasyonu sorunları vardır.

dan Novell (evet gerçekten? novell, biliyor musunuz?)

Jetonlar, bir kerelik parola oluşturmak için bir değişken kullanır. Bu değişkene meydan okuma denir. Parolayı oluşturmak için kullanılan değişkeni belirlemek için iki ana yöntem eşzamansız veya eşzamanlıdır.

Zaman uyumsuz veya sınama yanıtı yöntemiyle, sunucu yazılımı, belirteç aygıtının şifrelemesi için belirteci harici bir sorun (rasgele oluşturulmuş bir değişken) gönderir. Belirteç, bu meydan okuma değişkenini, şifreleme algoritmasını ve paylaşılan sırrı, yanıtı doğru şekilde şifrelenmiş parolayı oluşturmak için kullanır.

Eşzamanlı yöntemle, parolayı oluşturmak için kullanılan meydan okuma değişkeni dahili olarak belirteç ve sunucu tarafından belirlenir. Her değişken içindeki zaman sayacı, olay sayacı veya zaman ve olay sayacı kombinasyonu, meydan okuma değişkeni için temel olarak kullanılır. Simge ve sunucunun her biri ayrı ayrı ve dahili olarak meydan değişkenini kendi sayaçlarından belirlediğinden, zaman sayaçlarının ve olay sayaçlarının senkronize kalması çok önemlidir. Sunucu ve simgenin senkronizasyondan çıkması çok kolay olduğundan, çoğu uygulama sayaçlar arasında belirli bir miktar kaymaya izin verir. Genellikle, bu sayaç değerlerinin küçük bir aralığı veya penceresi şifreyi hesaplamak için kullanılır. Ancak, belirteç ve sunucu bu pencerenin ötesinde senkronizasyondan çıkarsa,

Pro:

  • Sertifikaların güvenilir ve güvenilir olmasını sağlayan CA kökleri vardır
  • İşletim sistemlerinde sertifika depolarını kolayca yönetmek ve bakımını yapmak için standart tesisler vardır
  • İyi çalışılmış bir yaklaşım, üzerinde çok fazla bilgi mevcut
  • Son kullanma tarihi, çeşitli diğer şeylerle birlikte standart sertifikaların yerleşik tesisleridir, genellikle sağlamdır

con:

  • Sertifikalar programlı olarak çalışmak zor olabilir
  • Harici bir CA'ya ihtiyacınız olup olmadığına bağlı olarak, ücretsiz olmayabilir
  • Beklenen kök güvenlerin yapılandırıldığından emin olmak için sertifika depolarını el ile tutması gerekebilir

NTLM

Bu daha küçük veya yalnızca dahili bir hizmetse ve bir Windows ortamındaysanız gülmeyin, erişimi garanti etmek için standart NTLM kimlik doğrulamasını kullanmanın yanlış bir yanı yoktur. Özellikle IIS ile çalışıyorsanız, bu en basit yaklaşımdır. Bir web.config dosyasında bakımı ve yapılandırması kolaydır.

Pro:

  • Yapılandırması, uygulanması ve bakımı son derece kolaydır

con:

  • Minimum birlikte çalışabilirlik
  • Halka açık kimlik doğrulaması için yeterli değil

Nonce'lar

Kimlik doğrulama yaklaşımınızda nonces ile çalışırken, hizmette nonce alma yöntemini sağlarsınız. Bu yöntem, her istekte benzersiz bir rastgele dize veya veri parçası ("bir nonce") döndürür. Diğer yöntemlere yapılan her istek artık bir nonce öğesinin alınmasını ve istek için kripto algoritmasında kullanılmasını gerektirir. Buradaki değer, sunucunun kullanılan nonces'leri izlemesi ve bir nonce'nin tekrar kullanılmasına izin vermemesidir, bu, bir nonce ile bir istek yapıldığında, bu nonce ile bir daha asla bir daha yapılamaz. Nüfus talep edildiğinden, kullanılabilir nosyonlar listesine eklenirler, kullanıldıkları için mevcut listeden kullanılan listeye taşınırlar.

Pro:

  • Thwarts saldırıları oldukça iyi tekrar ediyor
  • Uygulanması veya anlaşılması tamamen zor değil

con:

  • İstemcilerin her bir istek için iki istekte bulunmalarını gerektirir (ancak yalnızca belirli istekler için nonces gerektirerek azaltılabilir )
  • İşlemsel olması gereken nonces yönetimini gerektirir
  • Nonces için ekstra talepler talep ederek performansı olumsuz yönde etkiler (işlemsizlik, nonces ile çalışmanın kaynak maliyetini daha da artırır)

Bir dakikadan kısa olsa da TTL'nin bir saniyeden uzun olması gerektiğinden şüpheleniyorum (HTTP / HTTPS'yi taşıma olarak varsayarak). TTL, aktarımın gecikmesine bağlıdır (yani, e-posta için doğrudan bağlantıdan çok daha uzun).
Donal Fellows

1
Kerberos'u unuttun . Ve sorunun önerdiği gibi kendi kimlik doğrulama / jeton paketinizi yuvarlamaya karşı son derece güçlü bir uyarı verirdim. RYO yetkisi yanlış anlaşılması çok kolaydır; bir örnek, sadece 80.000 5 basamaklı sayısal değere sahip bir tohumlama anahtar alanı kullanmaktır (OP'nin 2. durumundan). Ayrıca kullandığınız karma değerlere (1. durumdan) dikkat etmelisiniz. Birçoğu şimdi gökkuşağı masa aramalarından önemsiz bir şekilde kırıldı.

1
Cevabınız için çok teşekkür ederim, bu projeden taşındım, ancak bu soruyu favorilerimde tutacağım. Çok kapsamlı olduğu için cevabınızı kabul etmediğim için üzgünüm. Peki, novell'in kötü olmasından ne haber? :(
SAFAD

@SAFAD Novell hakkında kötü bir şey değil, Novell'den modern bir şey bulduğum için güvenlik detaylarıyla ilgili kaynaklara bakarken atıldım, şirketin eskiden eskiden öldüğünü sanıyordum. uzun zaman önce. Kabul etmeyi takdir ediyorum, yukarıdaki Glen'in daha kapsamlı olabileceğinden bahsediyordu, ancak normal yaklaşımlara basit bir genel bakış sunmaya çalıştım. Kerberos oldukça büyük bir gözetim ve iyi bir seçim ... belki de şimdi ekleyeceğim ..
Jimmy Hoffa
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.