Send password over TCP connection

[dcrespo]

Hi all,

I have a program that serves client programs. The server has a login
password, which has to be used by each client for logging in. So, when
the client connects, it sends a string with a password, which is then
validated on the server side. The problem is obvious: anyone can get
the password just sniffing the network.

How can I solve this?

Daniel

 

[Paul Rubin]

I have a program that serves client programs. The server has a login
password, which has to be used by each client for logging in. So, when
the client connects, it sends a string with a password, which is then
validated on the server side. The problem is obvious: anyone can get
the password just sniffing the network.

How can I solve this?

If you really want to do it right, use SRP, <http://srp.stanford.edu>.

 

[Peter Tillotson]

simplest approach is to 1 way hash the password ... perhaps using md5

normally with passwords the server only has to check if it is the same
word, assuming the same hash algorithms the same hash value can be
created at client.

Its not hugely secure ... anyone sniffing can grab your hash value and
then try to crack it at their leisure. It would be better to communicate
over ssl.

Anyone know of a simple ssl api in python

 

[Steve Holden]

simplest approach is to 1 way hash the password ... perhaps using md5

No, it isn't - see below.

normally with passwords the server only has to check if it is the same
word, assuming the same hash algorithms the same hash value can be
created at client.

Unfortunately this means that the client sends the same string every
time the user authenticates.

Its not hugely secure ... anyone sniffing can grab your hash value and
then try to crack it at their leisure. It would be better to communicate
over ssl.

It's not even that secure: all they have to do is replay the data
sniffed from the server and they too can authenticate themselves. They
don't have to know what the plain-text password is.

Anyone know of a simple ssl api in python

A safer way would be to use some sort of challenge-response mechanism,
where the server presents a challenge C to the client, which then
computes some function of both C and the plain-text password provided by
the user. The server then authenticates by performing the same
computation on C and the known password.

As long as the server uses a different challenge each time then this is
at least secure from replay attacks. But this scheme does have the
weakness that the server must know the password of each user.

For something even more secure, look at OPIE and similar schemes. But
let's not forget that all these schemes only secure the authentication
exchange: they do nothing to protect application data.

regards
Steve

 

[Josef Meile]

Anyone know of a simple ssl api in python
Perhaps pow may help:
http://sourceforge.net/projects/pow

or pyopenssl:
http://pyopenssl.sourceforge.net/

Regards,
Josef

 

[Laszlo Zsolt Nagy]

How about an OTP (One Time Password) algorithm? It is described in RFC2289.

http://www.faqs.org/rfcs/rfc2289.html

I have a working implementation in Messlib. You can download it an look
at the "MessageSocket.SecureMessageSocket" class.
That is a modified version where a good random generator is used instead
of a finite sequence of passwords.
But it is just example implementation - you can get the idea there and
develop your own. In fact, my class also has support for
encrypting the communication channel, but the OTP algorithm itself only
requires a cryptographically secure hash algorithm and a
good random number generator. These are all included in Python. ;-)

I also tried to use SSL before, but I realized that for "secure
password" type authentication, OTP is much easier to understand and
use. Of course, SSL can be used for securing the communication line
WITHOUT AUTHENTICATION, and it is harder to understand
and use.

Best,

Les

 

[dcrespo]

I think you said the same as me:
Client:
Password = "password"
h = Hash(Password)
h is "GddTHww90lze7vnmxG" (whatever)

Sends h over the network to the server.

h is a string, so this approach is simply vulnerable.

SRP seems to be very good, but because I don't know it well, I think
I'll delay it for a while.

Thank you

 

[Dan Stromberg]

Hi all,

I have a program that serves client programs. The server has a login
password, which has to be used by each client for logging in. So, when
the client connects, it sends a string with a password, which is then
validated on the server side. The problem is obvious: anyone can get
the password just sniffing the network.

How can I solve this?

Daniel

What I've been doing for this, is to:

1) Store two copies of a (symmetric), one on the client host, one on the
server host.

2) When the client wants to connect to the server, have the server
generate a random string of bits, hash the client's password with the
string, and then the random string to the client

3) The client then hashes its copy of the same password with that random
string, and sends the result back to the server

4) The server, upon receiving the correct hash result, provides service

There are a lot of collisions being found in hash algorithms these days.
I haven't heard about any in the RIPEMD family of hash algorithms yet.

Another possibility is to just use Diffie-Helman key exchange (pretty
simple to code the base algorithm in python - I have an implementation
in pure python for you if you want - but I hear that some numbers are
more prone to attack than others, which my code does not attempt to take
into account) to get a shared encryption key on both ends of the
communication, and then encrypt everything with that.

 

[dcrespo]

Hi. I found TSL, a Python Library that supports SRP.
Do you know where can I find a sample client and server code? Thanks
for your help.

 

[dcrespo]

¡Beautiful and elegant solution!

Two copies of the password: one on the client, the other on the server.

1. Client wants to connect
2. Server generates a random_alphanumeric_string and sends it to the
client
3. Both Client and Server creates a hash string from
<password+random_alphanumeric_string>
4. Client sends the hash string to the server
5. Server compares his hash result with the hash string received from
de client.

I think it is a very good solution, Isn't it?

Daniel

 

[Dan Stromberg]

¡Beautiful and elegant solution!

Two copies of the password: one on the client, the other on the server.

1. Client wants to connect
2. Server generates a random_alphanumeric_string and sends it to the
client
3. Both Client and Server creates a hash string from
<password+random_alphanumeric_string>
4. Client sends the hash string to the server
5. Server compares his hash result with the hash string received from
de client.

I think it is a very good solution, Isn't it?

Sounds like it, but how is it different from what I just described?

Oh, also, I'm not 100% how much the alphanumeric part impacts things. You
may or may not get a better result by using a random string with all bits
random, not just the bits that vary in ASCII for letters and numbers.

Anyway, for an example of this sort of thing, you might look over my
fallback-reboot program at
http://dcs.nac.uci.edu/~strombrg/fallback-reboot/

It uses RIPEMD-160 for the hash.

The server side is in C (to reduce dependencies to a bare minimum), but
the client side is in python (for convenience).

 

[Tim Williams (gmail)]

Hi. I found TSL, a Python Library that supports SRP.
Do you know where can I find a sample client and server code? Thanks
for your help.

http://trevp.net/tlslite/

It comes with examples. I use it in several servers and clients.
Quite simple to impliment.

HTH

 

[Paul Rubin]

Hi. I found TSL, a Python Library that supports SRP.
Do you know where can I find a sample client and server code? Thanks
for your help.

I don't know about TSL, but TLSLite (www.trevp.net/tlslite) supports SRP.

 

[Paul Rubin]

3. Both Client and Server creates a hash string from
<password+random_alphanumeric_string>
4. Client sends the hash string to the server
5. Server compares his hash result with the hash string received from
de client.

I think it is a very good solution, Isn't it?

No. It's vulnerable to dictionary search. Use SRP if you can.

 

[dcrespo]

Sounds like it, but how is it different from what I just described?

That's right, but I wanted to rewrite it... I was for confirm my recent
acquired knowlegde

With "alphanumeric" I meant the md5 hash (for example).

 

[Dan Stromberg]

[quoted text muted]

No. It's vulnerable to dictionary search. Use SRP if you can.

Where can I learn more about this?

Thanks!

 

[=?ISO-8859-1?Q?Michael_Str=F6der?=]

Where can I learn more about this?

http://www.faqs.org/rfcs/rfc2945.html

Ciao, Michael.

 

[Paul Rubin]

Where can I learn more about this?

http://srp.stanford.edu as already mentioned. Also, RFC 2945
describes an older version (still ok).

 

[Dan Stromberg]

[quoted text muted]

http://www.faqs.org/rfcs/rfc2945.html

Ciao, Michael.

OK, thanks for the reference.

I guess I neglected to stress that we're talking about using random
strings of characters, not dictionary words or other weak forms of
user-chosen passwords.

Is there something easily attacked about the original algorithm, if you
use a long, quite random password in combination with a hash algorithm
that hasn't been broken?

If you look over my fallback-reboot package at:
http://dcs.nac.uci.edu/~strombrg/fallback-reboot/ you'll see that there's
a small python script that generates a 32 character hex string for the
passwords.

I suppose I probably should rewrite it to not use whrandom though.

Thanks!

 

[Peter Hansen]

Two copies of the password: one on the client, the other on the server. [snip]
I think it is a very good solution, Isn't it?

Ignoring all the other issues, any solution which actually requires the
password to be stored on the server is a bad solution. Administrators
should not have access to user passwords, and in addition users should
not be put in the position of having to trust your server-side security
to keep their passwords (which they might have used on other systems)
from being grabbed by hackers.

-Peter