Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 10 of 11 total
Thread How is security handled in EWB2 ?
Mon, Nov 14 2016 8:12 PMPermanent Link

TD

Advanced Data Systems, Inc.

I am new to EWB2 and I need help in understanding how security is handled in apps created with EWB2.  Is this information in the manual or does each developer roll their own?

FYI, I will be using the EWB2 web server on a Windows server and will also be using EDB.

Thanks,
TD
Tue, Nov 15 2016 5:00 AMPermanent Link

Matthew Jones

TD wrote:

> I am new to EWB2 and I need help in understanding how security is handled in apps created with EWB2.  Is this information in the manual or does each developer roll their own?
>
> FYI, I will be using the EWB2 web server on a Windows server and will also be using EDB.

An interesting question. The answer is complex I think, and on multiple levels. First, the EWB server connection is using HTTP, so you currently need to use a tunnel if you want HTTPS (search these groups for details). You may not need over-the-wire security if all internal though.

The database security is done by restricting access to prepared queries etc on the server. So you cannot just pop some arbitrary SQL to the server and delete everything.

In the browser, nothing is secure - you have to assume that the end user can see all the data (they can!) and understand the code. You can though "compress" the code so it is minified and becomes unreadable. I would recommend this as part of a build process to ensure it is never released without this option accidentally. You generally want to debug with the code readable, so not just compiling in the IDE makes it more reliably done.

The browser also reveals all the data being sent back and forth. Some security by obscurity might be handy here, though obviously not foolproof. For instance, in one application I mangle (using something like ROT13) data, and append a random set of characters to ensure that the data being sent doesn't look like something obvious. (As in, you type 3 characters, and 3 characters get sent, now you can see how to fake it and crack the system. Always 27 random looking characters means more work. Not hard perhaps, but might put some people off.)

Note also that encrypting in the browser application is probably not a good thing, as the key is obviously in the browser. (Hence me obfuscating data instead - a compromise).

But overall, EWB is as secure as any web system is.

--

Matthew Jones
Tue, Nov 15 2016 1:50 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

<< I am new to EWB2 and I need help in understanding how security is handled in apps created with EWB2.  Is this information in the manual or does each developer roll their own? >>

I'm going to repeat some of what Matthew has already said, but I just want to hit the high points:

If you're web application is facing the Internet, then you will want to use:

1) Stunnel as an https reverse-proxy that handles all traffic to/from the EWB Web Server.

2) EWB web server modules to handle logins/API calls on the server side.  You can see an example of this with the login example project, which includes an example loginmodule web server project for Delphi XE or higher.

3) You probably also want to use EWB web server modules for all data access, using the the TEWBDatabaseAdapter and TEWBDataSetAdapter components to handle shuttling data to/from TDataSet-descendant components in Delphi.  The reason for this is that the basic dataset handling that is included with EWB relies on the database engine to provide authentication, which may or may not be sufficient in your case.  With the adapter components that we provide, you can intercept this authentication process and provide your own, which will probably be safer and more flexible.

Tim Young
Elevate Software
www.elevatesoft.com
Tue, Nov 15 2016 6:32 PMPermanent Link

erickengelke

"Matthew Jones" wrote:

>An interesting question. The answer is complex I think, and on multiple levels. First, the EWB server connection is using HTTP, so you currently need to use a tunnel if you want HTTPS (search these groups for details). You may not need over-the-wire security if all internal though.

As usual, an excellent answer from Mathew Jones.  I hope you don't mind if I add to it.

> The browser also reveals all the data being sent back and forth.

Yes, and hackers look at that data.  Techniques to make it harder to decipher are good.


>Note also that encrypting in the browser application is probably not a good thing, as the key is obviously in the browser. (Hence me obfuscating data instead - a compromise).

When you use public key cryptography, the encryption key is not the same as the decryption key (usually called the public key and the private key respectively.)  The browser has only the encryption key, and the server never tells it the decryption key.  

The trick is employing large math problems that are easy to solve when you know the private key, but so highly improbable that they are likely to be never solved without that key given all the silicon in the known universe.

In my upcoming book I show how to use public key cryptography along with TLS and other techniques to build mathematically proven security that is impossible to break using known techniques.  And it's employed just by calling some functions: no hard math for you!  The password the browser shows in transmitted packets is encrypted and unreadable.

I'm waiting for the proofreader to finish with the book.  That could take another few days.  
I'm very excited about it.  And source/libraries will be available on my web site.

> But overall, EWB is as secure as any web system is.

I'd say EWB can be as secure as any web system, or as insecure as any web system.  The implementation is left to the programmer to handle or mishandle.  

For those interested in my book, I provide free libraries that can be used to raise the bar very high.

Erick
Wed, Nov 16 2016 5:37 AMPermanent Link

Matthew Jones

erickengelke wrote:

> > Note also that encrypting in the browser application is probably not a good thing, as the key is obviously in the browser. (Hence me obfuscating data instead - a compromise).
>
> When you use public key cryptography, the encryption key is not the same as the decryption key (usually called the public key and the private key respectively.)  The browser has only the encryption key, and the server never tells it the decryption key.  
>
> The trick is employing large math problems that are easy to solve when you know the private key, but so highly improbable that they are likely to be never solved without that key given all the silicon in the known universe.
>
> In my upcoming book I show how to use public key cryptography along with TLS and other techniques to build mathematically proven security that is impossible to break using known techniques.  And it's employed just by calling some functions: no hard math for you!  The password the browser shows in transmitted packets is encrypted and unreadable.

Hmmm. Not sure that helps any. Perhaps you could explain more. You may have the strongest encryption available (though that might take some processing power that eats browser time), but you have the key to encrypt with right there in the browser too. I can take that key, encrypt with it, and send to the server just the same. Just the same as if it were in plain text in the browser too, but a little more complex. How did that help really?

--

Matthew Jones
Wed, Nov 16 2016 6:35 PMPermanent Link

erickengelke

"Matthew Jones" wrote:


> Hmmm. Not sure that helps any. Perhaps you could explain more. You may have the strongest encryption
> available (though that might take some processing power that eats browser time), but you have the key to
> encrypt with right there in the browser too. I can take that key, encrypt with it, and send to the server just the
> same. Just the same as if it were in plain text in the browser too, but a little more complex. How did that help really?

The first thing to understand is that public key cryptography is also known as asymetric key cryptography.  This means the encryption key you use to encrypt something is totally different (asymetric or unequal) than the decryption key, and the public never see the decryption key, it's hidden on the server.

So... in JavaScript we kinda say jiberrish := encrypt( mypassword ), then we send that jibberish out the network.  Even if you look through the computers transmit logs, or cache, or browser logs, jibberish is unreadable.  You do not have the necessary secret to decrypt jibberish. Even if you know the formula, it doesn't help you solve the problem, it's not like ROT-13 where there is a reversible trick, it's just plain hard math.

In other words, the password is never sent clear-text OR even reversible without the secret decryption key that the client doesn't have.

I know that is counter-intuitive, but it was a major application discovery in mathematics to a class of difficult problems.  RSA were the first researchers to think of this application, but others have put forward other, even more difficult strategies since then.  The current one is based on points on an elliptic curve.

It's also the basis of SSL, which is why you can encrypt data going to a server, but you cannot decrypt other people's data going to that same server.  You simply don't have the key.

The point being, the attacker can have total control of your computer, or be a man-in-the-middle (MITM), but still never be able to retrieve your password.  Passwords are the holy grail of hacking because you can do anything to a system when you have passwords.

The system we use also prevents people from inserting bogus transactions, because each network transaction has the password encrypted into it and they are always changing, you cannot even replay a previous transaction because there is a sequence number that cannot be reused.

For each transaction there is a one in 4 billion chance the person can guess the right value, and there isn't enough time to mount a successful attack.

I've condensed a couple of pages of description to write this, I hope I've made it a little clearer.

Erick
Wed, Nov 16 2016 9:41 PMPermanent Link

Raul

Globestar Systems

Team Elevate Team Elevate

On 11/16/2016 6:35 PM, erickengelke wrote:
> So... in JavaScript we kinda say jiberrish := encrypt( mypassword ), then we send that jibberish out the network.  Even if you look through the computers transmit logs, or cache, or browser logs, jibberish is unreadable.  You do not have the necessary secret to decrypt jibberish. Even if you know the formula, it doesn't help you solve the problem, it's not like ROT-13 where there is a reversible trick, it's just plain hard math.

This is the key question right here - how does your JS app get access to
the server cert ?

In case of TLS certs are handled at browser communication layer and not
really visible to the JS app.

AFAIK JS apps have no visibility into underlying browser/OS certs.

Web Crypto API is still preliminary so not something that one wants to
use at this time.

Raul

Thu, Nov 17 2016 4:39 AMPermanent Link

Matthew Jones

erickengelke wrote:

> The point being, the attacker can have total control of your computer, or be a man-in-the-middle (MITM), but still never be able to retrieve your password.  Passwords are the holy grail of hacking because you can do anything to a system when you have passwords.

But that isn't the problem being solved.

The key is, if it is in the browser, I can have full access to it. I have the text "password", and the code can encrypt it with the public key. It is then sent to the server along with a request to change a record. All fine, it's my code.

The hacker then wants to do the same, so he takes the password from the variable, encrypts it with the public key he got from the code, and sends the command to delete all the data. Encryption *in the browser* added nothing because the hacker has everything.

If you want to stop anyone seeing what is going down the wire, then HTTPS is indeed the solution, and works as you suggest. But that is connection encryption, not data encryption.

Now, if you want to stop the user seeing the content of the HTTPS calls in the browser network traffic analyser, then applying some sort of transform is worth doing. But full on public key encryption is expensive in processing time, and no better than a simple obfuscator even like base64.

--

Matthew Jones
Thu, Nov 17 2016 8:15 AMPermanent Link

erickengelke

"Matthew Jones" wrote:

erickengelke wrote:

>The hacker then wants to do the same, so he takes the password from the variable, encrypts it with the public key he got from the code, and sends the command to delete all the data. Encryption *in the browser* added nothing because the hacker has everything.

The hacker doesn't have the "nonce".  The server gives a random value called a nonce every time someone connects, I think it's a 64 bit or 128 bit value, I forget.  You have to encrypt the password with the nonce too, so people just replaying past password encryptions don't work.

>f you want to stop anyone seeing what is going down the wire, then HTTPS is indeed the solution, and works as you suggest. But that is connection encryption, not data encryption.

HTTPS doesn't solve Man In The Middle attacks.

Security is best thought of in layers.  HTTPS is only one of several important steps.

>Now, if you want to stop the user seeing the content of the HTTPS calls in the browser network traffic analyser, then applying some sort of transform is worth doing. But full on public key encryption is expensive in processing time, and no better than a simple obfuscator even like base64.

You only have to encrypt the password expensively once at the beginning of the connection.  Otherwise it's just a few simple extra instructions per subsequent transaction.

Erick
Thu, Nov 17 2016 8:37 AMPermanent Link

Matthew Jones

erickengelke wrote:

> > The hacker then wants to do the same, so he takes the password from the variable, encrypts it with the public key he got from the code, and sends the command to delete all the data. Encryption *in the browser* added nothing because the hacker has everything.
>
> The hacker doesn't have the "nonce".  The server gives a random value called a nonce every time someone connects, I think it's a 64 bit or 128 bit value, I forget.  You have to encrypt the password with the nonce too, so people just replaying past password encryptions don't work.

Ah, okay, if there is a server based element too then fine. I've done protocols with nonces, but they tend to change for every call.

What stops the attacker from copying everything though? The nonce is good for stopping interception, and interjection, but the whole protocol is there in the browser code still, so they can log in and get their own nonce.

Anyway, I think we have demonstrated that security is a matter of layers, and you have to take the appropriate consideration of them all.

--

Matthew Jones
Page 1 of 2Next Page
Jump to Page:  1 2
Image