OData (1 Viewer)

[Auntiejack56]

Hi,
I have been experimenting with connecting my Access Database to an Odata source. Works a treat. But can it be made secure? And I mean, very secure. Any ideas?
Thanks,
Jack

 

[Ranman256]

some odbc has password on the backend.
the network folder the access db is passworded.
you can password the Access database
you can 'password' the forms the users open using code.

secure enough?

 

[Auntiejack56]

Thanks for your answer, but it is the connection to the OData source that is concerning me, not protecting the front end, which, as you've suggested, has some pretty straightforward and well-known 'solutions'.

I'm interested in ways to protect the connection to the data, given a cloud OData endpoint. Assuming that the ODBC connection a) has a plain text password embedded, and b) keeps the connection open and presumably vulnerable, I'd like to know if anybody has successfully implemented security at this level to get around these vulnerabilities. One comment I found on this topic was "you should not link tables to web service. Rather you should consume the properties and methods of the web service in the code and import data into tables", which has just made me all the more curious.

Jack

 

[The_Doc_Man]

You are worried about "security in motion" and that requires the cooperation of the Cloud host. Most TCP/IP protocols have a "normal" version and a "secure" version. E.g. HTTP and HTTPS, or FTP and FTPS, and I've even heard of SMBS to go along with Access SMB. But "secure" protocols are a two-way street. Both host and client must be able to implement the secure handshake that has to occur before you can HAVE a secure connection. You need to check with the Cloud host's staff to see what they support AND see if your PC can "play the same game."

 

[Auntiejack56]

Thanks doc_man, I'll get onto this approach. Your insight greatly appreciated.

 

[The_Doc_Man]

To amplify, if your host HAS / SUPPORTS a "secure" protocol then there is such a thing as a session key negotiation that occurs even before your password would be transmitted. Session key handshakes have been around for a long time and have been tested thoroughly.

By way of background, my last job before retirement was as a systems administrator for the U.S. Navy (as a contractor) at Naval Enterprise Data Center New Orleans. I held a Security+ certificate as well as a Systems Administrator certificate so I had to be up on secure communications to keep that position. We had a 3-year renewal cycle and yearly "refresher" training. We used the "S" variant of every protocol that supported it.

Note that if your host supports secure protocols, they will probably invite you to download their site's security and signing certificates, and if your office is on a domain that has them, you might be able to upload your corresponding certificates. When you have certificate-based dual-ended encryption, you are about as secure as modern non-military technology can support.