Re: dhRichclient3 CRpcListener Authentication & Encryption Questions/Thoughts.

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

On Nov 26, 10:06 am, "Schmidt" <s...@xxxxxxxxx> wrote:
In some way you could "cheat" there a bit, if you always use
the same RPCServerAdmin (+appropriate password) within
the client-app directly (per "obfuscated strings" within the
clientside code). If the clientside Encryption-property
is compiled in with True, then - on top of that necessity - the
correct Public-Key-File would be required too for a
successful Login (not only the correct RPCServerAdmin-
account-information).

So this seems to be working now as expected - if the connection
attempt to the business server fails (bad password or public key),
then my app decides to try to connect to the open (no password or
encryption) credentials server. It then requests the password
(randomly set) and public key of the business server (in an encrypted
byte array that holds a hash of the user-defined server password and
the GMT date and time of the request (to prevent replay attacks)). If
the password & date look good, then the credentials server returns an
encrypted byte array containing the randomly generated business server
password and public key. The client app will then try to connect to
the business server with those credentials.

The only problem that I just thought of with this approach is that I
believe the RPCPublicKey.dh file must be in the same folder as the
dhRichclient3.dll. Since I am currently installing to Program Files,
limited user accounts won't be able to write the download public key
file to that folder (at least on Vista+). Do you think it would make
sense to be able to set the public key as a byte array property of the
cRPCConnection class? This way we could also store the public key in
an encrypted file on the file system, decrypt it at runtime and then
set the property in code. This would also help with the problem of
attackers potentially scouring the FS for an unencrypted public key.

a successful attempt (leaving the clientside Encryption-Property
at False) would nonetheless require the knowledge about
the current RPCServerAdmin-password.
This could only be retrieved by analyzing your client-binaries.
But you are right - with a serverside ForceEncryption-Flag,
this Hurdle would be higher for such an attacker, since he
would need also the correct Public-Key-File (in addition
to the Admin-password).

I do think that the odds of an attacker with knowledge of dhRichClient
classes, my application and who to attack (my client base) would be an
extremely rare creature indeed. Maybe I am just being paranoid ;)

Hmm - not sure (even with such a ForceEncryption-switch)
what a potential attacker would find more difficult, to somehow
determine the "compiled in" Admin-password - or to seize
such a current Public-Key-File from a machine of an
"lazy user" of the application.

I suppose that the only good news about a successful attack either
way, is that one of them wouldn't be my fault :)

The best approach really would be (without any serverside
enhancements), if the Users would have to "type-something-
in" for a successful Login ("directly from their own mind" ;-) -
no password in no binary anywhere.

I completely agree. I've mostly been experimenting with some ideas to
streamline the connection process, but there is no doubt that strong
passwords that aren't stored anywhere is the most secure way to go.

Good idea - for example the latency of very small "Ping-like"
RPCs could be a good indicator - e.g. if you measure the
shortest roundtrip-time of a series of maybe 3 calls. In a LAN
the typical response-time for "simple RPCs" is below 1msec.
A pinged Server, that is reachable over Internet would have
at least 7-10msec latency (and this is for a very fast internet-
connection with a low hop-count, normally the Web-latencies
are more in the range of 15-30msec).

This is an interesting approach, and I never would have thought of it.
I will give this a try, and thanks a lot for the idea.

I was initially thinking that I could put a function in my unencrypted
RPC dll that would return a boolean set accordingly to whether the
remote callee's IP address was on the same subnet as the IP address of
the listener class. If TRUE, then encryption would be disabled, and if
FALSE then it would be enabled. What I don't know is if there is a way
for an RPC class to know the IP address of the remote callee...Is this
information anywhere in the thread collection perhaps? Or anywhere
else accessible to an RPC DLL?

To be honest, I don't know if that idea would be suitable anyway - I'm
showing limitations in my knowledge here, but I *think* that being on
two different subnets doesn't necessarily mean that you are
communicating over public WAN/Internet (although the worst case
scenario here is that the connection gets encrypted when it doesn't
need to be, so that's not a terrible result). In any case, perhaps
your PING approach is the best one anyway - it certainly would be the
easiest to implement, and sounds foolproof.

Thanks again for your help Olaf.
Jason
.

Relevant Pages

  • Encrypting off-site with certificates public key
    ... I thought it would be wise to use a certificate encryption scheme to allow ... Then the data is written into a varbinarycolumn on the central server ... For some reason the public key is generating a different algorithm on .NET ...
    (microsoft.public.sqlserver.security)
  • Re: WSJ Online: Voltage Unveils Encryption Program
    ... > proposed what they called identity-based encryption. ... > person's e-mail address, for example, could act as a public key, avoiding ... Server A makes a private key for you. ... had used PGP instead and put that directly in Outlook [not as some ad ...
    (sci.crypt)
  • Re: Encryption keys
    ... In other words, since the public key is public, anyone can ... cert plus the time stamp on the server), ... > simple hash like SHA1or something, then it is pretty easy to brute ... >> SSL uses asymmetric encryption, ...
    (microsoft.public.dotnet.general)
  • RE: Hardcoding RijndaelManaged Keys
    ... Let me clarify here -- RijndealManaged is an implementation of the AES encryption algorithm, ... The key and IV must be the same on both the server and the client, otherwise there is no possible way for the server to decrypt the client's data. ... request a public key from the server, then encrypt the data using this public key and send the encrypted data to the server which results in 2 round ...
    (microsoft.public.dotnet.security)
  • Re: dhRichclient3 CRpcListener Authentication & Encryption Questions/Thoughts.
    ... encryption) credentials server. ... RPCConn.Encryption = True 'enables Encryption ... would need also the correct Public-Key-File (in addition ... at the clientside, you could just get the ServerIP from the ...
    (microsoft.public.vb.general.discussion)