This seems to be a question that for weird reasons hunts me. When senior developers are out of arguments to bash Phosphorus Five about, they end up attacking it claiming that it’s insecure.
First of all, the “install.sh” file, which installs Phosphorus Five on a Linux production server, will patch and update your Ubuntu Server. This makes sure that existing security holes are eliminated, and your Linux server is up to date. Then it will install a firewall, and shut down every single network port, except port 80, port 443, and port 22. This implies that the only traffic your web server will accept, is HTTP, HTTPS and SSH.
When it has done this, it will automatically suggest for you to install an SSL key pair on your server, and suggest that you redirect all insecure traffic (port 80) to the encrypted channel (port 443). Assuming you take its advice, this makes it impossible for an adversary to see what type of data you are sending back and forth between your client and your web server. In fact, every single bit transferred over the wire will be encrypted if you choose this path. This also eliminates that a “man in the middle” can steal your credential cookie, or perform what’s known as “session highjacking”. It prevents somebody else from “impersonating” your user, pretending to be you, to gain access to your server’s data.
Then it will install the very latest stable version of Mono, which actually is not that easy, since the default Ubuntu repository contains a version that is almost 5 years old. Needless to say, but the number of security holes fixed in later versions, are probably possible to count in the hundreds, if not thousands. So this further eliminates some 100-1,000 security holes, compared to the default Ubuntu repository.
Then it stops your web server from announcing what version your server is running. This is to prevent an adversary from gaining information about which software version your server is running, such as the Apache version, Linux version, etc. Then it will turn OFF the ability to override security settings using .conf files in folders. This is a major security concern, since it in theory allows an adversary with write access to your Apache web server folder to override your web server settings. This is globally turned OFF, to prevent a whole range of security holes, that otherwise might give an adversary control over your web server.
Then it prevents the serving of “.hl” files. This is strictly not necessary, but is an additional layer of security, preventing an adversary to see your web server’s source code, trying to find holes in them, to exploit these to gain access to your data. There is a general rule in security, which is “don’t say shit”, implying the less you communicate out about your server, the less information an adversary has to start out with, in order to crack into it. If you don’t know what system the server is even running, an adversary don’t even know where to start looking for ways to penetrate it.
As it installs your SSL key pair, it will even automatically renew your keys every 90 days. This is something which is often forgotten by a web server admin, effectively rendering your web server insecure after 90 days. The above are the stuff it does to your base operating system. In addition to these steps, comes the security implementations of Phosphorus Five itself.
The passwords for your users are stored as server salted, hashed values, in a protected file. Only a “root” account has read access to this file. However, even if an adversary somehow should gain access to this file, he’ll still not be able to see its passwords, because they will appear to be rubbish. This is done by first applying a “salt” to your password, for then to “hash” the combined value, and only then store this value as the “password” in the password file. Surprisingly many developers fails this step. Then when a user logs into the system, the same salt and hashing function is applied, and the password stored on disc, is compared to this “rubbish” value. So a password such as “Thi$I4M4P@sSwo4d” might become “C90obd+yAoJ2Lgy8YiSf2VLTbI041XRaxEzNrwwej6k=”. So even if an adversary gains access to your password file, which by itself should be impossible, he still wouldn’t be able to figure out your actual passwords. This “salt” is automatically generated might I add.
In addition to the above, Phosphorus Five implements “brute force password protection”. This is useful in case some adversary has a database of commonly used passwords, and is performing what’s known as a “dictionary attack”. At which point he might have a function that tries to log in thousands of times, every second, with different passwords. Implying at some point he’ll probably “get lucky”, and successfully log into your system, at which point he knows your password. Phosphorus Five prevents this by not allowing the same username to attempt to login more than once every 20 seconds. Implying a “dictionary brute force password attack”, will basically take a decade to be successful – Even with fairly simple passwords. This poses a problem though, which implies that if you are currently experiencing a dictionary attack, you can’t login from a new client. This is fixed in Phosphorus Five, by circumventing the “brute force protection”, if you have chose to “Remember me” on some specific client – Effectively (almost) eliminating this problem for all practical concerns, since most users will probably use the same device(s) as they use Phosphorus Five, where they are encouraged to “Remember me” by default. Yet again, the cookie stored on disc on the client remembering the user, is also hashed and salted.
The cryptography libraries Phosphorus Five uses, are developed in Australia. This is actually very important, since Australia does not have export regulations on cryptography, the was US has. For instance, some parts of the cryptography applied in Phosphorus Five, would purely from a legal perspective in the US, fall into the same category as exporting nuclear weapons from the US. However, since I am based in Cyprus, and the guys who are building my cryptography libraries are based in Australia, I am legally allowed to export these cryptography libraries, to any countries not on the “terrorist list” (North Korea, Iran, etc). So a US company cannot legally even come close to the strength of the cryptography functions I happen to have in Phosphorus Five, without risking (at least in theory) the **death penalty** for being in violation of US export laws. An example of how this further strengthens the security of Phosphorus Five, is how you can for instance easily create encryption key pairs as strong as 16,000 bits! Which is 4 times the strength that the NSA is using for their own sensitive emails and communication might I add. If you don’t trust the default RNG seeding function, you can also provide your own manual salt, which is **added** to the existing salt, and does not “replace” it …
In addition to this, I have consciously chosen to NOT support cryptography functions I find suspicious myself. An extremely good example of this is S/MIME, which I knew for a fact, years ago was inferior in regards to security to PGP. Of course nobody believed me when I told them then, might I add. S/MIME and PGP are two overlapping standards, arguably doing the same – And some few weeks ago my “suspicions” were confirmed. S/MIME contains several security holes that PGP does not contain. This can be found by reading up on the Efail security holes in regards to cryptography protocols.
For synchronous encryption, I am using AES. This is the synchronous encryption protocol preferred by the NSA, which the NSA encourages American public institutions to use for “extremely volatile information”. Phosphorus Five also support 256 bits AES. I might add that AES is also an encryption protocol that has been applied on several occasions by WikiLeaks, in addition to other intelligence organisations, such as FSB and Mossad. So this is a well proven encryption protocol, that is considered “impossible to break”, by all the security paranoid organisations on the planet today.
In addition to the above points, I could probably mention security details for days, without even repeating myself. And although there exists no guarantees when it comes to security, and I would of course appreciate a (*serious*) security report, reporting holes in Phosphorus Five – I can confidently assure you that I doubt you have ever seen a more secure framework on this planet than Phosphorus Five. Basically …
I have no troubles what so ever suggesting Phosphorus Five to the MI6, CIA, NSA, FSB, Mossad, WikiLeaks, etc. In fact, Phosphorus Five could probably keep your Nuclear Rockets safe!
If you do have a serious concern about parts of Phosphorus Five, in relationship to security, you can send me a report using the schema below.