maxtardiveau2

Eight pixels ber byte would indeed be more efficient, but the intent of this library was to make the hidden message as discreet as possible, rather than transmit as much hidden data as possible. By modifying only occasional pixels, in an unpredictable pattern (based on a secure hash of the key), my hope was that it would make detection more difficult. Whether I succeeded or not remains to be determined, I suppose.

How can you hide data in DB2 from certain users?

A simple microservice (as a Docker image) that parses any Cassandra query or command (CQL) and returns a JSON object describing what the command is. This uses Cassandra's own parser, therefore it works with any valid CQL command.

A microservice that parses Cassandra CQL commands and returns information about those commands.

Here's an example for Redis using Gallium Data, Mongo would be very similar: https://www.galliumdata.com/tutorials/transparent-encryption...

When you need to share data, but not all of it, there are two fundamentally different approaches to data masking.

Linked servers are one of Microsoft SQL Server's most powerful features, but do you know how they work?

That's a reasonable position, and I think a good conclusion to a constructive debate.

Whether it's unfair to single out SQL Server -- I don't think it is. SQL Server is one of the foundations of modern IT infrastructure, and it should be held to the highest standard. This is clearly a chink in the armor, and Microsoft seems to be aware of it.

Thanks to your pushback, I have refined my argument and will publish a significantly revised version of it on SQL Server Central (https://www.sqlservercentral.com/) on March 2. There is a preview at https://www.galliumdata.com/articles/can-we-please-stop-send... in case you're curious.

I respect your expertise, and I appreciate your civility. Thank you.

You're right, I should not have gone on that tangent.

To get back to the main point, though, don't you think that the fact that Microsoft includes a disclaimer (kinda) in their docs lends some credence to the idea that they're not really proud of this?

> Isn't that also exactly as insecure as submitting an HTML form with <input type="password"> is?

Absolutely, but I am arguing that this is not worthy of an enterprise system like SQL Server. This is especially true for a back-end system, because at least in a web browser, you'd get a warning if the certificate cannot be verified (and the connection is therefore vulnerable).

> Which ones are you thinking of?

Most of the enterprise apps I have worked with use something like OAuth or SAML. For sure, many have an option to use basic auth, but that's only used for testing and development, and would be a red flag in any security audit.

I'll just quote Microsoft's documentation <https://docs.microsoft.com/en-us/sql/relational-databases/se...>:

  Disadvantages of SQL Server Authentication

  The encrypted SQL Server Authentication login password, must be passed over the network at the time of the connection.

It's good that they acknowledge it, but it would be a lot better if they did something about it.

I respectfully disagree. Like I said in the article, transmitting the password, rather than some form of token, means that this approach is exactly as insecure as HTTP basic auth over TLS, and how many serious enterprise apps use that?

>> we'd probably be better off using some sort of PAKE protocol

Yes, that's my whole point. This problem has been solved, there are tons of libraries, it's not that hard. Why have a weak link like this?

If everything is secured correctly, this is not a vulnerability, but how often are things 100% secured properly? TLS is fine, but many people use a self-signed certificate, which means a MITM attack is often possible. It's bad enough to have someone snoop on your connection, but to have your password compromised... And if your client is not Windows, it often has to use database authentication.

This just stinks. It's especially surprising in an enterprise-class system like SQL Server.

The giant green button at the bottom is just slimy -- I fell for it. No, I don't want to install your Protecto extension, whatever the frack it is. Geez.

The author thanks the commenter for the insightful feedback and helpful link, and will gave them all due consideration.