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.

I have a Grails app I'm working on that allows users to fill out a fairly lengthy application form. One of the requirements I've been given is to NOT require users to log in or create any sort of account. When they start filling out the app, I store their app ID in the session so it can be remembered from page to page. After one hour, the session expires. If they didn't finish the app, I send them an e-mail thanking them for considering us.

What I need to do is give users the ability to pick up where they left off so they can finish the application...again, without an account, without a username/login combination.

One way I thought to do this was to create a unique ID (like adbce-13428-etace-etc...) that is stored in the DB and maps to their application ID. I would then send them a link in the email that says "If you'd like to continue filling out your applicant, click the following link: myapp.com/continue/{their_unique_id}". When they click that, it looks up the unique ID in the database, gets their application ID, and puts the information back in the session so they can finish the application.

My question is: Is this bad form? Is it bad design? Is it bad for security? Why?

share|improve this question
    
I don't see a problem with that, as long as you use a cryptographically-random UUID. –  Stephen Touset Apr 23 at 20:32
    
Yep, that is the plan. Java has a UUID class that will generate a random UUID, and I planned on using that as the unique ID. –  grantmcconnaughey Apr 23 at 20:39

2 Answers 2

You could leverage local storage, but then you also risk exposing it a multi-user or public computer, or usability fail if the user uses multiple computers.

In your email solution, you could add a special code/token/password in addition to your identifier. So you have the identifier (UUID) and then a secret. You do still have an exposure if the email is compromised, but if the UUID is compromised from logs, packet capture, etc. without the secret access cannot be granted through the designed channel. You could put the secret as another parameter in the URL, but that is slightly less secure since it will be exposed whereever the URL is logged since its in the GET

eg.

Hey, come on back to http://somesite.com?your_app=12345...... on the page enter the following code to continue XXXX

The application data and the secret should expire and be removed or unviewable from the user perspective after a period of time as well (secrets tend to become less secret over time).

share|improve this answer
    
I like this approach. A UUID + a secret string in an email should provide an appropriate level of security. Also, I agree that the UUID should expire. I was thinking that we could add something like "this link will expire in one week". –  grantmcconnaughey Apr 24 at 0:15

Whether it's bad for security depends on whether the information they're entering could be considered "sensitive".

Would it matter to the applicant if someone else could guess (however unlikely) their session id and get access to whatever data they've already entered? (Is confidentiality of the data important?)

Would it matter to the organization who is receiving the applicant data that part 1 could have been filled in by one person and part 2, or part 3, etc. could have been filled out by another person or persons? (Is integrity of the data important?)

If an attacker managed to figure out the process being used to achieve the "save and resume later" functionality and was able to harvest all of the data submitted, would it be bad for the organization's reputation? Would their reputation suffer?

If the answer to any of these questions is yes, then it might not be a good idea. As with most things in security, it's all about the data.

share|improve this answer
    
In this case, the data is definitely sensitive (SSN, etc.), and even bound by FERPA regulations. However, I don't think it will be possible for another user to guess their session ID, as the UUID library generates something like 2^122 possible values. The only way for an attacker to get the correct URL with the unique ID would be to hack our database...in which case, they would already be able to get at all of that sensitive data anyway. –  grantmcconnaughey Apr 23 at 21:32
    
There may be other ways that this information is leaked, SQL injection, some type of poorly protected log. You should look to multiple layers and other areas of course beyond just assuming it is a hard to guess value (if there is no fault in you generator) etc. –  Eric G Apr 23 at 22:13

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.