RE: question on socket connection

RE: question on socket connection

[Ranga Reddy M - CTD ,Chennai.]

Now Iam puting alarm (SIGALRM) on the reader side if There is no
data/response for some time,(according to my application manipulation).Iam
disconnecting the client connection.

In the above design client application is implented like that each 5 min or
(according to my application manipulation) will send a "KEEP ALIVE request
to the server". With this request Iam updating the client connection in the
server.

According to me this is OK, but Iam wasting the network bandwidth and if by
mistake this packet is lost then server disconnects the client connection.

Can any one give me a idea.

Thanks
------
Ranga

-----Original Message-----
From: Glynn Clements [mailto:glynn.clements@virgin.net]
Sent: Monday, May 26, 2003 1:58 PM
To: Ranga Reddy M - CTD ,Chennai.
Cc: ronkhu@ntsp.nec.co.jp; linux-c-programming
Subject: RE: question on socket connection



Ranga Reddy M - CTD ,Chennai. wrote:

> Error -1: because of recv/send fail.
> Error EGAIN: this is because of MSG_DONTWAIT.
> 
> Client and Server Both are running on different systems.What if client
> crashes or powered off.How does the underlaying TCP/IP layer works
> here,There is no time for TCP/IP to say socket close to server.

The socket won't be "closed" until the other end is rebooted or
powered up and sends a RST, or (if SO_KEEPALIVE is used) until the
kernel times out the connection.

> Client does not give any indication of socket close.Then, I think server
> will does not know about the status of the client.

Correct. If you don't get a response, there's no way to tell whether
that's due to a transient network fault, or because the other end has
crashed or is powered off.

> I have read the article about the "Nagles allgoritham" . It sets a default
> time out of 2 hours. If there is not data on the socket for 2 hrs this
will
> disconnect the socket.

No. The "Nagle algorithm" is for coalescing many small writes into
fewer, larger packets.

TCP keep-alive is something else; it involves sending occasional
zero-byte packets when the connection would otherwise be idle in order
to detect whether the remote end is still functioning.

> Is there any way to trace???

I don't understand that question.

-- 
Glynn Clements <glynn.clements@virgin.net>

Re: question on socket connection

[John T. Williams]

send a keep alive packet every minute, and only have the server disconnect
if 10 in a row are missing.




Or cause your server respond to keep_alive packets. This way the client
knows if the server received it or not and can resend if it doesn't get the
appropriate response withing an given time period.



Unless bandwidth is at an unusual premium, I don't think you need to worry
about Keep_alive packets waisting bandwidth. TCP/IP waist plenty of
bandwidth; far more then any reasonable sized keep_alive packet could.



----- Original Message ----- 
From: "Ranga Reddy M - CTD ,Chennai." <rangareddym@ctd.hcltech.com>
To: "Glynn Clements" <glynn.clements@virgin.net>; "Ranga Reddy M - CTD
,Chennai." <rangareddym@ctd.hcltech.com>
Cc: <ronkhu@ntsp.nec.co.jp>; "linux-c-programming"
<linux-c-programming@vger.kernel.org>
Sent: Monday, May 26, 2003 4:44 AM
Subject: RE: question on socket connection


>
> Now Iam puting alarm (SIGALRM) on the reader side if There is no
> data/response for some time,(according to my application manipulation).Iam
> disconnecting the client connection.
>
> In the above design client application is implented like that each 5 min
or
> (according to my application manipulation) will send a "KEEP ALIVE request
> to the server". With this request Iam updating the client connection in
the
> server.
>
> According to me this is OK, but Iam wasting the network bandwidth and if
by
> mistake this packet is lost then server disconnects the client connection.
>
> Can any one give me a idea.
>
> Thanks
> ------
> Ranga
>
> -----Original Message-----
> From: Glynn Clements [mailto:glynn.clements@virgin.net]
> Sent: Monday, May 26, 2003 1:58 PM
> To: Ranga Reddy M - CTD ,Chennai.
> Cc: ronkhu@ntsp.nec.co.jp; linux-c-programming
> Subject: RE: question on socket connection
>
>
>
> Ranga Reddy M - CTD ,Chennai. wrote:
>
> > Error -1: because of recv/send fail.
> > Error EGAIN: this is because of MSG_DONTWAIT.
> >
> > Client and Server Both are running on different systems.What if client
> > crashes or powered off.How does the underlaying TCP/IP layer works
> > here,There is no time for TCP/IP to say socket close to server.
>
> The socket won't be "closed" until the other end is rebooted or
> powered up and sends a RST, or (if SO_KEEPALIVE is used) until the
> kernel times out the connection.
>
> > Client does not give any indication of socket close.Then, I think server
> > will does not know about the status of the client.
>
> Correct. If you don't get a response, there's no way to tell whether
> that's due to a transient network fault, or because the other end has
> crashed or is powered off.
>
> > I have read the article about the "Nagles allgoritham" . It sets a
default
> > time out of 2 hours. If there is not data on the socket for 2 hrs this
> will
> > disconnect the socket.
>
> No. The "Nagle algorithm" is for coalescing many small writes into
> fewer, larger packets.
>
> TCP keep-alive is something else; it involves sending occasional
> zero-byte packets when the connection would otherwise be idle in order
> to detect whether the remote end is still functioning.
>
> > Is there any way to trace???
>
> I don't understand that question.
>
> -- 
> Glynn Clements <glynn.clements@virgin.net>
> -
> To unsubscribe from this list: send the line "unsubscribe
linux-c-programming" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Password Encryption & Philosophy

[John T. Williams]

I had a problem, and I was wondering if anyone had a solution.
I'm writing a client which gives the user the option to store their
password, and I want to lend some security to the password being stored. My
problem is that no matter what algorithm I use to encrypt and decrypt the
password (it can't be a one way hash, bc I have to be able to send it to the
server in its original form), anyone who has access to the source code and
the encrypted password can get the original password back. Does anyone have
any suggestions on how to encrypt a password with an open source algorithm
and yet lend more security stored information.

Sincerly,
John T. Williams
jtwilliams@vt.edu

Re: Password Encryption & Philosophy

[John Anthony Kazos Jr.]

At 06:07 AM 5/30/03 -0400, John T. Williams wrote:
>I had a problem, and I was wondering if anyone had a solution.
>I'm writing a client which gives the user the option to store their
>password, and I want to lend some security to the password being stored. My
>problem is that no matter what algorithm I use to encrypt and decrypt the
>password (it can't be a one way hash, bc I have to be able to send it to the
>server in its original form), anyone who has access to the source code and
>the encrypted password can get the original password back. Does anyone have
>any suggestions on how to encrypt a password with an open source algorithm
>and yet lend more security stored information.

That's a really sticky problem. You have to consider what is being sent 
where, and why. Think of it in layers.

Start with a simple stored-cleartext, sent-cleartext password system. 
Anyone can sniff over the network for the user's password, so you one-time 
hash it when you send it. But that doesn't work, because the attacker can 
simply send the one-time hash, so you have the server send a random string 
to seed the hashing algorithm. Now it's secure against snooping (as long as 
your one-time hash algorithm is not susceptible to a 
partial-known-plaintext attack).

But what about storage? You can't store it hashed, like you said, because 
you have to have the password in its original form to hash. You can't have 
the server designate a permanent "salt" that you can hash'n'store with, 
because now you're doing the same thing as before, where the attacker can 
simply copy the hashed form and send it. You could encrypt it with some 
algorithm, but that relies on its own key. If you store the key with the 
password, it's no more secure. If you have the user remember the key, you 
may as well have saved time and told them to remember the password.

The basic thing is, there are only three ways to reliable authenticate 
someone nowadays: a secret they know and do not store or share, a device 
they have with a secret algorithm, and a public/private key pair signed by 
an authority like Verisign. How much security does all this get you? It 
depends.

The public key is *way* too long to remember, so it has to be stored 
somehow. On the disk? Same problem as before. If you cannot secure the 
disk, you have a big problem. On a read-only floppy or other peripheral 
device? If you cannot trust the disk, you cannot trust the programs on it, 
because for all you know the key-reading binary has been compromised. You 
could store the key on a computer connected by a network, a computer which 
does the encrypting/decrypting and which never tells you what the private 
key is, but you can't trust it fully unless you write everything from the 
OS to the client software all on your own, and test it completely for bugs. 
Using a "shrinkwrapped" OS might work, as long as it cannot be hacked from 
the network interface, because someone could compromise the computer 
connected to it and start sending Chernobyl packets.

How about one-time passwords? There is absolutely *nothing* software-based 
more secure than one-time passwords. But think about it: Someone can still 
guess it. By incredible, unbelievable, almost divine luck, someone can 
guess a one-time password. You want to secure by biometrics? Someone could 
fake some signs; someone could kidnap and coerce an authorized user; you 
could even be betrayed by that authorized user. Add visual inspection and 
monitoring of commands used? Humans can be fooled by humans.

You have to pick your battles. For your situation, I would suggest 
forgetting about trying to store the password any way other than plaintext. 
Some modern security systems even do that, if you go look up some PAM 
modules. What you need to do is secure the disk as best you can, and leave 
it at that.

You might also implement the security system I've come up with in the past 
week (though I have yet to look and see if someone's already done it). In 
the stead of certificate-signing authorities, record the client's public 
key the first time it is used. (When you're doing this, be careful, because 
the interceptor attack can break it.) Also choose a password at this time. 
Now, log them in by confirming their public key, not by asking for the 
password; ask for the password *only* if the public key is different, like 
they're logging in on another terminal. If you can confirm that no-one 
intercepted the original public-key exchange, then (I believe) you can 
consider the system very secure, so long as the private keys or the 
password are not compromised. 

Re: Password Encryption & Philosophy

[Andrew]

Is it necessary to store the password? IMHO it is bad policy to store the
password anyway because if someone gets physical access to your box they can
access everything without having to even look in the password file. This
could be collegues at work, friends or family at home, quite a lot of people
really. I'd avoid it if possible and not add the 'feature'.

If it has to go in I would encrypt it to disk, what you need to find is
something reasonably uniqe to seed it with. Perhaps a nic mac address or
something like that. Lets face it, if someone is really serious about it
they can get round anything, it only took a couple of weeks for versions of
XP with the security functions completely by-passed to start making the
rounds for instance.


----- Original Message -----
From: "John T. Williams" <jowillia@vt.edu>
To: "John T. Williams" <jtwilliams@vt.edu>
Cc: "linux-c-programming" <linux-c-programming@vger.kernel.org>
Sent: Friday, May 30, 2003 11:07 AM
Subject: Password Encryption & Philosophy


> I had a problem, and I was wondering if anyone had a solution.
> I'm writing a client which gives the user the option to store their
> password, and I want to lend some security to the password being stored.
My
> problem is that no matter what algorithm I use to encrypt and decrypt the
> password (it can't be a one way hash, bc I have to be able to send it to
the
> server in its original form), anyone who has access to the source code and
> the encrypted password can get the original password back. Does anyone
have
> any suggestions on how to encrypt a password with an open source algorithm
> and yet lend more security stored information.
>
> Sincerly,
> John T. Williams
> jtwilliams@vt.edu
>
> -
> To unsubscribe from this list: send the line "unsubscribe
linux-c-programming" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>

ipaddress from hostname

[John T. Williams]

I want to be able to get the ipv4 address of a hostname, what function can i
use?

Sincerely,
John T. Williams
jtwilliams@vt.edu

----- Original Message ----- 
From: "Andrew" <inbox@andy.co.uk>
To: "John T. Williams" <jowillia@vt.edu>
Cc: "linux-c-programming" <linux-c-programming@vger.kernel.org>
Sent: Saturday, May 31, 2003 5:05 AM
Subject: Re: Password Encryption & Philosophy


> Is it necessary to store the password? IMHO it is bad policy to store the
> password anyway because if someone gets physical access to your box they
can
> access everything without having to even look in the password file. This
> could be collegues at work, friends or family at home, quite a lot of
people
> really. I'd avoid it if possible and not add the 'feature'.
>
> If it has to go in I would encrypt it to disk, what you need to find is
> something reasonably uniqe to seed it with. Perhaps a nic mac address or
> something like that. Lets face it, if someone is really serious about it
> they can get round anything, it only took a couple of weeks for versions
of
> XP with the security functions completely by-passed to start making the
> rounds for instance.
>
>
> ----- Original Message -----
> From: "John T. Williams" <jowillia@vt.edu>
> To: "John T. Williams" <jtwilliams@vt.edu>
> Cc: "linux-c-programming" <linux-c-programming@vger.kernel.org>
> Sent: Friday, May 30, 2003 11:07 AM
> Subject: Password Encryption & Philosophy
>
>
> > I had a problem, and I was wondering if anyone had a solution.
> > I'm writing a client which gives the user the option to store their
> > password, and I want to lend some security to the password being stored.
> My
> > problem is that no matter what algorithm I use to encrypt and decrypt
the
> > password (it can't be a one way hash, bc I have to be able to send it to
> the
> > server in its original form), anyone who has access to the source code
and
> > the encrypted password can get the original password back. Does anyone
> have
> > any suggestions on how to encrypt a password with an open source
algorithm
> > and yet lend more security stored information.
> >
> > Sincerly,
> > John T. Williams
> > jtwilliams@vt.edu
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe
> linux-c-programming" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> >
> >
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe
linux-c-programming" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ipaddress from hostname

[ronkhu]

    #include <netdb.h>
    struct hostent *gethostbyname(const char *name);

    struct hostent {
        char    *h_name;
        char    **h_aliases;
        int     h_addrtype;
        int     h_length;
        char    **h_addr_list;
    };