We've gone the extra mile here protecting your data and we've proved it!
Dec 2016
Live Webapp Security
John Ince
Safe and Secure
How's our security? If you're considering a new technology you need to know how it stacks up again a regular secure website. We've gone the extra mile here protecting your data and we've proved it! Need an online fortress with a moat?
So are you all Security Theory?
In 2012 we released the very first version of our live framework. We knew right from the start that it would be of the upmost important to 'prove' our new technology was safe and secure practically. We decided that the best way to test our security model was to throw our software into the wild. But how do we attract hackers to even look at our security test webapp? A honeypot? Cash Clamber was born, based entirely on our live webapp framework and smart connections. We offer free bitcoin (a digital currency that's like cash for the Internet) for playing games. It's been a busy website and we've hundreds of players each day sending millions of application messages down our smart connections, it stress tests our live webapp framework too! Would it surprise you if we said it's hacked all the time? We know, since we monitor it in real-time. We raised our head above the digital currency parapet and said shoot us! We're still online, playing games for bitcoin 365/24/7 today! Does that answer your question is it secure? Let's step into why it's so secure...
It Starts with our Build Process
To create a running software application there's a process that we go through to turn our source code into a language that the machine understands. That's our build process and we've put a lot of effort into automating ourselves here. There's actually three distinct parts to our live webapps, the code that runs in the cloud, the code that displays the data in our browser hosted UX (User Experience) and our smart connections, which is the connection and data transmission between the webapp and browser. Let's tackle each one separately in regards to security.
Browser Code Minification and Obfuscation
Let's start with the bit that runs in the web browser. This is where our forms, controls and user interaction live. We've a browser user interface BUT that's all it is. Our real heavy duty business logic code hides safely in the cloud. We use the regular browser technologies like HTML (markup language a browser understands), CSS (a way to style the markup language in a pretty way) and JavaScript (a programming language to bring our UI to life). Using these technologies we can do the pretty visuals. When we write this JavaScript code we want to be really descriptive with our labeling using meaningful terms. It helps us understand what we have written in code and maintain it. But, it also helps someone looking at our code to understand our code. It's JavaScript right, all a hacker has to do is open the browser 'Development Tools' or 'Inspect' and it's all there to see. As part of our build process we minify and obfuscate our browser JavaScript code. For example, 'JuicyOrange' becomes '_zx', it's shorter and you wouldn't know it's a juicy orange. So the code can't be read and it's smaller to download to the browser. Try it yourself on any of our webapps just F12 and browse the source code. Impressed? Nothing is understandable or searchable. Most hackers simply move onto easier lower hanging fruit. Each new build generates new code words, 'JuicyOrange' is now 'cvy'. It's much too big to cover here in its entirety but we'd be happy to talk you through it.
Webapp Code is in the Cloud
You can't read our code in the cloud, even if you could access our server and browse around. It's a program, the simple binary output created by our build process that only a computer can read. Open it up in as text and it doesn't mean diddly-squat! Our source code is firmly locked away on our development machines and in our secure online source safe. None of our or your business algorithms are readable to a human being. We're not a website either with most hacks aimed at specific vulnerabilities, most hackers presume we're a website and conventionally poke at us this way. It's not going to work. But what about any databases that we use? We've gone the whole nine yards here too! We encrypt our database files using 256 bit AES (Advanced Encryption Standard). You simply cannot read it, open it, query it in a third party tool or glean any precious business information without the key. You guessed right too, the key's not on the server either. So we've secure code and unreadable data. Should keep your business out of trouble in the doomsday scenario of someone making it onto your server. There's nothing of value to steal or sell.
The Foundation of Smart Connections is Sockets or rather WebSockets
What's sockets? Just a little backgrounder in how remote computers talk to each other. Each computer has it's own unique phone number, called an IP address. Each phone number has a number of extensions, called a port. If you know a computer's IP address and port then you can potentially send data between both machines in either direction. It's called a socket connection. It's how your normal web server works too but the connection is always instigated by the browser and broken at the end of a request. A relatively new HTML5 standard specification defines the a WebSockets protocol. It's simply a way to create a second fixed connection from a web browser to the same or another server. This is NOT a make and break connection so the server can initiate the conversation too. So what? Currently to make a website appear live the browser needs to ask the server constantly if anything has changed, waste of data, energy and power. With the new fixed connection the server can PUSH changes only when they happen. If you're confused we're more than happy to explain the significance of this in more detail. So with our new found knowledge let's continue.
We rolled our own HTML5 Websockets Server
You can pick up an pre-coded websockets server and simply use it! But we wanted much more control of the performance and the security so we took the specification and coded it in c++, we created probably the fastest websockets server on the web, a hot rod tuned to the hilt that can manage application messages in microseconds. It's fast enough for head to head online gaming. We also wanted to add in our own multi-level security layer. Websockets are natively cross domain. Normally on a website a browser only allows code from the website domain to run. This stops hackers writing their own code and applying it to your website. But a websocket on our webapp could be accessed natively by anyone's code, potentially a hacker. We wanted more control and security than this, and so our smart connections were born.
Smart Connections are based on WebSockets
We're very, very selective about who we connect to and even more selective who we talk to, machine to machine. Our smart connections, which are several security layers above the raw websocket implementation, keep us safe! We only allow domains we specify to connect. We have a limited time, secret handshake negotiated between client and webapp. We have a secure websocket implementation to mirror HTTPS based on certificates. We checksum our application messages to ensure what is received is the same as what is sent. We validate message IDs and cross check parameters. That's just the start of what we do. We've built a fortress and a moat around our webapps. That's just the security aspect of smart connections, it's much bigger than this but that's another story!
Private Secure Webapps
Remember we're not just about websites, we build web applications. Not all of our client's webapps are for public consumption. They simply want an app in a browser that's private to their business but without the installation headaches. We can easily give them a none indexed private URL and restrict access via a login. But we didn't stop there. What if you only want your employees accessing at work, not a home? They've bookmarked the URL and can access on any device, phone, tablet, laptop from anywhere. We've built IP address only access. We can tie users to a location. Attempted logins from different IP addresses are sent to our admins who can optionally authorise multiple login locations. We are of course HTTPS and WSS (Secure Websockets) for our private, secure webapps. It's simply a great way to host secure private webapps with secure data over the public networks. If you want it all on your private network that's not a problem either.
We monitor our Security Errors in realtime
We've built an excellent, browser hosted admin panel for our administrators. We log everything that happens we feel is of interest. We log all our security errors for investigation. Everything we've discussed here from cross domain attempts to unauthorised IP login attempts are logged. We take your security very seriously. If there's an issue that's been blocked we want to know about it. Leave nothing to chance with your online world, knowledge is power!
Whatever you want you can have. If you want your company name next to that little padlock in the browsers URL bar, you got it! If you want just a regular webapp without the padlock then you got it! Our Cash Clamber bitcoin webapp isn't HTTPS, it's a regular HTTP connection. Is it safe? A bitcoin honeypot 365/24/7 since 2012 says it is! Basically it's your choice. Our webapps morph automatically to your chosen security level. If you go HTTPS then we allow a full credit card checkout without leaving your webapp, if HTTP then we offer payment via PayPal in the security of PayPal's own secure environment. Maybe the best way to think about all this security and technology is to not think about it! We got your back. We've proved our security! How do you test your security by the way?
Doing it differently since 2012. We're simply 10 years ahead. Our software is designed, coded, maintained, supported & hosted in the United Kingdom.
Why Project Peach?
The Hawthorn Gallery
DBD International
Knot 2b Missed
Monero Mine
About Us
Contact Us
Pay Us
Copyright 2020 Project Peach