Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
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?
My opinion is "There´s nothing 100% secure."
We have to work hard to secure each point of insecureness
I just don't understand why QlikView hides the algorithm, commiting the same mistake that Microsoft has done in the past...
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
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.
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
Emptying a connection string is like putting there an empty excel sheet, or an empty database as the source.
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
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.
You could always put the load script in a text file and they just use the include statement.
$(Include= c:\myscript.txt);