Programming

That's right. You need access to the encrypted password in order to verify that the user typed in a password that matches it. What did you expect? Do you think that su can verify that you typed in the root password without looked at the encrypted password? Well, here's a clue..su obtains the encrypted string and verifies the entered password using exactly this method.

i think that the simplest solution to solve this problem is to use the kdesu program , supplied with kde.

you'll have to run your program with this command :

kde will display a dialog box which let the user type the root password or exit.

thanks

kdesu is GUI flavour of su.
but i want to implement it after execution of the program.
mean...

I execute my application say ( ./test )
then I check the user inside the application and if it not root I prompt the user.

Hi Perderbo,
I am going to look foolish asking this question, but it is bothering me.

"Well, here's a clue..su obtains the encrypted string"

where does su obtain this encrypted string from ?
lets say root password is "unix.com". Lets also assume that su has somehow got the encrypted string for "unix.com". But what is the key it has used for encryption?
Since this is not known, if I have to simulate su, how do I get this encrypted string ?

so for eg su internal encrypted "unix.com" using key say "linuxpenguin", and encrypted key is "perderabo"
Now, I am simulating su, I have the encrypted string "perderabo" (dunno where i got it from, somehow I got it), my program prompts for password, which the user enters as say "unix.com" (hacker huh!! ), so now how do I encrypt this. Essentially I need to know the encrypted password and encryption key, both ? well then I would have even encrypted the root password
Can you please explain me understand this.

Regards

ok, is this the /etc/shadow file, that contains the encrypted passwords? Even if it does, then what is the encryption key that su uses?

Try 'man 3 crypt'. If I'm not mistaken, the encryption 'salt' is stored with the encrypted password.

Take a look at the code I posted. I sidestepped the issue with:
#define ENCRYPT "O26nQUAUM2vLA"
but the su program obtains the encrypted string from somewhere. Exactly where varies. It might be /etc/passwd. It might be /etc/shadow. It might be NIS or NIS+. There are other options too. All that matters is that the local su program knows where to obtain the encrypted string. And it gets the plaintext candidate password interactively from the user. Then it uses the code I posted to compare the two. (Or something pretty similiar. )

I think that what is bothering you is a missing piece of data. Usually we think of something roughly like this: PLAINTEXT + KEY = CHIPHERTEXT

Actually the cleartext password is the key and the encrypted password is the chiphertext. So where is the plaintext? It is a well known constant stored in crypt routine. This is why the Unix password is locked at 8 characters in length. It is easy to increase the length of the cleartext but a new algorithm is needed to the size of the key. They had to do it this way. If the key was stored in the source code, everyone (who cared) would know it and anyone could use it to decrypt the password. But there is no way to take the plaintext and the chiphertext and recover the key. They wanted the password to be secure even if you had the source code for crypt() and the encrypted password. Even today, all these decades later, brute force is still the only viable attack. The weakness of the Unix password scheme is that today brute force is feasible against an 8 character password. crypt() is actually an amazing piece of work.

The salt is just basicly one of 4096 random strings added to password. So if my password is "bullfrog" the encrypted password will be one of 4096 results. This makes it harder to recognize that two accounts have the same password. And if you try to build a database of possible encrypted strings, your job is now 4096 times harder.

The Unix password scheme is described in the paper Password Security: A Case History by Robert Morris and Ken Thompson. This is not the RTM who wrote the Morris Worm; this is his father. I found a copy in the UNIX System Manager's Manual which was part of the 4.3 BSD documents dated April, 1986. But I think that paper is circa 1975 or so. It is a very early paper. BTW, Morris and Thompson also wrote the crypt() routine itself.

[EDIT]
I found that paper at the ACM website: Link
Published in 1979 I see... oh well, I had the right decade!