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.

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?

share|improve this question
1  
Why don't you ask them?Actually have they also set some requirement on the temp password generation? –  Jim Sep 11 '11 at 8:24
    
Seems valid question at least to me –  Jim Sep 11 '11 at 8:37
    
@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 '11 at 9:53
add comment

2 Answers

up vote 14 down vote accepted

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.

Summary

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).

share|improve this answer
    
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 '11 at 18:53
add comment

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.

share|improve this answer
    
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 '11 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. –  Hendrik Brummermann Sep 11 '11 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? –  w3d Sep 11 '11 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 '11 at 18:57
add comment

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.