And here's the source code for the demo:
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 512
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.