Storing random initial (one-time) passwords in plain text

Question

I manage a vendor app that issues accounts (with passwords, of course) to end users. From what I can see, final user passwords are stored properly. My concern is the initial account generation and communication step. The first point of contact with end users often isn't over the web — it's just as likely to be by phone, mail, or other means — and so the app has many options for communicating the initial account credentials to end users. To facilitate this feature, the app stores the initial password in a database column in plain-text that can be used for generating letters, welcome packets, email, shown on screen for communicating over the phone, integrated with other software systems, etc.

There is a mitigating factor here. The end user must change this password before they can complete their first login. The changed password is not written back to the database in plain text, and is not stored in a recoverable format. The original password is only good for at most a few weeks before it is changed. Additionally, the end user can't do anything with a new account that couldn't be rolled back if needed. It may be possible to leak some personal information, but I believe a new account won't display any data yet that isn't considered directory information.

However, it still nags at me that this plain-text password exists at all, and hangs around even after it's replaced. Given the mitigating factors, is this still a big deal?

Answer 1

I would say, it depends.

If the Creation of this account is triggered by some external means, for example payment, or signing up for some other service, such as so if any unauthorized person access the new unused account on your site would cause a security breach, then it can be a security risk if the database leaks.

If however, the account Creation is directly triggered by the end user, and the account is plainly unuseable without setting a password, then a attacker could gain the same access by signing up himself, thus it would not create any security risk if a initial password leaked.

---

If you really dont want to store unencrypted passwords in database, I would suggest hooking up a network printer to your service. If the service reside on a web hotel, you could put up some sort of tunnel or Connection between your printer and web service, so the web service can print anything on your printer.

Depending on the security settings and security policies of your server host or web hotel, you can either have it that your web service Contacts your printer via ipp and prints password, or you could have that your print server "polls" the web site for any new accounts and prints them.

As soon as a user signs up so password should be distributed via snail mail, then the web service immediately send this to printer, and then stores the password encrypted in database. This means you can still batch process the snail mails, by putting them in envelopes. The papers with initial passwords and adresses and such just is there sitting in the printer output bin waiting for being processed, and can sit there for months.

A good thing with IPP is that its based on HTTP, so your can for example tunnel IPP in a SSL tunnel by using stunnel on the gateway or print server, and then on the client site, you simply encapsulate Everything in a HTTPS request instead of HTTP request.

This means the password will never be stored in cleartext anywhere on the server harddrive, it will only be available in cleartext on the paper, a paper that once sent away with snail mail, will no longer be available to you or any adversiary physically breaking into your location.

Answer 2

Where I have had to deal with something similar before, I have stored the encrypted password in the database and exported all of the plain text passwords to a csv file at the time they get generated. After this, 7zip the csv file with a strong password and store it somewhere safe. The csv file is still available to you in case you need to use it for mailshots etc, but the password is stored in the databse encrypted.

Answer 3

Ideally you wouldn't need to store it, after email generation you should be able to discard it. I wouldn't be too terribly concerned.

If the email is lost or deleted before account creation is finalized, you could just repeat the process. Gen a new one, send the email, discard it.