it-swarm-tr.com

API sırrının düz metin olarak saklanması veya şifresinin çözülebilmesi uygun mudur?

Değil API keys kullanıcı adları olarak kabul edildi ve API secrets şifreleri düşündünüz mü? Amazon Web Services gibi API sunucuları neden API sırrınızı düz metin olarak görüntülemenize izin veriyor? Düz metin olarak veya en azından şifresi çözülebilen bir biçimde sakladıklarını düşündürüyor.

API sırları oluşturmak için girmeniz gereken şifreler olarak ele alınıp daha sonra size düz metin olarak teslim edilmek yerine veritabanında karma yapılması daha iyi olmaz mı? Herhangi bir nedenle API gizli veritabanlarının güvenliği ihlal edilmişse, API'lerini kullanan birçok uygulama için sel kapılarını kolayca açacaktır. Bununla birlikte, şifresi çözülemeyen bir şekilde karıştırılmışsa, her şey kolayca kaybolmaz.

36
IMB

Hayır. API anahtarlarının açık metin olarak saklanması gerekir.

Bunlar şifre değil: kriptografik anahtarlar. Bu anahtarlar, isteklerin kimlik doğrulaması (SHA1-HMAC kullanarak) gibi şeyler için kullanılır. Şifreleme algoritmalarını uygulamak için sunucunun kripto anahtarını bilmesi gerekir.

Bu nedenle, API anahtarının sunucuda açık metin olarak saklanması gerekir. Sunucu API anahtarının yalnızca bir karmasını depoladıysa, istemciden gelen iletilerin gerçekliğini doğrulayamadı veya istemciye gönderilen iletileri doğrulayamadı.

17
D.W.

Hashing depolama değildir; verileri geri döndürülemez şekilde yok eder. Parola hashini "parola depolama" olarak çağırabiliriz, çünkü gerçekten parolaya ihtiyacımız olduğunda, yazmak için kullanışlı bir insan operatöre sahibiz. girilen şifreyi doğrulamak için yeterli.

Bir API anahtarı, katılımsız biçimde tekrar kullanılabilecek şekilde saklanmalıdır. Sunucu, bir hayaletini hatırlamak yerine gerçekten store olmalıdır, çünkü API'ya erişmek için orijinal anahtara ihtiyaç duyar.

13
Tom Leek

API jetonlarını hash etmek daha güvenli olsa da, bir kullanılabilirlik sorunu sunar: jetonlar uzun ve rastgele ve hashlamadan önce kullanıcıya sadece bir kez söylenmelidir. Bu onları bir karma ile sabitlemeyi biraz zorlaştırır.

Güvenli bir senaryo için önerim şudur:

  1. Rastgele bir salt değeri oluşturun ve bunu veritabanında saklayın. Bu tuz kullanıcının şifre tuzuna eşit olmamalıdır.
  2. Kullanıcının düz metin parolasını alın ve KDF(password, salt) hesaplayın; burada KDF, bcrypt gibi bir anahtar türetme işlevidir. Ortaya çıkan değeri k olarak adlandırın.
  3. Bir API anahtarı oluşturun.
  4. Anahtar olarak k kullanarak API anahtar değerini AES ile şifreleyin ve şifreleme metnini veritabanında saklayın.
  5. Düz metin API anahtarını ve k öğesini atın.

Kullanıcı oturum açtığında, webapp şifresini bilir ve daha sonra API anahtarının şifresini çözmek ve onlara göstermek için kullanılan k değerini hesaplamak için kullanır.

Kullanıcı API'yı kullanmak istediğinde, SSL üzerinden k ve düz metin API anahtarını göndermelidir. Webapp daha sonra k kullanarak saklanan API anahtar değerinin şifresini çözebilir ve verilen API anahtarıyla karşılaştırabilir. Eğer eşleşirlerse, geçerlidir. Bu, uygulamanın kullanıcının şifresini saklamasına gerek kalmadan API anahtarı kullanımına izin verir.

Bir saldırgan veritabanını ihlal ederse, k hesaplamak için kullanıcının şifresini kırmalıdır.

9
Polynomial

Burada biraz karışıklık var gibi görünüyor ve diğer yerler , bu yüzden bu yanıtı diğer kullanıcılar için durumu açıklığa kavuşturacak şekilde ekliyorum.

Kullanılabilecek iki tür API sırrı vardır.

Bu sayfadaki cevapların çoğunun tartıştığı kullanım örneği, HMAC gibi bir algoritma kullanarak iletileri imzalamak ve doğrulamak için kullanılan gizli bir anahtardır. Bu durumda, hem istemci hem de API, iletinin imzasını oluşturmak için anahtarın gerçek değerine ihtiyaç duyar. Sunucu daha sonra oluşturduğu imzayı, istemcinin gönderdiği imzayla karşılaştırır ve iletiyi doğrulayabilir. Yukarıda belirtildiği gibi, orijinal anahtar sunucuda çoğaltılamazsa, bu çalışmaz. Anahtarı ilk olarak istemciyle (şifreli bir kanal üzerinden) paylaştıktan sonra, anahtarın istemci ve sunucu arasında bir daha iletilmesi gerekmez.

Diğer yaygın API istemcisi sırrı yalnızca gizli bir kimlik bilgisidir (tipik bir OAuth2 erişim belirteci isteğinde görebileceğiniz gibi). Bu kimlik bilgisi her istek üzerine iletilir ve bu nedenle yalnızca şifrelenmiş bir kanal (HTTPS gibi) üzerinden iletilmelidir. Bu durumda, sunucunun yalnızca istemci tarafından sağlanan gizli değerin doğru olduğunu doğrulamak için yeterli bilgiyi tutması gerekir, bu nedenle sırrı hashedebilir ve hash edilmelidir. Bu durumda, sır etkili bir şekilde parola görevi görür ve bu nedenle aynı önlemler alınmalıdır.

Feragatname: Ben bir güvenlik araştırmacısı değilim ve bu StackExchange'teki tavsiyeleri körü körüne takip etmeden önce kesinlikle bu ve herhangi bir konuda daha fazla araştırma yapmalısınız.

tl; dr En önemli paket, farklı API'ların sırrı farklı şekillerde kullanabilmesidir. API'nızı depolamak için en iyi uygulamaları değerlendirmek amacıyla istemci sırrını nasıl kullandığını anlamak önemlidir.

8
Nick Sloan

Henüz bahsedilmeyen bir konu nedeniyle kendi iki sentimi koymak. Özellikle, @NickSloan'ın söylediklerine katılıyorum, ancak bir uyarı daha.

Bir API anahtarı ile şifre arasında bir önemli fark daha vardır. API Anahtarları sitenize özgüdür. Parola güvenliğini bu kadar kritik hale getiren kısım parola paylaşımıdır. Birisi bir kullanıcının sitenize kaydettiği şifreyi ele geçirirse, güvenliği ihlal edilen yalnızca siteniz değildir: kullanıcının bu şifreyi (ve e-posta/kullanıcı adı) kullandığı diğer her sitedir. Birçok kişi, kritik sitelerdeki şifreleri yeniden kullanır: bankalar, sosyal medya, e-posta vb. Bu, iyi şifre güvenliğinin sitenize erişimi korumakla değil, diğer sitelerdeki kullanıcılarınızı korumakla ilgili olduğu anlamına gelir. Kullanıcıları güvenliği daha iyi yapmaya zorlayamayız, bu yüzden en kötüsünü varsaymalı ve kendi gizliliklerini korumak için ek adımlar atmalıyız.

Bir API Anahtarı tamamen farklı bir senaryodur çünkü sitenize özgüdür. Sonuç olarak, çalınması durumunda saldırgan sitenize erişim kazanır, ancak o kişinin bankasına/e-postasına/vb. Bu, API anahtarları için risk düzeyinin aslında şifrelerden daha düşük olduğu anlamına gelir. Aynı top parkında değiller: API anahtarları, oturum tanımlayıcılarına şifrelerden daha yakındır.

Bunların oturum tanımlayıcılarına şifrelerden daha yakın olduğunu anlamak, bu tür anahtarların nasıl düzgün bir şekilde korunacağına dair bazı pratik bilgiler verir. Aşağıdaki tartışmanın, şifreleme kimlik bilgileri için değil OAuth kimlik bilgileri gibi şeyler için API Anahtarları için geçerli olduğunu unutmayın (yanıtında @NickSloan tarafından tartışıldığı gibi).

Parolalara yönelik en büyük tehdit, kimlik avı saldırıları ve saldırıya uğramış veritabanlarıdır, bu nedenle bunları veritabanlarımızda karma olarak saklarız. API anahtarlarına yönelik en büyük tehditler oturum anahtarlarıyla aynıdır: XSS güvenlik açıkları, MIM ve benzeri gibi ön uç uygulamalarındaki zayıflıklar. Ön uç uygulamasının şifrelenmemiş biçimde parolaya ihtiyacı olduğunu unutmamak önemlidir, bu nedenle API anahtarının karıştırılması, çalınması en muhtemel kişi düz metne ihtiyaç duyduğunda size hiçbir şey kazandırmaz.

Bunun yerine, öncelikle istemciyi takip ederek bir oturum tanımlayıcısını (veya OAuth belirteci veya istemciye özgü API anahtarı) korursunuz. Bir oturum tanımlayıcısı XSS ​​veya istemciden başka bir yolla çalınırsa Tipik bir sonuç, bu tanımlayıcının saldırgan tarafından yeni bir cihazda kullanılmasıdır.Bu, aniden yeni bir kullanıcı aracısıyla birlikte eski bir anahtar göreceğiniz anlamına gelir.Bu tür bir değişikliği tespit etmek ve düzeltmek kolaydır: Özellikle tüm API anahtarlarını geçersiz kılar.Özellikle OAuth istekleri durumunda, bu kullanıcı için çok acısızdır: sadece tekrar giriş yapıp hemen yeni bir tane alırken, sadece anahtarı çalan biri (ve parolaya sahip değil) çizim tahtasına geri döner.

Bu, daha akıllı bir bilgisayar korsanının çalınan anahtarla ilişkili kullanıcı aracısını kaydetmeye ve gelecekteki tüm isteklerde kullanmaya çalışmasına yetecek kadar yaygın bir savunma önlemidir, ancak aynı kullanıcının istekleri olduğunda balıkların devam ettiğini kolayca görebilirsiniz. birden fazla IP Adresinden. Dünyadaki diğer her şey gibi, bu da biraz kedi ve fare oyunu olabilir, ancak bazı önemli çıkarmalar var:

  1. Bir API Anahtarı/OAuth Jetonu/Oturum Kimliği gerçekten belirli bir cihazdaki bir kullanıcıyı hatırlamanın bir yoludur, bu nedenle şifrelerini her sayfaya koymaları gerekmez. Sonuç olarak, şüphe duyduğunuzda, tüm yetkili anahtarları öldürebilir ve kullanıcıyı tekrar oturum açmaya zorlayabilirsiniz.
  2. Her üç durumda da, Key/Token/ID'nin kaybedilmesi bir hesabın tehlikeye atılmasına yol açtığından, bu şeyler etrafında bazı aktif güvenliklere sahip olmak ve balıklı bir şey olup olmadığını tespit etmek/yanıtlamak önemlidir. Meksika'dan hesabınıza giriş yapmaya çalışan biri hakkında facebook/google/etc'den bildirimler aldıysanız, bunun nedeni bir yerdeki güvenlik görevlisinin işini doğru yapmasıdır.
  3. Anahtarlar/Simgeler/Kimlikler için birincil saldırı vektörleri, parolalardan farklıdır. Yine de bunları veritabanınıza hash etmek isteyebilirsiniz (yine, düz metin olması gereken şifreleme kimlik bilgilerinden bahsetmiyoruz), ancak bunları veritabanınıza hash edip kendinizi güvenli olarak çağıramazsınız. Bunları yepyeni bir saldırı vektörlerine karşı emin olmanız ve güvence altına almanız gerekir. Bunları yalnızca şifreler olarak düşünüyorsanız, büyük resmin bazı önemli kısımlarını kaçırırsınız.
5
Conor Mancone

Parolaların saklanmadan önce özetlenmesinin ana nedenlerinden biri, veritabanına salt okunur erişim sağlayan bir saldırgana karşı koruma sağlamaktır . Bu şekilde, bir saldırgan oturum açma kimlik bilgileri listesini tutarsa, parolalar karma/tuzlu olduğu için bunları doğrudan kullanamazlar.

Ve bu sadece burada çözmeye çalıştığımız teorik bir sorun değil, bu tür saldırılar gerçekten gerçekleşiyor ( endüstri ) ve uygun karma işlemi, bir saldırının etkisini azaltmaya yardımcı olur.

Kullanıcıların bir API sırrı kullanarak kimlik doğrulaması yapmasına izin veriyorsanız, API sırrı etkili bir şekilde bir şifre haline gelmiştir, bu nedenle güvenlik açısından aynı olmalıdır. normal parolalar gibi koruma mekanizmalarına sahiptir.

Amazon'un kendisi şimdi API sırrının alınmasına izin vermiyor . Unutursanız, yeni bir tane istemeniz gerekir.

2
Pedro Rodrigues

Hayır, bir çeşit hizmet için uygun değil.

ygulama

1. Giriş şifresi ile kullanıcı bağlantısı kurulduğunda, bu kullanıcı için verileri şifrelemek ve sunucudaki bir oturumda tutmak için şifresinden türetilen bir anahtar oluşturun.

Bu şekilde, her kullanıcının benzersiz bir anahtarı olacaktır. Bu türetilen anahtar tersinir olmamalıdır, ana nokta budur. Hash_mac veya tuz ve/veya ana anahtar ile başka bir karma yöntemi kullanmak buna izin verecektir.

2. Her kullanıcı için rastgele bir iv ile AES 256 kullanarak oluşturulan API Sırrını şifrelemek için bu anahtarı kullanın.

Veya

2.bis En son anda gerçek şifreleme anahtarını oluşturmak için bu anahtarı kullanın ve bellekte yüzen parolalardan kaçınmak için API yöntemini 2. ile aynı şekilde şifreleyin.

. iv'yi, kullanıcı kimliği ve uygulama kimliği ile birlikte veri tabanında özel bir tabloda depolayın

4. Şifrelenmiş API Sırrını veritabanında uygun tabloda saklayın.

Kullanımı

Artık kullanıcı kontrol paneline bağlandığında, anahtarı yeniden oluşturabilir, iv'i alabilir, bu kullanıcı için API Sırrı'nın şifresini çözebilir ve açık metin olarak görüntüleyebilirsiniz. Ayrıca, anahtarı görüntüleyebilir ve API Çağrısı yaparken her ikisini de sorabilirsiniz, böylece App Secret'ı doğrulayabilirsiniz.

Anahtarı görüntülemek istemiyorsanız ve API çağrısında talep etmek zorunda kalmazsanız, kimlik doğrulama için giriş için aynı yöntemi kullanabilirsiniz. Yani her istemci uygulaması için rastgele bir anahtar/tuz depolamak ve API Secret'ın hash_mac sürümünü saklamak için başka bir tablo oluşturabilirsiniz. Bu nedenle, API İsteğini doğrulamak için yalnızca API Kimliği ve API Sırrı gereklidir. ama daha çok iş.

Not

Bu pratik olarak @Polynomial cevapla aynıdır.

Bu şekilde, sunucunuzu ve veritabanınızı hackleyen birisinin kullanıcı kimlik bilgilerinizi çalması ve onların adına API çağrısı yapması çok zordur. Artık bir istek bir API istemcisinden kabul edilirse doğru istemci veya sızıntı olduğunu değerlendirebilirsiniz.

Kullanıcı şifresini kaybederse, yeni şifresinden yeni bir API Sırrı ve Anahtarı yeniden oluşturursunuz.

0
Nicolas Manzini