Contact usRequest a demo


The attacker tries to create a co-browsing connection with the agent. To do this, the attacker hopes to guess the PIN that the Collaboration Server uses to verify the connection between the visitor and the agent. By default, this is a six-digit number. If the attacker types the PIN before the visitor does, the Collaboration Server will create the co-browsing connection between the attacker and the agent.

There are a number of ways the attacker might learn the PIN:

  • By guessing, that is, by repeatedly connecting to the Collaboration Server using different PINs, until a number used by the attacker matches one used by the Collaboration Server.

  • By intercepting the PIN when it’s transmitted via telephone. This can be done in various ways, for example by hacking a phone or by listening in on the conversation.

  • By intercepting the PIN when it’s transmitted over the network after the visitor has entered it.

How we prevent attackers from guessing the PIN

If you want to prevent any possibility of attack, you can configure the length and format of the PIN to suit your needs. For example, you can set it to include five digits, or three letters and two digits, or a mixture of eight letters and digits.

In all use cases in which Unblu was used to date, including e-banking and online consulting, we haven’t observed any way an attacker could capitalize on an attack. We recommend you use a PIN format which requires some effort to guess, but is still easy to type for visitors.
The odds of correctly guessing a six-digit PIN (only numbers, no letters) is 10 to the sixth power, which equals one in one million. Given that letters are also permitted, the odds against anyone guessing the PIN run into many millions to one against such an event happening.

Unblu takes the steps below to guard against such attacks:

  • Dynamic PIN generation: PINs are created using an established and trusted random-number generator so they’re difficult to guess.

  • Once generated, PINs expire after a brief period (two minutes by default).

  • Each PIN is only ever valid for a single conversation at any time.

  • Once a PIN is used to make a connection, the number is discarded. An attacker can’t re-use a PIN after the visitor has used it.

  • The number of attempts to join a conversation with an invalid PIN is limited. Once this limit is reached, Unblu denies further requests to join the conversation in question for a limited period (one minute by default).

  • The session ID of the visitor’s session is independent of the PIN. If the attacker learns the PIN, they can’t use it to guess the session ID.

Possible effects of successful attack

If an attacker successfully guesses the PIN, the consequences are limited because of the way that Unblu works. Here are the possible outcomes:

  • The legitimate visitor fails to initiate co-browsing, as the PIN is already used.

  • The agent sees the attacker’s browser content. This doesn’t represent a security risk in itself, as the attacker could just as well (and more easily) get to this point by simply initiating a regular co-browsing session.

  • The attacker has a co-browsing session, but can’t do anything other than that permitted during a regular browsing session. Co-browsing doesn’t provide more access to the visitor than during normal browsing sessions.

  • As the agent and the visitor are still communicating via telephone, the most likely outcome is that the visitor reports that something went wrong. The agent will then re-initiate the co- browsing session. This will end the co-browsing session of the attacker. Even if the agent continues the co-browsing session for some time, this doesn’t present a security risk.

  • At no point does the attacker gain access to the legitimate visitor’s browser content or online account.

For some setups, guessing the PIN may introduce special security considerations. However, due to the architecture of the Unblu co-browsing solution, the attacker can never access the content of the legitimate visitor, and they can never execute commands as the legitimate visitor. The only possible risk is that the agent puts some privileged information into the attacker’s browser - which is unlikely for a number of reasons:
  • The agent doesn’t have any reason for doing so.

  • In high-security environments, you may prefer to configure the Collaboration Server in such a way that agents can’t interact with the visitor’s screen. In this case, it’s impossible that the attacker profits from co-browsing.

  • We recommend that you block the agent’s access to sensitive elements, such as login and password fields, and functions that execute payments. This usually happens as part of the general security precautions.

  • Again, it’s usually part of the standard security precautions that agents don’t have access to the visitor’s passwords, and are trained to be very careful when helping their visitors with log-in problems.

Can guessing the PIN succeed in the Unblu Cloud?

In the Unblu Cloud, this type of attack is blocked in the same way as in an on-premises setup. However, an attacker has more access points in the Unblu Cloud, and you can’t take as many security precautions as on your own server environment (such as blocking access from certain countries or setting alarms when login attempts fail frequently).