3

Logged in user on my site can create documents, pretty much like on Google Docs. The document can be made public by the user, or private (defualt). The documents are stored in a database table like this:

| id | title | content | public | owner |
| 1  | asd   | asd     | 1      |  1    |
| 2  | asd   | asd     | 0      |  1    |
| 3  | asd   | asd     | 0      |  2    |

If public equals 1, it is a public document that can be viewed with a link from any user: site.com/documents/id

The thing is, even though documents can be public, I don't want users to be able to just increment the url ID by 1 all the time to access all public documents:

  • site.com/documents/1
  • site.com/documents/2
  • site.com/documents/3

And so on...

So maybe I should hash the ID or something like that? Like so:

<?php echo 'site.com/documents/'.md5($id); ?>

Problem is, I can't figure out which ID it is on server side since it is hashed...

What can I do about my problem?

lawls
  • 1,498
  • 3
  • 19
  • 34
  • 5
    store hash in your table – kirugan Feb 17 '13 at 15:47
  • 1
    `ALTER TABLE documents ADD COLUMN unique_identifier VARCHAR(32) NOT NULL`, generate the identifier in code when creating the document. – DCoder Feb 17 '13 at 15:47
  • 1
    And btw add index to it, because you will search it very often – kirugan Feb 17 '13 at 15:48
  • @kirugan Sure, I can do that. But is hashing the best way to go? – lawls Feb 17 '13 at 15:48
  • You could generate tamper proof urls, by adding another parameter with a hash of the id and a secret string only the server knows. Then generate the hash and compare it when it is retrieved. – Vatev Feb 17 '13 at 15:52
  • Why do you want to prevent people from changing the id to get to the other documents? – PeeHaa Feb 17 '13 at 16:09

4 Answers4

5

Depending on your security requirements, you should ensure that your document IDs are actually random and not guessable. If you simply hash the auto-incrementing ID, the resulting hash may seem random, but once someone notices that you are simply hashing increasing numeric values (and correctly guesses your hashing algorithm), it is easy to guess possible document IDs.

To achieve this, you could simply hash random numbers (make sure that there are no hash collisions in your database), or work with UUIDs (see this question for an example on how to generate them).

In order to map your hashed identifiers to existing documents, simply store the hash alongside the document in your database (best use the hash as primary key).

Community
  • 1
  • 1
helmbert
  • 35,797
  • 13
  • 82
  • 95
0

You should definitely hash it. Notice that md5 is not secure enough this days, so you may want to take a look at Sha or Blowfish (even if the latter seems an overkill there).

Then you just have to store the hash in the database table that contains the documents properties.

Otherwise you could just create a random hash yourself to identify the document and use that instead of the ID (and obviously check that Murphy doesn't make it so there are two documents with the same hash).

Shoe
  • 74,840
  • 36
  • 166
  • 272
0

How are you validating that a private document is being viewed by the owner?

While having random ids is certainly helpful in preventing easy guessing of document ids, it seems you're looking at security by obscurity.

In your documents controller you need to check if public == 0 that owner == $logged in user. Within this method you would also verify your unique document id.

lhagemann
  • 1,268
  • 11
  • 13
0

MD5 is not ok for hashing numbers, anyone can reverse a numerical md5. I would recommend something a bit stronger, like SHA. (You can also encrypt the entire URL, for more security, as it wont be crackable easily - it wont take up any extra space, as all hashes are the same size regardless of how much data is hashed)

You need to store the hash in the database, and only store it for public files. So any url that has the following URL structure:

"site.com/documents/65hd83jd8h..."

you can lookup in the database, as the hash will be unique.

Husman
  • 6,819
  • 9
  • 29
  • 47