2

Some web applications enable registered users to grant temporal application access to un-registered users sending token/private/unlisted/signed URLs (I ignore the exact terminology for this), which are then used to submit sensitive/confidential user information. The reason for using such mechanism is to exempt these user from requiring an account, as they are very unfrequent to the system. This URL authentication/identification system may resemble mechanisms used to validate or reset user accounts, with the difference that they are available for a longer time span (e.g. one or two weeks).

What are possible security flaws on using this mechanism to grant access to users? From my understanding, posting confidential information can be secured with SSL, however sharing these links through email is susceptible of someone intercepting the email being able to supplant the user while the link has not expired, which could result in unwanted submitted information to the server. I assume that one way to minimize risks is to enable people using the URL to POST content only, so nobody (not event the same, legitimate user) has access to any data previously submitted through the same link. So, I assuming that I am not missing anything else, is this authentication design choice justified or it is overall an unrecommended practice?

Update:

The alternative to this is to ask even unfrequent users to create a username/pwd. With this, you make sure that nobody makes undesired requests to your server, and in addition, you can choose to display personal information from the user anytime.

| improve this question | |
1

As long as you are not giving access to any information and only allowing for input, there isn't really a downside, but there also really isn't a need. What are you gaining by sending such a link? You know nothing more about the user than you did if they just went to your website (other than perhaps that they do have access (either legit or not) to whatever communication mechanism you sent the link to.

This could be done before or after the information is entered and as long as no information is revealed, there is really no apparent security issue since all someone could do is convince you that someone else is actually someone that they aren't if the person they are pretending to be decides to go along with it.

You simply have to make sure that the token is random enough that it can't be guessed by an attacker. One possible way to do this is use two pieces of information and implement a lock out if too many tokens are tried for a given identifier.

| improve this answer | |
  • 1) to my understanding, providing the link is a way to put together the submitter and the requester without the need of the submitter creating an account. 2) why is a random guess so dangerous if the attacker would only be able to submit content? (apart from the obvious one of waisting your resources) 3) I am not sure if I understand the method you propose works. could you provide any reference? – jibiel May 21 '14 at 14:21
  • @jibiel - there seem to be some misunderstandings, for your first point, why is sending a URL necessary in the first place? Why can they not simply connect to the site and fill out a public page. What are you gaining by obfuscating it with a token? For the second point, it might not be. You were the one asking about potential security issues. I was simply pointing out that a low degree of randomness in the URL means that someone other than the person the link was sent to may be able to access it. That may not be a problem depending on your scenario. – AJ Henderson May 21 '14 at 15:10
  • For your third point, I'm not sure what you mean by the system I'm proposing. I wasn't proposing any system, I was observing about what I understood of what you suggested. I only suggested that it seems like much of the same thing could be done with a non-secured public site that is openly shared. – AJ Henderson May 21 '14 at 15:11
  • This is making me think ;-) The reason why the page is obfuscated is because you don't want the page to be public, so you are right in that you want to add some sort of security in the token. Regarding the 'system' I actually meant the method you are proposing for securing it. – jibiel May 21 '14 at 15:52
  • @jibiel - Assuming you are talking about the ID, I simply mean that you want to make sure that the system is resistant to guessing if the URLs should only be used by one particular person. If you make it some long random value, people can guess forever and maybe find one. If you make it a unique ID (which is public) and a random access code (which is quasi-secret), then you can disable the unique ID if the code is wrong more than a couple times. This helps prevents random guessing. – AJ Henderson May 21 '14 at 15:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.