วิธีการจัดเก็บชื่อผู้ใช้และรหัสผ่านไปยัง API ในตัวเลือก wordpress DB?

ขณะนี้ฉันกำลังพัฒนาปลั๊กอินและโอกาสที่ฉันจะปล่อยปลั๊กอินนี้มากกว่าที่เก็บปลั๊กอินสาธารณะเพื่อให้ผู้อื่นสามารถใช้งานได้

ปลั๊กอินจะใช้ API และใช้ API นี้คุณจะต้องส่งชื่อผู้ใช้และรหัสผ่าน ดังนั้นปลั๊กอินของฉันต้องเก็บข้อมูลการเข้าสู่ระบบเหล่านี้ในฐานข้อมูล ฉันไม่ต้องการเก็บสิ่งเหล่านี้ในรูปแบบข้อความธรรมดาแม้ว่า API ต้องการรูปแบบเหล่านี้ในรูปแบบข้อความล้วน

ดังนั้นคำถามของฉันคือฉันจะเก็บข้อมูลที่ละเอียดอ่อนเหล่านี้ได้อย่างไร การแฮ็ชออกมาแล้วดังนั้นจึงต้องมีการเข้ารหัสบางประเภท

ใน WordPress มีคีย์เฉพาะที่สามารถใช้ซึ่งจะแตกต่างจากบล็อกต่อบล็อกหรือไม่ ฉันควรใช้ฟังก์ชัน php ใดในการเข้ารหัสและถอดรหัส ฉันกำลังมองหาฟังก์ชั่นที่จะทำงานได้ดีกว่าการติดตั้ง WP ทั้งหมด

ในขณะที่ฉันเห็นด้วยกับคำตอบก่อนหน้าเพื่อตอบคำถามที่คุณถามจริง ๆ สิ่งที่อยู่ในใจคือการใช้หนึ่งในค่าคงที่เหล่านี้สำหรับ wp-config.php:

define ('AUTH_KEY', 'redacted');
define ('SECURE_AUTH_KEY', 'redacted');
define ('LOGGED_IN_KEY', 'redacted');
define ('NONCE_KEY', 'redacted');

มันมีความหมายที่จะไม่ซ้ำกันในการติดตั้ง wordpress - และเป็นตัวเลือกเฉพาะสำหรับคีย์ที่มีอยู่ก่อนที่จะพบใน wordpress ทางเลือกอื่นคือการเพิ่มค่าคงที่ที่คล้ายกันของคุณเองซึ่งสร้างขึ้นโดยการแฮชที่หนึ่งกับที่อยู่อีเมลของผู้ดูแลระบบหรือที่คล้ายกัน - จากนั้นเก็บไว้ในตัวเลือกการตั้งค่าที่ซ่อนอยู่ - เพื่อป้องกันการสูญเสียคีย์ของคุณ ติดตั้งปลั๊กอินแล้ว อันตรายคือถ้าพวกเขาไม่ได้สร้างความแตกต่างในการติดตั้งครั้งแรก แต่เจ้าของผู้ดูแลระบบ / ไซต์ตัดสินใจที่จะแก้ไขความล้มเหลวหลังจากข้อเท็จจริงพวกเขาไม่ควรทำลายการเข้ารหัสรหัสผ่านโดยไม่ตั้งใจ

สำหรับฟังก์ชั่นการเข้ารหัส / ถอดรหัส - การค้นหาโดย Google อย่างรวดเร็วจะส่งคืนรายการต่อไปนี้พร้อมรหัสที่ดูเหมือนจะพอดีกับใบเสร็จ: http://maxvergelli.wordpress.com/2010/02/17/easy-to-use-and-strong- การเข้ารหัสถอดรหัส-PHP ฟังก์ชั่น /

ฟังก์ชั่นการเข้ารหัส ($ 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 = hash ('sha256', $ key, TRUE);
    return base64_encode (mcrypt_encrypt (MCRYPT_RIJNDAEL_256, $ h_key, $ input_string, MCRYPT_MODE_ECB, $ iv));
}

ฟังก์ชันถอดรหัส ($rypt_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 = hash ('sha256', $ key, TRUE);
    trim trim (mcrypt_decrypt (MCRYPT_RIJNDAEL_256, $ h_key, base64_decode ($ เข้ารหัส _input_string), MCRYPT_MODE_ECB, $ iv));
}

นี่คือเอกสารบางส่วนของการเข้ารหัส AES ที่ใช้ที่นี่: http://www.chilkatsoft.com/p/php_aes.asp

นี่เป็นสถานการณ์ที่ OAuth ได้รับการออกแบบมาอย่างแท้จริง

จากหน้าแรกของ OAuth :

สำหรับนักพัฒนาผู้ให้บริการ ...

หากคุณสนับสนุน ...

• เว็บแอปพลิเคชัน
• API ฝั่งเซิร์ฟเวอร์
• ผสม

หากคุณกำลังจัดเก็บข้อมูลที่ได้รับการป้องกันในนามของผู้ใช้พวกเขาไม่ควรเผยแพร่รหัสผ่านของพวกเขารอบ ๆ เว็บเพื่อเข้าถึงข้อมูล ใช้ OAuth เพื่อให้ผู้ใช้ของคุณสามารถเข้าถึงข้อมูลของพวกเขาในขณะที่ปกป้องข้อมูลบัญชีของพวกเขา

ข้อดีของ OAuth คือคุณไม่จำเป็นต้องจัดเก็บรหัสผ่านของผู้ใช้ เมื่อพวกเขาตั้งค่าปลั๊กอินเป็นครั้งแรกพวกเขาจะถูกขอให้เข้าสู่ระบบด้วยชื่อผู้ใช้และรหัสผ่านผ่านแอปพลิเคชัน (โดยปกติแล้วหน้าเว็บที่โฮสต์บนเซิร์ฟเวอร์เดียวกันกับ API และโหลดในการเปลี่ยนเส้นทางหน้าหนาหรือ iframe) .

เมื่อผู้ใช้ล็อกอินแล้วเซิร์ฟเวอร์ (ระบบของคุณ) จะสร้างคีย์ความปลอดภัยที่ระบบของพวกเขา (WordPress) สามารถใช้เพื่อเชื่อมต่อกับ API คีย์นี้ไม่ซ้ำกันสำหรับบัญชีผู้ใช้และไซต์ - และให้สิทธิ์แอปพลิเคชัน (บน WordPress) ในการทำสิ่งต่าง ๆ กับ API ในนามของผู้ใช้โดยไม่ต้องส่งข้อมูลการตรวจสอบสิทธิ์ในแต่ละครั้ง

หากคุณต้องการที่จะเห็นตัวอย่างนี้ในการดำเนินการตรวจสอบJetpack

เมื่อคุณเปิดใช้งานปลั๊กอินมันจะบ่นว่าไม่ได้เชื่อมต่อ เมื่อคุณ "เชื่อมต่อ" คุณจะป้อนข้อมูลประจำตัวของคุณผ่าน WordPress.com และตั้งค่าการโต้ตอบ OAuth ระหว่าง WordPress และ API ของพวกเขา

แต่คุณจะต้องทำสิ่งนี้เพียงครั้งเดียวและชื่อผู้ใช้ / รหัสผ่าน WordPress.com ของคุณจะไม่ถูกเก็บไว้ในฐานข้อมูล WordPress ในพื้นที่ของคุณ

นี่เป็นปัญหาสำคัญเนื่องจากบริการจำนวนมากยังไม่รองรับ OAuth และการจัดเก็บรหัสผ่านในฐานข้อมูลตัวเลือกทำให้สามารถอ่านได้ทุกปลั๊กอิน Wordpress เดียว (ดูความคิดเห็นของฉันด้านบน)

นี่ยังไม่ใช่คำตอบที่แท้จริงสำหรับคำถาม แต่ยังยาวเกินไปสำหรับความคิดเห็น ฉันหวังว่าจะจุดประกายการสนทนากับสิ่งนี้โดยมีจุดประสงค์ในการหาทางออกที่ดีที่สุดสำหรับปัญหาที่ไม่สามารถแก้ไขได้

แนวคิดพื้นฐานที่ทำให้ฉันคิดว่าการเข้ารหัสรหัสผ่านเป็นไปได้คือ:

มีข้อมูลลับหนึ่งชิ้นที่ผู้ใช้ทุกคนมี: รหัสผ่าน Wordpress มันควรจะเป็นไปได้ที่จะจัดเก็บข้อมูลประจำตัวไปยังบริการของบุคคลที่สามที่เข้ารหัสด้วยรูปแบบที่ได้รับความลับรหัสผ่านนั้นและถอดรหัสเฉพาะเมื่อผู้ใช้เข้าสู่ระบบ

ด้วยวิธีนี้มันเป็นไปได้ที่อย่างน้อยจะทำให้มันเป็นไปไม่ได้ที่จะขโมยรหัสผ่านจากสำเนาของไฟล์ Wordpress และฐานข้อมูล ไม่สามารถแก้ปัญหาของปลั๊กอินอื่นที่ขโมยข้อมูลประจำตัวได้เนื่องจากปลั๊กอินทุกตัวสามารถจับภาพรหัสผ่านแบบข้อความธรรมดาในระหว่างการเข้าสู่ระบบ

จริง ๆ แล้วการถอดรหัสค่อนข้างง่าย: สมมติว่าเรามีรุ่นที่เข้ารหัสของบริการของบุคคลที่สามที่เก็บอยู่ในฐานข้อมูลแล้วเราสามารถขอเข้าไปใน'authenticate'ตัวกรองหรือโดยการเขียนทับwp_authenticate()ฟังก์ชั่นสร้างแฮชเค็มของรหัสผ่านผู้ใช้ข้อความธรรมดา หมายถึงwp_hash_password()) เก็บรหัสผ่านที่แฮชไว้เป็นรหัสการเข้ารหัสที่ใดที่หนึ่งจนกว่าผู้ใช้จะล็อกเอาต์ (ใช้'wp_logout'hook เพื่อลบคีย์) และใช้ทุกครั้งที่เราต้องการรหัสผ่านของบุคคลที่สามเพื่อถอดรหัสค่าการเข้ารหัสในฐานข้อมูล

ในขณะที่ฉันรู้สึกว่ามันควรจะเป็นไปได้ที่จะทำให้งานนี้มี แต่ปัญหาที่ยังไม่ได้แก้ไขหลายประการ:

1. วิธีการเข้ารหัส? 'authenticate'ที่อาจเกิดขึ้นอย่างใดอย่างหนึ่งสามารถเก็บรหัสผ่านข้อความธรรมดาจนกว่าผู้ใช้ล็อกออกและในอีกครั้งและทำในช่วงการเข้ารหัส ผู้ใช้อาจได้รับแจ้งให้เข้าสู่ระบบเพื่อให้ระยะเวลาจนกว่าจะเกิดเหตุการณ์นี้สั้น
2. จะเก็บกุญแจได้ที่ไหนและจะลบมันออกจากระบบได้อย่างไร? ฉันเข้าใจอย่างถูกต้องว่า'authenticate'จะทำงานเมื่อผู้ใช้เข้าสู่ระบบจริงเท่านั้น?
3. ในกรณีที่มีวิธีการจัดเก็บรหัสผ่านที่ถูกแฮชอาจมีใครสามารถรับคีย์จากคุกกี้เซสชันแทนได้หรือไม่
4. ใครที่จัดการกับการเปลี่ยนแปลงรหัสผ่าน ดูเหมือนว่าเป็นไปได้ที่จะตรวจจับการเปลี่ยนแปลงรหัสผ่านดังกล่าวและรหัสผ่านของบุคคลที่สามจะต้องถูกเข้ารหัสใหม่ด้วยรหัสที่ได้รับจากรหัสผ่านใหม่
5. มีวิธีให้การสนับสนุนผู้ใช้หลายหรือไม่ ในอุดมคติแล้วหนึ่งต้องการให้ผู้ใช้ผู้ดูแลระบบสามารถตั้งค่ารหัสผ่านของบุคคลที่สามในการตั้งค่าที่สามารถถูกฟ้องร้องโดยผู้ใช้ที่มีสิทธิพิเศษน้อยกว่าเพื่อโต้ตอบกับบริการของบุคคลที่สาม สำหรับสิ่งนี้ผู้ใช้ที่เป็นผู้ดูแลระบบจะต้องสามารถสร้างคีย์สำหรับผู้ใช้ทั้งหมดที่ผู้ใช้รายอื่นสามารถสร้างได้ด้วยตนเอง เป็นไปได้ไหม?