Re: Encryption scheme using RSA

fair enough. In this case your scheme looks good to me.


-----
Dominick Baier (http://www.leastprivilege.com)

Developing More Secure Microsoft ASP.NET 2.0 Applications (http://www.microsoft.com/mspress/books/9989.asp)

here are some more details which explain our choices:

suppose there is no way for an attacker to perform active attacks
(man-
in-the-middle, connection hijacking, setting up a spoofed server,
etc.). The only thing he can do is to sniff the network traffic,
trying to steal passwords for a later use.
My schema is intended to prevent this only risk, nothing more. So I
have only been careful about:
- the password bits which travels on the network must be encrypted;
- on every new connection, bits which are exchanged during
authentication must be completely different, in order to prevent
replay attacks
We are trying to implement a minimum effort solution in order to raise
a bit the security level of the system. More standard and powerful
solutions are currently unfeasible because of several reasons (tight
deadlines, concerns about speed of execution, and also some politics).

Thanks for any other comment you can give

On Jan 9, 1:43 pm, Dominick Baier
<dbaier@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
How do you want to protect the clients against spoofed servers? In
other words - there are no server authentication bits in your scheme.

Why don't you simply wrap the whole (clear text) protocol in an
SslStream?

-----
Dominick Baier (http://www.leastprivilege.com)
Developing More Secure Microsoft ASP.NET 2.0 Applications
(http://www.microsoft.com/mspress/books/9989.asp)

Hi,

in my company we are using a proprietary clear text protocol to do
the communication between client and server for a product of ours.
The protocol requires authentication, but login and password pass on
the network in clear text.

We want to modify the protocol in order to protect at least the
password. The scheme we invented is the following:

- CLIENT connects

- SERVER generates an RSA key pair and sends the private key to
CLIENT

- SERVER generates a random number and sends it to CLIENT

- CLIENT obfuscate the password bits using the random number ( in a
reversible way!), encrypt the result with the public key and sends
the encrypted stuff to SERVER

- SERVER decrypts with private key, un-obfuscate and obtain the
password of CLIENT.

- SERVER validate the password and allows/denies access

I know it not a standard way to use asymmetric encryption, but I
would like to hear from you what the main flaws are in this idea.

Thanks in advance
jaqq


.

Relevant Pages

  • Re: TcpChannel under .NET 2.0
    ... Dominick Baier ... Server stack trace: ... properly but the client crash right a way :-( ...
    (microsoft.public.dotnet.security)
  • Re: Auto-update protocol
    ... before doling it out to the client on the net. ... Would require writing a server side tool. ... I'm not worried about the client side as I can control that. ... I thought the same initially - but it was a simple scheme which did work ...
    (comp.arch.embedded)
  • Re: TcpChannel under .NET 2.0
    ... Dominick Baier ... Server stack trace: ... properly but the client crash right a way :-( ... For instance, from my client I ma login as BOB, BOB is calling the ...
    (microsoft.public.dotnet.security)
  • Re: Issues With User Control Embedded Into Web Page Since Installing .NET 2.0
    ... Dominick Baier - DevelopMentor ... I deployed the same test project to another 2003 server in the same ... - The issues stated above are reproducable from any client, ...
    (microsoft.public.dotnet.security)
  • Re: TcpChannel under .NET 2.0
    ... Dominick Baier ... Server stack trace: ... start properly but the client crash right a way :-( ...
    (microsoft.public.dotnet.security)