REST API çağrısına bir şifre koymak

Şifreleri ayarlamak / sıfırlamak için de kullanılan bir REST API'sım olduğunu varsayalım. Bunun bir HTTPS bağlantısı üzerinden çalıştığını da varsayalım. Bu şifreyi arama yoluna koymamanın iyi bir nedeni var mı, diyelim ki BASE64'te şifreleyeceğim mi?

Bir örnek şöyle bir şifreyi sıfırlamak olacaktır:

http://www.example.com/user/joe/resetpassword/OLDPASSWD/NEWPASSWD

BASE64'ün şifreleme olmadığını anlıyorum, ancak yalnızca bu durumda sörf yapmak için şifreyi korumak istiyorum.

İyi bir sunucu, URL'ler (genellikle, '?' Den sonra değişken kısmı olmadan), kaynak IP, yürütme süresi dahil olmak üzere kendisine gönderilen tüm istekleri günlüğe kaydeder ... Bu günlüğün (potansiyel olarak çok sayıda yönetici tarafından okunan) gerçekten içermesini istiyor musunuz? şifre olarak kritik derecede güvenli bilgi? Base64 onlara karşı bir durdurucu değil.

Önerdiğiniz şey ne güvenli ne de RESTful değildir.

@ Netch, günlüklerle ilgili sorundan daha önce bahsetti, ancak aynı zamanda, HTTP tarafından gönderilen şifreleri gösterdiğinizden başka bir sorun daha var, bu da herhangi bir tel teli veya ortadaki adam saldırısı ile şifreleri yakalamayı önemsiz kılıyor.

REST kullanarak bir GET isteği yaptığınızda, URL’deki farklı öğeler daha iyi taneli öğeleri temsil eder. URL’niz, sıfırlama parolanın bir parçası olan bir OLDPASSWD’nin NEWPASSWD kısmını iade ediyor gibi okuyor. Bu hiçbir anlamsal anlam ifade etmiyor. Verileri kaydetmek için GET'ler kullanılmamalıdır.

Böyle bir şey yapıyor olmalısın:

POST https://www.example.com/user/joe/resetpassword/
{oldpasswd:[data], newpasswd:[data]}

POST veri yazdığınız için ve https koklamalarını istemediğiniz için https.

(Bu gerçekten düşük bar güvenliğidir. Yapmanız gereken asgari minimum tutar.)

Önerilen programın bazı alanlarda sorunları var.

Güvenlik

URL yolları sıklıkla günlüğe kaydedilir; yolunda bozulmamış şifreler koymak kötü bir uygulamadır.

HTTP

Kimlik doğrulama / yetkilendirme bilgileri Yetkilendirme başlığında görünmelidir. Ya da potansiyel olarak, tarayıcı tabanlı şeyler için Çerez başlığı.

DİNLENME

resetpasswordURL’nizde olduğu gibi fiiller , genellikle temsili olmayan bir devlet transfer paradigmasının açık bir işaretidir. Bir URL bir kaynağı temsil etmelidir. GET'in anlamı nedir resetpassword? Veya SİL?

API

Bu şema daima önceki şifreyi bilmeyi gerektirir. Muhtemelen daha fazla davaya izin vermek isteyeceksiniz; örneğin, şifre kaybolur.

İyi anlaşılan şemalar olan Temel veya Özet kimlik doğrulamasını kullanabilirsiniz .

PUT /user/joe/password HTTP/1.0
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Content-Type: text/plain
Host: www.example.com

NEWPASSWD

Yola ultra hassas bilgileri koymaz ve HTTP ve REST kurallarını izler.

Başka bir yetkilendirme moduna izin vermeniz gerekiyorsa (örneğin, şifreyi sıfırlamak için doğrulanmış bir kanal aracılığıyla gönderilen bazı simgeler), başka bir şeyi değiştirmek zorunda kalmadan farklı bir Yetkilendirme başlığı kullanabilirsiniz.

Güvenlik dışında, bununla ilgili sorun, bunun RESTful bir yaklaşım olmamasıdır.

OLDPASSWDve NEWPASSWDkaynak hiyerarşinizdeki hiçbir şeye dayanmayın ve daha da kötüsü, işlem kesin değildir.

Yani sadece fiiliniz POSTolarak kullanabilirsiniz ve kaynak yolunuza iki şifreyi dahil etmemelisiniz.

Sorun, isteklerinizde düz metin parolalarını önlemektir. Dinlendirici web servis gereksinimlerini karşılamak için iki seçenek vardır.

1. müşteri tarafı hash

• Sanırım hash (password + salt) gibi şifrelerinizi saklıyorsunuz.
• Yeni şifreyi müşteri tarafında bir tuzla karşılaştırabilirsiniz
• Bunun anlamı şudur: Müşteri tarafında yeni bir tuz oluşturun, karma yapın örneğin hash (newPassword + newSalt)
• Yeni oluşturulan hasha artı tuzu huzurlu web servisinize gönderin
• Eski şifreyi karma olarak da gönderin (oldPassword + oldSalt)

2. Şifreleme

• / Otk / john benzeri bir kullanıcı için bir "tek kullanımlık anahtar" (otk) kaynağı oluşturun
• Bu kaynak güvenli bir rasgele benzersiz bir seferlik anahtar döndürür, örn.
• Huzurlu web servisiniz bu rastgele otk'u, ID 95648915125 ile bir sonraki güvenli iletişim için saklamalıdır.
• Yeni ve eski şifrenizi otk ile şifreleyin, örneğin AES (güvenlik nedeniyle eski ve yeni şifre için iki ayrı ot kullanmalısınız)
• Şifrelenmiş şifreleri, 95648915125 kimliği ile değişiklik şifresi kaynağınıza gönderin
• Bir otk ve ID kombinasyonunun sadece bir kez çalışmasına izin verilir, bu yüzden şifreyi değiştirdikten sonra bu kombinasyonu silmeniz gerekir.
• Olası daha iyi seçenek: Geçerli / eski şifreyi Temel Kimlik Doğrulama ile gönderin.

Not: Her iki seçenek için HTTPS gereklidir!

Parola sıfırlama işleminin özellikleri nelerdir?

1. Bir şeyleri değiştirdi.
2. Ayarlandığı bir değer var.
3. Sadece bazı insanların bunu yapmasına izin verilir (kullanıcı, yönetici veya her ikisi de, belki de her ikisinin de yapabileceği farklı kurallar olabilir).

Buradaki 1. nokta GET'i kullanamayacağınız anlamına gelir, ya parola değiştirme işlemini gösteren bir URI'ye parola değiştirme işlemini gösteren bir POST ya da parola değişikliklerini işleyen bir kaynağı temsil eden bir URI'ye ya da parolayı ya da bir şeyi temsil eden bir URI'ye yeni parolayı temsil eden bir şey koymalısınız (örn. kullanıcı) bu şifrenin bir özellik olduğu

Genellikle POST yapardık, çünkü garip olabilir çünkü daha sonra GET yapamadığımız ve tabii ki parolayı alamayacağımız bir şey SORUN.

Bu nedenle, 2. Nokta POST'lu olan yeni şifreyi temsil eden veri olacaktır.

3. nokta, isteği onaylamamız gerekeceği anlamına gelir; bu, kullanıcı mevcut kullanıcı ise, bize kanıtlanması için geçerli şifreye ihtiyacımız olacağı anlamına gelir (örneğin, geçerli bir şifreyi varsa, geçerli şifrenizi almamıza rağmen) bilgisini göndermeden ispatlamak için kullanıldı).

URI bu nedenle <http://example.net/changeCurrentUserPassword>veya gibi bir şey olmalıdır <http://example.net/users/joe/changePassword>.

Mevcut şifreyi POST verilerinde ve kullanılan genel yetkilendirme mekanizmasında almak istediğimize karar verebiliriz.