Jump to content
Sign in to follow this  
Guest plutopark

The Ultimate Unhackable Server

Recommended Posts

Guest plutopark

I've never worked with servers, but one can't help to have noticed that there seems to be an endless variety of ways to hack them. With the growth of crypto-currencies, it seems like the current generation of server operating systems/applications is woefully outdated. Why is this? Is a new generation of architecture needed to provide the security that is required? Does anyone know if this is something that is being worked on, or are our so-called guardians of the internet and operating systems developers going to keep adding more plugs, band-aids, pieces of tape, and rubber bands to what already exists?

Share this post


Link to post
Share on other sites

Generally, the problem isn't the technology, it's the people.  You can secure the heck out of a server or any system, but as soon as you make it accessible to even one person it's significantly weaker.

There are many folks working on securing things, and many more working on breaking through those security systems.  The ultimate unhackable server is the one that's powered off and at the bottom of the ocean

Share this post


Link to post
Share on other sites

Security depends on the people that operate them. If they have enough skills, enough funding, and support from the management, they can "create" very secure servers.

But often security is not taken seriously enough, simply because it is expensive and because it doesn't directly generate revenue. The operators of such services expose themselves to larger risks (they can go belly up if they are hacked) in exchange for larger profits (because they don't pay so much for security).

 

 

Edited by T8493

Share this post


Link to post
Share on other sites
Guest plutopark

I suppose then that the server needs to be made unhackable from both sides of the fence. I mean, DESIGNED so that there is nothing that can be done from the inside that might create a vulnerability. A lot of people have worked on creating better programming languages - I don't know why this hasn't been addressed.

Edited by plutopark

Share this post


Link to post
Share on other sites
4 minutes ago, plutopark said:

I suppose then that the server needs to be made unhackable from both sides of the fence. I mean, DESIGNED so that there is nothing that can be done from the inside that might create a vulnerability.

 

If you wanted to design it that way, then you would have to design and produce your own CPUs, RAMs, BIOSes, kernels...... It is just not practical.

For example, when you run a program on PC, you trust Intel or AMD that your CPU executed your program exactly as it was supposed to.

 

Share this post


Link to post
Share on other sites

Yeah, and that's usually the goal.  The issue is that in order to be a "server" it must serve something, and with serving something, you're opening up a way to access the server.  That one access method (via HTTP, FTP, SSH, etc.) allows for all kinds of things to go wrong.  All of those access methods must be written (programmed) by humans, and humans are susceptible to error.  Let's say the programmer missed a cup of coffee the morning he was working on the access piece and he missed one little thing in the code.  That one little thing could be just enough for an attacker to gain access to that server. 

Share this post


Link to post
Share on other sites
Guest plutopark
1 minute ago, T8493 said:

If you wanted to design it that way, then you would have to design and produce your own CPUs, RAMs, BIOSes, kernels...... It is just not practical.

For example, when you run a program on PC, you trust Intel or AMD that your CPU executed your program exactly as it was supposed to.

 

That's like saying it's more practical to stick with a hardware/software system that is subject to human error, hackable, and could allow the loss of hundreds of millions (or billions) of dollars.

Share this post


Link to post
Share on other sites
Guest plutopark
2 minutes ago, sparr0w said:

Yeah, and that's usually the goal.  The issue is that in order to be a "server" it must serve something, and with serving something, you're opening up a way to access the server.  That one access method (via HTTP, FTP, SSH, etc.) allows for all kinds of things to go wrong.  All of those access methods must be written (programmed) by humans, and humans are susceptible to error.  Let's say the programmer missed a cup of coffee the morning he was working on the access piece and he missed one little thing in the code.  That one little thing could be just enough for an attacker to gain access to that server. 

Seems like the 'firewall' should check the incoming code for correctness, and completely reject if it not correct. I realize that then makes the firewall itself subject to hacking. Somewhere, there must be a solution, even if http needed to be completely done away with, and a better method/set-of-code utilized.

Share this post


Link to post
Share on other sites
Guest plutopark

I think the real impediment is that no one has come up with an architecture that can eliminate the possibility of human coding error.

Share this post


Link to post
Share on other sites
1 minute ago, plutopark said:

Seems like the 'firewall' should check the incoming code for correctness, and completely reject if it not correct. I realize that then makes the firewall itself subject to hacking. Somewhere, there must be a solution, even if http needed to be completely done away with, and a better method/set-of-code utilized.

 

Firewalls don't operate at application levels (see for example OSI model). They can detect just some "incorrect" requests, but not all.

Share this post


Link to post
Share on other sites
1 minute ago, plutopark said:

I think the real impediment is that no one has come up with an architecture that can eliminate the possibility of human coding error.

Exactly.  And additionally, a way to eliminate the general failures of humans in general.  Some people really, really need to click on that e-mail that says "Click here and you'll win a million dollars! Oh and give us your password please...."

Share this post


Link to post
Share on other sites
2 minutes ago, plutopark said:

I think the real impediment is that no one has come up with an architecture that can eliminate the possibility of human coding error.

There are some automatic provers, but they don't operate at the level of whole operating systems and services.

 

Share this post


Link to post
Share on other sites
6 hours ago, T8493 said:

There are some automatic provers, but they don't operate at the level of whole operating systems and services.

And if there were such automatic provers, you best hope they don't have a bug... 

The reality is that an "unhackable server" is a virtual impossibility; even if your software is entirely bug-free, they tools you use to compile it might not be. The firmware controlling your hardware might have a bug. Even the hardware itself might have issues. Modern computers are insanely complex beasts. The average hard drive likely has more computing power than a shiny top-of-the-line Pentium had back in 1993 and runs a real-time OS along with custom (and almost certainly buggy) firmware.

The best you can hope for is that developers work to minimize bugs. Sadly, most don't because that it's a luxury that most companies can't afford: few people can afford the kind of slow, deliberate work it takes to deliver quality software.

Luckily, at Ripple, we not only have technical people of the highest caliber but we also have management to match, all the way up to C-level executives. They understand the importance of allowing us to take the time to get it right.

If I can focus on the rippled team for a moment: we take pride in our code and are dedicated to delivering the best software we can. We know how important it is and how much is riding on our work. To be sure, we aren't perfect but we've iterated on our process for the last three years, we've learned from our mistakes, and are continually refining our code to make sure that it's as good as we can possibly make it.

Share this post


Link to post
Share on other sites
1 hour ago, nikb said:

[...]

Luckily, at Ripple, we not only have technical people of the highest caliber but we also have management to match, all the way up to C-level executives. They understand the importance of allowing us to take the time to get it right.

If I can focus on the rippled team for a moment: we take pride in our code and are dedicated to delivering the best software we can. We know how important it is and how much is riding on our work. To be sure, we aren't perfect but we've iterated on our process for the last three years, we've learned from our mistakes, and are continually refining our code to make sure that it's as good as we can possibly make it.

On a more funny note: for the people that didn't know yet, this is where the term 'Soon™' came from. When asking Ripple folks when specific features on RCL would be ready and go live, @nikb often answered: 'soon'. (not sure if he actually trademarked the term, or everyone just thinks of nikb when the word is used in this context)

When asking how soon was soon, he commonly answered that the feature is already 100% coded and functional (the moment 'normal' companies just push it live), but that it has to go trough a thorough testing phase before they are willing to push it out to the open. And that can take quite some soon™.

Share this post


Link to post
Share on other sites
41 minutes ago, Eik said:

On a more funny note: for the people that didn't know yet, this is where the term 'Soon™' came from. When asking Ripple folks when specific features on RCL would be ready and go live, @nikb often answered: 'soon'. (not sure if he actually trademarked the term, or everyone just thinks of nikb when the word is used in this context)

When asking how soon was soon, he commonly answered that the feature is already 100% coded and functional (the moment 'normal' companies just push it live), but that it has to go trough a thorough testing phase before they are willing to push it out to the open. And that can take quite some soon™.

To my knowledge Soon™ originates from the announcement of the Market Maker Incentive Program, which was displayed as "Coming Soon" well over a year, on the XRP Resources page (don't get fooled by the date of August 23: the announcement actually dates from February 29 2016). The delay of releasing program details was discussed many times, such as here and here. The program has always been considered very relevant in solving the chicken and egg problem of RCL liquidity. But maybe that problem is solving itself now. Although the page with the dreaded and embarrassing Coming Soon announcement is still up, they removed the link from the XRP Portal navigation. I think we may consider that a step forward.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×
×
  • Create New...