Jesus H Christ. Security is hard, but It's fucking trivial to store data in encrypted format. Hang them.
Lawyers harrumph at TalkTalk's 'no obligation to encrypt' blurt
Lawyers have taken issue with claims by TalkTalk boss Dido Harding that the telco was under no legal obligation to encrypt customers' sensitive data. Harding's comments came on Sunday, three days after TalkTalk admitted a breach on its systems that may have exposed the personal details, including bank information, of up to …
COMMENTS
-
-
Monday 26th October 2015 20:08 GMT Velv
Security is hard. It's hard because there is no single solution and it must be implemented in layers.
Encryption is completely useless against a straightforward extract using the correct credentials. A bulk export to clear text is a (relatively) trivial query, which is where other layers of protection are required. And since we don't yet know what has been taken or how, there is no way of knowing if encryption would have made any difference.
But you're right, encryption is one of the simple and powerful layers to implement and there's no excuse for not doing it.
-
Monday 26th October 2015 21:00 GMT Dazed and Confused
Broken by design
> Encryption is completely useless against a straightforward extract using the correct credentials.
The simple fact of the matter is that the front end web servers shouldn't have unrestricted access to sensitive customer data. It should not be possible to issue a query from those systems that can retrieve full credit card and bank account details. Sure it makes life bloody easy for the website developers to be able to issue a simple SQL query to the back end and pull out the data, but so long as that is possible then these breaches will happen. Only by stopping the data being there to be hacked are you going to stop it being hacked. In the case of the card number the most that the web server should be able to see would be a bolloxed version with the middle full of stars.
Like the way that password are handled, the system doesn't store the plain text password, it stores a hash. When the user logs in then you hash what they type and compare the resulting garbage. In the case of the card numbers the user should say which card they want to use and then either the list id number (she chose card 3) or the full card should be sent to the back end system to do the financial transaction. There should be no unrestricted access from the webserver to the backend box. There should be no other access to the backend box from the any of the public facing machines.
If it was possible to get access to the banking/credit details from the webserver then the whole management team should be doing time and the there should be massive fines plus liability to customers who lose out. Only by sticking the boot in like this will companies start to take security seriously.
-
Tuesday 27th October 2015 09:30 GMT LucreLout
@Velv
Encryption is completely useless against a straightforward extract using the correct credentials. A bulk export to clear text is a (relatively) trivial query, which is where other layers of protection are required.
Agree completely, however, the immediate answer to questions surrounding a breach like this should always always be "Yes, the data was stored in an encrypted format". Obviously on its own that won't be enough, but its fairly trivial to do, and is one of the foundations/cornerstones of data protection.
If the CEO has to resort to statements like "well, we don't really know because we have millions of lines of code, but its possible some of it might have been", well, what you've got there is a company that has no business retaining or otherwise handling customer information.
*cough* erm, like my company... but that really isn't for want of flagging this to the powers that be.
-
Tuesday 27th October 2015 09:37 GMT itzman
By definition..
Hacking is not 'using the correct credentials;'
I have implemented several websites that store sensitive information, The scripts that allow 'correct credentials' to extract pertinent information do NOT allow global access to all information. Because the strictly limited SQL queries are built into the scripts., And the keys are stored outside the scripts themselves so that even if the scripts are compromised, they cannot be run successfully on another machine against a stolen encrypted database.
In order to extract data from a database encrypted in this way you need all three elements to be accessible - the database, the scripts showing how the keys are used to decrypt it, and the keys themselves.
To get all three you need to root the machine,. SQL injection will not help.
-
Tuesday 27th October 2015 09:52 GMT John Smith 19
@itzman
"I have implemented several websites that store sensitive information, The scripts that allow 'correct credentials' to extract pertinent information do NOT allow global access to all information. Because the strictly limited SQL queries are built into the scripts., And the keys are stored outside the scripts themselves so that even if the scripts are compromised, they cannot be run successfully on another machine against a stolen encrypted database."
I understood your description in about 30 seconds.
I don't really understand what is so hard about implementing this process.
-
-
-
Monday 26th October 2015 22:40 GMT Anonymous Coward
I've been working with web servers for about 10 years.
I've yet to come across an encrypted one.
I've worked with both Apache/Linux/MySQL stacks and Windows/IIS/SQL Server stacks...all without encryption.
Instead they have good security in the web application side of things. Encrypted https connections, hashed passwords, no direct SQL to the database, locked down databases and regular security checks, not to mention very good physical security - for which you pay a high price to good hosts.
I will say for the most part these haven't been the most interesting of databases and all payments would have been held with a third party processing company.
I'm not entirely sure of the point of encrypting the database which so many seem to be advocating here in order to prevent an attack of this sort. If you've got past the web security side of things then chances are you can find the keys that the web service uses to access the database (unless they're write only access). Encryptions only really going to help if someone steals the server(s) and plugs it in elsewhere. Which hopefully they're not going to be able to do because of the physical security.
As for trivial... I'm not so sure it is. Obviously anyone can create a true-crypt container or the likes and stick something in it. However encrypting a SQL Server database correctly requires for example SQL Server Enterprise - which to my limited and slight dated understanding is licensed per core at some extortionate rate beyond many small-medium size businesses capability...not to mention some more specialist understanding than your average web developer might have. Maybe for a business the size of talk talk this shouldn't be a problem... but is it the right solution or just a rubber stamp people are looking for? I'm curious to understand others opinions here.
-
Tuesday 27th October 2015 09:45 GMT itzman
Re: I've yet to come across an encrypted one.
Well all you are saying is the average level of security on most sites is total pants.
I've written several that are, simply because of certain isues pertaining to those sites that made it possible that entire databases might be stolen by e.g. sysdadmjns responsible for the server infrastructure, or in one case where a portable database was carried around on a ;laptop. In the latter case we split the database from the application using a USB drive so that even if the laptop went AWOL with the encryption keys, the database would not. And vuice versa.
Given that SQL injectins is something that no competent programmer should have left the possibility for, in this case encrypted data clearly would have prevented critical information from becoming public.
Those that have suggested that encryption would not have helped seem to have no idea how a website built over a database actually works, or what sql injection is.
-
-
-
-
Tuesday 27th October 2015 09:37 GMT LucreLout
Re: Security is hard
@Stretch
This data was retrieved via the application, which of course would have the encryption keys, and would handily decrypt the data for you.
Yes, yes it would. Any developer still building web sites that are vulnerable to SqlInjection has literally no business building web sites at all. Ever.
This is just another reason why we need an industry regulator with the power to authorise people to work in the IT industry, or prohibit them due to lack of skill or care.
-
Tuesday 27th October 2015 09:51 GMT itzman
Re: Security is hard
SQL injection actually is rertieving data NOT by the applications as it was designed to run, but via a flaw in it. That flaw would not have invoked the decryption if that had been present.
That is if you manage to tack onto a form variable that is not checked for it the string '; select * from credit_cards' you make get the entire credit card database, but not in an unencrypted form.
You are assuming that the encryption is somehow inside of the SQL server. It shouldn't be there. It should be in the application, so that direct access to the database does not return unencrypted data. Encrypting a database but having sql return an unencrypted format is not security, its lunacy.
-
Tuesday 27th October 2015 10:58 GMT LucreLout
Re: Security is hard
@Itzman
You are assuming that the encryption is somehow inside of the SQL server. It shouldn't be there. It should be in the application, so that direct access to the database does not return unencrypted data.
Yes, correct. And that takes about 5 minutes to implement and should be so standard throughout the enterprise that the CEO can confidently declare "Yep, the data was encrypted". The application should not execute arbitrary statements and should have access to return only that which is required for the operation it is supposed to be executing.
Anyone building web sites that does not know about parameter binding and Sql Injection should be stopped from building web sites. That they cannot be stopped does not reflect well on our industry.
-
Tuesday 27th October 2015 14:00 GMT Anonymous Coward
Re: Security is hard
@Itzman
OK so if I'm getting you right you're saying encrypt the data that goes into the database rather than the database itself.
Which you can do with things like payment data if you actually process that yourself... and I get that. That makes sense.
However you can't encrypt things like customers names, addresses, emails etc in that way.
If you did you wouldn't be able to do a customer look up by name for example without decrypting every name in the database first.
Assuming your website also has some kind of call centre/admin login that's a fairly simple piece of functionality that you're going to have?
-
-
Tuesday 27th October 2015 10:15 GMT alain williams
Re: Security is hard
It is not hard to put the really sensitive information in a separate table. Then not allow direct access to that table and provide some SQL functions to do the jobs needed: CheckThisPassword, UpdateThePassword, ... like that the web application can only pass in a candidate password or a new one to be set, ... it does not see the stored password, encrypted or not.
No, not perfect but it makes it harder to grab everything. Security is about belts and braces, assume that one will break and that the other(s) will keep you safe.
-
-
-
Monday 26th October 2015 19:22 GMT Ben Tasker
Legality (and common sense) aside, the one position you don't want to be in is one of, just after apologising to 4 million people who's data you've lost, having to justify why you hadn't encrypted that data.
I'm surprised Harding was allowed to approach it in quite the manner she did. You'd think someone would have forewarned her.
I'd have more sympathy if she'd had to explain to a group of idiots (as I'm sure we've all had to, even if only hypothetically) that the data was encrypted, but they got the keys because the web service needs to be able to decrypt the data to use it.
But to say we didn't implement a simple measure because we weren't legally compelled to
-
Monday 26th October 2015 20:42 GMT Doctor Syntax
"I'd have more sympathy if she'd had to explain to a group of idiots (as I'm sure we've all had to, even if only hypothetically) that the data was encrypted, but they got the keys because the web service needs to be able to decrypt the data to use it."
Maybe that's how someone explained it to her.
-
Tuesday 27th October 2015 09:54 GMT itzman
How would someone get the keys
by SQL injection?
Unless they were - gasp - stored in the database...
I was feeling pretty contemptuous of Talktalks management until I read the plethora of ignorance in these posts here.
It seems that virtually no one in the IT business understands how to make a website secure, either.
-
Wednesday 28th October 2015 14:25 GMT Ben Tasker
Re: How would someone get the keys
by SQL injection?
Unless they were - gasp - stored in the database...
Sadly I've seen exactly that more than a few times. Along with one idiot who had debug on, so, amongst other things, the decrypt key was in the response headers. Which idiot thought doing that, even in debug mode was a good idea I don't know, but I told him he needed to migrate off that CMS or at the very least have a full code audit urgently.
But, I was actually thinking of more skilled/thorough compromises where the attacker has managed to nab a copy of the service from the filesystem too (which might jnclude something as stupid as leaving an old backup in a web accessible location).
People think encryption is a panacea, but it's not. It's something you should be doing, but there are still a lot of attack profiles where it makes no difference. Doesn't mean there isn't a benefit to closing off the others though.
-
-
-
Tuesday 27th October 2015 02:50 GMT streaky
As I was saying to somebody earlier, my understanding is one of the main rules of PR is you shouldn't try to pass yourself off as a lawyer. She did and failed miserably.
The law isn't clear - but one would assume the test would be what a reasonable (competent) person would do; if they're found wanting they could be up shit creek.
Crypto or otherwise - a reasonable developer wouldn't have SQL injection flaws everywhere (they're a bit 2006) and a reasonable person may set their systems up with crypto for various aspects of their data. Even if they're about as useful as a paper bag and don't fully secure you and maybe wouldn't have kept customer data safe because a reasonable competent person would have done it you could end up being liable under the law.
-
-
Tuesday 27th October 2015 14:24 GMT Anonymous Coward
I worked for a firm who had a very nice CEO who understood that if you don't know something don't try and bluff it. Then he left and his replacement didn’t understand this. Basically a building firm down the road had cut cables supplying the building with connectivity by accident. He addressed a large meeting of staff and said our downtime couldn't happen again because of technical measures he'd implemented after the incident. So his technical measures was just a decision that as our contract was up we'd switch to a new supplier, who obviously (well to the rest of us) were going to be using the same cables He'd been told that this wasn't a solution before the meeting but for some reason decided to spout crap that convinced nobody.
-
-
-
-
Monday 26th October 2015 19:24 GMT Dan 55
In their info for business and government customers they also say they are ISO 27001 compliant which requires encryption for data at rest. So, if someone asks them this question (Go Reg), either they're not actually ISO 27001 compliant or they've got to come out and say they don't care about consumer accounts. And if it's the second, can they be 27001 compliant and non-compliant at the same time on the same infrastructure?
-
Monday 26th October 2015 19:43 GMT Chris Miller
I think you may be conflating 27001 with PCI-DSS (which is based directly on it and does mandate encryption for certain credit card related data). Hardly any actual security measure is mandated by 27001, it provides a list of over 100 security controls (including encryption) which are set out in ISO 27002, and if you choose (after due consideration by those responsible for the security management process) not to implement them, you must justify your decision.
Note that claiming you're 27001 compliant means precisely zilch - it's only certification that matters.
-
Monday 26th October 2015 20:56 GMT Anonymous Coward
they are ISO 27001 compliant
Well, that's one of those things that has been pissing me off for quite some time. ISO 27001 is basically confirming you have some system to manage the security policy you should have in place (known as an Information Security Management System, in the world of IT naturally turned into an acronym ISMS), on the pretext that without it you'd be very disorganised. But it still just confirms you have a system, it is not really looking at the quality of what you actually do - which is ISO 27002. In short, the ISO 27001 cert is based on presumption rather than on the presence and execution of the very policies it's supposed to manage, and only those actually ensure controls are in place.
I much rather deal with an organisation that seeks to work according to ISO 27002 than one that shows me an ISO 27001 cert, and if I were to review such an organisation, it's their approach (read: policies) what interest me, also because a smaller outfit can be compliant without spending big $$$ on consultants to give it the ISO 27001 accreditation, and thus be secure by default without doing it just to get a tick in the box.
I see ISO 27001 certs as consultant food and mainly focused on avoiding liability. If you are genuinely concerned about security you review ISO 27002 deployment, and I suspect you would probably find problems at TalkTalk...
-
Monday 26th October 2015 21:27 GMT Chris Miller
I think your experience with 27001 is a bit out of date. What you describe may have been true many years ago (a bit like the old joke about ISO 9000 and 'concrete life-jackets' - as long as your documentations says "we provide concrete life-jackets" and you provide them, you've passed!), but you've got to produce a (public - and you'd be well advised to examine it if you're assessing the security posture of a potential business partner) document setting out for each of those 100+ 27002 controls, whether it's applicable to your activities, and (if so) how you've implemented it.
An external assessment (mandatory and normally every 6 months) will focus on any controls that you've excluded (there'll normally be a handful at most) and examine your justification for doing so. There'll then be a detailed examination of a sample of the remaining controls, to check that you're actually implementing them as you say.
Just like ISO 9000 in regard to quality, gaining ISO 27001 certification is not proof that you've achieved a certain level of security - it's that you have management systems in place that should allow your organisation to deliver the required or contracted level of security.
[Disclaimer: I'm a 27001 consultant (how did you guess?) so this may not be completely unbiased. OTOH I'm freelance so will try to avoid the 'baffling the bastards with bullshit' that certain larger consultancies may occasionally indulge in.]
-
-
-
-
-
-
-
Tuesday 27th October 2015 10:12 GMT Ben Tasker
Re: Change the law then?
>> I'm not sure which is the Pacific coast of the UK.
>Such details remain classified until the treaty is signed.
To reduce businesses advertising costs, the treaty will mandate that all countries relocate so that they have a pacific coast. That way all times can be advertised in PST. We also need to consider USD legal tender, and start understanding Jay Leno references.
In reciprocation, we will be given the privilege of acquiring overpriced tat from US companies, with the bonus benefit of more US style reality TV gracing our screens.
-
-
-
-
Monday 26th October 2015 20:18 GMT Velv
Re: Change the law then?
Encryption only protects agains certain types of loss, and anyone with the right credentials can export the data. Taking "sufficient measures to protect data" therefore might include encryption, but requires other measures to also be implemented. Making encryption a legal requirement would make companies believe that's all they need to do.
-
Tuesday 27th October 2015 10:00 GMT itzman
Re: Encryption only protects agains certain types of loss (was Change the law then?)
And SQL injection is one of those types of loss. It protects against the loss of raw database data.
Unless the decryption is carried out, not by the application, but by the database itself, there is no way an SQL injection attack can reveal the plain text of encrypted data.
Those that say in a silly hand wavy way that 'because the application can decrypt the data, and the attack used the application, therefore encryption is useless' betray an alarming depth of ignorance into how such applications and attacks work.
-
-
-
Monday 26th October 2015 19:53 GMT Bronek Kozicki
Encryption wouldn't have helped. Since this was SQL injection attack, it must have been performed under credentials of the authorized web application, one which would have access to decrypted data. When talking about database encryption, it is usually the database file which is protected, but once an engine connects/attaches/opens it and starts sending queries, the data must be decrypted on the flight, usually at the filesystem level.
Yes, SQL injection attacks are nasty, which is why I spoke about them on security conferences in the previous century. They are also easy to protect against, assuming the company has coherent IT strategy. Which, apparently, Talk Talk does not. And the last thing : it is CTO or CIO whose jobs should hang on balance here, not "chief security officer" (who cannot act against company's IT strategy) or CEO (who does not have a clue about technology and does not need to - if CIO is competent)
-
-
-
Monday 26th October 2015 22:26 GMT Commswonk
Re: it is CTO or CIO whose jobs should hang on balance here
There is also the post of Data Controller to consider, although it would not necessarily require a "techie" to occupy the post; is not the Data Controller the person with overall responsibility for the proper management of the data held?
I wonder if it was a situation where different people were squabbling over "who does what" (an old fashioned turf war) leaving the proper protection of the data to fall between the cracks.
-
-
-
Monday 26th October 2015 22:13 GMT Anonymous Coward
"not "chief security officer" (who cannot act against company's IT strategy)"
The head of security should be able to veto a dangerous IT strategy in exactly the same way as a Chief Safety Officer can veto a factory process, irrespective of what the Chief Operations Officer, Production Manager or Board of Directors want to do.
The Health & Safety Executive and associated legislation set all the precedents needed to deal with stuff like this decades ago - it just needs to be adopted.
-
Monday 26th October 2015 22:29 GMT Anonymous Coward
Re Bronek
I agree with almost everything you put except this bit:
And the last thing : it is CTO or CIO whose jobs should hang on balance here, not "chief security officer" (who cannot act against company's IT strategy) or CEO (who does not have a clue about technology and does not need to - if CIO is competent)
If the Chief Security Officer is a C-Level Exec then surely it should be just as hard for the CTO/CIO to act against the companies security strategy as it would be for the CSO to act against the IT strategy?
Part of the problem is when organisations make infosec subservient to CTO/CIO objectives. In these organisations there is no real Chief Security Officer.
Also, the reality is any decisions which have led to this problem will have stemmed from every C-level exec. Budgets will have been set, goals established, risks taken. When the money comes in, every exec takes credit so now the monster has bitten, they all need to feel the pain.
Senior execs often get praise for their "high risk" strategies when it generates profits, but risk always carries the chance of it going wrong. It has, so now they must make amends for years of underfunding security.
-
Monday 26th October 2015 23:02 GMT Commswonk
Re: Re Bronek
"Budgets will have been set, goals established, risks taken."
I would very much lilke to see the corporate Risk Register, at least the bit starting "Loss or Theft of Customer Data". The entries for Probability / Impact / Mitigation would make for interesting reading, as would those for "Reputational Damage" and "Disaster Recovery"; an entirely different scale would be needed: 0 - n, where n is a large integer.
I then remembered this: http://dilbert.com/strip/2000-08-15.
As usual Scott Adams got it right.
-
-
Tuesday 27th October 2015 04:57 GMT Infernoz
Filesystem encryption is only useful to prevent unauthorised access to data on a physical storage device or clone, so useless for a logged in user. Proper database encryption is not coarse database file encryption, because it needs to be user permission based.
SQL injection attacks are avoidable if parameterised SQL with robust value validation (including blocking exploits in complex data types like XML and JSON) are done, better still is if the application user only has database permissions to use some stored procedures and some stored functions (with robust value validation), and some restricted views for dynamic query use, but no direct table access.
It isn't just SQL injection, public facing servers must now be both sneaky and paranoid about both provided and received data, this includes not passing secret data in 'hidden' web content, using mapped tokens and using varying page security tokens to reject abusive reuse of page requests or repeated submission issues. Sneaky reflection injection attacks can be prevented by use of whitelists, maps and other anti-reflection validation. Browser side page validation is useful to improve user experience, but useless for security!
Talk Talk look to seriously need some up-to-date web developer and DBA security training, proper databases which have the functionality and user security to do security properly, and security awareness all the way up to director level to support this. The CEO is still ultimately responsible, especially when they reveal how clueless they are!
-
Tuesday 27th October 2015 10:11 GMT itzman
Filesystem encryption is only useful to prevent unauthorised access to data on a physical storage device or clone, so useless for a logged in user. Proper database encryption is not coarse database file encryption, because it needs to be user permission based.
We are talking record encryption.
Specifically the credit card records would be prime choice.
You can even hash that with the user password or some unique customer linked key to avoid the ability to decrypt all the records, even if you have the credentials to decrypt one.
If I go into my bank, they still need MY password to access MY records.
As well as THEIR passwords to log into the system at all.
-
Tuesday 27th October 2015 14:19 GMT Bronek Kozicki
If you are doing record encryption, that implies your queries are too complex to avoid using stored procedures. And if you have to use stored procedures, you are unlikely to be vulnerable to SQL injection assuming you pass the parameters right (i.e. not by dynamically building query string).
I referred to simple case of encrypted data files and my get-away clause is here: "usually the database file". Yes more sophisticated encryption is possible and even desirable, but c'mon we are talking in the context of Talk Talk. Talking about record encryption is like explaining quantum physics to nursery children, they probably think that "input sanitation" is a dirty word.
-
-
-
Tuesday 27th October 2015 10:06 GMT itzman
You are simply wrong.
Credentials give you access to your won data.
Not the entire database.
Neither does the ability to decrypt a single record using an application function imply the ability to decrypt an entire database.
There seems to be a series of deliberately ignorant trolls/shills spreading false information here in an attempt to make talktalks position tenable. It is simply not.
I have implemented encrypted database tables and records precisely because I feared the loss of the entire database via - amongst other things - sql injection, although the way the application is designed that is unlikely to work - I certainly left no holes open that I was aware of.
-
-
Monday 26th October 2015 20:02 GMT Disgruntled of TW
Interview about SMTP From: address
If Dido hadn't gone on camera claiming that trusting the SMTP "From:" address was "ok", then perhaps the TalkTalk media engine would have a chance. But they let her do that, and deserve what they get as a consequence.
Geez - media really need to get their facts right, so that non-techies and techies alike are all happy to consume the goo they spew. As it seems to be right now, it all stinks.
Without actual facts, I ignore the headlines and media, as most of us probably should. Let them get fined, according to the seriousness of their cockup, decided by experts who have access to the facts. Mooing and bleating about it based upon media reports is putting us all back into the medieval ages.
-
Monday 26th October 2015 20:04 GMT Shadow Systems
It's called "Due Dilligence".
You're required to do everything reasonable you can in order to protect that which has been entrusted to you. Failure on your part to practice DD to protect said entrusted thing (data, items, money, property, etc) renders you liable to legal prosecution. If I give you my car keys to hold as my "Designated Driver" for the night, but you then get my car stolen because you couldn't be arsed to lock it after dropping me off, it's *YOUR* fault it's been stolen and *YOU* get to pay to replace it. If I've entrusted you with my PII (such as Real Name, telephone number, & CC details) and your failure to practice DD results in said data being stolen, then guess what - it's *YOUR* arse on the line for the theft & subsequent misuse of said data.
I'm not sure what brand of crack she's been packing into her pipe but it must be some pretty powerful shite for her to think she didn't need to bother with DD about her customer's data. If I were a TT customer I'd seriously be discussing with a barrister right about now about a lawsuit for failure to secure said data. Can't be bothered to keep my bits from getting stolen off your servers? Then I can't be bothered to care that all your customers rise up in a unified howl for your head.
Enjoy those pitchforks, buckets of burning pitch, and the hounds baying for your ass.
I'll be the guy over here with the bowl of popcorn & giving Schadenfreud a "High Five" over your demise.
-
-
Tuesday 27th October 2015 07:06 GMT mark 177
Re: Ah yes fines...
No, the customers will not pay.
In a competitive market, shareholders will pay.
The last thing that a company with a trashed reputation is likely to do is to raise prices - it will probably need to drop them for a while to win back business after a cock-up of these Brobdingagian proportions.
-
-
Tuesday 27th October 2015 06:47 GMT Anonymous Coward
Agility
As I explained in my recent interview at RBS (still waiting to hear back from them), if you want to be Agile, then you follow these rules:
1. Extra code is dead code is wasted time is poor UX. Do you really need that validation in multiple layers? You do not.
2. Users generally know what they want, so make the front end flexible. Power users probably need some sort of custom query interface, so provide this. SQL is a rich and flexible language, ideal for power users, who may even know it already. Consider adding a data model map to your site map: websites should be nodes of discovery, not barriers to fulfilment.
3. SSL slows down a website connection by at least a factor of 152. Let me explain: that means that if a non-SSL query takes 1 second, enabling SSL will make that query literally take 2 minutes, a whopping 97% degradation. You do the maths. And, as recent news has shown, SSL is buggy and unreliable. Hardly anything needs SSL, probably only Instagram.
4. There's no point in testing over a VPN, as it's not how your users will work. Don't make a 2 tier website: make it what I call "AgileAdaptive" and allow debugging across the Internet. Your offshore Dev team can work from home and still do their jobs.
5. The PC is a horribly under-utilised resource, sitting idle for most of the time. So why filter and sort on a busy central server - send everything to the browser as XML and use XSL and CSS to sort. Don't want people to see something? Simple: make the text colour the same as the background colour.
Follow these rules and I guarantee people will globally flock to your site. Remember, if traffic is King of the noble land of Web, then all publicity is its regal Queen. Be "AdaptiveAgile", get both now!
-
Tuesday 27th October 2015 08:35 GMT Anonymous Coward
All hot air, no action
For all the bleating that is going on, nothing will happen. The ICO has no real power and what little it does have, it rarely uses. It's a a wet sop to keep the public quiet and provide a pretence of our Master actually giving a shit. Which they don't.
What should be happening right now is the CEO (and other executives) made personally liable for customer's losses, the company fined £1,000 per breach (i.e. per customer record lost) and then the CEO etc can face criminal prosecution, jailed and the remainder of the worldly assets sold to recoup costs.
You only need to do something like the above ONCE to get companies to wake up and actually behave themselves.
But our unrepresentative, out-of-touch, champagne swilling and canapé scoffing Etonian Old Boys club don't give a damn about you or me; just where the next "donation" is coming from.