Send password over TCP connection

[Laszlo Zsolt Nagy]

¡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?

In fact this is almost an OTP but be aware!
A man-in-the-middle attack can crack your algorithm. This is beacuse you
create a random string only on one side.
You cannot trust in the connection you are using. You can modify you
algorigthm to be more secure:

1. Client wants to connect
2. Server generates a server_random_alphanumeric_string and sends it to the
client
3. Client generates a client_random_alphanumeric_string and sends it to the
client too
3. Both Client and Server creates a hash string from
<server_random_alphanumeric_string+password+client_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.

This is only a bit difference, but is makes sense. An intuder (who knows
the your algorithm, because getting the code is not as difficult) could
make a fake server to you, and send back HIS string (that is not
random). Suppose we have a weakness in the hash function. The intuder
can exploit this weakness by sending you his special string. The
modified version has the advantage of sending two random strings, this
way the intuder cannot take advantage of possible hash function
weaknesses, because the hash function will be called on a string that is
random for sure.

Best,

Les

 

[Laszlo Zsolt Nagy]

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.

Users will always need to trust in the server. The authentication
process ensures that the
client is really talking with the desired server and vice versa. But
even if you know that you
are talking to the right server, you need to trust in the server. The
administrator of the server
has access to all data. Possibly other persons and softwares too.
Passwords are not different
from this point of view.

Les

 

[Laszlo Zsolt Nagy]

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

This is a bit offtopic here. I read the RFC and I do not see why SRP is
not vulnerable to dictionary attacks.
If I have a working client software then I can use it to reveal
passwords. Isn't it a dictionary attack?
Can you please enlighten me?

Les

 

[Paul Rubin]

This is a bit offtopic here. I read the RFC and I do not see why SRP
is not vulnerable to dictionary attacks.
If I have a working client software then I can use it to reveal
passwords. Isn't it a dictionary attack?

Dictionary attack in this context means an eavesdropper records a
session, then compares all the hashed passwords against a word list
offline. If the attacker is allowed to make unlimited online queries,
then he can guess at SRP passwords too. But the host should notice
that and prevent it.

 

[Laszlo Zsolt Nagy]

Dictionary attack in this context means an eavesdropper records a
session, then compares all the hashed passwords against a word list
offline. If the attacker is allowed to make unlimited online queries,
then he can guess at SRP passwords too. But the host should notice
that and prevent it.

I see. So the eavesdropper records the random strings and the password
hash value sent.
Having these values, he can try to find a suitable password in his list
that will result in the same communication.
He can do this without having to connect to the server again, just by
replaying the algorithm for a given password
(and the same 'random' strings).

The difference in SRP is that the random strings are private, they will
never be sent over the network.
So they cannot be eavesdropped. Cracking SRP would require to calculate
the dividers of a product of
two very big primes (like in RSA). This is why it is hard to use
dictionary attacks - you cannot replay the
algorithm for a given password.

Thank you, I think I understand now.

Les

 

[Peter Hansen]

Users will always need to trust in the server. The authentication
process ensures that the
client is really talking with the desired server and vice versa. But
even if you know that you
are talking to the right server, you need to trust in the server. The
administrator of the server
has access to all data. Possibly other persons and softwares too.
Passwords are not different from this point of view.

If you're saying that people have no choice but to trust that their
passwords, stored in the clear on the server of some idiot who didn't
know better, are safe from casual administrator observation and safe
from hackers stealing the password file, then you shouldn't be allowed
anywhere near a supposedly secure system...

If you're just saying that one has to trust that the server you are
talking to at this instant in time is really the one you thought it was,
then that's an entirely different issue and I agree.

But storing passwords in the clear, thus allowing administrators full
access to users' passwords, is absolutely *not* necessary. That's my
point, regardless of what other issues this thread spawns. If the OP
implements strictly the sequence he mentioned in the posting to which I
was replying, he'll be the aforementioned idiot...

-Peter

 

[dcrespo]

then, what you proppose?

 

[Laszlo Zsolt Nagy]

If you're saying that people have no choice but to trust that their
passwords, stored in the clear on the server of some idiot who didn't
know better, are safe from casual administrator observation and safe
from hackers stealing the password file, then you shouldn't be allowed
anywhere near a supposedly secure system...

Of course I would not say this.

If you're just saying that one has to trust that the server you are
talking to at this instant in time is really the one you thought it was,
then that's an entirely different issue and I agree.

Not just this.
"one has to trust that the server you are talking to at this instant in
time is really the one you thought it was" - this is just authentication.
I'm saying that even if the authentication is secure and the server is
really the one that you wanted to talk with, the server can still be
vulnerable to other kinds of attacks. Since users are storing data on
the server, they need to trust in its security. Storing the clear
passwords is not a good idea, I agree. But having a secure
authentication method and not storing clear passwords doesn't
automatically mean that the server is secured.

I'm sorry, I was not clear. I think we were talking about the same thing.

Les

 

[Peter Hansen]

then, what you proppose?

I'll assume that question was for me, in response to my comment that one
should never store passwords in the clear.

Do you know how any other system manages to do this? Linux, for example
(assuming a 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.

If you don't know about this stuff yet, I strongly suggest lots of
additional research and reading prior to implementing a serious system.
There are _many_ web pages to be found which discuss this sort of
thing, probably including lots of tutorials for people starting on the
ground floor.

I bet Paul R or others more experienced in this area can point us to
some excellent ones, but a little googling with "passwords store clear
text" or "encrypted passwords" would get you started. I expect that
would quickly lead to the term "hashing", since you really don't want to
just encrypt the password: that can easily be reversed if anyone has the
key, and certainly an administrator could access the key used by some
random application that encrypts its passwords. The first few hits for
that last search seem to include pages that introduce the concept of
"salt", one of the "additional things" I mentioned above.

I'm not going to try to give a tutorial: I'm not nearly expert enough to
be trusted for that. I just wanted to warn against one of the most
basic and easily avoidable problems.

-Peter

 

[dcrespo]

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_input).hexdigest()
SavePasswordInDatabase(user,password)

 

[dcrespo]

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_input).hexdigest()
SavePasswordInDatabase(user,password)

 

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

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_input).hexdigest()
SavePasswordInDatabase(user,password)

It would be better to use salted SHA-1.

Ciao, Michael.

 

[Paul Rubin]

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_input).hexdigest()
SavePasswordInDatabase(user,password)

The usual way to do it is something more like:

import os,binascii
salt = binascii.b2a_base64(os.urandom(6))[:6]
user_input = raw_input("Type your password: ")
password = md5.md5(salt + user_input).hexdigest()
SavePasswordInDatabase(user,salt,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]

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]

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

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.

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

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.

All this is sustented over a VPN.

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]

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.

Why do you want to do that? All of them get compromised if the one password is compromised.

How is it that all of them get 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.

With 'password' I meant simply a string to log in.

so why do you need this password stuff at all?

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

 

[Paul Rubin]

Important data like diplomatic traffic. Must be accessible from all
Clients inmediatly a client publish his data. Its an online system.

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.

How is it that all of them get compromised?

It sounded like you're using the same password on all the clients.
If not, then that helps.

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

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