Sephia Five’s technical security implementation details

This is a fairly technical blog, mostly intended for developers, such that they can verify the security measures in Sephia Five. Hence, it is intended as a starter guide, for people interested in checking up how strongly secured Sephia Five actually is.

I make some pretty bold claims in some of the material I have created for Sephia Five, and some developers might be suspicious about some of them. However, it is actually quite easy to understand, once you understand the details of the implementation. Below are some of the security measures I have taken while creating Sephia Five.

SQL insertion attack

This is a big one in our industry. Many novice developers aren’t even aware of the problem, and it comes from the fact that developers tends to concatenate input from users directly into their SQL statements. This creates a whole range of problems, based upon the fact that you can never guarantee that the user is not providing malicious data in his forms. Imagine something like the following for instance running on the server.

var sql = string.Format("select * from contacts where name like '%{0}'", searchQuery);

The problem with the above approach, is that the searchQuery might contain data such as the following.

foo';\r\nselect username, password from users;//

If the user supplies a search query such as the above, instead of retrieving the contacts, the end user will retrieve all usernames and passwords. Simply because the above SQL command will transform into two commands, looking like the following

select * from contacts where name like '%foo';
select username, password from users;//'

Hence, you will very effectively have created a security breach in your application. Few novice developers are aware of the above problem, and hence it is a very real and common problem in our industry. A couple of months ago, a research laboratory in Telemark, Norway was plagued by the problem illustrated above.

Sephia Five completely avoids this, by never concatenating SQL with data supplied by the user, but instead uses what’s commonly referred to as “SQL parameters”, which will completely avoid the above problem.

HTML injection

Any app that is intended to run in the browser is a potential candidate for HTML injection. This allows a malicious user to inject HTML into your client, by for instance sending you a dubious email. This could be done by creating an email with a subject, which is actually a JavaScript inclusion directive, executing some malicious piece of JavaScript, that compromises the client reading the email.

This is avoided in Sephia Five by always making sure that we HTML encode everything from received emails. This makes it impossible to create malicious HTML, that will compromise the client. In Sephia Five, HTML encoding is performed on everything we show in the browser, that originates from a received email. Including the email address,  sender’s name, subject, body, etc.

In addition, the few places where Sephia Five actually needs to display HTML, such as when converting Markdown to HTML, it will run the resulting HTML through a “whitelist”, excluding all tags, that are not considered 100% safe. This makes it impossible for an adversary to include malicious code, in some email, that creates a security breach once the email is displayed.

Server side salted hashed password storage

Sephia Five is built on top of Phosphorus Five, which is an extremely defensive full stack web application framework, built from the grounds up with security in mind. Among other things, no passwords are ever stored in clear text, but rather as server side saltet hashed strings, implying even if an adversary should physically gain access to your user password file, he can still not find out what the passwords for your users are.

This file is not accessible for any “non root” account in Sephia Five, which further reduces the risk of having passwords spread out in the wild. Many software vendors will simply create a “users” table in their database. This implies that every single user that has access to execute SQL queries towards your database, has access to also your authentication and authorisation database. In Phosphorus Five, the user objects, are stored outside of the actual database. This implies that even if an adversary could get physical access to the database, he would still not have access to any credentials for its users. This is “yet another layer of defensive coding”, created with the assumption of that “everything that can go wrong, will go wrong”. When you add that fact on top of that the passwords are stored as salted hash values, it becomes almost entirely impossible, even on a theoretic level, for an adversary to gain access to passwords that belongs to your users, without applying social engineering.

We are also working on further tightening this area of P5 constantly.

Virus protection

A friend of mine told me that my “100% perfect virus protection” claim sounded too good to be true, so I thought I’d take the time to explain it, such that you can understand its technical details for yourself.

First of all, assuming you’ve guarded against the above problem; HTML injection – Virus is spread to a client exclusively by having a user download an attachment, which is able to execute code on the client. One of the most notorious type of attachments spreading virus, is actually (surprise) PDF documents, since the PDF format contains support for scripts. In fact, PDFs are according to a study I once saw somebody reference responsible for more than 50% of all malware on the internet! This means that an attachment that might otherwise seem to be innocent, can sometimes include malicious scripts, that compromises the client.

In Sephia Five we have fixed this, by allowing the sys-admin of an installation choose which attachments are legally allowed to be downloaded. This means that a sys-admin could allow only file types that cannot contain virus, not even in theory. There exists some few file formats that are considered to be 100% safe. Some examples are given below.

  • Most image formats such as .png, .jpeg and .gif, assuming your image library doesn’t have a buffer overflow bug
  • Plain text files, such as .txt
  • Most video formats, such as .wav and .ogg, assuming the same as with images

If you create your whitelist to only allow filetypes that are considered to be 100% safe, it is impossible for a user to download a file, that might potentially contain a virus, or some other malware. And you get “100% perfect malware and virus protection”.

Of course, this would for most practical concerns render Sephia Five very difficult to use, since for instance .pdf files would not be possible for your users to download. We have therefor created two such “whitelists” in Sephia Five. One which contains all safe file types, and another that contains all potentially dangerous file formats, which most users still would probably want to download none the less.

If a user tries to download a safe file, everything is all cozy and warm. If he tries to download a file that is on the “warning list”, he will be properly warned, hopefully resulting in that he thinks a couple of additional times, before he actually opens this attachment.

So even though Sephia Five is possible to configure such that it is indeed 100% perfect in regards to virus protection, such a configuration would probably be considered “too much” for most users, since it would not allow even pdf files, not to mention Microsoft Office files, etc. However, this doesn’t stop the user from configuring Sephia Five into such a configuration, which would basically imply that Sephia Five would have the same extreme security measures that were expected out of military grade email systems.

Hence, if somebody like the CIA, MI6, etc, where to install Sephia Five in their most top secret environments, I would not be surprised in fact. Simply since Sephia Five can easily be setup such that it indeed is a military grade email system, intended to run in top secret environments.

Phishing protection

Most security breaches today are variations of what is commonly referred to as “phishing”. For instance, I often get emails that apparently originates from PayPal, attempting to have me “verify my account”, or “upgrade my security”. Often these emails originates from domains such as “paypayl-security.somewhere.com”.

In most other email systems, you wouldn’t even realise that these emails originates from a different domain, than that which you’d normally expect from emails coming from PayPal. This is because these URLs are rendered with anchor text, displaying stuff such as “paypal.com/security”, actually leading you to “mafia.com”.

Sephia Five will never display HTML emails. This means that a URL like the above, will reveal itself for what it actually is, and not be able to masquerade itself as something else. Implying that before the user clicks the URL, he can clearly see with his own eyes where the link will lead him, further reducing the possibility of that he’ll actually click it.

A lot of security breaches can easily be avoided, by revealing that which is hidden, and attempts to trick the mind of your users, into doing something they falsely believed would yield a different result, than that which it actually gives them. This is a mindset first and foremost, and a mindset that we have developed to the extreme!

No leaking business logic

There are never any “business logic” executed on the client. Most Ajax web apps of today, are built with lots of JavaScript, doing a lot of wiring, and often even business logic on the client. In Sephia Five, there is not as much as a single line of “business logic” JavaScript ever being executed on the client. This makes it literally impossible for an adversary to compromise a client, and such become capable of indirectly compromising the server, through the compromised client.

This means that all relevant data for usage of Sephia Five, is exclusively stored on the server, eliminating a whole range of problems, that would often surface in other systems, built with other types of architectures. This is due to the design of Phosphorus Five, and its concept of “Managed Ajax”.

RNG entropy

Literally every single famous last words on the planet is a variation of “I trusted it”. According to the maintainers at Bouncy Castle, which Sephia Five is using internally for all things related to PGP, their random number generator is rock solid. Bruce Schneier recently wrote a blog about this problem, where a group of adversaries, could predict when a slot machine would pay out its next winner – Simply because their random number generator was predictable.

When you deal with cryptography, random numbers are always a problem. If an adversary could predict the random numbers generated by a specific system, he could predict things such as for instance the creation of your PGP key pairs, etc.

We have fixed this, by adding to the entropy of Bouncy Castle whenever it is creating a PGP key pair, in such a way that two different systems, would never be, not even in theory, capable of creating the same random numbers. We do this by adding the server salt to the RNG as a “seed”, in addition to several other things, which all in all, adds an extreme amount of entropy to your RNG. However, in addition, when you create a PGP key pair, you can also explicitly seed it yourself, through the GUI, by adding any number of characters. This would not “set” the RNG’s seed, but rather “add” to it, and hence make it possible for you to create 100% perfectly unpredictable random numbers, making the process of “guessing” your key pairs configuration, literally impossible. Assuming the RNG in Bouncy Castle does not have some dubious bug though!

This is referred to as “defensive coding”, where you assume that “everything that might go wrong, will go wrong”. Hence, the art of security becomes to eliminate any potential places where things might go wrong.

PGP key pair strength

According to conventional knowledge in our industry, 1024 bits keys are not considered safe. 2048 keys are “probably” safe, and 4096 bits keys are “definitely safe”. In Sephia Five you could, if you wanted to, create PGP key pairs as strong as 8192 bits key strength. This is probably overkill, and way more than what’s necessary. However, in an extremely paranoid environment, “probably” doesn’t exist. As you create these extreme PGP key pairs, you can also provide your own RNG salt, which further eliminates an adversary’s ability to break your key pair. All in all, resulting in an extremely defensive environment, having some extreme security measures, allowing you to have an environment for your email communication, probably outperforming anything else out there in existence today!

Sephia Five is not identifiable

This might come as a surprise to my readers, but all attacks on a computer system, starts out with attempting to figure out what you’re dealing with. Hence, a simple logo, giving away the name of the system, is actually a potential security breach. Sephia Five does not even give away its name, not even in its GUI – And definitely no places in the data it transmits to other systems, such as when it sends an email.

Sephia Five will never identify itself when it sends an email, and even if an adversary physically bends over your shoulders, as you are reading your email at a coffee shop, he will understand what system he is dealing with. In fact, we also encourage all of our customers to never brag or tell anybody what email system they are using. Simply because if you do, you have reduced the potential candidate systems an adversary needs to investigate, and/or test for, down from a “gazillion” to _ONE_!

Facts are, nobody outside of your most trusted colleagues should know “jack shit” about anything within your organisation’s IT structure, including probably also most of your employees, since they simply don’t understand these risks. If you “brag” about your security, and its technical specification, you are unwillingly giving a potential adversary valuable information, which he can use to break into your system. This is true for not only email, but also every other aspect of your IT infrastructure.

Now of course, for us the situation is different, simply since we would want other developers to know as much as possible about Sephia Five, such that they could help us out, and find potential security breaches in it. But for you, the game is to never even let an adversary know where to even start looking!

Do me a favour, and check out this website, and/or other material from us, and see if you can find a single reference to our customers. Facts are, you will never find a “happy customer testimonial” on this website. Simply because it is a potential security breach. We encourage you to treat us the same way as we treat you, which is basically; Don’t say shit!

For the record

We also have other security counter measures, which we don’t publicly speak about, which are of non-technical character, intended to further reduce the possibility of a data breach. Hence …

Can you keep a secret? Me too, so fuck off! 😉

Some of these security measures are of a nature, that only allows for us to speak about them, in a one to one conversation with our customers. See below if this is of interest to you …

Disclaimer

If you wish to use a configuration such as illustrated above, to create a security configuration, matching that of the CIA, MI6, etc – You would probably want to be extremely defensive when installing Sephia. Sephia Five is built on top of 3rd party libraries and components, some of who might contain security holes. Hence, if you’d like to go this route, I would for instance recommend you to not exposing the system to the internet, but rather install it on your local area network – In addition, to configuring the system much “tighter” than what would be feasible for most other users. This would also eliminate a whole slew of other potential user errors, such as people bringing out top secret material, in the form of simply being able to read their emails on their phones, while having adversaries simply peeping over their shoulders, etc. However, all in all, in an extremely defensive environment, Sephia Five could easily perform within “MK-Ultra requirements”, if it was being setup by an extremely skilled sys-admin, to perform to the point which you would expect out of even the most heavily secured systems, intended to run in extremely top secret environments.

In the end though, no system is more secure than its weakest link – Which is almost always humans. For instance, a whole range of problems might arise simply by the way you’ve configured your MySQL database, and Apache – Which is completely out of our control when you simply download it yourself, and install it on your own server. If you’d like to be extremely defensive in these regards, and make sure your system is correctly configured, we do provide help with this for professional customers, wanting to ensure their security and privacy.

We also provide training of staff and employees, which in the end, regardless of how secure your IT infrastructure is, becomes the defining factor of how secure your organisation actually is! All we ask of you, is to give us a simple declaration of good faith, such that we can be certain of that we don’t get in trouble by helping you! We provide security services and products, at a level previously unseen in the commercial market, which creates a situation for us, where we need additional compliance in order to make sure we do not break international law!

If you’d like to hear more about our offerings in these regards, feel free to toss us an email using the form below.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s