Discussion in 'Article Discussion' started by Gareth Halfacree, 2 Nov 2015.
Company downplays severity.
Oh, well that's ok then.
So long as they're not legally obligated to encrypt details, then these companies will just keep taking the short-sighted, cheaper option.
And they'll keep getting hacked. ****ing dumbasses.
The really, really annoying thing is that encryption is pretty much free. Gone are the days when you used to carefully decide what content you'd serve over SSL or invest in a crazy-expensive accelerator card: systems are fast enough these days that a report by Google (years old now) indicated there was zero performance hit to using SSL on everything. Hell, my desktop PC uses an AMD APU and even that has built-in AES acceleration (which works pretty damn well.)
Passwords should be hashed as a matter of course, 'cos why wouldn't you hash 'em? Everything in the damn table should then be encrypted, because again: why wouldn't you? You can still get hacked ('cos at some point what is encrypted will have to be decrypted so you can use it, and while a dump of an encrypted database might be of no use there's nothing to stop the attacker using the same entry-point as you to get at the decrypted data - but that does make it harder, and introduces rate-limiting potential) but at least you don't then have to go on TV and tell your customers that you didn't bother encrypting their bank details 'cos The Law didn't explicitly say you had to and that's fine and dandy and what are you all complaining for no you can't leave early without paying a penalty fee tough luck so sad thanks for your cash.
It's not working, it's not working.
I still want to yell and scream.
A former employer of mine had a remote access server, sitting on the internet, with out of support linux, that hadn't been updated in years. Containing I don't know how many known exploitable security holes all of which were unpatched. The server in question had access to a customers mission critical systems.
I raised the issue with my boss a number of times and outlined the potential security problems, the IT guy was also aware of it. Nothing was ever done about it. I don't think anything short of doing some live penetration testing in front of senior management would actually get them to do anything about it. What a bunch of cowboys.
My point is, that you can bring a horse to water but you can't make it drink. Sometimes people just don't give a ****. That's the reality of business, as is exemplified by talk talk. Why spend money when there is no immediately problem, that is actually tangible.
They don't care if it doesn't bring more money in. Also, encrypting does nothing at all for data that needs to be reused (names, codes, numbers). Hashing a password is one way usually, but you wouldn't hash the username nor encrypt because you are just adding an extra layer of nothingness. Why? Because you then have to set up a system to decrypt the data adding more resource cost and if the hackers access that layer too (if they can get in your front door, usually the rest isn't much harder to find) then it becomes pointless.
SQL injection attacks don't care about encryption because the account doing the queries is already authenticated. Put in simple cursor and you can dump out all the information until the tempdb is full.
Cases where encryption would matter are on say a flash drive or laptop, or remote storage, where an unauthorised person has obtained the data and is trying to read it.
There's no way anyone getting past my front door is going to find my wall safe, it's well hidden behind the painting of the fallen Madonna with the big b**bies...
This is a good point. Authentication prevents unauthorised access from within the database and encryption prevents someone from taking the files that contain the tables. I think encryption is still valid if someone accesses the server through means other than the database. Getting to a non root shell for example.
I'm not an expert but from what little I've read isn't some parts of SQL encrypted, such as the stored passwords, definitions of stored procedures, views, triggers, user-defined functions, defaults, rules, and the data sent between the server and the client.
Like i said I'm no expert, although having said that it's only taken me 10min and a quick Google search to find a plethora of articles that seem to provide plenty of information on how to protect from SQL injections, and other best practices.
SQL injection is where you would include some SQL executable code in a form on a web page or through some other means. This code is then read in by the database and executed with the same privileges as the user on the database, that would for example make new customer accounts or handle customer data.
Think of it this way, if you had an encrypted hard drive. I then come over to yours and hypnotise you and command you to decrypt the hard drive and give me whats inside. You are hypnotised so you are compelled to carry out my commands, even though you would prefer not to under normal conditions. Because I am controlling you directly, it doesn't matter if the hard drive is encrypted or not.
If on the other hand, I climb in the window and nick the hard drive and run away. Because its encrypted the data can't be easily got at.
Monroe as always, gives a great example
You don't encrypt password on a database, you run them through a one way process called a hash. Encryption is more like a box with a key that you put things in, hashing is a process of manipulation that is only one way. The hash cannot be easily reversed, ideally its irreversible. When hashed a password looks like a random string of characters. When someone enters their password into the website, the password entered is run through the same hashing process and compared to the hash stored on the database, if they match then the entered password is correct, if not then its incorrect. The people that own the database only know the hashing process and not the actual passwords.
Stored procedures can be encrypted, but they still must be executable. So if an attacker is manipulating a database user with permissions to execute the stored procedure then they can execute it. I think encrypting the likes of stored procedures is more about keeping the actual code behind it secret from other database users, rather preventing attacks on the database. In fact I think an encrypted stored procedure might not be encrypted but obfuscated.
I absolutely disagree with this entire paragraph. You encrypt *everything*, because as I detailed upthread there is no performance penalty any more. Will encrypting the database prevent someone coming in through the same access point as you and receiving the decrypted data - either by snagging a staff login or by exploiting a hole in the system as per SQL injection examples? No. Will it prevent someone who has access to the server itself through a different hole making use of copies of the database table? Yes.
Look at it this way: would you leave your windows wide open when you go on holiday? No, you wouldn't. Locking the windows wouldn't stop someone coming through your front door, but that's a silly argument: no step you take will be 100 per cent effective in stopping attacks; if you can come up with a step that is 100 per cent effective in stopping all attacks, you're going to be a very, very wealthy individual when it hits the market. Saying that you won't lock your windows because burglars can use the door is a nonsense argument; so is saying you won't use encryption because attackers can use SQL injection.
Is what you are referring to encrypted SSL connections rather than database tables other system file?
I'm talking about everything: you use TLS as standard, you encrypt data before it is stored on disk, and you sure as hell don't store the passwords themselves. Defence in depth, dude.
If you read my posts you will see that they agree with the fact that the database should be encrypted.
Your said there is no performance hit when using encryption on everything. That's what your post seems to imply but what you are referring to as a basis for that seems to refer to the performance hit (or lack there of) from encrypted internet connections only rather than encrypted everything.
Its this lack of continuity that I am questioning.
Not sure what you're getting at, here. For any given service, the amount of data transferred over the internet is far greater than the amount of data stored or retrieved from a database. If encrypting the internet traffic has negligible impact on performance, why would encrypting the database not be the same?
This from 2009 suggests that Microsoft SQL Server's transparent encryption option "does not add a noticeable amount of CPU overhead." Overall, it measured a 6.36% wall time hit - but, remember, this is from 2009 on a CPU with no AES extensions. Even that negligible overhead has likely gone away.
Have you tried asked a big business to move away from an aging box with SQL 2000?
Not saying that is what TT are using, but you get the gist of what I am saying. It's likely most ISP's are running the same backend equipment since they launched.
Well, if we're talking about TalkTalk specifically (or even ISPs specifically), then I'd love to point out that the database we're discussing was for login and billing. I haven't logged into my ISP's website in months, and they bill me monthly; it wouldn't matter if enabling encryption doubled the time it takes to retrieve my record, it's so low usage.
Ok, but the amount of traffic that a server itself handles from the internet at any one time is unlikely to be greater than the amount of data stored in the database. An internet connection dealing with a stream of only a few packets resulting in a small in size database query (such as select * from table bit-tech join hexus, thats only a few characters), could turn into the database accessing large tables, with a large number of table joins and handling much more data than just a few packets from the internet. They are inherently different ways of handling data using different mediums which is why I questioned that what applies to one applies to everything else.
I've only glanced at the test but its using what appears to be a very small database, how does that scale to enterprise level database, with millions of accounts which would mean even millions more of individual data entries into what is probably not an insignificant amount of tables and massive amounts of disk and cpu I/O
Yup, simply put Create SP_x with Encrpytion as (...) and boom, no user that can login to that SQL server can read that SP. They can still put things in and get things out of it if they are permitted to execute it or dbo.
You can decrypt the SP through 3rd party means, but not normally through SQL Server Management Studio.
Usually used for protecting IP.
The encryption algorithm doesn't care what the data is or where it comes from: the encryption algorithm receives a stream in one side and chucks out a stream at the other. If your server can encrypt at 10Gb/s, then it can encrypt at 10Gb/s - regardless of whether that data is coming from or going to a web browser, a database, or anything else.
You want scaling? Okay, here's an IBM blog specifically entitled Overcoming Performance Obstacles in Data Encryption, from The Big Data Hub. You don't get much more enterprise-scale than that. The conclusion? ' Compared with a similarly configured server that was not encrypting data, the encrypting server delivered less than 4 percent fewer transactions per second at peak system performance. In other words, the performance overhead for encrypting this mission-critical workload at heavy system utilization was almost negligible.'
Now, if you'd like to continue this, I'd ask that you do a bit of Googling for documentation to support your point of view; it's feeling a little one-sided at the moment, I have to be honest.
Separate names with a comma.