Client Portal Security

Related products: Client Communication

Below is some information on the Client Portal Security. For more information on the Client Portal please see this FAQ and How to Guide. To see it in action, please see this demo video

 

Client Portal Security

Karbon takes our responsibility for our clients, and their clients’ data security seriously. The Karbon Client Portal is a Karbon platform feature that allows trusted advisors to engage with their clients and share information in a manner that is more secure than email.

This document outlines our security approach to Karbon’s Client Portal Magic Links and client login.

Client Requests

The Client Portal is protected by many of the same safeguards that protect access to the Karbon platform.

All client request messages are configured with transport layer security (TLS) encryption protocol (an advanced form of secure socket layer - SSL encryption) to encrypt client request messages and submitted client documentation or artifact during data transmission (i.e., data travel) activities over the internet.

This encryption transfers all messages and artifacts within the Client Portal over the internet in ciphertext, reducing the likelihood of your data being compromised during your client’s use of the Client Portal. Encrypting the Client Portal with TLS means that your client’s use of the Client Portal is secure and our client’s activities and data is encrypted and safely shared.

 

Magic Links

Magic Links, provide a convenient and secure method for a party to verify their Identity. When a client receives a Client Request from Karbon, it will include a unique Magic Link to access the request from the body of the email.

Magic Links can only be used once by a single device. A magic link can only be used a single time. Once it has been used, the device that received the email is considered a trusted device. Any attempt to reuse the link on any other device will be declined. If a client wants to access the portal on a second device they can request that a new link be generated and sent to them.

Magic Links expire after 30 day. Regardless of whether a link has been activated or not, its access to the portal will expire after 30 days of being generated. At this time the client will be prompted to generate a new link.

Magic Links are only valid for the lifetime of the work item. Once a work item associated with a magic link has been marked complete, the magic link is no longer available for use.

Magic Links are unguessable. Unlike a PIN, which could be guessed, a Magic Link cannot be guessed ahead of time.

Only one Magic Link can be valid at a time. If you resend a Client Request to a new email address the link in the initial request will immediately become unusable.

Magic Links cannot be used to download sensitive documents. Documents uploaded by clients via client requests are not able to be downloaded via Magic Links. Documents uploaded by clients are only accessible inside the Karbon platform.

 

Full Access via Login

If your clients require access to all open and completed requests (including comments and documents), they can log in to the Client Portal, which is a password-protected web application. This differs from a magic link, which only provides access to the request details for a specific work item.

The Client Portal requires that your client submit a username and password prior to gaining access to the portal. Submission of a username and password requires that the Client Portal validates the identity of the user prior to gaining access to all of the client requests sent to the client.

Only your clients can access your Client Portal. To access your portal, the email address needs to be associated with a contact in your Karbon account. Once logged in, your client will only see the client requests sent to the email address they logged in with.
 

Security Best Practice

Firms using the Karbon platform to send magic links and request items from their clients are responsible for securing 1. their use of the Karbon platform, and 2. their associated email provider utilized to communicate via Karbon.

The Karbon platform authenticates based on the credentials of the firm's email provider, selected during the Karbon account registration process; therefore, client requests and magic link communications are sent via an authenticated connection to the selected email provider.

We suggest that you keep the security of emails ‘top of your mind’ when using the Karbon platform and its features. As the vulnerability of your emails lives in your email provider, it is your responsibility to implement appropriate security safeguards at this level. Please ensure there is a process in place for your firm's email security. We’ve outlined some best practices for securing your emails:

  • Strong Complex Password Credentials - A strong password is one you can’t guess or crack using a brute force attack in a reasonable amount of time. They consist of a combination of uppercase and lowercase letters, numbers, and special symbols, such as punctuation. Enforcing these for all personnel can increase your security. The most secure way to protect your password is by using a password manager.
  • Multi-factor Authentication (MFA) - Adds an additional layer of security. This means that anyone trying to log in to your account requires two or more verification factors to gain access. Rather than just asking for a username and password, MFA requires one or more additional verification factors, such as an SMS code, which decreases the likelihood of a cyber attack.
  • Security Awareness Training - Firms are vulnerable because of one key factor: human error. 98% of Cyber Attacks in 2021 involved some form of social engineering, so it’s important that all personnel within your firm understand the basics of information security and asset protection.
    We encourage you to deliver security awareness training on best practices for password protection, phishing attempts, and your firm’s practices for information security.

Karbon Platform Security

All information stored within the Karbon platform, including Client Request data, is encrypted in transit and at-rest using enterprise-grade highly scalable cloud servers and databases.

Karbon has implemented many additional security practices to safeguard data processed by the Karbon platform. These security practices are evaluated during periodic internal audit activities and external security audits, including the SOC 2 Type 2 examination. A copy of our general use SOC 3 report covering Security, Availability, Confidentiality, and Privacy service commitments for our Karbon web application can be requested here.

Karbon customers wanting a copy of our more comprehensive SOC 2 Type 2 report should contact our customer support team. If you have any additional questions about the security of the Karbon Client Portal, please contact our customer support team at support@karbonhq.com

Thanks for this, @Amelia Freeman!

My biggest concern is that client logins are secured with only a username and password on a always-available front door landing page. Does Karbon monitor or protect against brute force attempts to log into the client portal as a client?

We have the Karbon portal linked on our website, so it’s public. If someone were to brute force a client login, they would have access to the most recent 100 work items and associated firm-delivered documents.

I love that client-sent documents are not available on the client-side of the portal. That’s a great way to reduce the exposed surface area.

I would eventually like to see 2FA, passwordless, and FIDO2 options available for client portal logins.



Magic Links can only be used once by a single device. A magic link can only be used a single time. Once it has been used, the device that received the email is considered a trusted device. Any attempt to reuse the link on any other device will be declined. If a client wants to access the portal on a second device they can request that a new link be generated and sent to them.

@Amelia Freeman I assume that trust here is accomplished using an authentication cookie and that this trust is, therefore, browser-level not device-level. That is, trust/access would not extend across browsers on a single device. 


Thanks for this, @Amelia Freeman!

My biggest concern is that client logins are secured with only a username and password on a always-available front door landing page. Does Karbon monitor or protect against brute force attempts to log into the client portal as a client?

Is MFA (or at least OAuth) not an option for v1 of the client portal? If so, I’m concerned.

I’ve seen plenty of examples of passwords created by our clients and know that many clients have a tendency to use (reuse) weak passwords even for systems that access sensitive data/functions.

If a client has an account compromised because they didn’t pay attention to security, they tend to blame the account provider, not themselves. In the case of the Karbon client portal, we’ll be get the blame. 


I think it’s a solid V1 release. The magic link is an excellent move towards true frictionless secure communication. 
 

I would love to see Karbon, a progressive and forward-focused software company, engaging in cutting edge frictionless (passwordless) security for the portal login. 
 

I think it fits the Karbon culture as I’ve experienced it. :)


This is a wonderful article.  I copied the link and sent it to my entire team.  A must-read!🤓


Thanks for this, @Amelia Freeman!

My biggest concern is that client logins are secured with only a username and password on a always-available front door landing page. Does Karbon monitor or protect against brute force attempts to log into the client portal as a client?

Is MFA (or at least OAuth) not an option for v1 of the client portal? If so, I’m concerned.

I’ve seen plenty of examples of passwords created by our clients and know that many clients have a tendency to use (reuse) weak passwords even for systems that access sensitive data/functions.

If a client has an account compromised because they didn’t pay attention to security, they tend to blame the account provider, not themselves. In the case of the Karbon client portal, we’ll be get the blame. 

I agree that MFA or at leasat an extra layer of security on top of the username/password is required for the client portal.  I was excited, and still am, for the client portal functionality but I am hesitant to roll this out or to put the URL on our website due to what I see is weak security.  

Karbon has mentioned above that best practice is to have MFA, so shouldn’t the client portal have MFA too?   We are following best practice for security in our firm, but I see the weakest link is the client’s password, just like @stupefly’s example above.  Unfortunately, security is only as strong as the weakest link.

 

Would it be possible to not allow clients to create a portal, in the absence of MFA security?   We should be able to turn this functionality on/off for clients (at a firm level).  


Thanks for this, @Amelia Freeman!

My biggest concern is that client logins are secured with only a username and password on a always-available front door landing page. Does Karbon monitor or protect against brute force attempts to log into the client portal as a client?

Is MFA (or at least OAuth) not an option for v1 of the client portal? If so, I’m concerned.

I’ve seen plenty of examples of passwords created by our clients and know that many clients have a tendency to use (reuse) weak passwords even for systems that access sensitive data/functions.

If a client has an account compromised because they didn’t pay attention to security, they tend to blame the account provider, not themselves. In the case of the Karbon client portal, we’ll be get the blame. 

I agree that MFA or at leasat an extra layer of security on top of the username/password is required for the client portal.  I was excited, and still am, for the client portal functionality but I am hesitant to roll this out or to put the URL on our website due to what I see is weak security.  

Karbon has mentioned above that best practice is to have MFA, so shouldn’t the client portal have MFA too?   We are following best practice for security in our firm, but I see the weakest link is the client’s password, just like @stupefly’s example above.  Unfortunately, security is only as strong as the weakest link.

 

Would it be possible to not allow clients to create a portal, in the absence of MFA security?   We should be able to turn this functionality on/off for clients (at a firm level).  

Hi Melissa and Stupefly 

For V1, we do not have MFA. If this is a concern for you and you do not want your clients to use the log in, we can provide you with the option to turn it off for them. In settings, you will still have the Client Portal Settings page with the URL we provide (if you shared it, they could create accounts) but we can remove the ‘log in’ option from the magic link your clients receive . This would mean the only change is the replacement of the pin for the magic link. If you would like this option when the portal is turned on, please email me (or the account owner of your account if that is not you). 


Hey @max could you suggest the MFA / 2FA please as a feature as I would definitely vote for it, and it’s something we’d really like to see from a cyber security standpoint as well.  We might be doing plenty at our end, but we can’t control the security from the client’s side.


Here’s my feature idea:

😀


Hey @max could you suggest the MFA / 2FA please as a feature as I would definitely vote for it, and it’s something we’d really like to see from a cyber security standpoint as well.  We might be doing plenty at our end, but we can’t control the security from the client’s side.

@Ellouise Hempstead   I created this Feature Idea a couple of weeks ago:  

 


Unfortunately, Karbon have mentioned that MFA is currently not on the development timeframe.  Please vote for MFA if you think it’s an issue for the Client Portal.

 

 

 


Thanks @Melissa Gock , and apologies for missing your suggestion.
It may not be on the development timeframe, but we definitely think it should be.