use cPanels username & password for authentication

[Thaeke.com]

Hello, I'm new to cPanel but I think it's great so far. Now I have a question which I can't find an answer to in the searchpart of this forum.

I want to create a password protected area on my site where users can get extra information. I have allready found a nice phpscript to use and it works fine with mysql. The only problem is that my customers now have 2 passwords, one for cPanel and one for their userpage. Is it possible to use cPanels username and password for authentication on a loginpage? (I do not want to use password protected dirs on this)

[linux-image]

the username and password for the C-panel authentication is stored in a filenamed /etc/shadow encrypted with md5.

it depends on which encryption your php script is using. Moreover the php script must be using a database to store the password. If you can synchronize the password in this database with the /etc/shadow file and maintain the md5 encryption; you are done.

[Ramsy]

How would you go about implementing this in a script ?

[lamp]

Hello, I'm new to cPanel but I think it's great so far. Now I have a question which I can't find an answer to in the searchpart of this forum.

I want to create a password protected area on my site where users can get extra information. I have allready found a nice phpscript to use and it works fine with mysql. The only problem is that my customers now have 2 passwords, one for cPanel and one for their userpage. Is it possible to use cPanels username and password for authentication on a loginpage? (I do not want to use password protected dirs on this)

Did you ever figure out how to do this?

Thanks.

Lamp

[Thaeke.com]

I am stil searching for an answer to this question...

[typhon]

the username and password for the C-panel authentication is stored in a filenamed /etc/shadow encrypted with md5.

it depends on which encryption your php script is using. Moreover the php script must be using a database to store the password. If you can synchronize the password in this database with the /etc/shadow file and maintain the md5 encryption; you are done.

these are md5'd and then crypted.

if you want to use the login and password from cpanel i describe how to access this in this thread: http://forums.cpanel.net/showthread.php?t=29730

[brianoz]

The problem which others seem to have missed is that you probably don't have permission to read /etc/shadow - that's why the passwords are kept in a separate file, to prevent non-root users from reading them. The only way for a non-root user to check a password is to simulare a logon.

The ways to do this are:

1. Attempt a logon [messy]
2. Attempt an ftp access [probably the easiest]
3. Run an su command with password [not sure]

The easiest is probably number 2. You'd login to their account using the supplied password, and either check for the correct NNN status codes from FTP, or check that a directory listing of '.' returns something. Sorry I don't have time to write a version of number 2 at the moment but it shouldn't be hard if you can find some FTP code around the place and just use that.

- Brian

[typhon]

As for me I do have root access. My plan is to actually control the passwords within a database or mirror a file of it off of a cron job. Then nightly run a cron to update the dataase.

While this may perk some of your minds why I would do such a thing, but overall it gives much more functionality to ones services.

The problem with FTP is FTP usernames and passwords are easily sniffed. A problem with using the su command is that the command is often disabled. And actually attempting a login is not very messy. If running curl you may post the information to the cpanel login page, then return the http header result from the login page to see if it was successful or not. This might actually work the best to simulate the user only having to login once inorder to have access to all there tools without relogging in again.

Mike

[brianoz]

The problem with FTP is FTP usernames and passwords are easily sniffed.

FTP isn't easily sniffed if it's a connection to localhost (ie not even leaving your machine). If your machine has been compromised to that point then no other security on the system would work anyway!!

A problem with using the su command is that the command is often disabled. And actually attempting a login is not very messy.

If the su binary itself is disabled, then you're out of luck with su. However, though "su" won't log you in with the correct password it will probably give a different message after successful password check which will let you know you got the password right (ie "bad username/password" vs "account disabled"). If you can get this to work it's the simplest method. Problem is, many versions of su won't read the password from stdin, it has to be a terminal. It's not that hard to work around that requirement with expect, if you have a little time.

If you even have to mention using curl, the ftp method is going to be easier -- by a long way!!!! Note that if you're talking about off-machine access for ftp - sure, the passwords could then be sniffed, and I'd also go with curl. Bear in mind though, their passwords could be sniffed just as easily on almost any other access to cpanel, unless you force them to use the https versions of cpanel. Most users don't even know those https cpanel logins EXIST!

By the way, something to think about: I don't agree that sniffing is likely to be a real life risk. These days with modern switches people have to go to extraordinary extents to sniff. For example, they'd need to compromise a switch, the switch would have to support a debug/monitor port, they'd have to compromise a machine on the same switch to catch the sniffed data, and they'd have to not make any mistakes and get caught for long enough to catch passwords. You're talking a high degree of sophistication, and frankly, if someone that smart wants to get into your machine I promise you they won't be sniffing it externally!!! (and also they probably work for the NSA!)

Offtopic I know, but I'm not sure about your plan for keeping a database of passwords. Remember the ones in /etc/shadow are irreversibly encrypted. You'd only be keeping a database of encrypted passwords, unless you intervened somehow to record them when they were initially set. You'd still want to encrypt them, perhaps with pgp or something, so they couldn't just be stolen off disk if your machine got compromised. Of course, once an attacker's root it's only a matter of time before they get everything anyway, unless they're a 37337 skript kiddy and get caught.

cheers ...

[typhon]

FTP isn't easily sniffed if it's a connection to localhost (ie not even leaving your machine). If your machine has been compromised to that point then no other security on the system would work anyway!!

as you said later on, i might be using it for remote access sometime -- so keeping that in mind i usually go with some other route. but who hates curl lol.

If the su binary itself is disabled, then you're out of luck with su. However, though "su" won't log you in with the correct password it will probably give a different message after successful password check which will let you know you got the password right (ie "bad username/password" vs "account disabled"). If you can get this to work it's the simplest method.

any attempt to run the binary on my machine will result in a permission denied. the only user i allow to run su is root.

If you even have to mention using curl, the ftp method is going to be easier

FTP is easier, however, would it be the correct way?

Offtopic I know, but I'm not sure about your plan for keeping a database of passwords. Remember the ones in /etc/shadow are irreversibly encrypted.

the plan for this would be to keep the irreversibly encrypted password, then encrypt it again using mcrypt to add another layer of protection for the database.

then authenticating a username password from the database would take decrypting then checking against the crypt-md5

[brianoz]

[QUOTE=typhon]as you said later on, i might be using it for remote access sometime -- so keeping that in mind i usually go with some other route. but who hates curl lol.
FTP is easier, however, would it be the correct way?
[QUOTE]
I just think curl is complex is all, I know you can pretty much copy and paste but still ..

CURL is probably best off-machine as you can use https. However, https is kinda pointless because they're probably coming into your machine with an unencrypted password. I'd just trial both methods for speed, but I'd tend towards FTP because the interface isn't likely to change, ever! Of course, it depends on the size of your hosting enterprise as to how much effort you expend here (ie cost-vs-benefit!)

cheers!!