Currently, unless you're using SSL/TLS, phpBB submits passwords in plaintext when users login. This isn't much of a problem unless you're on a potentially hostile network (ie. maybe a coffee shop where there's an evil twin or something) but if it is a problem then the phpBB Javascript Password Protection Format (JPPF) can help. Before discussing it, here's a demo:

The phpBB Javascript Password Protection Format (JPPF) is the concatenation of an OAEP-padded RSA encrypted string, an unencrypted string serving as the initialization vector, and an AES128-CBC-encrypted PKCS#7 padded string. The RSA ciphertext contains the randomly generated AES key and the AES ciphertext contains a nonce (generated by add_form_key) concatenated with the user password. The nonce protects against replay attacks. Even if, at some point, AES128-CTR were to be used (which would have the effect of turning AES from a block cipher into a stream cipher), the use of PKCS#7 padding would still be recommended as it obscures the password length.

Overall, the format is basically a lightweight version of PKCS#7 - the Cryptographic Message Syntax. In PKCS#7, encryptedKey contains the encrypted symmetric key, contentEncryptionAlgorithm identifies the symmetric key algorithm and the unencrypted initialization vector (eg. aes128-CBC and AES-IV) and encryptedContent contains the symmetrically encrypted data. Of course, where PKCS#7 provides for user selectable encryption algorithms, the phpBB Encrypted Login Format does not. If a different encryption algorithm is to be used, the javascript provided to the client should be updated.

The RSA public key is transmitted in the javascript used to perform the RSA encryption. In theory, this public key could be cached by a Firefox plugin or something and used to verify the identity of the server, however, in lieu of such a plugin, identity verification is not possible.

The default RSA key is 512 bits long. To speed key generation up, two-prime RSA is not employed, but rather, multi-prime RSA. In particular, eight 64-bit prime numbers are generated as opposed to two 256-bit prime numbers. This format, although discussed in PKCS#1 v2.1 (RFC3447#appendix-A.1.2), is not widely supported. It's also less secure then traditional two-prime RSA since determining the prime factorization of a multi-prime RSA key is faster than determining the prime factorization of a two-prime RSA key for keys of the same length. Stronger keys may be generated offline, either with rsa.php (in conjunction with the gmp extension) or openssl, via the command line, as follows:

Note that the techniques described here only protect the initial authentication - session_id's are still broadcast in the clear in the form of cookies. Short of using TLS/SSL, there's not much that can be done about that. That said, session_id's are also not in as dire need of protection as passwords are. In particular, session_id's can only be reused if your IP address is sufficiently similar to the one you logged in with, you still need to re-authenticate yourself to log into the ACP and a sniffed session_id will not reveal information that could be used to log into other accounts you control (email, other accounts on other message boards, etc) since it is, itself, completely randomly generated.

DIGEST-MD5 was also considered as a mechanism by which the password might be protected, however, DIGEST-MD5 requires, at best, a hash of the password be available for retrieval (which is what "htdigest -c .htpasswd realm user" provides). Unfortunately, light weight as this may be, it also doesn't work for authentication methods like LDAP authentication. There, the password might change independently of phpBB and phpBB would never know. As such, phpBB can't just cache the hash (well, md5('realm:pass:user')) when users change passwords through the UCP.

Additional protection through encryption is reliable. But there is one but.

Encoder (your code) is delivered to end user through the same channel, by which will be transferred encrypted password(which is completely controlled by attacker in any case). What prevents an attacker to completely replace encipher(your JS and HTML code) by own, which will send password as plain text?

In classical cryptography attacker have not full control over any side, only over channel. But it is not our case IMHO. In our case attacker have full control over user-side. So it is not enough only to cipher password. We must protect user-side encipher from being substituted by attacker i.e. not send encipher over this channel at all. But we have not any other channel, have we?

PS: I have not anything against JPPF. I only stated my opinion: it will not solve problem you raised.

FeyFre wrote:Additional protection through encryption is reliable. But there is one but.

Encoder (your code) is delivered to end user through the same channel, by which will be transferred encrypted password(which is completely controlled by attacker in any case). What prevents an attacker to completely replace encipher(your JS and HTML code) by own, which will send password as plain text?

In classical cryptography attacker have not full control over any side, only over channel. But it is not our case IMHO. In our case attacker have full control over user-side. So it is not enough only to cipher password. We must protect user-side encipher from being substituted by attacker i.e. not send encipher over this channel at all. But we have not any other channel, have we?

PS: I have not anything against JPPF. I only stated my opinion: it will not solve problem you raised.

There are passive eavesdropping attacks and active ones. This will do nothing to stop active eavesdropping attacks unless an as-yet-to-be-written Firefox plugin as discussed in the previous post were used, however, that doesn't mean that protecting against passive eavesdropping attacks is, all of a sudden, without merit.

Besides, to some random person off the street, it might not be possible to protect against active eavesdropping attacks anyway. ie. "The SSH server signature has changed? I don't even know what that means! Connect anyway!"

And even if you use a COTS product to create an evil twin or are just sharing the same LAN with your target victim and have put your nic into promiscuous mode actively rewriting the HTML the server sends out, although technically feasible, may not be practically so. At least not for the average attacker.

And what about average user:
1. Will password masters work in such cases?
2. What about JavaScript-disabled browsers?
3. What about CLDC devices? Will they have enough resources to perform encryption? Native browsers of mobile devices, Opera-mini, Fennec, etc etc etc? (For instance: my Nokia6233 native browser can browse phpbb forums on standard styles, and it is JavaScript-enabled, but I not sure it have enough resource to perform complex encryption algorithm).

I just want to be sure solution your propose will justify time and resources spent to implement it without noticeable losses for both server side, user side(and 3rd party contributors side too).

And what about average user:
1. Will password masters work in such cases?

If encrypted onsubmit then yes.

2. What about JavaScript-disabled browsers?

No.

3. What about CLDC devices? Will they have enough resources to perform encryption? Native browsers of mobile devices, Opera-mini, Fennec, etc etc etc? (For instance: my Nokia6233 native browser can browse phpbb forums on standard styles, and it is JavaScript-enabled, but I not sure it have enough resource to perform complex encryption algorithm).

RSA encryption is not nearly as CPU intensive as RSA decryption and AES encryption was never CPU intensive. Well, it is, I suppose, if you're going to encrypt two gigabytes, but that's not what's being proposed.

I count 50 kb of javascript code being referenced here and I see references to php libraries for performing cryptography. Who audited all this code and where is a guarantee that it does not have a bug that would allow someone to login with an incorrect password, or with no password?

nn- wrote:I count 50 kb of javascript code being referenced here and I see references to php libraries for performing cryptography. Who audited all this code and where is a guarantee that it does not have a bug that would allow someone to login with an incorrect password, or with no password?

All the protection scheme I've proposed doing does is encrypt / decrypt the password. It does not verify the password - that's still the responsibility of the authentication plugins (DB, Apache, LDAP). And if there were a bug that allowed people to login with incorrect passwords or with no passwords it wouldn't be in the crypto code that's being used - it'd be in the authentication plugin being used.

The worst thing that could happen is that the password would either not be encrypted (like it is right now) or it would be encrypted incorrectly (at which point it, presumably, wouldn't decrypt).

The only other thing I can offer is that the PHP code in question interoperates successfully with OpenSSL, per this:

The fact that the Javascript code successfully interoperates with the PHP code, which, in turn, successfully interoperates with OpenSSL, suggests to me that the code works. I'm sure there are bugs lingering in both packages but then there are bugs lingering in phpBB, too. I can't offer perfection and I think it's a bit unreasonable to expect it.

While this is certainly not a perfect solution, I'd love to see a patch for this in 3.1. I would suggest we enable it by default, but provide an option to disable it. Why might even want to disable it on SSL automatically.