Ticket #3604 (closed enhancement: wontfix)

Opened 1 year ago

Last modified 1 week ago

wp-admin Password Encryption via JavaScript

Reported by: robertaccettura Assigned to: anonymous
Priority: low Milestone:
Component: Administration Version:
Severity: normal Keywords: security, encryption
Cc:

Description

A great security addition would be the ability to encrypt passwords via javascript.

Advantages: - no need to buy an SSL Cert (more affordable) - safer for login via hotspot, etc. - extra security measure

Should fallover so it's possible to login without. For example:

- If JS is enabled, it should set a hidden <input/> to give the thumbs up for encryption. - If JS is disabled, the <input/> remains off, and login is via insecure plain text. - If server can't support it, it's off. Implementation could likely be done by piping to OpenSSL or an included class.

This is already done by sites like Meebo.

Example (and possible code to use, if licensing can work) here: http://www.ohdave.com/rsa/

1024bit RSA would be a big security gain. And this way there's no good reason for WP users with remotely modern browsers to not be encrypting.

Bonus points if you can serialize all form data and transmit encrypted.

Change History

03/27/07 16:55:12 changed by foolswisdom

  • milestone changed from 2.2 to 2.4.

12/09/07 19:07:55 changed by fergbrain

  • type changed from defect to enhancement.

This should be filed under 'enhancement', not 'defect'

12/27/07 04:53:05 changed by davidszp

+1 for this, since SSL is difficult to set up on some shared hosting accounts and the password is the most important piece of information generally transmitted to WordPress (think posting from open WiFi? hotspots, etc.).

If the BDS license in use is compatible, the JavaScript? libraries provided by the Clipperz online password service at http://code.google.com/p/clipperz/ may be usable as well as the ones mentioned already.

12/28/07 08:44:13 changed by westi

  • milestone changed from 2.4 to 2.6.

These feels like plugin material to me.

01/06/08 04:53:31 changed by kalgriffen

I believe this should be included in the core. User security should be a priority for any software application. Encrypting the password, for those browsers that have javascript enabled, would go a long way towards increasing security. Having the ability to turn off javascript encryption for those sites that use SSL could also be an option. Just my two cents.

01/06/08 05:04:50 changed by darkdragon

I agree. However, submit a patch. I would, but well, this is beyond my ability. There might be a JavaScript library already that does this.

You might have to convince Westi that this is a good idea, but as long as it works, then you have my support. Not that it means much, but good luck to anyone that takes on this issue.

01/06/08 15:39:34 changed by kalgriffen

Ok, here are my thoughts on how to implement this. The most secure encryption, to my knowledge, uses public and private keys.

If we generate a public/private key pair when wordpress is installed, or updated from a version that does not have a key pair, we can send the public key to the user inside the login page. A simple javascript could then encode the password using the public key and send it back to the server when the user logs in. The password is then decoded on the server side using the server's private key, and authenticated against the user's password.

We would also need an additional value to be sent to the server from within the form to indicate if the password has been encrypted (indicating the user has javascript enabled), or that the password has not been encrypted (indicating javascript is disabled).

Any thoughts on how strong a key we should use? I was thinking 128 or 256 bit, but we could easily use larger keys. Keep in mind that a longer key will require more processing power, and time, during the install.

06/27/08 14:12:01 changed by pishmishy

  • keywords changed from security, encrypt, tinfoilhat to security, encryption.
  • status changed from new to closed.
  • resolution set to wontfix.
  • milestone deleted.

I'm not sure that the public/private key bit is relevant. You need a secure means to transfer one of the keys to the other end point - that you're not likely to be using a public hotspot at the time of install isn't good enough.

As for Clipperz - I believe it only provides secure local storage of passwords, it doesn't secure the password in transit to a web application.

I believe that this ticket is asking for a challenge/response system implemented using Javascript/RSA. This'll be very complicated to get correct. It's planned that 2.6 will have better support for https protected admin pages. SSL is tried and tested and doesn't introduce code that we need to maintain.

Closing as WONTFIX. A working and tested plugin implementation would do much to persuade me otherwise.