5

I have to built an order process for an energy provider. The order process is very big and the user needs 10-15 minutes to complete it with all the data. The last point is to set a password to access the client area. But I am not sure what is the right way to do this.

We have 3 options to handle the problem:

  1. The user can set a password themselves at the end of the ordering process. The problem with this option is, that we also have a lot of clients with non-technical background. I think many people don’t know what they need this password for and I want to reduce the cognitive load.
  2. The user gets an e-mail after completing the process with the password in it. The advantage is, that they we can tell more things about the client area in the email to make it easier to understand what they need the client area for. And they can look in the email too see what the password is when they forgot it.
  3. Or we send an email after users complete the process with a one-time-link to set the password.

Note: The option to change the password is always given via the client area. Of course.

What is the best way to handle it in your mind?!

|improve this question
  • 3
    NOT #2. Email clients are not secure so they can easily be intercepted or read when the user doesn't delete the email and doesn't change the password. – DasBeasto May 25 '16 at 12:36
  • 3
    10-15 minutes to set up an account? Fck that. – colmcq May 25 '16 at 12:53
  • 1
    Not #2. Let the user pick their own password. – Ken Mohnkern May 25 '16 at 13:06
  • Agreeing with everyone else that #2 is very much not the design. Sketch up one of your workflows and do a user study. They're awesome for telling you whether creating a password after they've already spent 15m entering information is too much of a cognitive load. – nadyne May 25 '16 at 16:35
  • 1
    @DasBeasto, Ken, I totally agree with you that #2 is not secure but I see that most people answering here neglect the fact that people very infrequently login to energy provider websites, and will most certainly have forgotten which password (heck, which email too) they used. This is a typical situation where users need to have this data in a format that is convenient for storage, e.g. a letter. – Steve Dodier-Lazaro May 26 '16 at 10:59
5

The best way is to let the user set a password. Why?

  1. Most people know why all accounts are safeguarded with passwords, be it people with good technical backgrounds, or none at all. They have ATM pins, bank passwords and even employment account passwords. So they will not get confused with the request for a password and why it is needed.

  2. The user should always feel like they have complete control of their accounts. For this, a client will trust a website/ application that gives them the freedom to choose their own password, rather than being assigned with a password by the server.

  3. The users will tend to remember the password they chose, rather than the ones assigned to them. If you send a password via an E-mail, and say, they are in a position where they cannot access their E-mail accounts and they have forgotten their password, they will be annoyed. You could argue that they can click 'Forgot Password'. But, can you imagine it this happens frequently? It is really unfavorable.

  4. Safety concerns. E-mail accounts are never 100% safe. Given these accounts could hold important data, security is something we cannot over-look. Having the users select their own passwords is always safer than providing them with a password, via their E-mail accounts.

  5. Non-technical users may not be familiar with one-time passwords and single sign-on methods. Many users are thoroughly confused how to work with confirmation codes and OTPs sent to their E-mails/ Mobiles. This gives rise to an unwanted complication.

They reasons can go on and on. But in my personal opinion, you should give the power to the client and let them choose their own password.

|improve this answer
  • 1
    +1 for point 4. Never, ever, really never send a password via email. – Hennes May 25 '16 at 18:06
  • 2
    heh I find it amusing that people would think that e-mail accounts are never secure. the vast majority of sites I use allow for password reset via e-mail, so malicious access to e-mail account == account access. The only sites that tends not to be true for are those that have set-up 2FA or perhaps banks. – Rory McCune May 26 '16 at 13:33
5

I think the third option is the best way to handle it if you want to split the process into two steps. You can display a message after the first step to notify the user he needs to update soon the profile and set the password.

Sending a password in email isn't secure and the user will have to change it immediately after logging in this case too. You can read about this here https://security.stackexchange.com/questions/17979/is-sending-password-to-user-email-secure

With this solution (the third option), the user can sign up and then can read more about the information required to complete the registration in the profile section or in the email.

|improve this answer
1

You need to take into consideration:

  • how often users login and how likely they are to remember any credential
  • how sensitive the information is (both financially and legally)
  • whether federated authentication is an option or you need a specific form of id verification (e.g. legal proof of address)

I suppose you are authenticating households rather than individuals, therefore you might have legal requirements to not rely on e.g. Google or Facebook accounts. However, you could still set a password and, on top of that, allow customers to link their Google/Facebook identities to manage their account. It might depend on legal constraints whether or not you are able to do that, but it would greatly decrease the stress on users to remember their password.

One specificity of your business is that you probably provide users with a paper trail of their registration, at some point. It's very common for utility companies to provide identification information on bills and letters because it helps customers re-find this information. As it is rarely needed, it is quickly forgotten (and sometimes you've changed devices by the time you need to access such an account to e.g. close it or change addresses, so password managers might not help).

Therefore I strongly recommend you go for a solution that leaves customers with a paper trail. It is unlikely that a thief would break into their house specifically to mess with their energy information (since this information would primarily be valuable to... schedule a house robbing in the first place!). Mailing passwords seems a better option for me than emailing them (security issues; not all email is encrypted) or letting people choose them because it solves the frequency problem.

Letting customers choose them is acceptable only if logging into the account cannot cause financial damage or facilitate robberies (e.g. if you provide the ability to view logs of a smart energy reader, these show when people are usually not at home). This is for security reasons. Many users will choose crap passwords, and they'll be even more justified in doing so that they need a simple and highly memorable password for infrequent logins. Still, you can do like Twitter and ban the few thousand most common passwords (on top of ensuring that you use expensive hashing functions).

|improve this answer
  • Generating passwords is inherently flawed from a security point of view. Anyone gaining access to the algorithm you use to generate them can then go away and generate all possible passwords along with their hashes. This is a REALLY bad idea. – Andrew Martin May 26 '16 at 11:33
  • 1
    @AndrewMartin sorry, you're completely wrong and your downvote was misplaced, I'm afraid. On any secret-based auth scheme (passwords, swipe grids, PIN grids, passfaces...) it's been shown that users pick more predictable patterns than algorithms, therefore simplifying brute-force attacks. You're confusing sequential PRNGs based on a seed. Any password generator that uses its OS's sources of entropy is good enough for the job since every run is independent from the others. There is no security risk involved and this is standard practice for secret generation (e.g. RSA key generation). – Steve Dodier-Lazaro May 26 '16 at 13:09
  • 1
    FYI: security.stackexchange.com/questions/71187/… – Steve Dodier-Lazaro May 26 '16 at 13:23
  • 1
    The presence of an additional passphrase is inconsequential to the concept of there being reliable sources of entropy on computers. Algorithms like Diffie-Hellman certainly do not rely on users manually providing random data. – Steve Dodier-Lazaro May 26 '16 at 13:24
  • 1
    (feel free to come have a chat on the DMZ if any further clarification is needed) – Steve Dodier-Lazaro May 26 '16 at 13:31
-1

Good arguments above, but I guess to faster the process and since they are not much into the technology or using the machines, generate password with medium length A-Z, 0-9 without special characters and display it for them upon completion, as well as send an email with the generated password and give them link to change the password if needed.

|improve this answer
  • Never, ever send passwords by email! – Andrew Martin May 26 '16 at 8:58
-1

Wow! It sounds like you're planning to store the password for direct checking - this is such a bad idea I don't know where to start! - No secure system should store users passwords.

Most modern secured system do not know what your password is: When you enter a password, the system uses a one-way mathematical operation to arrive at a new string. This new string is what it checks against what it has in its database. Because the mathematical operation only works in one direction you password cannot be discovered by looking at the resulting string - This is known as Hashing. This guy explains it really well. And there's more about Hashing here too.

As a result, the only possible answer here is to let user set their own password - any other option is simply not secure.

|improve this answer
  • 1
    You can send it to clients and then only keep the hash, you know. There are contexts where generated passwords are better than chosen ones. – Steve Dodier-Lazaro May 26 '16 at 10:49
  • @SteveDL NO! Never send passwords! Ever! If you're worried about how your users are creating password then give them validation targets to hit ("must be more than 8 characters and contain numbers, letters, and punctuation symbols"). If you use systems generated passwords then they will follow a pattern and can be reverse engineered or, even worse, what happens if a hacker gets access to the algorithm you use to generate them? - They produce rainbow tables, published details of every possible password your system can generate. Very bad idea. – Andrew Martin May 26 '16 at 11:30
  • 1
    Sorry, there is literally no such thing at the moment as a decent password strength meter. These things are misleading at best and are certainly not the best practice to avoid weak passwords (algorithms such as Telepathwords, or distance metrics to ban-lists of common passwords, are the best method available at the moment). See my other comment for why generated secrets are not an issue at all. The only question is whether you prefer a weak and reused password over the risk of a one-time secret transmission. If using postal mail, the channel is very hard to opportunistically attack at scale. – Steve Dodier-Lazaro May 26 '16 at 13:12
  • 1
    Also, rainbow tables are not what you think they are. They do not produce lists of passwords that a generator can produce (notwithstanding the fact that said generator would generate among a set of possible passwords of much, much higher entropy than user chosen passwords). They map hashes to cleartexts, and if using a proper KDF with unique salts per hash, rainbow tables are rendered moot. – Steve Dodier-Lazaro May 26 '16 at 13:14
  • 1
    Andrew - feel free to visit Security Stack Exchange - you are currently very misguided on this. Come and speak to folks who know how system generated passwords can be much more secure, people who run and use rainbow tables correctly, and a general community who lives and breathes this stuff :-) – Rory Alsop May 26 '16 at 13:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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