Làm cách nào để lưu tên người dùng và mật khẩu vào API trong tùy chọn wordpress DB?


19

Tôi hiện đang phát triển một plugin và nhiều khả năng tôi sẽ phát hành nó nhiều hơn trên kho plugin công cộng để những người khác có thể sử dụng nó.

Plugin sẽ sử dụng API và để sử dụng API này, bạn cần phải nhập tên người dùng và mật khẩu. Vì vậy, plugin của tôi cần lưu trữ các thông tin đăng nhập trong cơ sở dữ liệu. Tôi không muốn lưu trữ chúng trong văn bản thuần mặc dù API cần chúng ở dạng văn bản thuần túy.

Vì vậy, câu hỏi của tôi là làm thế nào để tôi lưu trữ những thông tin nhạy cảm này? Băm là ra, vì vậy nó phải là một loại mã hóa.

Trong WordPress có một khóa duy nhất có thể được sử dụng sẽ khác nhau từ blog này sang blog khác không? Tôi nên sử dụng chức năng php nào để mã hóa và giải mã? Tôi đang tìm kiếm các chức năng nhiều khả năng sẽ hoạt động trên tất cả các cài đặt WP.


3
Điều này là không thể giải quyết được. Không quan trọng bạn mã hóa bao nhiêu nếu cần phải đảo ngược. Nếu WP có thể giải mã nó và WP bị xâm phạm thì mã hóa không thành vấn đề.
Rarst

Nhưng tại sao API của bạn cần biết mật khẩu? Sẽ không đủ nếu API biết rằng người dùng biết mật khẩu?
onetrickpony

1
@One Trick Pony - Mật khẩu cần được lưu trữ để quá trình có thể được tự động hóa mà không cần sự can thiệp của người dùng.
Brady

1
@Rarst - Tôi biết rằng nếu WP bị xâm phạm thì mật khẩu cũng vậy. Tôi không thể ngăn chặn điều này. Điều tôi có thể ngăn chặn là nếu thu được kết xuất SQL thì mật khẩu không ở dạng văn bản thuần túy.
Brady

@Brady yep, nếu chỉ có kết xuất SQL bị xâm phạm thì mã hóa sẽ giúp ích. Tuy nhiên tôi thấy kịch bản như vậy không có khả năng. Nếu bạn có quyền truy cập cơ sở dữ liệu, việc thỏa hiệp WP cũng là chuyện nhỏ.
Rarst

Câu trả lời:


4

Mặc dù tôi đồng ý với các câu trả lời trước đó, để trả lời câu hỏi bạn thực sự hỏi, điều khiến bạn suy nghĩ là sử dụng một trong các hằng số này cho wp-config.php:

định nghĩa ('AUTH_KEY', 'đã xử lý lại');
định nghĩa ('SECURE_AUTH_KEY', 'được điều chỉnh lại');
xác định ('LOGGED_IN_KEY', 'đã xử lý lại');
định nghĩa ('NONCE_KEY', 'được điều chỉnh lại');

Chúng có nghĩa là duy nhất trên các cài đặt wordpress - và là về các tùy chọn duy nhất cho các khóa có sẵn được tìm thấy trong wordpress. Thay thế sẽ là thêm hằng số tương tự của riêng bạn được tạo bằng cách băm một trong số chúng theo địa chỉ email quản trị viên hoặc tương tự - và sau đó lưu trữ trong tùy chọn cài đặt ẩn - để bảo vệ khỏi mất khóa nếu ai đó vô tình sửa đổi khóa sau plugin được cài đặt. Điều nguy hiểm là, nếu chúng không được tạo duy nhất trên cài đặt ban đầu, nhưng chủ sở hữu / chủ sở hữu trang web quyết định khắc phục lỗi sau khi thực tế, họ không nên vô tình phá vỡ mã hóa mật khẩu của bạn.

Đối với các chức năng mã hóa / giải mã - một tìm kiếm nhanh của Google trả về danh sách sau với mã có vẻ phù hợp với hóa đơn: http://maxvergelli.wordpress.com/2010/02/17/easy-to-use-and-strong- mã hóa-giải mã-chức năng php /

mã hóa hàm ($ input_ chuỗi, $ 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);
    trả về base64_encode (mcrypt_encrypt (MCRYPT_RIJNDAEL_256, $ h_key, $ input_ chuỗi, MCRYPT_MODE_ECB, $ iv));
}

chức năng giải mã ($ mã hóa_input_ chuỗi, khóa $) {
    $ 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);
    trả về
}

Dưới đây là một số tài liệu về mã hóa AES được sử dụng ở đây: http://www.chilkatsoft.com/p/php_aes.asp


4

Đây chính xác là hoàn cảnh OAuth được thiết kế cho.

Từ trang chủ OAuth :

Dành cho nhà phát triển Nhà cung cấp dịch vụ ...

Nếu bạn đang hỗ trợ ...

  • Ứng dụng web
  • API phía máy chủ
  • mashup

Nếu bạn đang lưu trữ dữ liệu được bảo vệ thay mặt cho người dùng của bạn, họ không nên truyền bá mật khẩu của họ trên web để có quyền truy cập vào nó. Sử dụng OAuth để cung cấp cho người dùng của bạn quyền truy cập vào dữ liệu của họ trong khi bảo vệ thông tin đăng nhập tài khoản của họ.

Ưu điểm của OAuth là bạn không cần lưu trữ mật khẩu của người dùng. Khi lần đầu tiên thiết lập plugin, họ được yêu cầu đăng nhập bằng tên người dùng và mật khẩu thông qua ứng dụng (thường là một trang được lưu trữ trên cùng một máy chủ với API và được tải trong chuyển hướng trang, hộp dày hoặc iframe) .

Khi người dùng đã đăng nhập, máy chủ (hệ thống của bạn) sẽ tạo một khóa bảo mật mà hệ thống của họ (WordPress) có thể sử dụng để giao tiếp với API. Khóa này là duy nhất cho tài khoản người dùng và trang web - và nó cho phép ứng dụng (trên WordPress) thực hiện mọi việc với API thay mặt người dùng mà không chuyển thông tin xác thực của họ mỗi lần.

Nếu bạn muốn xem một ví dụ về điều này trong thực tế, hãy xem Jetpack .

Khi bạn kích hoạt plugin, nó phàn nàn rằng nó không được kết nối. Khi bạn "kết nối" nó, bạn nhập thông tin đăng nhập của mình thông qua WordPress.com và thiết lập tương tác OAuth giữa WordPress và API của họ.

Nhưng bạn chỉ phải thực hiện việc này một lần và tên người dùng / mật khẩu WordPress.com của bạn không bao giờ được lưu trữ trong cơ sở dữ liệu WordPress cục bộ của bạn.


1
Sẽ rất tuyệt nếu sử dụng cái này nhưng API tôi đang xử lý không phải là của tôi và chúng không có hệ thống OAuth.
Brady

1
Trong trường hợp đó, lựa chọn thực sự duy nhất của bạn là chấp nhận rằng bạn cần lưu trữ mật khẩu trong DB và việc bạn có mã hóa hay không thực sự không khác biệt gì về bảo mật. Như những người khác đã đề cập ở trên, nếu nó trong db và mã hóa có thể đảo ngược, thì bất kỳ ai có quyền truy cập vào WordPress (hợp pháp hoặc bị hack) đều có thể nắm bắt được nó.
EAMann

0

Đây là một vấn đề quan trọng, vì nhiều dịch vụ vẫn không hỗ trợ OAuth và lưu trữ mật khẩu trong cơ sở dữ liệu tùy chọn giúp chúng có thể đọc được với mọi plugin Wordpress (xem bình luận của tôi ở trên).

Đây không phải là (chưa) một câu trả lời thực sự cho câu hỏi, nhưng cũng quá dài cho một nhận xét. Tôi hy vọng sẽ châm ngòi cho một cuộc thảo luận với vấn đề này, với mục đích đưa ra giải pháp "tốt nhất" có thể cho vấn đề "không thể giải quyết" này.

Ý tưởng cơ bản khiến tôi nghĩ rằng mã hóa mật khẩu là có thể như sau:

Có một thông tin bí mật mà mọi người dùng đều có: mật khẩu Wordpress của họ. Có thể lưu trữ thông tin đăng nhập vào các dịch vụ của bên thứ ba được mã hóa bằng một biểu mẫu có nguồn gốc bí mật đó và chỉ giải mã chúng khi người dùng đăng nhập.

Theo cách này, ít nhất có thể làm cho không thể đánh cắp mật khẩu từ một bản sao của các tệp và cơ sở dữ liệu Wordpress. Nó không thể giải quyết vấn đề của các plugin đánh cắp thông tin đăng nhập khác, bởi vì mọi plugin đều có thể chụp mật khẩu văn bản đơn giản trong quá trình đăng nhập.

Trên thực tế việc giải mã khá dễ thực hiện: Giả sử chúng ta đã có phiên bản mã hóa của dịch vụ bên thứ ba được lưu trữ trong cơ sở dữ liệu, chúng ta có thể nối vào 'authenticate'bộ lọc hoặc bằng cách ghi đè wp_authenticate()chức năng, tạo ra hàm băm của mật khẩu người dùng văn bản đơn giản (bởi phương tiện wp_hash_password()), lưu trữ mật khẩu băm đó dưới dạng khóa mã hóa ở một nơi riêng tư cho đến khi người dùng đăng xuất (sử dụng 'wp_logout'hook để xóa khóa) và sử dụng nó mỗi khi chúng ta cần mật khẩu của bên thứ ba để giải mã giá trị được mã hóa trong cơ sở dữ liệu.

Mặc dù tôi có cảm giác nên làm cho công việc này hoạt động, tuy nhiên có một số vấn đề chưa được giải quyết:

  1. Làm thế nào để thực hiện mã hóa? Có khả năng người ta có thể lưu trữ mật khẩu văn bản đơn giản cho đến khi người dùng đăng xuất và đăng nhập lại và thực hiện mã hóa trong thời gian 'authenticate'. Người dùng có thể được nhắc đăng nhập để giữ khoảng thời gian cho đến khi điều này xảy ra ngắn.
  2. Nơi lưu trữ khóa và làm thế nào để xóa nó trong khi đăng xuất? Tôi có hiểu chính xác 'authenticate'chỉ chạy khi người dùng thực sự đăng nhập không?
  3. Trong trường hợp hiện tại có cách lưu trữ mật khẩu băm, thay vào đó, người ta có thể lấy khóa từ cookie phiên không?
  4. Ai để xử lý thay đổi mật khẩu? Có vẻ như có thể bắt được các thay đổi mật khẩu như vậy và mật khẩu của bên thứ ba sau đó sẽ phải được mã hóa lại bằng khóa có nguồn gốc từ mật khẩu mới.
  5. Có cách nào để cung cấp hỗ trợ nhiều người dùng không? Lý tưởng nhất là người dùng sẽ muốn người dùng quản trị có thể đặt mật khẩu của bên thứ ba trong cài đặt mà sau đó người dùng ít đặc quyền sẽ bị kiện để tương tác với các dịch vụ của bên thứ ba, lý tưởng ngay cả khi không tiết lộ mật khẩu đó cho họ. Đối với điều này, người dùng quản trị sẽ cần có khả năng tạo khóa cho tất cả người dùng mà những người dùng khác chỉ có thể tự tạo. Điều đó có thể bằng cách nào đó?
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.