Send password over TCP connection

[dcrespo]

Re: Send password over TCP connection

> Do you know how any other system manages to do this? Linux, for example assuming properly configured system)? The passwords aren't stored: hashes of the passwords are stored (with additional things thrown in to prevent certain kinds of attacks even if someone nabs the password (/etc/shadow) file). If you store the password or even encrypt it (i.e. something that can be reversed if someone knows the key), it's a risk.

Ok, I understand it. What about the MD5? Is it good enough to use when
saving a hashed password on the database?

For example:
user_input = raw_input("Type your password: ")
password = md5.md5(user_in put).hexdigest( )
SavePasswordInD atabase(user,pa ssword)

[Michael Ströder]

Re: Send password over TCP connection

dcrespo wrote:[color=blue]
>
> Ok, I understand it. What about the MD5? Is it good enough to use when
> saving a hashed password on the database?
>
> For example:
> user_input = raw_input("Type your password: ")
> password = md5.md5(user_in put).hexdigest( )
> SavePasswordInD atabase(user,pa ssword)[/color]

It would be better to use salted SHA-1.

Ciao, Michael.

[Paul Rubin]

Re: Send password over TCP connection

"dcrespo" <dcrespo@gmail. com> writes:[color=blue]
> Ok, I understand... What about the MD5? Is it good enough to use when
> saving a hashed password on the database?
>
> For example:
> user_input = raw_input("Type your password: ")
> password = md5.md5(user_in put).hexdigest( )
> SavePasswordInD atabase(user,pa ssword)[/color]

The usual way to do it is something more like:

import os,binascii
salt = binascii.b2a_ba se64(os.urandom (6))[:6]
user_input = raw_input("Type your password: ")
password = md5.md5(salt + user_input).hex digest()
SavePasswordInD atabase(user,sa lt,password)

The random salt slows down offline dictionary attacks against the
database. Say you have 1000 accounts on your system and the attacker
needs just one password to log in and mess with stuff. With your
scheme, he hashes each word in a large dictionary (say a million
words), sorts on the hash values, sorts your hashed password list on
its hash values, then compares the two sorted lists and if there's
even one match, you're cooked. Each hash he computes can be compared
against all your accounts in parallel. The salt means he has to do
them one by one, slowing him down by a factor of 1000. However,
computers are now fast enough that dictionary attacks against every
single password are a serious threat.

If you have a way of storing a secret key K, then rather than using
unkeyed md5(whatever), use hmac(K, whatever). But revealing K
effectively turns the hmac into an unkeyed hash.

Can you say what your application is? That will help figure out how
far you need to go to protect these passwords, and what alternatives
might be possible.

I highly recommend the book "Security Engineering" by Ross Anderson
for a good cultural introduction to what you're getting into when you
program this stuff. It's a fun book to read, too.

[dcrespo]

Re: Send password over TCP connection

> Can you say what your application is? That will help figure out how far you need to go to protect these passwords, and what alternatives might be possible.

Sure, no problem (see this on fixed text):


___________ MasterServer ___________
// / || | \\ \
ClientServer ClientServer ClientServer
// \\ // \\ // \\
Client Client Client Client Client Client

// = XML-RPC connection
/ = Pure TCP connection

Clients, connects to MasterServer through ClientServer using XML-RPC
ClientServer interacts with MasterServer using 2 modes: XMLRPC and pure
TCP.

Pure TCP connection is used for athenticating ClientServer. When a
ClientServer is authenticated,
the ClientServers can connect to MasterServer for running RPC functions
requested by its Clients.

All ClientServers log in supplying only one hashed password. It is
hashedly stored in MasterServer.

The way I elected to log in is:
-Generate an MD5 string from a Random Alpha_Numeric string on
ClientServer side
-Generate another MD5 string from a Random Alpha_Numeric string on
MasterServer side
-Send each string from one host to the other.
-Apply a Hash algorithm using both MD5 in conjunction with the
password that each one knows.
-Then, the ClientServer sends its resulting hashed string to
MasterServer
-MasterServer then compares its own resulting hashed string with
the one received from ClientServer

ClientServer logs in if:
- IP's ClientServer is not a Blocked IP by MasterServer
- IP's ClientServer is in an Allowed IP Range
- hashed strings match

All this is sustented over a VPN.

Suggestions are welcomed

[Paul Rubin]

Re: Send password over TCP connection

"dcrespo" <dcrespo@gmail. com> writes:[color=blue][color=green]
> > Can you say what your application is? That will help figure out
> > how far you need to go to protect these passwords, and what
> > alternatives might be possible.[/color]
>
> Sure, no problem (see this on fixed text):[/color]

Well, I mean, what kind of data is it? Sports chat? Personal
correspondence? Financial info like credit card numbers? Medical
records? Military/diplomatic traffic? I'm asking how severe the
security requirements are.
[color=blue]
> All ClientServers log in supplying only one hashed password. It is
> hashedly stored in MasterServer.[/color]

Why do you want to do that? All of them get compromised if the one
password is compromised. What do you mean by "password"? If it's not
something a user has to remember and type in, then I hope you mean a
long random string rather than a password. I sort of remember your
mentioning this though.
[color=blue]
> All this is sustented over a VPN.[/color]

If the VPN is any good, it should authenticate all the peers in some
reasonable way, so why do you need this password stuff at all?

[dcrespo]

Re: Send password over TCP connection

> Well, I mean, what kind of data is it? Sports chat? Personal correspondence? Financial info like credit card numbers? Medical records? Military/diplomatic traffic? I'm asking how severe the security requirements are.

Important data like diplomatic traffic. Must be accessible from all
Clients inmediatly a client publish his data. Its an online system.
[color=blue]
> Why do you want to do that? All of them get compromised if the one password is compromised.[/color]

How is it that all of them get compromised?
[color=blue]
> What do you mean by "password"? If it's not something a user has to remember and type in, then I hope you mean a long random string rather than a password. I sort of remember your mentioning this though.[/color]

With 'password' I meant simply a string to log in.
[color=blue]
> so why do you need this password stuff at all?[/color]

I don't want to permit anyone to run RPC functions. It's my desire.

[Paul Rubin]

Re: Send password over TCP connection

"dcrespo" <dcrespo@gmail. com> writes:[color=blue]
> Important data like diplomatic traffic. Must be accessible from all
> Clients inmediatly a client publish his data. Its an online system.[/color]

OK, if it's actual diplomatic traffic you need to work with your
government about criteria. If you're in the US, you'd get help from
the NSA. This sounds more like business data. It's pretty normal to
rely on your VPN. That will probably be more secure than some
home-cooked protocol. If it's highly sensitive then you should use
secure terminals (not PC's), hardware crypto tokens at the endpoints,
and so forth. Please do read Ross Anderson's book, it sounds like you
really might need it.

Can I ask what country you are in? Also, how is the data supposed to
get handled at the endpoints? Is it something like text messages that
get displayed on a screen for someone to read? Or something like
database updates? Something like a cash dispenser network where the
leaf clients only make online queries (and maybe dispense cash) but
don't really store much data?

There are a lot of industry standards for different applications like
this. You should follow one if you possibly can, even if you think
your own method is better. There are two problems you have to
consider. The first is how to make the system secure. For that, you
should assume at this point that the people who designed the standards
knew what they were doing. The second is what you'll tell the jury if
something goes wrong despite your best efforts. For that, the best
thing you can tell them is "I followed the standard written by the
industry experts that represents the best knowledge in the field", and
almost the worst thing is "I thought I was smarter than the experts so
I used my own home-cooked method". So in both areas, following
standards is the best policy.
[color=blue][color=green]
> > Why do you want to do that? All of them get compromised if the
> > one password is compromised.[/color]
>
> How is it that all of them get compromised?[/color]

It sounded like you're using the same password on all the clients.
If not, then that helps.
[color=blue][color=green]
> > so why do you need this password stuff at all?[/color]
> I don't want to permit anyone to run RPC functions. It's my desire.[/color]

I don't understand how the password stuff is related to RPC. You
shouldn't have RPC ports open on the server.