pnoe@dg13.cec.be (Pierre Noel) (08/25/90)
Hi, I have here at CEC to write a Daemon socket server program which sould provide new facilities for users connected from their PCs. My problem is that my server has to authenticate the connected user to allow him to go further in the job. I would then know how it is possible, for the daemon process, to check the validity of the tuple UserName-Password as a real logname to the system. In fact, what I'm looking for is kind of a function which takes the Name and thePassword as parameter and reply Yes or No depending on the validity. The target Machine is a Targon/35 (Pyramid) but the program should be ported to any machine. By the way, I don't have crypt function (as we are in Europe, not in USA). Thank you for your help Pierre Noel
kimcm@diku.dk (Kim Christian Madsen) (08/25/90)
pnoe@dg13.cec.be (Pierre Noel) writes: >I would then know how it is possible, for the daemon process, to check the >validity of the tuple UserName-Password as a real logname to the system. >In fact, what I'm looking for is kind of a function which takes the >Name and the Password as parameter and reply Yes or No depending on >the validity. 1) Read the encrypted password from the password file and store it in a variable, store the user typed password in another variable and use the function below: int authenticate(crypt_pw,typed_pw) char *crypt_pw, *typed_pw; { char salt[2]; extern char *crypt(); (void) strncpy(salt,crypt_pw,2); return(strcmp(crypt_pw,crypt(typed_pw,salt)) == 0); } >By the way, I don't have crypt function (as we are in Europe, not in USA). I'm pretty sure you have mixed two different issues up, the crypt missing outside USA is the UNIX command (crypt(1)), the C library routine crypt(3) is another matter, it has to be there for jos like these, otherwise you could grap the code from reverse-engineering of the su(1) program, since it has to be there as well. Best Regards Kim Chr. Madsen
rickert@mp.cs.niu.edu (Neil Rickert) (08/25/90)
In article <1990Aug25.025441.18302@diku.dk> kimcm@diku.dk (Kim Christian Madsen) writes: >1) Read the encrypted password from the password file and store it in > a variable, store the user typed password in another variable and > use the function below: > > int authenticate(crypt_pw,typed_pw) > char *crypt_pw, *typed_pw; > { > char salt[2]; > extern char *crypt(); > > (void) strncpy(salt,crypt_pw,2); > return(strcmp(crypt_pw,crypt(typed_pw,salt)) == 0); > } What is wrong with skipping 'salt[2]' and the strncpy, and using: return(strcmp(crypt_pw,crypt(typed_pw,crypt_pw)) == 0); -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Sci Dept, Northern Illinois U., DeKalb IL 60115 rickert@cs.niu.edu +1-815-753-6940 =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
kimcm@diku.dk (Kim Christian Madsen) (08/27/90)
rickert@mp.cs.niu.edu (Neil Rickert) writes: >In article <1990Aug25.025441.18302@diku.dk> I wrote: >>1) Read the encrypted password from the password file and store it in >> a variable, store the user typed password in another variable and >> use the function below: >> >> int authenticate(crypt_pw,typed_pw) >> char *crypt_pw, *typed_pw; >> { >> char salt[2]; >> extern char *crypt(); >> >> (void) strncpy(salt,crypt_pw,2); >> return(strcmp(crypt_pw,crypt(typed_pw,salt)) == 0); >> } > What is wrong with skipping 'salt[2]' and the strncpy, and using: > return(strcmp(crypt_pw,crypt(typed_pw,crypt_pw)) == 0); Well, nothing is wrong with skipping the salt, except that I find your solution confusing if you compare it with the manual entry for crypt(3C) and the formal parameter declaration of crypt(). Granted, my solution uses an extra function call, the strncpy(), and two extra bytes on the stack, but if tight optimizing or conservation of stack usage isn't called for I prefer to use more describing/understanable code, instead of rigid optimized code. Incidently I think the most terse code will result from: return(!strcmp(crypt_pw,crypt(typed_pw,crypt_pw))); As Always, Best Regards Kim Chr. Madsen kimcm@diku.dk