I'm pretty much doing a similar thing on a site I'm working on: login.pl will generate a long string which is a combination of the time, user id, random numbers, and a checksum. This string is passed to successive scripts via a hidden field. This is probably as secure as the least secure method of authenication that you use (in my case, not very as I'm using non-SSL, password field form elements, but that's not an issue in my case).

Once you start playing with the various scripts, however, I would make sure that you save the data for each page in a temporary area somewhere, only passing along the autherization code between scripts as opposed to all those variables, as in the latter case, you might forget to pass all those variables back to the next script, and upgrading would be a pain in the butt. A database solution, if you already have one working, is fine, but if you don't, it's probably easier to simply write the data out to temporary files (maybe create a directory for each login try, write each page's data out by Data::Dump-ing the $cgi parameter). You'd then simply need one script at the end that is aware of how to encorporate all the data and do the final modifications, whether this means transferring data around in a DB, or rereading the temporary files and putting those into place. I would also make sure that any solution, you have a reaper cron job that uses timestamps to remove old entries from either temporary storage place so that they don't fill up by incompleted form fillings over time.

Also, given that you're going to have many form elements alike to navigate between pages, I'd suggest grabbing the Template Toolkit (see a recent question I put up on this) to standardize how each 'panel' script prints out the html to go to other scripts.

You could also use cookies, that is, once they've passed the login.pl state, require that a cookie be set and be present on further pages, and then make sure when you hit the confirm script that collects all data and puts it into place, you set the expiry of the cookie as to make it disappear when the browser next flushes them. Of course, this does require the use of cookies, which may or may not be how you want to approach the site. (the hidden field approach above, of course, does not require cookies and should work on all browsers).