Welcome Guest, Not a member yet? Register   Sign In
Select id by md5??
#11

[eluser]slowgary[/eluser]
I see. Well if they're public URLs then there would probably be a browse function somewhere anyway, and if not there should be some authentication that would stop them from seeing other accounts. Of course as you said it wouldn't stop them from seeing how many ids there are. Unless you require the auth before you check for the ID.

What about storing the ID as session data upon login, then it never needs to be exposed by the URL. Would that make sense at all or should I just go jump off a bridge?
#12

[eluser]Aea[/eluser]
That works all fine and good until you want users to be able to access something, but they can't without having the ID in their session, chicken and egg. You could get around with a token system but that would result in a) in-usability since you couldn't link, b) me screaming.

Don't over-engineer the problem, you want to obscure URLs to:
a) Prevent Fishing Attacks
b) Knowledge of Size

Build or a key as proposed above or use an existing function like uniqid() to build a key for you. Both are a little bit deterministic when fully implemented (i.e. based off of time), but are random enough that it solves your problem. md5() is a non solution, nothing stops me from iterating through using md5's instead of id's.
#13

[eluser]mvdg27[/eluser]
Basically the reason I need this kind of thing is that my client doesn't want the user profiles to be browseable to easily.

I'm writing this app for an alumni database. All the alumni profiles are public, and they can be accessed with a search function for all logged in user. The only thing they want to prevent is people going through all the profiles just by changing the URL and possibly ripping all the contact details (they somewhat want to prevent their database of alumni).

I'm aware that this is never fool proof. In this case the goal is just to have a very basic "protection".

I agree that md5 might not be too smart, since once you figure out I'm using md5, it's just as easy as entering all the id's in the URL. However in my case, there is no need for a super safe solution.

I'll look into the suggestions you made.

Thanks, Michiel
#14

[eluser]jedd[/eluser]
Quote:I agree that md5 might not be too smart, since once you figure out I'm using md5, it's just as easy as entering all the id's in the URL. However in my case, there is no need for a super safe solution.

Why not just salt the id before creating your md5 then? It doesn't matter what you salt it with - date, id, login_name, etc. Cycling through every combination of md5 would take a remote user a heck of a long time, especially if you put in some code to slow frequent-hitters right down (there's a few threads on doing this in the forums).

Assuming you're doing the extra column for the md5 data, of course.
#15

[eluser]mvdg27[/eluser]
Yeah, my current setup is using an extra column with a hash. I'm now using md5() on the ID, but I might use another thing to create the hash yes.
#16

[eluser]Aea[/eluser]
If your salt isn't constant you still should check for collisions, it's pretty unlikely that you'd get a collision, but MD5 has some issues and it would be possible. Or at least set the field as a UNIQUE so it can fail.




Theme © iAndrew 2016 - Forum software by © MyBB