72

I'm developing a web site where people will have accounts. However, unlike most web sites, user do not register, rather they are invited by the site admins. The site admins will create a new user profile, based on their email address, and then want the site to email them telling them that their profile is ready for use.

However, I'm not sure of the safest way to let people know of their password. In a normal registration, the user enters their password of choice, which is hashed and stored. All that remains is to send them a link to verify their email address.

In our case, they don't register, so don't supply a password. Whats the safest way to proceed?

This answer suggests sending them a link to a page where they can see their password, but I'm not sure if that has any benefits over sending them to a page where they can enter their own password. Actually, I think the latter suggestion is better, as if the password has already been set, the web page can inform them that the password has been set, and if this wasn't them, to contact the admins immediately.

What would be the best way to inform a new user of their password, security-wise?

  • 24
    BTW there is no difference in sending a one-time-Link or a one-time-initial-password by mail, whatever is easier to implement. Both will rely on email security which is weak but a common trust model. So unless you don’t have alternate contact information or a encryption key of the users you have to go with that. Make sure they can alert you if they find the one-time-thing not working (because someone else used it) – eckes Jun 24 at 9:41
  • Why have a password at all. Why not use passwordless logins using emailed time limited one time links. – Sentinel Jun 26 at 4:43
  • 1
    The safest method is personal contact. – RonJohn Jun 26 at 15:14
  • 1
    Do you want the actual safest way, or the safest way that’s reasonably practical and convenient? For example, if your CTO personally visits each user to tell them their password face-to-face, that’s very safe but very impractical. – Mike Scott Jun 26 at 15:52
  • 1
    @marstato well fist of all this would probably be much safer then having „password“ as password but I am talking about a initial password which has to be changed on first login. – eckes Jun 26 at 16:41
205

The best practice in this instance is to send them a link to a page where they can set their own password.

You should ensure that after they have used this link to register, that the link cannot be used for account takeover. One way of achieving this is including a time limited, single use token in the URL.

  • Comments are not for extended discussion; this conversation has been moved to chat. – Rory Alsop Jun 26 at 13:32
  • 6
    -1 This answer is rather terse. "The best practice is X" ... okay, but why?! This answer is quite useless in its current form. – Luc Jun 26 at 14:25
  • What benefit is there over a one-time link to a registration page as opposed to a temporary password that forces you to change it when you log in? – Captain Man Jun 26 at 15:11
  • 6
    The benefit (per comments on User3399's answer) appears to be UX: if you're going to provide a temp password to the user, you also should force the user to change it immediately. But then why include the extra step of giving them a temp password? Why not just give them a link to set their password? Plus the latter is simpler to code. @DavidWaters it might be worth editing your answer to indicate this (or whatever you consider the benefit to be, i.e. why it is best practice). – bob Jun 26 at 16:36
  • @bob Please read the discussion that was moved to chat, this came up already :). You don't have to give a temp password, one would ideally email a link which generates a permanent password after user interaction (to make sure it's not a link checker). But yes, either way, the answer should be edited to indicate the reasoning. – Luc Jun 27 at 7:11
53

You should just send the new created users a link where they can set their own password. But consider the following thoughts to prevent abuse, because mails are sent in plain text:

  • make sure the link can be used just once (so only if the user does not have a password yet)
  • maybe set a date until the password needs to be set, otherwise they need to request a new link
  • random link generation, so it will be (nearly) impossible to guess the link for an email
  • add another step of verification (e.g. require them to enter their email and / or birthday)
  • 10
    I kinda agree with the extra step of verification, but I wouldn't make it an email or birthday. Both of these are generally considered public information that can easily be found or generally is easily shared around on various social media platform. You ideally want something that can be verified automatically but not easily datamined, though I have no idea what that might be. – Nzall Jun 24 at 13:36
  • 1
    @Nzall depends on the website and need for security, but if a user enters their credit card their name could be validated that way. – Grant Garrison Jun 24 at 15:24
  • 12
    Don't use credit card validation; a lot of people have names which don't match the name on their credit card for a number of reasons (joint account, in the process of a name change, issues with localizing non-roman script, etc.) and not everyone even has a credit card. – fluffy Jun 24 at 20:51
  • 22
    @GrantGarrison Why on earth would one hand over the credit card information to any page unless it's to process a purchase? That screams phishing attempt. – Frank Hopkins Jun 25 at 0:25
  • 3
    Depending on the users email provider, you can also at least prevent intermediate snooping - e.g. if you connect to gmail on port 587 and verify their SSL certificate, you can be reasonably certain that only the end user will be able to read the email. – Wayne Werner Jun 25 at 4:30
7

From my experience, it's usually done in two ways.

One way has already been described by David Waters, so I won't talk about it.

The other way is to send them a one-time use password, wich they'll have to change in a certain timeframe (usually a 48h windows).

With this method, you need to make sure they receive a randomised password wich is secured enough not to be bruteforced, and is unique and cannot be used again.

Once the user connect using this password, the website should redirect them towards a page where they can choose a password of their choice.

  • If you send the new user a link with a long randomized token that can be opened only once, a time limit is not really necessary. I created such a system for a large hosting company I worked for a few years ago and it was integrated into their support system so a new password could be generated, the token generated and the email with the URL generated and sent at the press of a button. – P. Goetterup Jun 24 at 11:04
  • 13
    From an UX perspective, I believe this solution to be worse. If I'm going to be required to change the password after first login, what's the point? Just let me set a password directly, instead of having to copy-paste (or type) a temporary password and then setting a new one. (Whenever that is possible). – Marc.2377 Jun 24 at 17:31
  • @Marc.2377 If the system requires regular changes of passwords anyway, it's the same process as a regular password change after X amount of time, and in that case it's a procedure a user already knows. I'd prefer that slightly over some new process from a UX perspective and strongly from a technical perspective for being able to reuse much of the existing process/code. But if such a process is not present, I'd be with you. – Frank Hopkins Jun 25 at 0:28
  • 1
    @P.Goetterup The time limit prevents malicious access in cases the original user ignores the mail and "forgets" about it, but at some point an intruder gains access to his mail account where he find's the mail and can still use the reset-link. With a time limit this expansion of the intruder's access is not possible. Granted it might not be much of an issue, but in some cases it can be all the difference between a simple loss of some old communication of an ex-employee and a breach to the main customer database, financial management tool etc. pp. – Frank Hopkins Jun 25 at 0:31
  • @P.Goetterup so whether it's necessary really depends on the security requirements. That it wasn't in your case, doesn't imply it isn't in all other cases. Though, granted, the question from OP - and the fact that he needs to ask here - make it likely (hopefully^^), that OP's system has not that high a security requirement. – Frank Hopkins Jun 25 at 0:33
3

Ask your users to do a first time authentication through an OpenID or Oauth provider, such as Google, Microsoft, Amazon etc., to verify their identity. This avoids any security concerns of emailing a password to the user.

  • 7
    One might ask why should anyone even have a username/password at all if they're going to use OpenID or OAuth. – fluffy Jun 24 at 20:52
  • 4
    @fluffy and vice versa, if the user chooses using email/password to avoid any public SSO/OpenID solution, he'll laugh like a maniac when he completed some registration steps and then is asked to login via any such provider^^ – Frank Hopkins Jun 25 at 0:35
  • @fluffy there are many cases where providers had outages or gone away. Especially if you allow external providers you have to at least offer a recovery from that. But yes, it depends on the depth of your service offering if you want to stay away from account management or depend on others. – eckes Jun 25 at 8:10
2

So users have an account with an associated e-mail address, but have not set their password. That is the exact same situation as when they have set but forgotten their password.

So implement a "forgotten password" procedure that allows for a user to request a link via e-mail to set a new password. Then have your users use that procedure to set their password the first time they use their account. You can have their passwords set to a randomly generated string when creating their accounts.

This allows you to create their accounts at your own time, without having to generate a one-time-only or expiring URL then. If they never use their account, their password remains that randomly generated string, which should be secure enough against brute-forcing attempts.

1

From my point of view E-Mails is a common used communication channel. It's generally considered as secure which might be true if everyone will set things right up like using SSL/TLS connections for POP3/IMAP or SMTP. In reality not all people know what these techniques are good for and just move forward with no transport security and so the misconfigure their system. So how to overcome this problem?

I would say there will be a safer way to provide an account to your customer. Think about your phone. No need to set it up and it works. So there won't be the problem of misconfiguration. So let's think about it a bit. I know SMS Token and calls are also not that safe, but it's a bit harder to get a SMS from another telephone redirected to the hackers phone. So why not using the phone number to send them a one time password which they use on a setup page and finish their registration? I would say this will be more secure then using e-mails.

Anyway if you want to use E-Mails i would not set the password for the user and send it to them. And I got some reasons to think about why you shouldn't do it that way and let them set the password on their own:

  • If you send a password some users might think you store them unhashed and you can see it so they won't trust you, even if it's not true.
  • Some users aren't changing the password and leave it like the sent one.
  • If the customer leave the password the original one and someone has access to the others E-Mail account or the senders E-Mails, he got his password.

For that reasons I would just send a link where they can create a password on their own.

  • 16
    I, for one, am very reluctant to give my telephone number to some website. It's a piece of personally identifiable information which is a far too reliable personal identifier and very easy to abuse for harassment or scamming when it falls into the wrong hands. If your service requires me to give you my phone number, then I am not going to use it. – Philipp Jun 24 at 10:35
  • @Philipp Yea I'm also doing it like that but if I want a service from a company I need to provide it normally. I think the problem is that we don't know which service the company is providing. If It's a social media Plattform I won't give them my number, but what if it's a hosting service and they need to contact me some day? And as he stated that they need Admins to set everything up it cannot be a normal service. – CD Rohling Jun 24 at 10:39
  • 1
    I was working with several hosting companies and never did I talk to one over the phone. All communication with them is usually via email. The reason they are asking for a telephone number is because it's another piece of PII they can use to track you down if you don't pay your hosting bills. – Philipp Jun 24 at 10:46
  • 2
    @Philipp I understand your point of view but sometimes there is no other way. If you want a service you need to provide the number. Otherwise you can't get it from them. I think a normal customer will understand this and has no problem with this practice. Anayway, the question was how to deliver the password the safest way and that was my idea. If it's good or not he need to think about it for himself. But thank you for your input man! – CD Rohling Jun 24 at 10:50
  • 3
    I would concur that unless we know the particulars of the service, there is no reason to dismiss two factor authentication. Besides, being reluctant to submit phone information is a matter of trust more than information security as concerning this question – Gnudiff Jun 24 at 11:24
1

The most widely used method is to send the user a link to create their own password.

If however that is impractical (E.G. because you haven't developed this part of the site yet) and still want to invite the user sitting next to you by giving them their first password manually, use a One-Time Secret.

There are lots of services out there, but https://onetimesecret.com is easy to remember.

Don't forget to tell them to notify you if someone else has already read their secret (E.G. The FSB or the NSA has already accessed their account) ;-)

Please click here for the secret you need to access our invite-only service.

If you receive the following warning:

Unknown Secret

It either never existed or has already been viewed.

Please contact us immediately on +00800 IVEBEENHAD

  • Unfortunately, many antivirus programs will read emails - thereby invalidating one time view workflows. On the other hand a one time USE token to create a password is secure. If a government agency routinely breaks the law by reading random emails, unless they've completed the workflow for you, they won't know the password. – gburton Jun 26 at 10:43
  • @gburton read emails and GET the HTTP link inside them? Please ping me in chat to elaborate as I've never heard of that one. – Fabby Jun 26 at 14:14
  • 1
    I don;'t have time, but off the top of my head I know that Norton does this. IIRC its a relatively common feature of antivirus software. If you think about it, that makes sense, especially if they offer email phishing protection. I've had to jury rig software to work around this problem when 300 users for a client couldn't reset their passwords. – gburton Jun 26 at 15:03
  • I'm taking your word for it now... ;-) @gburton – Fabby Jun 26 at 18:54
0

Send a link to set their own password with a randomly-generated one-time token. What you're doing now violates a couple security principles:

1) Site admins should not know the users' passwords

2) Passwords should never be sent plaintext

Ensuring the token is randomly-generated will prevent an attacker from brute forcing possible tokens then setting the password themselves. Having users set their own password eliminates the need for a secure distribution channel. I would also recommend a time limit on the token, after which a new one must be generated. This will prevent the situation where users who do not set their password can have their token guessed and their account hijacked.

  • "This will prevent the situation where users who do not set their password can have their token guessed and their account hijacked." so use a long, long token. putting a time limit doesn't really add any security value IMO. – Ave Jun 26 at 9:04
  • A hard to guess token is hard to guess, but a time limit also means a compromised token can't be used. A really-long, hard to guess token that is compromised is still a security issue. I should've been more clean about the compromise scenario in my answer, though. – Steve Gazzo Jun 27 at 15:55
0

I would send this same email (from admin@InvitedTrading.com) to everyone (the only difference between emails is a long auto-generated account code # which cannot be brute-forced):

A new trading account #3298889119019881 is available for you.

To activate it, please:
  1) Respond to this email with the words "I accept with password suffix X"
  2) Then, log in to https://InvitedTrading.com using username=<your email> and password=<3298889119019881 + private details + X>
      <private details> is a string of first name, last name, birthdate, and social security number
      E.g., "3298889119019881JohnDoe06251984123456789f76djisuh" for John Doe, born June 25, 1984, with social security number 123456789, with X=f76djisuh
  You must then change your password and can change your username if desired

Or, do nothing and all will be deleted in 48 hours.

If you do not trust https://InvitedTrading.com or have any reason to doubt that they should already know your
private details above, please do nothing.
  • As someone who has to develop a gatekeeper for a community of people who are expected have a certain level of technical knowledge, I can assure you that the UX on this would confuse a lot of people who aren't great with computers or with English (and therefore would cause a lot of users to not register), would be seen as phishing. – Ave Jun 26 at 9:03
  • I agree, the procedure needs to be polished up and maybe standardized. Just covering all the possible checks for "one-factor plus personal-factor" authentication. – bobuhito Jun 26 at 16:42

protected by Rory Alsop Jun 26 at 13:31

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.