topic QlikView Brute Force Attacks in QlikView

QlikView Brute Force Attacks

Mon, 26 Jan 2026 18:19:17 GMT

I heard there's no brute force attack for QlikView documents.

I guess it's because the encryption algorithm is unknown. It is always a bad strategy used by Microsoft in the past, because one day someone will find the algorithm.

The encryption should always be based on the key.

What do you guys think?

Re: QlikView Brute Force Attacks

Clever_Anjos — Tue, 08 Oct 2013 13:47:20 GMT

My opinion is "There´s nothing 100% secure."

We have to work hard to secure each point of insecureness

Re: QlikView Brute Force Attacks

Tue, 08 Oct 2013 13:49:18 GMT

I just don't understand why QlikView hides the algorithm, commiting the same mistake that Microsoft has done in the past...

Re: QlikView Brute Force Attacks

hic — Tue, 08 Oct 2013 15:43:39 GMT

The QlikView file is not encrypted. It is just binary code slightly scrambled so that you cannot read the clear text. But there is in principle no security. If someone gets hold of a file with sensitive data, I would guess it is fairly straightforward to extract what you want.

If you want a secure solution, you should keep the file on a server and connect to it using e.g. SSL.

HIC

Re: QlikView Brute Force Attacks

Wed, 09 Oct 2013 09:27:01 GMT

Ok I think I found a way, because our clients don't want us to publish the reports on the web server.

Before sending the qlikview file to another user just empty the connection string to the source and refresh the reports.

All the reports will be empty, and the new user will have to refresh the report to fetch the data and he will only get data from data sources he will be authorized.

What I'm not sure is if when you empty the report by changing the connection string, if the data really gets erased from the file, or if it's still there and just is not shown.

Re: QlikView Brute Force Attacks

hic — Tue, 15 Oct 2013 08:36:04 GMT

It depends on what you mean with "empty the connection string".

If you change the connection string to a dummy user (with the right to see only non-sensitive data) then it could work: Running the script will discard old data, and replace it with new non-sensitive data, and you can then distribute the file.

HIC

Re: QlikView Brute Force Attacks

Tue, 15 Oct 2013 15:58:58 GMT

Emptying a connection string is like putting there an empty excel sheet, or an empty database as the source.

Re: QlikView Brute Force Attacks

hic — Tue, 15 Oct 2013 17:51:38 GMT

No, emptying the connection string completely will cause a script error.

So, as I said - it depends on how you do it: You must do it so that the following SELECT does not cause an error.

HIC

Re: QlikView Brute Force Attacks

Wed, 16 Oct 2013 07:25:45 GMT

So what I did was to commment the load script and refresh the tables.

All tables will be empty.

Then you can uncomment the load script and send the file to other people.

Re: QlikView Brute Force Attacks

Bill_Britt — Thu, 17 Oct 2013 10:04:55 GMT

You could always put the load script in a text file and they just use the include statement.

$(Include= c:\myscript.txt);

Re: QlikView Brute Force Attacks

Thu, 17 Oct 2013 10:07:07 GMT

Thanks, it's a new feature to me, but I don't see what that has to do with this thread...

Re: QlikView Brute Force Attacks

swuehl — Thu, 17 Oct 2013 10:16:39 GMT

Maybe you need to clarify what this thread is all about.

Brute force attacks / QlikView binary data format?

How to remove the data from QV applications (File -> Reduce Data -> Remove all values)?

How to distribute applications to users that may not see all data (Section Access?)?

It's pretty unclear to me. Maybe you could clarify what you actually want to do.

In your current idea of a distribution setting (the user uses another connection string), this may lead to load errors if he tries to access tables / fields he is not authorized to. So in the end either he won't see anything (not even the tables he is authorized to), or it will break your data model and potentially makes your app unusable.