Sage reveals decode password processes

Mid-afternoon yesterday UK/CET time, a tweet from Duane Jackson, CEO KashFlow suggested:

Hmm, not sure @sageuk meant to publish this. But useful for anyone who fancies a bit of Socal Engineering #security - kf.cm/Qrb2MP

— Duane Jackson (@DuaneJackson) July 30, 2012

The link in question relates to a payroll help desk article entitled: "Real time password decode process." It has since been placed behind a 'permission wall' but at the time of the Tweet, the linked document was in plain view from any browser. I saw it on an Android device. 

I asked Sage to comment on the issue.  

They said: "The link points to an article in our 'ask sage' knowledgebase that we provide to our supported customers, business partners and our internal support technicians. This is a dedicated service (not connected to any other systems or services) and contains no customer or business data." So far so good. 

However, the 11 step process describes in significant detail how to provide the requisite customer help, the methods Sage employs, how to identify that the call is bona fide, the name of the remote software support system they have deployed to retrieve the relevant files for decoding, links to other security related documents and talks about seven 'common passwords types' that Sage customers might use. See graphic below (password types are excluded):

As Sage explained: "At no point in the article does it advise how to decode a password, just how to get the data to Sage for our internal Data Services team to decode." Unfortunately, that's not the point. 

Among other things, the document clearly sets out how to ensure that the help desk technician is speaking to the right person within the customer organisation and if not then how to update the Sage internal contact systems.

A knowledge of help desk processes could be used to contact Sage customers with the purpose of obtaining passwords. All that would be required is a simple re-engineering of the password decode process to get the customer to reveal the appropriate information and at worst, to manually hand over sensitive files. 

Such a re-engineering would not work in every case and of course a nefarious individual would need to know who is and is not a Sage customer. That's not too difficult to acertain, given the fact Sage's database of contacts can never be 100% up to date and the bones of the process for updating customer data along with the name of the system used was also in plain view.

This is not the first time that Sage has been caught out using less than optimum processes. In 2009, Jackson found that the now defunct SageLive was largely insecure:

Sage seems to be aware that security is important. They have a few pages about security that all say the right things. But in reality they fail on the most basic security measures. There’s no point in sticking your servers with Rackspace and shouting about how great the security is if the end-users password isn’t protected. After all, that’s all that is needed to get into a Sage Live account.

Defaults to “Remember me”
The default option on the Sage Live homepage is for it to remember your username and password. You can untick it if you like, but you’ll have to remember to untick it every time you log in. Other wise, all someone needs to do is fire up your computer, put in the url and click the Login button. Your password is already there!

Password shown in clear text
I really had to struggle to stop myself adding 3 exclamation marks to that sub-heading. Almost unbelievably, they show your password on-screen when you log-in – in plain text.

It’s sent to their central “passport” service using a GET rather than a POST – so your password is actually in the requested URL which is displayed in the status bar.

What was surprising is that Jackson's SageLive post was live for nearly a week before Sage closed SageLive off 'for maintenance.' Immediately prior to the take down, I contacted Sage to ask whether they were aware of the issues and it was only then that SageLive was killed. On this occasion, it is my understanding that the support document link was live for anyone to see for a month. It was only after the Tweets started flowing that Sage acted. 

Sage said: "This service is secure albeit we will be looking into why this particular article was visible to customers rather than being restricted to technicians." Surely the broader questions must be:

• How many other documents are there that can be easily accessed in this manner?
• How does Sage manage the third party support relationship such that it knows customer security related requests are handled appropriately?
• What is Sage doing to refine its decode or re-engineer its password processes to ones that are more secure?
• What is Sage doing to ensure that customers setup passwords that have a good chance of remaining secure?