How to accept quotes without logging in??

[bluesteam]

I have a very difficult client that refuses to take the time to log in to accept a quote because be forgot his password and complains that he doesn't have the time to go through the password reset process.

I can accept it on his behalf but I would prefer not to because I want to be able to say later that he accepted the quote himself without him accusing me if doing it for him.

Is it possible to allow a client to simply click the link in the mail and then display the ACCEPT button without the client having to log in first??

[zitu4life]

Hi   @bluesteam I do agree with you.   I have edited   my template email,  saying that also client can just reply to that email to us. So now they mostly do that, replying. we agree with quote.

But  if    there is more friendly way to  improve it, I would like to listen too😇

[bluesteam]

Yh, by doing it the way you are doing it now really circumvents the whole quote process.  Really silly that the email link doesnt have a simple encrypted key in the URL that is like an email verification link.

[brian!]

1 hour ago, bluesteam said:

I have a very difficult client that refuses to take the time to log in to accept a quote because be forgot his password and complains that he doesn't have the time to go through the password reset process.

oh there's always one... why isn't he saving it in the browser? 🙄

1 hour ago, bluesteam said:

I can accept it on his behalf but I would prefer not to because I want to be able to say later that he accepted the quote himself without him accusing me if doing it for him.

he sounds a right... I hope he's worth it financially!

1 hour ago, bluesteam said:

Is it possible to allow a client to simply click the link in the mail and then display the ACCEPT button without the client having to log in first??

from settings, I wouldn't have thought so - I think it's in the code that they *have* to login.

29 minutes ago, bluesteam said:

Yh, by doing it the way you are doing it now really circumvents the whole quote process. 

i'm tempted to say so are you by wanting to not require login to accept the quote. 🙂

31 minutes ago, bluesteam said:

Really silly that the email link doesnt have a simple encrypted key in the URL that is like an email verification link.

I don't think there would be anything to stop you linking (in the email) to another page that displayed an accept quote link - effectively, you would likely need to bypass viewquote and get the accept quote button to run the AcceptQuote API which only needs a quote ID value to be passed to it... possibly you could even cut out the middle man and have the accept quote button in the email and link that directly to the API file... the file will take the variables passed to it in the link, which will have to include the quote number and some sort of verification method...

security is the biggest issue with this - logging in is the better option, but if you accept lower security, them I think it would be possible.

though personally, I wouldn't be keen on changing the accepting quotes process just for one awkward customer.

[Kian]

5 hours ago, brian! said:

security is the biggest issue with this - logging in is the better option, but if you accept lower security, them I think it would be possible.

You could make it work like "Password Reset" URLs. Create an hash based on userid/email/quoteid and a page that verifies the request. The bad news is that it takes 30-60 minutes of coding.

[ManagedCloud-Hosting]

Hi,

I also a  few customers who have the same problem. What I do is create a quote under my account and then copy paste it to send via the Accounts & sales email address and request them to accept by replying to the emails formally.

19 hours ago, bluesteam said:

I have a very difficult client that refuses to take the time to log in to accept a quote because be forgot his password and complains that he doesn't have the time to go through the password reset process.

We as webhosts cannot compromise everyone security for a few such clients who always want their way in everything. So doing it manually makes sense to me without loosing the client or order :)

 

 

[bluesteam]

There is clearly something I am not understanding here. Why is it NOT a security compromise when other systems and websites all over the world can send a client an email verification link with a hash in the url and yet WHMCS considers this a security compromise on their own system for their own email verification process as well as the quote process?

Edited June 23, 2020 by bluesteam

[ManagedCloud-Hosting]

We use Vision Helpdesk for Support Tickets and they add link with a hash in the url with every reply so that client can check without having to login every time.

While in WHMCS security should be treated as top priority as here we have server management access got clients alongside billing.

7 hours ago, bluesteam said:

Why is it NOT a security compromise when other systems and websites all over the world can send a client an email verification link with a hash in the url

[Kian]

Here is my attempt. The gif is super compressed 😞

It works with 2 action hook.

In EmailPresend I detect Quote Delivery with PDF email to override the default {$quote_link} so that instead of redirecting the user to /viewquote.php?id=5 I redirect him to /index.php?qhash=e4aa361fb07969dbb1fbe28d8974e8286-5. qhash is the md5 of quote ID + user ID + user email (reversed).

When the user lands on the above URL, in ClientAreaHeadOutput hook point I run a check to make sure the request is legit by comparing the given hash in the query string against the one I have in database. If they are exactly the same, the request is legit so I run a query to update quote status from "Delivered" (or any other status) to "Accepted".

In the same time I show a modal that confirms the quote has been accepted. As you can see the modal includes client firstname, quote ID and quote subject but you can freely customize it. Of course login is not required and the modal shows up only once.

Here is the code:

<?

/**
 * Accept Quote without Logging In
 *
 * Written by Kian
 *
 * Requirements:
 *
 * - WHMCS 7.8.0 or later
 * - WHMCS standard modal in footer.tpl
 */

use WHMCS\Database\Capsule;

add_hook('EmailPreSend', 1, function($vars)
{
    if (in_array($vars['messagename'], array('Quote Delivery with PDF')))
    {
        if ($vars['mergefields']['quote_link'])
        {
            $data = Capsule::select(Capsule::raw('SELECT t1.id, t2.id AS clientid, t2.email FROM tblquotes AS t1 LEFT JOIN tblclients AS t2 ON t1.userid = t2.id WHERE t1.id = "' . $vars['mergefields']['quote_number'] . '" LIMIT 1'))[0];
            $hash = strrev(md5($data->id . $data->clientid . $data->email)) . '-' . $data->id;
            $quote_link = (new SimpleXMLElement($vars['mergefields']['quote_link']))['href'];
            $url = parse_url($quote_link);
            $merge_fields['quote_link'] = str_replace($quote_link, $url['scheme'] . '://' . $url['host'] . '/index.php?qhash=' . $hash, $vars['mergefields']['quote_link']);

            return $merge_fields;
        }
    }
});

add_hook('ClientAreaHeadOutput', 1, function($vars)
{
    if ($_GET['qhash'])
    {
        $data = Capsule::select(Capsule::raw('SELECT t1.id, t1.subject, t2.id AS clientid, t2.firstname, t2.email FROM tblquotes AS t1 LEFT JOIN tblclients AS t2 ON t1.userid = t2.id WHERE t1.id = "' . explode('-', $_GET['qhash'])[1] . '" AND stage != "Accepted" LIMIT 1'))[0];
        $hash = strrev(md5($data->id . $data->clientid . $data->email)) . '-' . $data->id;

        if ($hash === $_GET['qhash'])
        {
            $adminUsername = ''; // Optional for WHMCS 7.2 and later
            $results = localAPI('AcceptQuote', array('quoteid' => $data->id), $adminUsername);

            return <<<HTML
<script>
setTimeout(function()
{
    $("#modalAjax .modal-title").html('Quote #{$data->id} Accepted');
    $("#modalAjax .modal-body").html('<div class="container col-md-12"><div class="row"><div class="col-md-8"><h4>Hey, {$data->firstname}</h4><p>Thanks for accepting quote <strong>#{$data->id}</strong> ({$data->subject}). Here is what happens now:<ul><li>You will receive the invoice shortly</li><li>Once we receive your payment, we\'ll activate your order</li></ul>Please do not hesitate to <a href="contact.php"><strong>contact us</strong></a> if you have any questions.</p></div><div class="col-md-4 text-center"><p><a href="cart.php"><i class="fas fa-cart-plus fa-5x"></i></a></p><p><small>Keep browsing our Products</small></p><p><a href="cart.php" class="btn btn-info btn-block">Discover</a></p></div></div></div>');
    $('#modalAjax .loader').hide();
    $('#modalAjax .modal-submit').hide();
    $("#modalAjax").modal('show');
}, 250);
</script>
HTML;
        }
    }
});

 

Edited June 23, 2020 by Kian

[bluesteam]

Dude this is very cool!  Nice work there!

 

So my question is this,  why is this considered INSECURE?!?  I don't consider this INSECURE because we expect the email that goes out to the client to be delivered to the email address on the WHMCS system. We don't expect this mail to end up in anyone elses mailbox and if it does, because the mailbox is compromised, then that is not our problem nor is it our fault.

But this is anyway unlikely 

So my question remains, why is it so insecure to have an hash in the url to accept a quote?  MANY systems use this approach!

[bear]

16 minutes ago, bluesteam said:

We don't expect this mail to end up in anyone elses mailbox

Mail does not go directly from the server to a remote mailbox. Along the way it typically passes through many points, which could, at least theoretically, be seen by someone else. Can something like a hash be used to do things that are unexpected? Possibly.  Certainly more unsafe than having someone log in to do things, which requires a password, so more secure. 

[Kian]

Not to mention that if you have a page that allows to accept quotes by simply visiting page.php?quoteid=1, who stops a lamer from creating a never ending loop?

page.php?quoteid=1
page.php?quoteid=2
page.php?quoteid=3
page.php?quoteid=4
page.php?quoteid=5
...
page.php?quoteid=9999

It ruins your business. Even my approach is not foolproof but of course an hash is more secure than an ID. I don't think a lamer would waste time to brute force a string like a7a4d8eb90f6b1b6eb8289d36ef214978 or to reverse engineer the hash registering X times, asking N quotes and stuff like that.

 

[brian!]

17 minutes ago, bluesteam said:

So my question is this,  why is this considered INSECURE?!?

has anyone said that it's insecure? I would maintain that it's LESS secure than logging in.

20 minutes ago, bluesteam said:

We don't expect this mail to end up in anyone elses mailbox and if it does, because the mailbox is compromised, then that is not our problem nor is it our fault.

even if you're hosting the domain?

what happens if the client has subaccounts that are entitled to receive Quote Emails and accept them ? you could then get yourself into a situation where one of them, or someone else who checks their mail, has accepted the quote, but you've got no way of knowing who is accepting it without them logging in - even if you were logging IPs etc in the hook.

[bluesteam]

1 hour ago, bear said:

Mail does not go directly from the server to a remote mailbox. Along the way it typically passes through many points, which could, at least theoretically, be seen by someone else. Can something like a hash be used to do things that are unexpected? Possibly.  Certainly more unsafe than having someone log in to do things, which requires a password, so more secure. 

That is true but most mail these days is anyway encrypted.  I say MOST mail...

1 hour ago, Kian said:

Not to mention that if you have a page that allows to accept quotes by simply visiting page.php?quoteid=1, who stops a lamer from creating a never ending loop?

page.php?quoteid=1
page.php?quoteid=2
page.php?quoteid=3
page.php?quoteid=4
page.php?quoteid=5
...
page.php?quoteid=9999

It ruins your business. Even my approach is not foolproof but of course an hash is more secure than an ID. I don't think a lamer would waste time to brute force a string like a7a4d8eb90f6b1b6eb8289d36ef214978 or to reverse engineer the hash registering X times, asking N quotes and stuff like that.

 

Then how do millions of websites around the world circumvent this that use hashes? Maybew WHMCS can learn from them and if not, then that would implt all of them should find an alternative method and WHMCS is doing it right and them wrong?

1 hour ago, brian! said:

has anyone said that it's insecure? I would maintain that it's LESS secure than logging in.

It's obviously implied by all the talk on this thread advocating NOT to do it with hashes. The word security has been used in a negative context a few times on the thread in relation to using hashes in the URL:

10 hours ago, VirtualWorldGlobal said:

We as webhosts cannot compromise everyone security for a few such clients who always want their way in everything.

 

2 hours ago, VirtualWorldGlobal said:

While in WHMCS security should be treated as top priority as here we have server management access got clients alongside billing.

You referred to security yourself in your first reply.

On 6/22/2020 at 6:36 PM, brian! said:

security is the biggest issue with this - logging in is the better option, but if you accept lower security..

Sure you said that logging is still a better option but you referred to security nonetheless which implies that it is not as secure.  I challenge why it is a real issue at all when so many platforms use the hash in the url method.

So I am not making things up when I pose the question about it being impled that hashes are insecure based on the content in this thread when it is so widely used across the world.

So, I will maintain my position, if using hashes in urls is not best practice because of the potential pitfalls, who of this group of people here is going to tell them all that it's a bad idea and it should not be done?

I am of the opinion that hashes have become standard practice all across the world and if it can be used to verify email accounts or using it in other method's, it can't be that bad. right?

I just think that it should be an option available in the WHMCS to allow this if we desire it to be this way.

In  order for us as WHMCS admin users to send quotes to new potential clients, they now first have to be told to register an account BEFORE they can even be quoted.  90% of new clients won't want to do this.

So, the only way around that is to quote the user from a phantom account which means if they ever do accept the quote that we manually accept in the WHMCS system on their behalf, it's never going to be linked to their account when they DO finally sign up so they cannot even access the quote using Billing -> My Quotes in their dashboard to see what was sent them when logging in to their own account
This is what I meant when I said it is circumventing the whole quoting process intended by WHMCS developers when we ask them to accept the quote in an email and not using the WHMCS system.

I hardly believe that this was the intention by the WHMCS developers when they implemented the quoting system. They wouldn't want the client to have to reply in an email and bypass the quoting system.

So, at present the only way to correctly process quotes and have said quote linked to the clients account for them to also access it properly without us admins from fiddling in the database is for the NEW potential client to first have a registered account so that the quote history can be tracked by both us and the client.
After that, if the client is an already registered client, He/She still has to be logged in to accept the new quote and the argument can be made, why not save their username and password in their browser as you stated here:

On 6/22/2020 at 6:36 PM, brian! said:

oh there's always one... why isn't he saving it in the browser?

Well, not everyone believes in the security of saving their passwords in their browser. I am not one of those but many people still don't do it.

I just feel that the quoting process can be improved and should be improved!

Edited June 23, 2020 by bluesteam
Spelling mistake

[bluesteam]

1 hour ago, brian! said:

even if you're hosting the domain?

what happens if the client has subaccounts that are entitled to receive Quote Emails and accept them ? you could then get yourself into a situation where one of them, or someone else who checks their mail, has accepted the quote, but you've got no way of knowing who is accepting it without them logging in - even if you were logging IPs etc in the hook.

Especially when we are hosting the domain!  It's only our responsibility to secure the server.  It's not our responsibility to make sure the client secures his password to his mailbox.  We can tell them to use strong passwords and even implement configurations that force them to use strong passwords but we can only do so much!

Regarding sub-accounts, if the client has added ANYONE to his list of sub-accounts and allows them to accept or reject quotes, then that was his choice.  It is not my problem if he/she creates those sub-accounts and puts their trust in someone else. 

We as admins should not be adding people from the backend on behalf of the client allowing the client to point the finger at us and even if we do do it on their behalf, we should not be doing it without a support ticket requesting this so that we can refer back to it in future.
The client should use the tools from within his dashboard.

And the quoting system can also be coded in such a way to log who accepted the quote when they clicked the link.  The link that is generated can be created PER email that goes out to each recipient so that it can be tracked as to WHO accepts the quote but regardless of how you look at it, there is definitely room for improvement here.

Edited June 23, 2020 by bluesteam
Improved the context of my reply.

[ManagedCloud-Hosting]

4 minutes ago, bluesteam said:

The word security has been used in a negative context a few times on the thread in relation to using hashes in the URL:

If you use Gmail which surely has many security protocols implemented, they also suggest an option to be activated when you allow a third party app  - "Less Secure Apps" it's on a user to select what they want to do.  It's your perception how you manage your user policies and security levels...

As WHMCS has inbuilt server management options it's surely less secure in my opinion too.

 

[bear]

23 minutes ago, bluesteam said:

That is true but most mail these days is anyway encrypted. 

Based on what?
Maybe if it's Gmail to Gmail it may be, but unless the user and WHMCS are both using encryption (in fact the same encryption, process and key), it's not. Having an HTTPS website doesn't mean it's encrypting your email; that's an entirely separate process.

[brian!]

4 minutes ago, bluesteam said:

It's obviously implied by all the talk on this thread advocating NOT to do it with hashes. The word security has been used in a negative context a few times on the thread in relation to using hashes in the URL:

I never said not to use hashes, all I was trying to do was point out the possible implications of going down that road instead than logging in - security isn't black & white, but degrees of grey.

14 minutes ago, bluesteam said:

Sure you said that logging is still a better option but you referred to security nonetheless which implies that it is not as secure.  I challenge why it is a real issue at all when so many platforms use the hash in the url method.

it patently isn't as secure as logging in... in the sense that anyone clicking on Kian's link and the quote gets accepted; click on the unmodified link and it's not...

18 minutes ago, bluesteam said:

So I am not making things up when I pose the question about it being imp

lied that hashes are insecure based on the content in this thread when it is so widely used across the world.

I think the difference between us on this is that you think things are either secure or insecure.... i'm just saying that it's more nuanced than that.

I haven't said whether using hashes is good or bad - I honestly don't have an opinion on the topic and i'm not running around the street in horror, waving my underwear in the air screaming "INSECURE! INSECURE!" at the thought of using hash keys..

28 minutes ago, bluesteam said:

I just think that it should be an option available in the WHMCS to allow this if we desire it to be this way.

You won't hear any complaints from me if WHMCS give admins more options.

31 minutes ago, bluesteam said:

In  order for us as WHMCS admin users to send quotes to new potential clients, they now first have to be told to register an account BEFORE they can even be quoted.  90% of new clients won't want to do this.

again, i'm not disagreeing with you on this.

35 minutes ago, bluesteam said:

I hardly believe that this was the intention by the WHMCS developers when they implemented the quoting system. They wouldn't want the client to have to reply in an email and bypass the quoting system.

I doubt that they would care on the second point... and the quoting system was probably designed 10+ years ago and it hasn't really changed that much during my time here.

41 minutes ago, bluesteam said:

So, at present the only way

I would dispute it's the only way, but let's not prolong this... 🙂

besides, your original question was about an existing client, so I never considered quotes to non-users when answering...

45 minutes ago, bluesteam said:

I just feel that the quoting process can be improved and should be improved!

again, i'm totally with you on that... but feature requesting is practically pointless, and by the time we get to the v8 betas, WHMCS will have already decided what's going to be included... and I doubt an updated quoting system will be on that list.

[bluesteam]

6 hours ago, bear said:

Based on what?
Maybe if it's Gmail to Gmail it may be, but unless the user and WHMCS are both using encryption (in fact the same encryption, process and key), it's not. Having an HTTPS website doesn't mean it's encrypting your email; that's an entirely separate process.

Based on the fact that if you are not using SSL  with your SMTP sending on your WHMCS installation then you really shouldn't even be a web host at all.

And based on the fact that 90% of modern mail clients that are available today default to using SSL and if a mail client is not using SSL then it was probably manually configured like that by the end user. I don't think I have set up a mail client in the past few years that isn't using SSL.

Not to mention the fact that I'm pretty sure there aren't any server admins out there that are just waiting and watching for emails to arrive in the mail server queues directly from a web host using WHMCS having the word Quote in the subject just so they can accept it to prove that it can be compromised.

Edited June 24, 2020 by bluesteam

[bluesteam]

5 hours ago, brian! said:

I would dispute it's the only way, but let's not prolong this... 

Well if you include email replies as an acceptance method then that isn't using the WHMCS quoting system the way it was intended to be used. So if you know of any other way that uses the WHMCS quoting system to it's full expected potential without the client being forced to first register an account and then forcing him/her to log in after to accept the quote and having the quote history linked to the new clients account then I would really appreciate it if you could tell me because I need an answer to this problem.

Edited June 24, 2020 by bluesteam

[bear]

1 hour ago, bluesteam said:

Based on the fact that if you are not using SSL  with your SMTP sending on your WHMCS installation then you really shouldn't even be a web host at all.

And based on the fact that 90% of modern mail clients that are available today default to using SSL and if a mail client is not using SSL then it was probably manually configured like that by the end user. I don't think I have set up a mail client in the past few years that isn't using SSL.

SSL connections and secure sockets do *not* encrypt email. STARTTLS will add an encryption layer that helps mask the contents, but there's an important caveat:
"The encrypted message is revealed to, and can be altered by, intermediate email relays. In other words, the encryption takes place between individual SMTP relays, not between the sender and the recipient."

To make email unreadable by third parties requires end to end encryption, which uses public and private keys at both ends. That's important. 

Quote

I'm pretty sure there aren't any server admins out there that are just waiting and watching for emails to arrive in the mail server queues directly from a web host using WHMCS having the word Quote in the subject just so they can accept it to prove that it can be compromised

You should probably look into "bots" and "sniffers". Also, with WHMCS installations being a ripe target for stealing user and payment info (not to mention server credentials), perhaps you shouldn't be so cavalier about that. 

Edited June 24, 2020 by bear

[bluesteam]

5 hours ago, bear said:

SSL connections and secure sockets do *not* encrypt email. STARTTLS will add an encryption layer that helps mask the contents, but there's an important caveat:
"The encrypted message is revealed to, and can be altered by, intermediate email relays. In other words, the encryption takes place between individual SMTP relays, not between the sender and the recipient."

To make email unreadable by third parties requires end to end encryption, which uses public and private keys at both ends. That's important. 

You should probably look into "bots" and "sniffers". Also, with WHMCS installations being a ripe target for stealing user and payment info (not to mention server credentials), perhaps you shouldn't be so cavalier about that. 

I don't think it is fair to say that I'm being cavalier about any of this. If I was, I wouldn't bother discussing any of this, not to mention that I would not bother doing my part on using security wherever I can using SSLs on WHMCS and websites or making sure that email clients are configured to use SSL etc.

So why in certain scenarios is the mail that was sent unreadable in a bounce back?

These are honest questions and I raise these questions in fear of being accused again of being cavalier which I feel I am definitely not. 😉

Nevertheless, the reason we even arrived at this level of detail about security is that it was suggested to use a hash in a url for accepting quotes and that was rejected by most people in this thread because it is obviously not secure to log in rather. I don't dispute that.

My point is this...

I feel that this discussion is a little pointless because millions of platforms all over the world incorporate hashes in their urls for verifying many events and none of them are complaining about such things such as sniffers and bots and transmission breaches during transport or someone else clicking the links that they sent to a recipient etc etc.

The use of hashes in the url is clearly not such as big of an issue in the way it is made out to be here in this thread if it is so widely used every single day.

So I personally don't see the problem in using them and don't feel it is worth our time debating whether we should or should not use them based on the wide use of them across the world.

Edited June 24, 2020 by bluesteam

[bear]

5 hours ago, bluesteam said:

I don't think it is fair to say that I'm being cavalier about any of this.

It was a reference specifically to this: "I'm pretty sure there aren't any server admins out there that are just waiting and watching for emails to arrive".
Asking if it's safe then dismissing a potential security concern because you feel it would require an actual person carefully watching emails is too narrow a viewpoint when it comes to security and unencrypted emails with potentially exploitable content.

Quote

So why in certain scenarios is the mail that was sent unreadable in a bounce back?

I've never seen that, despite using STARTTLS, though get few legitimate bounces. If both connected servers are using the encryption layer, it's stripped on arrival to show the underlying email (which is stored in plain text, as explained). 

[bluesteam]

1 hour ago, bear said:

I've never seen that, despite using STARTTLS, though get few legitimate bounces. If both connected servers are using the encryption layer, it's stripped on arrival to show the underlying email (which is stored in plain text, as explained). 

I have often received a query from a client asking why he/she received a certain bounce-back and I have to investigate and then find that the RAW contents displays the actual textual/html content as garbled or scrambled.

The headers are visible but the content is not.

1 hour ago, bear said:

It was a reference specifically to this: "I'm pretty sure there aren't any server admins out there that are just waiting and watching for emails to arrive".
Asking if it's safe then dismissing a potential security concern because you feel it would require an actual person carefully watching emails is too narrow a viewpoint when it comes to security and unencrypted emails with potentially exploitable content.

I simply meant that a server admin is not sitting waiting to read other peoples email just so he can click a URL that has a hash in it. I never disputed the fact that bots and sniffers could be a potential risk.

But it really doesnt matter.  It's off-topic.

My below point still remains:

7 hours ago, bluesteam said:

The use of hashes in the url is clearly not such as big of an issue in the way it is made out to be here in this thread if it is so widely used every single day.

So I personally don't see the problem in using them and don't feel it is worth our time debating whether we should or should not use them based on the wide use of them across the world.

 

[bear]

2 hours ago, bluesteam said:

I have often received a query from a client asking why he/she received a certain bounce-back and I have to investigate and then find that the RAW contents displays the actual textual/html content as garbled or scrambled.

The headers are visible but the content is not.

Possibly encoding, faulty server or even origin issues (sender error). 
Or it was an embedded image, and you're seeing the raw image data. 😉