1

If you know of a better title, please feel free to edit the title.

I'm making a simple google Web App so colleagues at my workplace can view details about a QA that they received. The issue is only certain individuals have Google Apps accounts, so the Web App cannot be restricted to users on our domain.

I was considering generating a random number for each QA response, then using the QA details and that number to generate a hash that is essentially a unique url. ie https://script.google.com/a/macros/MyDomain/MyApp/?code=UniqueCode. visiting that URL with the unique code will show you the details on the QA.

The unique code would be retrieved via GET.

Is this secure? Can this be easily cracked to view very basic info on employees?

Improve this question
2
  • Can't you just tell them to get Google accounts? What your suggesting is weak. URLs get logged and bookmarked and such. You also have no logging without logins.
    – Neil Smithline
    Nov 23, 2015 at 1:22
  • Google Apps accounts are $10/m per pop. This is a call center environment, with a very frugal employer. That's not going to happen. I'd rather take the time and make a proper site with ASP.Net or something similar, but a google Web App is the best I can do given short notice.
    – Douglas Gaskell
    Nov 23, 2015 at 1:35

1 Answer 1

Reset to default
2

Your scheme is moderately secure provided the random value is long enough and random enough, however it has a number of flaws:

  • Passing your authentication token in the URL means it'll be in HTTP server logs, browser history, etc. Data in these places is not usually stored in an especially secure way.
  • You have no way to revoke access (eg. if an employee leaves or if your system is compromised somehow)
  • There's no time limit to the validity of the tokens

Ideally you'd have some kind of global method to authenticate all users (eg. everyone registers an account on your system), but if you have nothing other than email addresses to authenticate with then I'd suggest the following:

  1. The link emailed to the user is a link to an authentication page with the content/QA ID and user's email as parameters.
  2. The authentication page generates a hash/signature containing the content/QA ID, the user's email, an expiry timestamp (expiring in say 30 minutes) and a unique ID which can only be accepted once (ie. nonce), and emails a new link with the hash/signature to the user
  3. The user follows the second link in the new email containing the hash/signature and the parameters (expiry, content/QA ID, nonce and email) and the page checks the validity of the parameters before displaying the content.

Having to wait for an email containing a second link every time might be slightly annoying, but it has the following advantages over your scheme:

  • URLs in server logs / browser history won't be a security issue because they can only be used once thanks to the nonce.
  • When someone leaves the company their email can be invalidated, therefore their URLs won't be accepted any more
  • The expiry timestamp will ensure old unused links will be benign

I'd also recommend using JSON web tokens instead of rolling your own signature/hashing scheme.

Improve this answer
1
  • Thanks for the reply! In this case the token being stored in browser history or email is not as much of a worry since that is only accessible on site. The only reasonable way to get the tokens out of the contact center would be to write them down, and even then only the person to whom the QA pertains has the access token (ie. Only I have the access tokens for my QAs). I like the idea of adding the email address to the token, and invalidating the email once that person has left the company. I will definitely implement something to that effect. Sadly, afaik I cannot use JSON web tokens w/gscript
    – Douglas Gaskell
    Nov 23, 2015 at 1:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .