October 24th, 2014 Release notes: Visitor and Open API tweaks

Happy Friday,

Today we have a handful improvements, including:

* Not showing the agent survey (if enabled) at the end of the chat if the visitor has been banned

* We recently rolled out a small change to indicate which fields on PreChat and Offline forms are marked as Required with a small red asterisk. A small bug in certain environments caused this asterisk to be added twice. We’ve added a small patch to make sure that only one star is added, as expected.

* Fixed the Content-type header for the JSON Open API

* Fixed various encoding issues when values sent to integrations: javascript variables are encoded correctly, chat transcript first message when sent to Desk.com and Description field from Custom mappings.

* Fixed an issue when “from URL” is being truncated in Zendesk ticket description.

 

 

Introduction to our New Security Settings

Nothing can bring a real sense of security except true love. We do love you, for sure, but in a world of complex threats we want to, tangibly, offer you a secure service as well.

That is why we’re proudly introducing our new Security Settings!

Our conscious developers’ team has been working during the past few weeks on a series of configurable settings that will protect you more effectively against any malicious hacking and mischiefs. As the account owner, you – and only you- will now have actual control on the security of your SnapEngage account.

*The new security settings are available on premier, unlimited and enterprise accounts.


Password Rules

The security of your team’s passwords is by all means imperative for the overall security of your account. You are, now, able to choose among and combine a series of password requirements that will add up to the password complexity and increase the difficulty of password cracking.

Being safe is good but being paranoid with safety could drive your team crazy since every time you increase the requirements of your passwords all your users passwords will be expired. For your users’ sake, keep this to a minimum!

1st

Password Complexity

Your password complexity can be based on four different elements; namely  length, mIxed caSE LetTers, special characters! and user information. 

Length

Each added character in your password increases exponentially the time it would theoretically take for it to be cracked. ‘alongerpassword’ would be harder to crack than ‘password’. Thus, you can require your users to set their password using a certain number of characters.

Require letters in mix case

By requiring your users to combine both upper case and lower case characters also improves the password strength. In such a case ‘notsafepassword’ would not be accepted but a ‘safePassword’ would have to be used instead.

Require at least one special character

Can question marks strengthen your password? Yes they can!!! Exactly as exclamation marks can also do. So, require your users to include at least one special character (non-alphabetic and non-numeric) in their passwords and instead of having a ‘notsafepassword’ to create a ‘safepassword!’ or a ‘safe+password’. With so many special characters one can be quite creative 😉 .

Password cannot contain user information

If someone tries to guess your password, it is more likely than not that they will also try to get information from your users login. This is common practice for hackers because it is also a common for users to include elements from their login in their passwords in order to, more easily, remember them. That is why you should make sure that your users are not using parts of their login information in their password. Thus, if you log in your SnapEngage account with the email: name.surname@domain.com, you  would not be allowed to use neither ‘name’ nor ‘surname’ in your password.

Password Handling

Besides the password complexity per se, there are more tools at your disposal which can increase your account’s safety, the first one of them being the password originality.

Require password originality and forbid password reuse

Why prohibit password reuse? -Because of risk mitigation and human psychology.

Imagine that you become aware of a password leak in your administration. The first and easiest thing to do, would be to ask your account owner to reset all user passwords. Nevertheless, we, humans, tend to be wary of changing our passwords. Many of us would actually decide to just  set our old password as our new one again; this however, would render the safety action of resetting all passwords useless. To make sure this does not happen, you can disallow password reuse when a user renews their password.

You have the option to either not allow any password that has been used during the last 1, 6 or 12 months or any of the 5-8 most recently used passwords.

2nd

*If the two password settings get compared, we would consider the ‘x last passwords’ option more secure than ‘passwords in the last x months’.

Password expires automatically

By using this option you obligate your users to renew their password on a recurring basis (every 1,3,6 or 12 months).

Lock account after a number of failed login attempts

We are no robots and same applies for you and your colleagues. As humans, we all make mistakes and we are entitled to forgetting one of the many passwords that we are required to use in our everyday life. Many of us use multiple email accounts – personal and professional – Facebook, twitter and other social media, credit cards etc.These are many passwords and pins that we need to remember.

Nevertheless, many failed attempts to log in an account could also mean that somebody is trying to hack it. Thus, after a certain amount of failed attempts you can have an account locked which will then be unlocked again after a certain amount of time (except if specifically required to be locked permanently) or manually from the admin dashboard.


Access Rules

To, even further, protect your account, you can allow restricted access to SnapEngage based on IP addresses. You can either give specific IP addresses or use wildcards.

6th

For more details on the Access rules please click here.

Deactivate an agent’s account due to inactivity

Automatically deactivating an agent’s account if they haven’t logged in for a set amount of time is another additional safety measure that you can decide to use.

 

Whatever the settings that you decide to use are, please remember that the basic rule is to always play it safe. It might get a bit uncomfortable at some point but it can save you from a lot of trouble later.

 

 

Open API Integration Now Delivers JSON

For those who are unfamiliar with the SnapEngage Open API, this is a service we provide where a SnapEngage customer can register a URL which will receive support requests represented as a JSON object.  What this means is that you can integrate SnapEngage into your own system without any work other than configuring the Open API integration.

How To Configure the Open API Integration

In the SnapEngage widget configuration, under the “Integrations” tab, select “Open API” and enter the URL of where you want to receive the support request JSON object.  A POST will be made to this URL when a new offline request or live chat is processed by SnapEngage. Once you are done making changes, just make sure to click the “Save” button.

post api

What Happens Next

Once the API is activated, whenever a new support request is received, SnapEngage will automatically send a POST transaction to the URL specified in the Open API configuration. The transaction will provide details about the support request as a JSON object.

For further information please see our POST API doc