News Third suspect arrested over TalkTalk breach

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.

 

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.

 

^ this.

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

http://xkcd.com/327/

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.

 

Is what you are referring to encrypted SSL connections rather than database tables other system file?

 

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.

 

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.

 

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.