Soru:
BASIC-Auth HTTPS üzerinden yapılırsa güvenli midir?
Morten
2010-12-06 04:42:45 UTC
view on stackexchange narkive permalink

Bir REST-API yapıyorum ve basit bir BASIC kimlik doğrulama girişi yapmak. Sonra HTTPS'nin bağlantıyı güvenli hale getirmesine izin verin, böylece api kullanıldığında şifre korunur.

Bu güvenli kabul edilebilir mi?

Evet, http kullanıcısı / şifresi SSL üzerinden geçtiği için uygun olacaktır, ancak şifrenin güçlü olması gerekir.
Pekala, sunucuma çok fazla parola deneyen bir istemciyi yasaklayan bir mantık koyabilirim. Bu, DoS ve şifre tahminini engeller mi?
Dokuz yanıtlar:
AviD
2010-12-06 05:18:48 UTC
view on stackexchange narkive permalink

HTTP Temel Kimlik Doğrulama ile ilgili birkaç sorun vardır:

  • Şifre, tel üzerinden base64 kodlamasında gönderilir (bu, kolayca düz metne dönüştürülebilir).
  • Şifre, her istek için tekrar tekrar gönderilir. (Daha büyük saldırı aralığı)
  • Parola, pencere / işlem süresi boyunca en azından web tarayıcısı tarafından önbelleğe alınır. (Sunucuya gönderilen diğer herhangi bir istekle sessizce yeniden kullanılabilir, örneğin CSRF).
  • Kullanıcı isterse şifre tarayıcıda kalıcı olarak saklanabilir. (Önceki noktayla aynı şekilde, ayrıca paylaşılan bir makinede başka bir kullanıcı tarafından çalınabilir).

Bunlardan SSL kullanmak yalnızca ilkini çözer. Ve bununla bile, SSL yalnızca web sunucusu - herhangi bir dahili yönlendirme, sunucu günlüğü vb. Düz metin parolayı görene kadar korur.

Yani, her şeyde olduğu gibi resmin bütününe bakmak önemlidir.

HTTPS geçiş sırasında şifreyi korur mu? Evet.

Bu yeterli mi? Genellikle hayır. (Her zaman hayır demek istiyorum, ancak bu gerçekten sitenizin ne olduğuna ve ne kadar güvenli olması gerektiğine bağlıdır.)

aslında, HTTP Özeti ile bile, parolanın bir karmasını elde edebilirsiniz (“md5 (kullanıcı adı: bölge: parola)`, bazen HA1 olarak adlandırılır).
@AviD ♦ Imho puanlarınız 3) ve 4) REST API'leri için nadiren geçerlidir.
Temel kimlik doğrulama durumunda, şifre tarayıcıda "saklanmalıdır" ve bu yalnızca bir çerez aracılığıyla yapılabilir ve bu hiçbir zaman güvenli sayılmaz. Burada benzer bir soru yayınladım: http://stackoverflow.com/questions/27177224/how-to-keep-state-at-the-client-safely/27177995#27177995 Benim sonucum Temel Kimlik Doğrulamanın güvenli DEĞİLDİR, Bu şekilde KULLANILMAMALIDIR ve hassas verilerin istemcide saklanması (kullanıcı şifresi gibi) bile düşünülmemelidir.
Temel Kimlik Doğrulama için @KimGysen, şifre bir çerezde iletilmez veya saklanmaz, "Yetkilendirme:" istek başlığında gönderilir ve tarayıcının belleğinin özel (korumalı) bir bölümünde saklanır. Size katılmadığımdan değil, genel durumda Temel Yetkilendirme kullanılmamalıdır, ancak değiş tokuşun uygulanabilir olabileceği bazı durumlar vardır.
İkinci nokta sorun değil. Her istekle birlikte kimlik bilgileri göndermek, arka ucunuzun durumsuz kalmasını sağlar.
"Daha geniş saldırı penceresine" ek olarak, kaba zorlamaya karşı korumak için hesap kilitleme gibi yerleşik bir mekanizma yoktur.
@Artjom: Temel kimlik bilgilerinin her istekte gönderilmesi bir sorundur, kimlik bilgilerini göndermeye devam etmeniz gerektiğinden değil, her istekte aynı dizenin gönderilmesi nedeniyle. Yetkilendirme başlığının şifresinin kullanıcının sırrına göre çözülemeyeceği ve sunucunun kullanıcının sırrını bilmeden isteği doğrulayabildiği HMAC gibi başka kimlik doğrulama mekanizmaları da vardır. Bu mekanizmada, Yetkilendirme başlığında gönderilen dize, isteğin karma değerine göre değişir.
@LieRyan Gerçekten anlamadım: - \.Aynı dizeyi göndermenin sorunu nedir?Çeşitlilik hayatın baharatı olduğu için mi?
@DavidS: tekrar saldırısı.Ayrıca, trafiğinizi bir proxy veya CDN hizmeti üzerinden geçirirseniz, bir saldırganın kullanıcının isteklerini değiştirmek için proxy / CDN'ye saldıramayacağına dair bir güvence elde edersiniz.
@Bruno, HTTP Özeti * daha kötüdür * çünkü sunucunun kullanıcı parolalarını düz metin olarak saklamasını gerektirir!
@Jacco Prensip olarak, sunucu yalnızca "md5 (kullanıcı adı: bölge: şifre)" depolayabilir ve şifreye açık bir şekilde ihtiyaç duymaz (örneğin "htdigest" ile oluşturulan bir dosyanın içeriğini kontrol edebilirsiniz).Bu, uygulamaya bağlıdır.Bununla birlikte, hala harika değil (ayrıca saldırıları Basic'e düşürmeye karşı kolayca savunmasız olmanın dezavantajı).
"Daha büyük ekleme penceresi" Çerez olarak gönderilen normal oturum belirtecinde de benzer sorun var değil mi?
@JithinJose kullanıcının şifresini içermediği gibi, statik + çok uzun süre geçerli değildir.
@LieRyan HMAC, Basic ve Digest'ten farklı olarak standart HTTP kimlik doğrulama mekanizmalarından biri değildir.[AWS tarafından uygulanan] (https://docs.aws.amazon.com/en_us/AmazonS3/latest/dev/RESTAuthentication.html#ConstructingTheAuthenticationHeader) hakkında mı konuşuyordunuz?
@LieRyan: TLS'nin bir kusuru olmadıkça, TLS ile hem tekrar oynatma hem de proxy / CDN senaryosu mümkün değildir.
Nemo
2012-07-15 08:27:07 UTC
view on stackexchange narkive permalink

Bunu şu şekilde düşünmeye çalışın: SSL kullanan herhangi bir web sitesinde oturum açtığınızda, büyük olasılıkla parolanızı HTTPS üzerinden düz metin olarak geçiriyorsunuzdur (örneğin GMail).

Tek fark Temel Yetkilendirme, kullanıcı adı / şifrenin istek gövdesi yerine (GET / POST) yerine istek başlıklarında geçirilmesidir.

Bu nedenle, temel-kimlik doğrulama + https kullanılarak HTTPS üzerinden form tabanlı kimlik doğrulamadan daha az veya daha güvenli değildir.

Bu durumlar arasında küçük bir fark vardır: http temel kimlik doğrulamasında parola * her istek * için gönderilirken, form tabanlı oturum açma ile yalnızca bir kez gönderilir ve ardından oturum tanımlama bilgisi gibi bir şey kullanılır. Bu * çok az * saldırı yüzeyini azaltır.
Kullanıcı şifresi yalnızca bir kez gönderilir, ancak kimlik doğrulama çerezi de her istekte gönderilir, bu nedenle soru yalnızca çerez yerine kullanıcı ve şifreyi göndermektir.
@deFreitas ve böylece OAuth öncülüne sahipsiniz: u / p'yi her zaman göndermek yerine kimlik doğrulaması için başka bir belirteç kullanmak.
Sanırım ufak bir fark var: POST örneğinde, kullanıcı kimlik bilgilerini girmeye ve onları geri göndermeye (güvenli bir şekilde) karar vermeden önce ilk sayfa görüntülemenin HTTPS üzerinden gönderilmesi gerekiyor.HTTP temel kimlik doğrulaması ile, sunucu HTTPS olmayan bir isteğe hizmet vermeyi ve HTTPS'ye yeniden yönlendirmeyi reddetse bile, kimlik bilgileri zaten güvensiz bir şekilde kablonun üzerinden geçmiş ve ardından MiTM gözetlemesine saygı duyulmaktadır.İstemci, başlangıçta POST HTTPS'ye karar vermeli veya güvenli olmayan bir kanalı riske atmalıdır.POST senaryosu ile bu daha az olasıdır.
@PepijnSchmitz Bir oturum anahtarının (geçersiz kılınabilen) farkının, oturum açma kimlik bilgilerinin çalınmasından büyük ölçüde farklı olduğunu belirtmek isterim.Hasar, başka bir tarafın özel oturum anahtarına sahip olduğu halde yine de verilebilir, ancak doğası gereği çok daha sınırlıdır, özellikle de anahtarı geçersiz kılmak için uygulamanızın yürütülmesi bittikten sonra API oturumunu kapatabilirsiniz.
goodguys_activate
2010-12-06 11:49:54 UTC
view on stackexchange narkive permalink

HTTPS üzerinden Temel Kimlik Doğrulama iyidir, ancak tamamen güvenli değildir. Fiddler 'ın SSL hata ayıklaması için çalışma şekline benzer şekilde, kurumsal bir HTTPS proxy, web tarayıcısı ile Proxy (IP adresi web sunucusu günlüklerinizde görünen) arasındaki bağlantıyı yönetir. Bu durumda, HTTPS şifresinin şifresi çözülür ve daha sonra kurumsal proxy'de yeniden şifrelenir.

Proxy'yi kimin yönettiğine ve günlüklerinin nasıl kullanıldığına bağlı olarak, bu sizin açınızdan kabul edilebilir veya kötü bir şey olabilir.

SSL müdahalesinin nasıl yapıldığı hakkında daha fazla bilgi için , bu bağlantıya bakın:

SSL Proxy, bir SSL bağlantısına müdahale ettiğinde, istemci tarayıcısına öykünülmüş bir sunucu sertifikası sunar. İstemci tarayıcısı, tarayıcı ProxySG tarafından kullanılan yayıncıya güvenmediği için son kullanıcıya bir güvenlik açılır penceresi verir. SSL Proxy tarafından kullanılan yayıncı sertifikası, istemci tarayıcısının sertifika deposunda güvenilir bir kök olarak içe aktarılırsa bu açılır pencere oluşmaz.

ProxySG, tüm yapılandırılmış sertifikaları kendi yönetim konsolu aracılığıyla indirilebilir hale getirir. Son kullanıcılardan sertifika veren sertifikayı Internet Explorer veya Firefox aracılığıyla indirmelerini ve seçtikleri tarayıcıda güvenilir bir CA olarak yüklemelerini isteyebilirsiniz. Bu, öykünülmüş sertifikalar için sertifika açılır penceresini ortadan kaldırır ...

Bazı şirketler, GPO aracılığıyla her iş istasyonuna kök sertifikaları (Proxy'nin) dağıtarak yukarıda belirtilen sertifika açılır sorununu aşar. Bu yalnızca Microsoft Sertifika deposunu kullanan yazılımları etkiler. Firefox gibi yazılımların farklı şekilde güncellenmesi gerekiyor.

Aslında bu, bahsettiğiniz siteye bağlıdır. Örneğin. Bankanıza iş yerinden göz atıyorsanız ve Temel Kimlik Doğrulama kullanıyorlarsa, bu işinizdeki proxy tarafından şifresi çözülmez. SSL bunun üzerinden geçer.
Bu bana mantıklı gelmiyor - hangi senaryoyu düşünüyorsunuz? Proxy'ler, tarayıcı onu gerçek uç noktayla ayarladıysa, iyi bir sertifika (veya DNSSEC veya her neyse) ile düzgün bir şekilde doğrulanmışsa, bir https oturumunun içinde ne olduğunu göremez.
Olumsuz seçmen bağlantılı belgeleri okumalıdır, çünkü bu genel olarak bilinmeyen gerçek ve geçerli bir noktadır. Dokümanlar: http://www.bluecoat.co.jp/downloads/manuals/SGOS_DG_4.2.x.pdf
Evet, haklısın - BlueCoat, işi güvensiz kılmak için FUD kullanan kurumsal kötü amaçlı yazılım gibi görünüyor.
Ve btw - Chrome, Windows Sertifika Mağazasını kullanıyor ...
Bir tür ruh bu cevabı yükseltmeli ki artık değil (-1) Bu cevap doğru, gerçek bilgi içeriyor
@AViD,, kurumsal proxy'lerin aslında kendi sertifikalarını sunarak SSL trafiğinin şifresini çözdüğü bazı durumlar vardır (bu, tüm kurumsal iş istasyonlarında güvenilir bir kök yetki sertifikası olarak içe aktarılan dahili bir kurumsal sertifika tarafından imzalanır).Şirketim bunu Gmail dahil birkaç site için yapıyor (ancak bankacılık siteleri için değil).Çalışır ve genellikle kullanıcılar tarafından görünmezdir çünkü şirket ayrıca masaüstlerini / tarayıcıları da yönetir.Sıkı Taşıma Güvenliği'nin (HSTS) bunu yenebileceğini unutmayın ... Beni ilk etapta uyaran firefox HSTS uyarısıydı!
@MichaelLucas - evet, BlueCoat (bu alandaki popüler bir kötü amaçlı yazılım, erm, yazılım satıcısı) ile ilgili önceki yorumlara bakın.İma ettiğim gibi, bu, birçok dezavantajı olan bir anti-modeldir (örneğin, kullanıcının geçersiz veya sorunlu sunucu sertifikaları konusunda bir göstergesi yoktur ... ve bu, gizlilik sorunlarının yanı sıra)
@MichaelLucas Bildiğim kadarıyla, bunu doğru bir şekilde yaparlarsa HSTS bunu yenemez, HSTS'nin bunu nasıl ele aldığını açıklayabilir misiniz?Tarayıcınızdaki Sertifika Zincirine gerçekten bakarsanız ve şirketinizin neden üçüncü taraf bir sitenin CA'sı olduğunu merak etmeye başlarsanız, fark edeceğinizi düşünüyorum.Ancak şirketim bunu yaparsa, şikayet ederim!
@Nappy Muhtemelen ne demek HSTS'den ziyade [HPKP] (https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning) idi?Bu, kötü kurumsal tarayıcıları kesinlikle yenebilir.Wikipedia'nın çoğu tarayıcının, özellikle bu tür tarayıcılara izin vermek için özel köklere sahip sertifikalar için HPKP denetimlerini devre dışı bıraktığını belirtmesi dışında.Oh iyi...
Şirket, çalışan trafiğine MITM saldırıları yaparsa, yalnızca Temel Kimlik Doğrulama'yı değil, hemen hemen her tür kimlik doğrulamasını ortadan kaldırır.Bu nedenle, web sunucusu 2 faktörlü kimlik doğrulama gibi daha karmaşık bir şeyi kullanmaya istekli olmadığı sürece, Temel neredeyse diğer kimlik doğrulama biçimleri kadar güvenlidir.
nealmcb
2012-07-14 07:04:17 UTC
view on stackexchange narkive permalink

İstemcinin kimliğinin doğrulanması gerektiğini not ediyor ve SSL üzerinden HTTP temel kimlik doğrulamasının güvenliğini soruyorsunuz. SSL'nin tasarlandığı şey budur ve şifre iyi olduğu sürece iyi çalışacaktır. Bunu gerçekten tek bir istemci için ayarlıyorsanız, rastgele uzun bir şifre seçerek bunu sağlamak kolaydır, ör. İyi bir rastgelelik kaynağı kullanan 12 karakter veya bu sitede tartışılan diğer teknikler.

Müşterinizin ayrıca sunucu için doğru sertifikaya sahip olduğunuzdan emin olması gerekir. Tarif ettiğiniz gibi bir durumda, referans verilen python ssl sayfasında açıklandığı gibi kendinden imzalı bir sertifika kullanmak yeterli olacaktır.

Kendi kendine imzalıyorsanız, bağlantı kurulduğunda meşruiyetini doğrulayabilmeleri için sertifikanın SHA1 ve MD5 parmak izlerinin ne olması gerektiğini ilettiğinizden emin olun. Veya mümkünse önceden dağıtın.
HTTP temel kimlik doğrulamasının kullanılmasıyla ilgili başka bir endişe daha vardır: tam şifre SSL tüneli üzerinden gönderilir. Diğer bir deyişle, parola gönderilmeden önce hashing uygulanmaz ve bu nedenle yakalanabilir (uygulama kodunuzdaki hata vb.). Bu genellikle büyük bir endişe kaynağı değildir (bu, web sitesi giriş formlarında ve hatta SSH şifresinde bile HTTPS üzerinden gönderdiğiniz çoğu şifre için geçerlidir), ancak not almaya değer.
@ChrisKuehl İstemci tarafında javascript'te herhangi bir kripto yapmaya karşı güçlü argümanlar yok mu? Önerdiğin bu mu? Bana göre TLS, sertifikayı imzalamak için ödeme yapmaktan başka alabileceğim kadar iyi.
@StevenLu farkında olduğumdan veya çabuk bulabileceğimden değil, ama konuyla ilgili her şeyi okumak isterim. Bir şeyi sunucu tarafına göndermeden önce önceden hash etmenin, sunucu tarafında depolamadan önce daha fazla hash işlemi yapsa bile güvenliği azaltabileceği bir yol göremiyorum. Bunun yerine [SSL / TLS kimlik doğrulaması] 'nı (http://goo.gl/xmzFI) kullanmak isterdim (modern tarayıcılar, anahtar kimlik doğrulaması kullanan web sitelerinde 2 yönlü kimlik doğrulamaya izin verir), özellikle görüntülenmesi amaçlanmamış bir sayfa için düzenli kullanıcılar tarafından. Bu, kullanım durumunuza büyük ölçüde bağlıdır ve Python web sunucunuz için muhtemelen zordur.
TLS'deki TLS'ye ne dersiniz, bence 4 kez sarmalamanın bir kez sarmadan daha güvenli olacağını düşünüyorum. Bu şekilde kök anahtarları farklı konumlara yayabilirsiniz, bu nedenle bunu yapmak için 4 şirket kullanırsanız, büyük olasılıkla onlar (THEY) gizli kök anahtarına veya hepsine sahip olmayacaktır.
Bir göz atın: http://www.matasano.com/articles/javascript-cryptography/
@StevenLu ilginç, ancak noktayı kaçırıyor; TLS kimlik doğrulaması, [tarayıcılarda uygulandığı gibi] (http://www.browserauth.net/tls-client-authentication), JavaScript içermez. Bu, tarayıcının kendisinin bir özelliğidir. Kullanıcıya dönük kimlik doğrulamayla kullanıma uygun olmayan sorunlar var, ancak geliştiriciler / yöneticiler için bunun için yapılabilecek güçlü bir durum olduğunu düşünüyorum.
@ChrisKuehl Yani, sanırım sunucumu tam TLS istemci kimlik doğrulaması yapacak şekilde ayarlamanın bir yolunu bulmak için biraz daha derine inmem gerekecek?
@StevenLu, kurulumunuz bana iyi geliyor, ancak hepsi ne kadar güvenlik istediğinize bağlı. Sadece ek bir fikir atıyorum :-).
@ChrisKuehl TLS sunucu kimlik doğrulaması ihtiyaçlarım için kesinlikle yeterli ve onu kurabildiğim basitliği keşfetmekten hoş bir şekilde şaşırdım. Şimdi tam müşteri yetkilendirmesi almak için ne gerekir diye merak ediyorum.
Steve
2010-12-06 04:59:26 UTC
view on stackexchange narkive permalink

Tamamen ne kadar güvenli olması gerektiğine bağlıdır. SSL üzerinden temel kimlik doğrulaması, kimlik bilgilerini düz metin olarak göndermeye devam edecektir, bu da yalnızca tek bir koruma katmanına sahip olduğunuz anlamına gelir.

Parolaya bir nonce ile hashing uygulamanız veya daha iyisi, yetkilendirmeyi güvenilir bir 3. tarafa aktarır.

Weber
2010-12-06 06:25:50 UTC
view on stackexchange narkive permalink

Pek çok büyük ve popüler site, HTTPS üzerinden temel (veya başka bir form tabanlı) kimlik doğrulama kullanır. Genellikle güvenlik bilincine sahip kişilerden 'iç çeker'. İstemci tarafında şifreyi karıştırıp onun yerine karma gönderebilir misiniz? Bu, çıtayı biraz daha yükseltebilir.

Bununla birlikte, oturum açma formunu barındıran açılış sayfanızın da HTTP / S olması koşuluyla, genellikle kabul edilebilir olarak kabul edilir. Bir RESTful API durumunda, muhtemelen bir açılış sayfanız yoktur, bu yüzden sorun değil. Yapabiliyorsanız, Watcher ve Skipfish gibi bazı ücretsiz güvenlik araçlarıyla uygulamanızı doğrulayın.

yalnızca hash içeren bir sorgulama yanıtı, güvenlikte bir yükseltmedir, aksi takdirde saldırgan, hash'i izleyebilir ve oturum sona erdiğinde yine de erişebilir
Luc
2012-07-15 05:47:41 UTC
view on stackexchange narkive permalink

Ben bunu birçok şey için kullanıyorum ve tarayıcıdan gelen TLS uyarılarını görmezden gelmediğiniz sürece iyi olmalısınız.

TLS, HTTP'nin altında çalışır, dolayısıyla HTTP üzerinden iletilen tüm veriler şifrelenecek. Herhangi bir şifre formu göndermek kadar güvenli olacak.

Kendinden imzalı bir sertifika kullanmak yerine Let's Encrypt kullanmanızı öneririm. Ücretsiz sertifikalar sağlarlar ve Microsoft, Mozilla vb. Tarafından güvenilirler ve bu nedenle tarayıcıda bir TLS uyarısı vermezler. Kendinden imzalı sertifika yerine bunu kullanmanın daha iyi olacağını düşünüyorum; TLS hatası görürseniz bunun gerçek olduğunu anlarsınız ve yalnızca sertifikanızın kendi imzalı olması nedeniyle değil.

Kesinlikle böyle bir şey yapardım, özellikle de ücretsizse. "Geçersiz sertifika" hataları oldukça dikkat çekicidir.
Evet, StartSSL gerçekten bir tür homebrew çözümüdür, ancak büyük taraflarca güvenilmektedir, bu nedenle milyonlarca değerinde bir şey sağlamadığınız sürece sorun değil. Her şey, kendinden imzalı bir sertifikadan daha iyidir. Kendinden imzalı güvenli hale getirmenin yolu parmak izini kontrol etmektir, ancak bunu (örneğin) StartSSL kullanırken de yapabilirsiniz.
Güvenli içeriğimi, bir sertifika için hedef etki alanını belirleyebileceğim (StartSSL tarafından verilecek) farklı bir sunucuda barındırıyorum. Bunun nedeni, statik IP'ye sahip bir VPS için ödeme yapmadığımdan, IP'ime yönlendirme sağlamak için No-IP hizmetini kullanıyorum. Sitemi geçersiz sertifika hataları göstermeden herhangi bir yerden açmamı sağlayacak bir anahtar / sertifika almam mümkün mü?
Bu yüzden dinamik bir IP ile doğru bir SSL sertifikası kurmanın kesinlikle bir yolu olmadığı bana açık görünüyor. Tamam, sanırım tarayıcı hatasıyla sıkışıp kaldım (bir tür proxy kurulumu yapmazsam).
Güncelleme: StartSSL kapılarını kapattı.Bir sonraki en iyi seçeneğiniz Let's Encrypt.
@starbeamrainbowlabs Teşekkürler!Cevabı güncelledim.
lightxx
2015-03-06 17:32:02 UTC
view on stackexchange narkive permalink

Şimdiye kadar belirtilmeyen bir diğer argüman (sanırım), akıllı telefonlar gibi birçok mobil cihazın, tarayıcıda HTTPS üzerinden temel kimlik doğrulama yaparken kullanıcının sertifikayı kontrol etmesine izin vermemesidir. Bu, form tabanlı yetkilendirmeden farklı olarak, kimlik bilgilerinizi girmeden önce sertifikayı kontrol etmek için çoğu mobil platformda kalıcı bir iletişim kutusu olan temel kimlik doğrulama açılır penceresini atlayamayacağınız anlamına gelir. Bir saldırgan geçerli bir sertifika kullandığında bu risk oluşturabilir.

Daniel Szpisjak
2019-02-05 13:05:44 UTC
view on stackexchange narkive permalink

İşte tarih için biraz daha bağlam.Diğerlerinin, birkaç sınırlamayla yaşayabiliyorsanız, TLS üzerinden Temel Kimlik Doğrulamanın iyi çalıştığını söylediği gibi.

İstemci tarafında kullanıldığında, muhtemelen Temel Kimlik Doğrulama için oldukça zor olan oturum yönetimiyle başa çıkın.

Arka uçta , Temel Kimlik Doğrulama iyi performans gösterir ancak tamamen TLS'ye dayanır gizlilik ve bütünlük için.Token tabanlı yetkilendirmeye benzer.Daha sağlam bir şeye ihtiyacınız varsa, bir imza şemaları veya TLS İstemci Kimlik Doğrulaması kullanmayı düşünün.



Bu Soru-Cevap, otomatik olarak İngilizce dilinden çevrilmiştir.Orijinal içerik, dağıtıldığı cc by-sa 2.0 lisansı için teşekkür ettiğimiz stackexchange'ta mevcuttur.
Loading...