Techies: Am I being over sensitive about data security?

Quality of coding, or management is not something that I experienced much of at sage.

Before I worked there I spotted one incredibly dangerous flaw in the operation of there software (it was such a basic thing it was flabergasting it had obviously never been tested, and was fundemental to safe multi-user operation) - when I told them about it they were greatful, but asked me to keep quiet about it as 'it was embarassing to them'.

Whilst working for them, I cant say to much, as I was working for them, but lets just say things were not impressive.

Personally I dont think you are being oversensitive, a lax attitude from a major company can set back the industry quite a lot if a damage occurs it can dent confidence in the users of software across the board.
 
Upvote 0
An excellent article Duane, and a real eye-opener too. I cannot profess to know much about SaaS or development for it, but the article gave a clear understanding even my layman knowledge was able to cope with.

I particularly liked the 'someone forgot to put the batteries in' comment when referring to their (lack of?) intrusion detection. :D

To say that this could be a setback to your industry is an understatement, it could have serious 'trust' problems for the industry as a whole. Sage are a household name, and if they make a public mess of this, the average Joe will tar the whole industry as a result.
 
Upvote 0
yes, of course you have an axe to grind and any other business leader in your position would feel the same.

You are taking on the biggest fish in the pond, you little upstart (hoe dare you!), and are beating them hands down! They are old and ugly enough to know how to build a product, but this appears to be a classic example of 'do you know who we are?'.

If you had similar flaws in your system, I am sure they would be kind enough to point them out.

Regardless of the fact that there are 'issues' in your relationship, maybe they should emply you as a tester - you seem to be doing a better job at finding bugs (pretty serious ones at that!) than they are.

Get out your sharpening stone - I predict you will be using it for some time!
 
Upvote 0
Thanks all. You were meant to calm me down, but the comments above and the comments on the blog post itself suggest they're serious problems that go deep in the companies culture.

I'm starting to wish they'd leave SaaS alone now.
 
Upvote 0
You'll be as surprised to learn as I was that (over HTTPS) a GET is apparently as secure as a POST in that they're both encrypted. But passwords visible in the querystring? That's a schoolboy error.
 
Upvote 0
I'm not so sure the HTTPS URL is encrypted ;)

Apparently. Ask google.

Apparently handshake takes place first to establish an encrypted session - then the URL is sent.

There is absolutely no reason whatsoever to pass a password encoded or otherwise in a visible URL.

Any application that does was obviously designed by numpties :)

^^ what he said.
 
Upvote 0
Yeah,

The URL would be encrypted.

Before any http/https connections take place, the secure layer is established first.

> Hostname is derived from the URL
< Connects to the host
> Validate certificate
<> Diffe-Hellman is used to exchange keys and create Secure Layer
> HTTPS is sent to server
< HTTPS response (both encrypted)


Having all that traffic encrypted is brilliant. But having it in plaintext in the nav-bar is sheer stupidity.
 
Upvote 0
You wouldn't think I had just done a Computer Forensics module on SSL technology would you?

Sending GET requests and the data in a URL never came up in it though - very interesting! :)


P.S. Sage wont be feeling the credit crunch as they're still living in 1997.
 
Last edited:
Upvote 0
Umm......... not good.

However, you raise the question of exactly what is acceptable security on logins to SaaS services where sensitive data is stored. As always with remote access the problem lies in authentication rather than securing the data transmission, the latter being relatively easy.

So is username/password good enough, even if it is encrypted when transmitted? My experience is that it is not, and a more robust authentication method should be used. I could be wrong but I don't think that any online banking systems use just a username/password authentication system any more.
 
Upvote 0
Umm......... not good.

However, you raise the question of exactly what is acceptable security on logins to SaaS services where sensitive data is stored. As always with remote access the problem lies in authentication rather than securing the data transmission, the latter being relatively easy.

So is username/password good enough, even if it is encrypted when transmitted? My experience is that it is not, and a more robust authentication method should be used. I could be wrong but I don't think that any online banking systems use just a username/password authentication system any more.

This is a very good point.

Authentication is a very serious issue - and it's often overlooked.

Something you know (password authentication) is no longer enough to ensure the person on the computer really is who they say they are. A lot of banks have introduced the Something you have authentication whereby they issue you with a special device that generates a time-defined key.

http://ceres.napier.ac.uk/staff/bill/e_presentations/authentication.htm <-- have a peek here for a fantastic wee video.
 
Upvote 0
GET or POST not as different as you might think :)

The only difference is in how a browser chooses to display something, if it liked it could display the post information in bright flashing neon, with a chorus of synthesised trumpets beating out the binary interpretation of the data sent.

SSL does not send the URL in the plain, instead the DNS is resolved and a request to the IP is made for a certificate, this is why it is awkward to have multiple SSL certs on one IP (there are workarounds though).

GET is used to get information, and where the server state stays the same.

POST is used to indicate when the server state changes.

If you take logging out of the equation, then you can see that POST should be used when sending login details, as the session association to a logged in state changes.

But, if you were just getting information say based on the time of day and date, a user criteria and the server was not altered then GET should be used.

So, a query string should only contain parameters to a display function.

So technically they are wrong to send the password in a GET request, but the security lapse happens at the browser, and here you are talking degrees of security, the post information is available but perhaps not as readily.
 
Upvote 0
What if someone looks at the temp internet files, on mine I can see all the https urls I have visited, many with parameters.

Can you see the username and password for the sage account that way?

If so, that means anyone can get into your account, even if you have logged out of sage, all they need is access to your browser. So a collegue, or someone who steals a pc etc could have some fun surely?
 
Upvote 0
In many instances form data is stored in the plain as well.

If your computer gets stolen, then yes nearly every online account you have is potentially compromised.

Firefox is using something called signon3.txt where you should use a master password.

It is encrypted with key3.db, so this is an example of obfuscation, but if you have both files then you can decrypt the passwords out, if a master password is not set.
 
Upvote 0
So is username/password good enough, even if it is encrypted when transmitted? My experience is that it is not, and a more robust authentication method should be used. I could be wrong but I don't think that any online banking systems use just a username/password authentication system any more.

Areed. You need to get the balance between security and usability right though.

On KashFlow, after entering the username/password - you are asked for 3 letters of your memorable word, chosen from a drop down list.

So if there is a keylogger on your PC it wont give someone the details needed ot get in.

This is also the way Lloyds TSB online banking works
 
Upvote 0
Proper authentication using challenge response without password sent to defeat man in the middle are things like SASL.

If you have a keylogger installed on your machine, then why not a session sniffer, at that point the machine is compromised, and theoretically could send and masquerade as the user.

The thing is crackers tend to go for the low hanging fruit, but things as outlined above can also backfire by giving a false sense of security, so you think you are in the clear, but you are not.

Security is a constant monitoring process, and accessing sensitive information from a public terminal is not wise, the problem is the extra security features can leave one thinking it is.
 
Upvote 0
What I'm going to find interesting is how Sage deal with the issues.

The right and responsible thing to do take the service offline whilst they sort out the 2 major problems (password in querystring, unauthorised access to backend). Whether that be for 5 minutes, 5 days or 5 weeks - whatever it takes.

The alternative is to bury your head in the sand and not even acknowledge that there are any issues.

Guess which one my money is on?
 
Upvote 0
Well if Sage browse these boards, which I'm sure they do, then we'll find out soon enough how serious they want to take this...


True. Not a nice position to be in for them though. Damned if they do, damned if they don't.

If they don't take it offline to resolve the issues then they're showing they're not taking the security issues seriously and/or don't know how to deal with them. Not good if they want to be taken seriously with SaaS.

If they do take it offline, they look bad because they're conceding that the jumped up upstart they reported to Trading Standards has discovered major flaws in their security.

The right option is the first one. But I suspect they're more concerned about losing face than losing client data
 
Upvote 0
To be honest, it wouldn't be that big a job to fix it

Perhaps not for you or me, but this is a £2bn PLC we're talking about.

Someone has to decide that it should be fixed.
They need to tell relevant manager to get it fixed.
Manager asks techie for some sort of report on what is involved with fixing it, and so on and so on.
 
Upvote 0
....but things as outlined above can also backfire by giving a false sense of security, so you think you are in the clear, but you are not.

Wise words.

Duane: Taking a "Ha ha, we're secure, Sage are not" line is setting yourself up for a big fall if anything does go wrong at your end. Some would say that getting hacked is when not if.

Would you not be better with a "Unlike many competitors we........". Obviously without revealing to the hackers exactly how your security works.
 
Upvote 0
Wise words.

Duane: Taking a "Ha ha, we're secure, Sage are not" line is setting yourself up for a big fall if anything does go wrong at your end. Some would say that getting hacked is when not if.

Would you not be better with a "Unlike many competitors we........". Obviously without revealing to the hackers exactly how your security works.

I don't think Duane is saying his software is invincible, rather he's done all he can to make his software secure. Whereas Sage has done nothing!

If people can hack into the White House etc I'm sure if they wanted they could hack into a piece of accounting software.
 
Upvote 0
I can tell you exactly why they have implemented the get instead of a post on authentication. They came across an annoying problem that we had on our hosted forms payment solution. It has to do with SSL - changing SSL URLS at the server end and variant browser security settings that cause browsers to pop out warnings at various places in the post - get process which can leave the browser in one state and the server in another.

I will not cover the solution here but if sage wants to chuck me a contract I am sure we can get in done for 4.6m GBP and 9 months work.
 
Upvote 0
I've learned a lot over the years about picking fights with stronger, more powerful foes.

They don't always win, but the hassle they can cause you is disruptive when you should be dealing with your business.

Criticising another company's development approach is a bit glass houses in most cases. I've not seen many web (or local) applications which is correct principles throughout. Data is often stored incorrectly, security dubiously managed, and far too little testing.

Most of the time it doesn't really matter - at least not in the short term. In the long term poor data structures will cost a massive amount of money to put right. But too many developers are rewarded for short term benefits and rarely for long term benefits. The long term thinkers are at their best running their own companies, because they understand. I'm not sure if Sage management really understand their software that well - but they've been very very good at locking down the UK small business accounting software market. Mind you, it's no surprise - I've tried some of the rival stuff and it was uniformly dreadful. Dangerously dreadful, in fact. A classic example is to allow editing of invoices after issue - 0 points for fraud prevention, that one.

Whether Kashflow is good or not, I don't know, because I haven't tested it. Nor have I tested Sage Live. But I decided against Sage software in general because of a:their pricing, and b:their business approach and artificial limitation of functionality across versions, designed to get you onto the most expensive package possible. The downside of going against the Sage flow is that my accountant appears to be a little lost. We'll find out how much at year end :-)
 
Upvote 0
Has sage done anything about this yet, or has it still got it's head stuck firmly in the sand?
 
Upvote 0
Not-So-Sage.jpg
 
  • Like
Reactions: ken_uk and sm1
Upvote 0
They've not done anything yet.

This guy contacted me saying my blog post only touched the surface of the huge underlying security problems they had with Sage Live (check out his credentials, he knows what he's talking about)

He contacted Sage and they didn't respond. He contacted them again and basically said, talk to me or I talk to Duane with the details. That woke them up. This lady got back to him. They're going to "start a conversation" with him (which probably means they'll try to sell him something!).

I'll update my blog when there's more to report.
 
Upvote 0
They've not done anything yet.

This guy contacted me saying my blog post only touched the surface of the huge underlying security problems they had with Sage Live (check out his credentials, he knows what he's talking about)

He contacted Sage and they didn't respond. He contacted them again and basically said, talk to me or I talk to Duane with the details. That woke them up. This lady got back to him. They're going to "start a conversation" with him (which probably means they'll try to sell him something!).

I'll update my blog when there's more to report.

This is definitely an interesting development Duane, and it would be good to have Russ write a follow up post on your blog detailing the full extent of the security problems.

Sage themselves will be bricking it as this could potentially leave them with serious egg on their face, as well as cost them a lot of dosh to provide a crucial fix.

If nothing else, your posts show that the whole industry is not just ignoring the security aspect, and hopefully it will add to your own and Kashflows credentials.

When are you taking over at Sage btw.....? ;) :D
 
Upvote 0

Latest Articles