hash

(10 posts) (3 voices)

Tags:

  1. aschwa, Blocked

    Hello. I'm rather confused as to what the purpose of the hash is. It doesn't seem to provide any security (I assume security continues to be provided by the usernames/passwords) and it certainly makes it more cumbersome to use external user interfaces with mydbr for reporting. Thanks.

  2. myDBR Team, Key Master

    Hash does indeed provide added security to myDBR.

    myDBR reports are accessible through an URL. User may have access to report with certain parameters, but not with other. User could for example be able to see he's own customers (customer ID as a parameter) but not customers belonging to someone else.

    In order to protect the data a hash is added to the URL to includes information about the report to be run, used parameters (if not user modifiable). With the hash we can guarantee that the origin or the URL is a trusted one the user can only change those parameters that (s)he is allowed to.

    The hash has a seed value (changeable per installation) that only the admin knows. Writing an external application that knows how to generate the hash based on the seed and the algorithm used, requires admin rights. We are updating the documentation how to generate a valid the hash in your own application.

    We are also working to make myDBR more easily integrable to other systems in finer grade than what is possible today. We have some things in already in next realease coming out quite soon.

    --
    myDBR Team

  3. aschwa, Blocked

    Thanks myDBR team. I see that it does provide security. However, it does seem a bit odd that the security is irrevocable. Once I've provided a user with a hash, I can never revoke that user's ability to use a given report with a given set of parameters.

    Also, it seems that some parameters are hashed and others are not. What in the user interface determines whether a parameter is hashed or not?

  4. myDBR Team, Key Master

    The hash is there to verify that the URL generated comes from trusted source. The hash is not the final protection for your data in cases where the data access changes. Consider that the report should include checks for data protection in cases where data access is likely to change.

    myDBR hashes parameters it gets from database and keeps user chageable data non hashed. Let's say you have a report which shows list of your bank accounts. You also have another linked report that shows events in the selected account. When you click open the linked report, the passed account ID is considered a protected parameter since the parameter comes from data derived from a report content. The report may also include user changeable parameters like date range. Now the same linked repoert can be used for different user and the hash protects your data integrity.

    --
    myDBR Team

  5. brad@foreverybody, Blocked

    myDBR reports are accessible through an URL. User may have access to report with certain parameters, but not with other. User could for example be able to see he's own customers (customer ID as a parameter) but not customers belonging to someone else.

    I would love to know how to do this. I can't for the life of me figure it out tho. Is it somewhere in the documentation, or is this something being added to a future version?

    I can see how to make reports accessible via url, but I cant figure out how to write a report where the user only has access to see a restricted set numbers instead of being able to see everybody's info.

  6. myDBR Team, Key Master

    myDBR handles this automatically. Let's take the bank account example.

    First you create a report which lists user's own bank accounts. This can be done by passing the 'inLogin'-parameter to the report and looking for bank accounts that belong to that user.

    With the list of bank accounts you link a bank account detail report to it, by setting the bank account number as a parameter to be passed to the detail report. This bank account parameter is treated as a protected parameter and is included in the hash. You no longer need to pass the 'inLogin'-parameter to the detail report since you already know that only the owner of that bank account would know the URL.

    --
    myDBR Team

  7. aschwa, Blocked

    If the "report should include checks for data protection in cases where data access is likely to change", is there any point of the hash in these cases? Is there any way to disable the hash check entirely? For our purposes, it is not necessary, and it makes writing external UIs cumbersome.

    Last, looking at your latest post, you write:

    "This bank account parameter is treated as a protected parameter and is included in the hash. You no longer need to pass the 'inLogin'-parameter to the detail report since you already know that only the owner of that bank account would know the URL."

    This security model seems somewhat concerning, given that a bug in one report would allow a user to have access to protected data in another report. It seems far simpler to simply require that each report be responsible for its own security.

  8. myDBR Team, Key Master

    The hash calculation is very straightforward, so using it in external UI's should be easy. We have also added the ability to select the report based on the sp's name in addition to the ID. This shoud ease up setups where testing and production environments have different ID's. Also, we've enhanced the ways of getting only selected parts of report if you wish to use myDBR as a data source.

    This security model seems somewhat concerning, given that a bug in one report would allow a user to have access to protected data in another report. It seems far simpler to simply require that each report be responsible for its own security.

    The hash is an automated feature that eases up the report authoring by removing the necessity of putting same check in every report. As said, it should be used in combination of data checks and the decision of using the right method is up the to report author. One of the design principles of myDBR is that you get the most done with least amount of effort.

    Give the next version a try and you we'll see if you are ok with the hash.

    --
    myDBR Team

  9. aschwa, Blocked

    Great. Are the specs on the hash currently available? If so, could you point me to where I can read about them in the docs?

  10. myDBR Team, Key Master

    We are putting finishing touches to the myDBR 2.0 and this has been added to the docs.

    --
    myDBR Team


Reply

You must log in to post.