Finding/Using the Encryption key or salt used for account passwords

[dualistic]

Hi,

I was wondering where I can find the salt or key used for the AES 128 CBC encryption that Plesk 11 uses. I need to create my own authentication mechanism, and would like to match the user input to the database. I would NOT like to use mail_auth_view.

Thank you for your time.

 

[IgorG]

Do you understand that you asking us about opening of Plesk protection for all intruders?

 

[dualistic]

Do you understand that you asking us about opening of Plesk protection for all intruders?

So you're saying that revealing where the location of the salt or encrypted private key is is somehow more unsafe than the mail_auth_view utility? It seems like if someone can access one, they can access the other.

 

[Nikolay.]

I've seen several similar threads since this feature appeared in Plesk. And they never produce anything remotely useful as those who post in such threads never share their business cases they intend to solve. Seems like the only thing they want is to "find the salt or key" or something alike. Of course Parallels wouldn't reply constructively to such nonconstructive requests.

I propose you to share your exact business need. You obviously don't need mail accounts, but some other type of accounts (maybe customer accounts?). Which ones? You probably don't need to know the exact passwords from those accounts, just need a way to check if a given password matches a given account (think crypt(3) function). You would probably be satisfied with an API method that does that.

After you've shared your business need, somebody from Parallels staff or other members of this community may be able to help you. If what you want is not achievable in current Plesk versions, maybe this could still be implemented in the next one (which I assume is close to release). Please note that chances of getting something in the next version lower significantly the longer you wait or the less specific you are.

Cheers!

 

[dualistic]

I don't understand why it needs to be more specific than the fact that I want to authenticate against the Plesk accounts. Whether it's mail or not (in this case it happens that I do need the mail accounts, and setting autoresponders), I think it's quite normal to want to authenticate against the plesk db, or set my own salt or key.

Yes, an API for authentication would be fine for me.

 

[Nikolay.]

That's exactly the problem I described. You operate in technical terms and details, being overly specific in irrelevant ones ("authenticate against the plesk db, or set my own salt or key") and not specific enough where it actually matters ("against the Plesk accounts").

1) There is a number of account types in Plesk. Mail accounts is just a single type. Authenticating as a certain account may not be the same as an account of another type.
2) You still didn't specify what an authentication is for you. Will you be satisfied with an API-RPC method that accepts an account type, name, and password provided by end user and returns whether the password matched or not?
3) You still didn't specify what you actually want to do (with autoresponders, as it seems). Maybe you don't even need a dedicated authentication mechanism?

 

[dualistic]

That's exactly the problem I described. You operate in technical terms and details, being overly specific in irrelevant ones ("authenticate against the plesk db, or set my own salt or key") and not specific enough where it actually matters ("against the Plesk accounts").

1) There is a number of account types in Plesk. Mail accounts is just a single type. Authenticating as a certain account may not be the same as an account of another type.
2) You still didn't specify what an authentication is for you. Will you be satisfied with an API-RPC method that accepts an account type, name, and password provided by end user and returns whether the password matched or not?
3) You still didn't specify what you actually want to do (with autoresponders, as it seems). Maybe you don't even need a dedicated authentication mechanism?

I disagree that what you describe as irrelevant is actually irrelevant, and what you think is relevant is relevant. But nonetheless:

1) I only see one "accounts" table, and that's what I don't want to match to. Specifically mail for now, but maybe other ones in the future? Some general solution for all account types seems best, so I don't see why this point is relevant.
2) I said I would be satisfied. Authentication for me just means "yes, this person provided the correct credentials". I do not want passwords returned in plain text to match, if that's what you're trying to clarify. Either give me a method such that I can encrypt the password and then match it against the db or what you suggested is fine.
3) Again, not sure why that matters. It's a pretty common use case to want to authenticate against a common db. Just because I might not need to (I am letting users set their own autoresponders), there exists reasonable use cases that could use that functionality.