One of our clients has sent us a list of security requirements. One of them was that registration does not including setting a password - once complete, a temp password is sent to the user, and the user must change the temp password on the first login.

I think I have come across this flow as a user, but I can't figure out what is it good for. If it's to force the user to use a real email, the common practice is to send a validation link to email used, and make the account inactive until the link's url is accessed.

So, is there a real security benefit in assigning temporary passwords to newly registered users, or is it just some IT manager who tries to be clever?

  • 1
    Why don't you ask them?Actually have they also set some requirement on the temp password generation?
    – Jim
    Sep 11, 2011 at 8:24
  • @Jim, the requirements were distributed to all the software vendors who serve that client, and we are not obliged to fulfill them (there were some I won't even bother asking about, as they just don't make enough sense). We'd like to use the occasion, though, and improve our user management. I'm wondering if this is a feature generally worth having.
    – Eran
    Sep 11, 2011 at 9:53

2 Answers 2


The procedure you describe seems to be the conflation of two distinct procedures which apply to distinct contexts.

1. Registration for a targeted individual

There are some contexts in which the registration is for a specific individual, with a defined physical identity, and occurs in a process which does not allow the setting of a user-chosen password. An example is when you "register" someone who you met at some trade show, and who gave you his business card. You know his email address, but when registration takes place, the user is not there. In such a situation, you have to send him a way to initially log in to your system (with at least some level of authentication -- you do not want to create an account for everybody, just for that guy) so that he could complete the procedure by choosing his own password.

An initial password, sent by email, and which must be changed upon first usage (enforced by the application), is one way to cope with that context. Sending him a "unique registration link" which brings him to a page where he can choose his password is, from a security point of view, exactly the same thing.

This is a non-ideal situation, in that the initial credentials must travel unprotected. Forcing password change upon first usage is a mitigation measure: yes, an attacker could intercept the initial password / validation link, but then he would have to choose a password himself, and at least the intended user will notice the problem (by not receiving the email or not being able to log in).

2. Registration for "anybody"

Most deployed Web apps which use registration work in a different context. Consider a Web-based vendor of some goods (think Amazon). Here, you accept anybody as new user. You need to "register" users because you want users to be able to keep track of their commands, and they should not be able to see the commands of other people.

In such a context, the user is available during the initial registration: he initiated it, he is right behind his keyboard at that time, and he can type in his chosen password under the cover of HTTPS. The Web app can accept this kind of registration because it is not picky: by design, anybody is entitled to register.

You still need a "validation link" sent by email, but for a very distinct purpose: the validation link is used to make sure that the email address is genuine. An attacker intercepting that communication could fool you (i.e. register under an email address which he does not "own" -- although he can intercept emails sent to that address, so he really owns it, to some extent), but such an attacker would not attack the same thing than in the first context. In the first context, the attacker impersonates the user who is entitled to log in; in the second context, the attacker is entitled to log in anyway, but he succeeds in doing so while providing the email address of someone else.


Sending a one-time initial password through email is a good or bad thing, depending on what kind of registration you are running. For a classical Web-based account creation that anybody can do, this is bad. For registration of a specific individual, the enforcement of a password change from the initial password is good, because in that case you already had to sent it by email, which is a security hazard (you just had no choice, and you must mitigate risks).

  • We actually have two interfaces (desktop and web) which somewhat correspond to the two contexts you describe. What I had in mind in this question is the web environment, in which, as you say, there's really no need to send a temporary password instead of letting the user create one himself. Thanks for the elaborated answer!
    – Eran
    Sep 14, 2011 at 18:53

From security point of view, that practice is a bad one. First of all, the password is transmitted in plaintext in the email. Secondly, the password is "known" to the application.

From the development point of view, however, this flow makes it simpler to implement. You do not need a separate "activation" flow.

  • I agree with the different views (I'm a developer, btw). However, I'm not sure the implementation is simpler with temp passwords - the user is still required to type a new password on the first login instead of just follow a link. That's another web page, extra test upon login etc.
    – Eran
    Sep 11, 2011 at 7:55
  • 4
    And it is important in this scenario that the change password step cannot be skipped by clicking on a navigation link with an already active session. Sep 11, 2011 at 7:59
  • "That's another web page..." - Or a redirect to your change password page. You might also implement the same system if the user forgets their password and it needs to be reset? Or, if you need to force the password to be reset every N days?
    – MrWhite
    Sep 11, 2011 at 12:03
  • @w3d, yeah, there probably would be other uses for that mechanism, like renewing dated passwords. Anyway, I'm not that worried about the extra work (if any). Usability and security are the important factors here.
    – Eran
    Sep 14, 2011 at 18:57

You must log in to answer this question.

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