Security of using a long hash in the querystring to identify a dynamic document_问答_开发者

I'm working on a small webapp that generates exercise program printouts. A user (ie personal trainer) can create an exercise program, then enter the email address of one of their clients. A link to the exercise program then gets sent to the client, like so...

http://www.myurl.com/generate.php?hash=abiglonghash...

The hash is a sha512 string.

I don't want people to be able to easily discover other people's exercise programs. At the same time I would really prefer to avoid prompting people for additonal password info, etc, when they click on that link. I would like a client to click on the link in their email, and immediately get their program, no fuss.

I'm wondering what thoughts are as to 开发者_运维问答the security of the above, without additional authentication? I know it's not Fort Knox, but it seems about as safe to me as a typical "Forgot your password" system. Any thoughts, suggestions as to how this could be improved, without getting into full-blown user authentication?

Thanks in advance,

A "forgot password" system typically does a few things:

Requires you to "know" something once you get to the page (like your mother's maiden name, your high school, etc)
Sends you your new password in an email. Even if you get to the 'forgot password' URL of another user, the new password is sent to that user's email address on file. This means you would need access to their inbox, as well as their "secret question"

For your purposes, a SHA512 string should be secure enough. Using a SHA512 is similar to using a UUID, in theory. It is long enough to be statistically improbable that someone could guess someone else's hash. The odds of it happening are astronomically high.

Of course, there are always easier ways than guessing to get access to someone else's hash. Things like the user's browser history, intercepting their net traffic, looking over their shoulder, etc. Only SSL combined with a protective login system would protect against those things.

Security always brings up questions like these. Obviously the only way to keep all the people you want out is to keep everyone out! But that is not going to work.

If all you are interested in doing is shallowly hiding a user's workout program from another, then what you are doing is not a problem at all and there are no security issues.

If someone guesses (or investigates and finds) a link to another workout program, then there is nothing you can do to stop it with your system. If that is a concern, then you are going to have to come up with another method to know who you are letting in. If you don't care about people actively trying to get at others' workout programs and only trying to stop this from happening incidentally, then you have no problem.

Technically it's exactly as safe as a login/password pair, 32 chars each, i.e. very. Even brute forcing for random records is not an option. With a billion users and billion brute force attempts per second it would take well over 10^100 times the age of the universe before you found a working hash.

In practice there are other consideration, such as caching proxies, browser history and so forth. I would recommend against doing this with important data, but it's really in how you present and explain it to users.

I think this is not a bad idea as long as you don't allow those "magic tokens" to continue to work forever. You should store the tokens in a database and keep track of whether they've been used. Once a client uses the magic token to reach the system, they really should create a "normal" account with a username and password, like every other site on the internet. After that use, the token should be marked as "used" and further uses of it should be disallowed.