Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

A web application I've been developing has a new use case that has me searching for something easier than username/password authentication.

Current users don't sign up for the service themselves because it's a b2b service being used by their companies, so for standard username/password authentication we send them their username and a single-use temporary password via email. They are required to change their password and accept terms of use on first login.

For this new use case, some subset of users will now only be entering data during a 90-day period that happens once a year. Most of the time this means they'll only be doing this for one day, maybe two, a year.

Because it will be easy for them to forget the password they set after logging in with the temp password I would like to try something like a unique URL that expires. The URL needs to be valid for 90-days (or at least until they've finished entering their data if we can figure out how to measure that).

Each year they get a new email with unique URL to start that 90-day period.

The security drawbacks here are the typical ones:

  • Unique URL shows up in bookmarks and browser history
  • Unique URL shows up in server logs
  • User might forward the email to another mailbox and the message is not transported securely.
  • Need to guard against SQL injection in URL

Normally unique URL schemes are valid for short periods like 24 hours, so I'm worried that a 90 day period is just too long.

As for risks: if an unauthorized person gains access there would be very little information leakage (and certainly nothing that is PII) but there is still some "loss of trust" concerns.

Is this secure enough? If not, are there any other authentication methods we might use here?

share|improve this question

1 Answer 1

up vote 7 down vote accepted

Two problems with this question:

Nobody can say for sure that X days is too long. If there's nothing at stake and none of this has any value, then X can be infinite and nobody will care.

If there's something at stake, or something of value, though, it depends, and that's where you should perform a risk and threat assessment.

You have a 90 day requirement over which a task may occur; your solution to enabling someone to perform that task is an unknown unique URL and no other protections.

A unique (but unknown except to the trusted party) URL is an example of security through obscurity.

The longer the lifetime, the more chance someone unauthorized will access the URL. The higher the payoff, the shorter that timeframe is likely to be and the larger the likelihood that an attacker will invest time, effort and money in breaking in (or getting someone to forward that URL to them).

Payoffs may include revenge for disgruntled employees/contractors; just because no dollar value is attached to something doesn't make it worthless to hack it (you mentioned reputational damage).

If trusting input is important, leakage of the secret (URL) could lead to erroneous, malicious or misleading information being entered.

So my $0.02 - if it's worth protecting, do a careful analysis on how trustable you expect your user population to be, or just stick with username and password authentication; use a unique URL for password recovery / mail account authentication.

share|improve this answer
    
As TristanK points it. It sounds like it would be fair easier just to implement the ability to quickly reset the user's password. You mention this application is used by an employee at a business, I would say its safe to assume, that access to the employees email account will be monitored. This means the need for additional verification outside of knowing the email, in order to get a "reset password" link that is valid for a short period of time, would be prevent abuse and allow people who cannot remember a password to reset their password. –  Ramhound Jan 31 '12 at 14:22

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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