http://www.frostjedi.com/terra/dev/rsa/index.php
And here's the source code for the demo:
http://www.frostjedi.com/terra/dev/rsa/index.txt
An explanation:
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:
Code: Select all
openssl genrsa -out rsakey.txt 512Note 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.
