Wordpress Option DB'de API'ya Kullanıcı Adı ve Parola Nasıl Saklanır?


19

Şu anda bir eklenti geliştiriyorum ve muhtemelen diğer eklenti kullanabilirsiniz böylece eklenti deposunda muhtemelen daha fazla serbest bırakma şansı vardır.

Eklenti bir API kullanıyor olacak ve bu API'yı kullanmak için bir kullanıcı adı ve şifre geçmeniz gerekiyor. Eklentimin bu giriş bilgilerini veritabanında saklaması gerekiyor. API bunları düz metinde gerektirse de bunları düz metin olarak saklamak istemiyorum.

Benim sorum şu hassas bilgileri nasıl saklayacağım? Hashing çıktı, bu yüzden bir çeşit şifreleme olmalı.

WordPress'te blogdan blog'a farklılık gösterebilecek benzersiz bir anahtar var mı? Şifrelemek ve şifresini çözmek için hangi php işlevlerini kullanmalıyım? Tüm WP yüklemelerinde muhtemelen daha fazla çalışacak işlevleri arıyorum.


3
Bu biraz çözümsüz. Tersinir olması gerekiyorsa ne kadar şifrelediğiniz önemli değildir. WP şifresini çözebilirse ve WP tehlikeye girerse şifreleme önemli değildir.
Rarst

Peki API'nizin neden şifreyi bilmesi gerekiyor? API, kullanıcının şifreyi bildiğini biliyorsa yeterli değil mi?
onetrickpony

1
@One Trick Pony - İşlemin kullanıcı müdahalesi olmadan otomatik hale getirilebilmesi için parolanın saklanması gerekir.
Brady

1
@Rarst - WP tehlikeye girerse şifrelerin de farkındayım. Bunu engelleyemiyorum. Ne önleyebilirim eğer bir SQL dökümü elde edilirse şifreler düz metin değildir.
Brady

@Bdydy yep, sadece SQL dökümü tehlikeye atılırsa şifreleme yardımcı olacaktır. Ancak böyle bir senaryoyu pek olası görmüyorum. Veritabanı erişiminiz varsa, WP'den ödün vermek de önemlidir.
Rarst

Yanıtlar:


4

Önceki cevapları kabul ederken, gerçekten sorduğunuz soruyu cevaplamak için, akla gelen wp-config.php için bu sabitlerden birini kullanmaktır:

define ('AUTH_KEY', 'düzeltilmiş');
define ('SECURE_AUTH_KEY', 'düzeltildi');
define ('LOGGED_IN_KEY', 'düzeltildi');
define ('NONCE_KEY', 'düzeltilmiş');

Wordpress kurulumlarında benzersiz olmaları amaçlanmıştır ve önceden mevcut anahtarların wordpress'te bulunması için tek seçenek hakkındadır. Alternatif olarak, bunlardan birini yönetici e-posta adresine veya benzeri bir adrese ayırarak oluşturduğunuz kendi benzer sabitinizi eklemek ve ardından gizli bir ayar seçeneğinde depolamak - anahtarınızı yanlışlıkla değiştirdikten sonra anahtarınızı kaybetmekten korumak için eklenti yüklü. Tehlike, ilk kurulumda benzersiz hale getirilmediyse, ancak yönetici / site sahibinin, hatayı sonra hatayı düzeltmeye karar vermeleri durumunda, yanlışlıkla şifre şifrelemenizi kırmamaları gerektiğidir.

Şifreleme / şifre çözme işlevlerine gelince - hızlı bir Google araması, faturaya uygun görünen kodu içeren aşağıdaki listeyi döndürür: http://maxvergelli.wordpress.com/2010/02/17/easy-to-use-and-strong- şifreleme-şifre çözme-php-işlevleri /

işlev şifreleme ($ input_string, $ key) {
    iv_size = mcrypt_get_iv_size (MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB);
    $ iv = mcrypt_create_iv ($ iv_size, MCRYPT_RAND);
    $ h_key = karma ('sha256', $ anahtar, DOĞRU);
    dönüş base64_encode (mcrypt_encrypt (MCRYPT_RIJNDAEL_256, $ h_key, $ input_string, MCRYPT_MODE_ECB, $ iv));
}

işlev şifresi çözme ($ encripted_input_string, $ anahtar) {
    iv_size = mcrypt_get_iv_size (MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB);
    $ iv = mcrypt_create_iv ($ iv_size, MCRYPT_RAND);
    $ h_key = karma ('sha256', $ anahtar, DOĞRU);
    dönüş kırpma (mcrypt_decrypt (MCRYPT_RIJNDAEL_256, $ h_key, base64_decode ($ şifrelenmiş_input_string), MCRYPT_MODE_ECB, $ iv));
}

Burada kullanılan AES şifrelemesinin bazı belgeleri: http://www.chilkatsoft.com/p/php_aes.asp


4

Bu tam olarak OAuth'un tasarlandığı durumdur.

Gönderen OAuth ana :

Servis Sağlayıcı geliştiricileri için ...

Eğer destekliyorsanız ...

  • internet uygulamaları
  • sunucu tarafı API'ları
  • mashup'lar

Korumalı verileri kullanıcılarınızın adına saklıyorsanız, erişebilmek için şifrelerini web'e yaymamaları gerekir. Kullanıcılarınızın hesap kimlik bilgilerini korurken verilerine erişebilmeleri için OAuth'u kullanın.

OAuth'un avantajı, kullanıcının şifresini saklamanıza gerek olmamasıdır. Eklentiyi ilk kez kurduklarında, uygulama üzerinden bir kullanıcı adı ve parola ile oturum açmaları istenir (genellikle API ile aynı sunucuda barındırılan ve bir sayfa yönlendirmesine, kalın kutuya veya iframe'e yüklenen bir sayfa) .

Kullanıcı oturum açtıktan sonra, sunucu (sisteminiz) sistemlerinin (WordPress) API ile arayüz oluşturmak için kullanabileceği güvenli bir anahtar oluşturur. Bu anahtar kullanıcı hesabı ve site için benzersizdir ve uygulamaya (WordPress'de) kimlik doğrulama bilgilerini her seferinde iletmeden kullanıcının adına API ile bir şeyler yapma izni verir .

Bunun bir örneğini çalışırken görmek istiyorsanız Jetpack'e bakın .

Eklentiyi etkinleştirdiğinizde, bağlı olmadığından şikayet eder. "Bağlandığınızda", kimlik bilgilerinizi WordPress.com aracılığıyla girersiniz ve WordPress ile API'ları arasında OAuth etkileşimini ayarlarsınız.

Ancak bunu yalnızca bir kez yapmanız gerekir ve WordPress.com kullanıcı adınız / şifreniz asla yerel WordPress veritabanınızda saklanmaz.


1
Bunu kullanmak güzel olurdu ama uğraştığım API benim değil ve yerinde hiçbir OAuth sistemi var.
Brady

1
Bu durumda, tek gerçek seçeneğiniz şifreyi DB'de saklamanız gerektiğini ve şifreleyip şifrelemediğinizi gerçekten güvenlikten önemli ölçüde farklı kılmaz. Yukarıda belirtildiği gibi, db'de ise ve şifreleme geri döndürülebilirse, WordPress'e (meşru veya saldırıya uğramış) erişimi olan herkes aklınıza gelebilir.
EAMann

0

Birçok hizmet hala OAuth'u desteklemediğinden ve şifreleri seçenekler veritabanında saklamak, her bir Wordpress eklentisine okunabilir hale getirdiğinden bu önemli bir sorundur (yukarıdaki yorumuma bakın).

Bu (henüz) soruya gerçek bir cevap değil, aynı zamanda bir yorum için çok uzun. Bu "çözülemez" soruna "en iyi" olası çözümü bulmak amacıyla bununla bir tartışma başlatmayı umuyorum.

Şifreleri şifrelemenin mümkün olduğunu düşündüren temel fikir şudur:

Her kullanıcının sahip olduğu tek bir gizli bilgi vardır: Wordpress şifresi. Kimlik bilgilerini, şifrelenen gizli türetilmiş bir formla şifrelenmiş üçüncü taraf hizmetlerine depolamak ve yalnızca kullanıcı oturum açtığında şifresini çözmek mümkün olmalıdır.

Bu şekilde, en azından Wordpress dosyalarının ve veritabanının bir kopyasından şifreleri çalmayı imkansız hale getirmek mümkün olmalıdır. Diğer eklentilerin kimlik bilgilerini çalma sorununu çözemez, çünkü her eklenti oturum açma sırasında düz metin parolasını yakalayabilir.

Aslında şifre çözme yapmak oldukça kolaydır: Veritabanında kayıtlı üçüncü taraf hizmetin şifrelenmiş bir sürümüne sahip olduğumuzu varsayalım, 'authenticate'filtreye bağlanabilir veya wp_authenticate()işlevin üzerine yazarak , düz metin kullanıcı şifresinin tuzlanmış bir karmasını oluşturabiliriz ( anlamına gelir wp_hash_password()), hashed parolayı, kullanıcı oturumu kapatana ( 'wp_logout'anahtarı silmek için kancayı kullanın) ve veritabanındaki şifreli değerin şifresini çözmek için üçüncü taraf parolasına her ihtiyaç duyduğumuzda özel bir yerde bir şifreleme anahtarı olarak saklar .

Bu işi yapmanın mümkün olması gerektiğini düşünmeme rağmen, henüz çözülmemiş birkaç sorun var:

  1. Şifreleme nasıl yapılır? Potansiyel olarak kullanıcı oturumunu kapatıp tekrar kapanıncaya kadar düz metin parolasını saklayabilir 'authenticate'. Kısa olana kadar süreyi korumak için kullanıcıdan oturum açması istenebilir.
  2. Anahtar nerede saklanır ve oturumu kapatırken nasıl silinir? Bunun 'authenticate'yalnızca kullanıcı gerçekten oturum açtığında çalıştırıldığını doğru anladım mı?
  3. Şimdi karma şifreyi saklamanın bir yolu varsa, bunun yerine oturum çerezinden bir anahtar türetilebilir mi?
  4. Parola değişikliklerini kim üstlenir? Bu tür şifre değişikliklerini yakalamak mümkün görünüyor ve üçüncü taraf şifresinin yeni şifreden türetilen anahtarla yeniden şifrelenmesi gerekiyor.
  5. Çoklu kullanıcı desteği sağlamanın bir yolu var mı? İdeal olarak, bir yönetici kullanıcının, daha sonra daha az ayrıcalıklı kullanıcıların üçüncü taraf hizmetleriyle etkileşimde bulunabilmeleri için ideal olarak bu şifreleri açıklamalarına gerek kalmadan ayarlarda üçüncü taraf şifreleri ayarlayabilmelerini ister. Bunun için, yönetici kullanıcının, diğer kullanıcıların yalnızca kendileri için üretebileceği tüm kullanıcılar için bir anahtar üretebilmesi gerekir. Bu bir şekilde mümkün mü?
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.