OAuth belirteçleri oluşturmaya ilişkin en iyi uygulamalar?

Farkındayım OAuth Spec ConsumerKey, ConsumerSecret, AccessToken, RequestToken, TokenSecret veya Doğrulayıcı kodu kökeni hakkında bir şey belirtmez, fakat (özellikle Token önemli ölçüde güvenli belirteçleri oluşturmak için en iyi uygulama varsa merak ediyorum / Gizli kombinasyonlar).

Gördüğüm kadarıyla, token oluşturmak için birkaç yaklaşım var:

1. Sadece rastgele baytlar kullanın, tüketici / kullanıcı ile ilişkili veritabanında saklayın
2. Kullanıcı / tüketiciye özgü bazı verileri karma hale getirin, tüketici / kullanıcı ile ilişkili veritabanında depolayın
3. Kullanıcıya / tüketiciye özel verileri şifreleyin

(1) 'in avantajları, en güvenli görünen bilgilerin tek kaynağı veritabanıdır. Saldırı yapmak (2) veya (3) 'ten daha zor olurdu.

Gerçek verilerin karma haline getirilmesi (2), jetonun muhtemelen zaten bilinen verilerden yeniden üretilmesine izin verecektir. Zaten depolamak / aramak gerekeceğinden (1) 'e gerçekten herhangi bir avantaj sağlamayabilir. (1) 'den daha yoğun CPU.

Gerçek verilerin şifrelenmesi (3), şifre çözmenin bilgileri bilmesine izin verir. Bu, (1) ve (2) 'den daha az depolama ve potansiyel olarak daha az arama gerektirir, ancak potansiyel olarak daha az güvenli de olacaktır.

Dikkate alınması gereken başka yaklaşımlar / avantajlar / dezavantajlar var mı?

DÜZENLEME: Başka bir husus, Jetonlarda bir tür rastgele değer OLMALIDIR, çünkü yeni jetonların süresinin dolması ve yeniden yayınlanması yeteneği olması gerektiğinden, yalnızca gerçek verilerden oluşmaması gerekir.

Soruları Takip Edin :

Kriptografik olarak önemli ölçüde güvenli hale getirmek için minimum Token uzunluğu var mı? Anladığım kadarıyla, daha uzun Token Sırları daha güvenli imzalar oluşturacaktır. Bu anlayış doğru mu?

Hashing açısından belirli bir kodlamayı diğerine göre kullanmanın avantajları var mı? Örneğin, onaltılık kodlamalar kullanan birçok API görüyorum (örn. GUID dizeleri). OAuth imzalama algoritmasında, Token bir dize olarak kullanılır. Onaltılık bir dizeyle, mevcut karakter kümesi Base64 kodlamasından çok daha küçük (daha tahmin edilebilir) olacaktır. Bana öyle geliyor ki, eşit uzunluktaki iki dizge için, daha büyük karakter kümesine sahip olanın daha iyi / daha geniş bir karma dağılımı olacak. Bu bana güvenliği artıracak gibi görünüyor. Bu varsayım doğru mu?

OAuth spesifikasyonu bu sorunu 11.10 Entropy of Secrets'da gündeme getiriyor .

OAuth, kendisiyle ilişkili bir sırrı olması dışında jeton hakkında hiçbir şey söylemez. Yani bahsettiğiniz tüm planlar işe yarayacak. Jetonumuz, siteler büyüdükçe gelişti. İşte daha önce kullandığımız versiyonlar,

1. İlk jetonumuz, kullanıcı adı, jeton sırrı ve son kullanma tarihi vb. İle şifrelenmiş bir BLOB'dur. Sorun, ana bilgisayarda herhangi bir kayıt olmadan jetonları iptal edemememizdir.

2. Bu yüzden, her şeyi veritabanında saklamak için değiştirdik ve jeton, veritabanının anahtarı olarak kullanılan rastgele bir sayıdır. Bir kullanıcı adı dizini vardır, bu nedenle bir kullanıcı için tüm jetonları listelemek ve iptal etmek kolaydır.

3. Oldukça az sayıda bilgisayar korsanlığı etkinliği alıyoruz. Rastgele sayı ile, belirtecin geçerli olup olmadığını bilmek için veritabanına gitmemiz gerekir. Bu yüzden tekrar şifrelenmiş BLOB'a geri döndük. Bu sefer, jeton yalnızca anahtarın şifrelenmiş değerini ve son kullanma tarihini içerir. Böylece veritabanına gitmeden geçersiz veya süresi dolmuş tokenları tespit edebiliriz.

Size yardımcı olabilecek bazı uygulama ayrıntıları,

1. Jetona bir sürüm ekleyin, böylece mevcut olanları bozmadan jeton biçimini değiştirebilirsiniz. Tüm belirteçlerimizin sürüm olarak ilk baytı vardır.
2. BLOB'u kodlamak için Base64'ün URL güvenli sürümünü kullanın, böylece URL kodlama sorunlarıyla uğraşmak zorunda kalmazsınız, bu da OAuth imzasıyla hata ayıklamayı daha zor hale getirir, çünkü üçlü kodlanmış basestring görebilirsiniz.