2

I want to implement a log in system:

  1. User simply provides his / her email to sign up / sign in.
  2. A random password is generated and sent to his / her email, with a valid period of, say, 30 minutes. Hash is stored in database that will be deleted 30 minutes later.
  3. He / she enters the password within 30 minutes; optionally, he or she can choose to be remembered for x days.
  4. He or she is logged in if the password is correct.
  5. The password is invalidated and hash deleted.

After googling, I found this: http://en.wikipedia.org/wiki/One-time_password

It seems all right, but no points concerning usability. My main concern is whether or not it would be annoying to the end users, because every time he or she needs to log in, he or she has to check their email inbox for the password. I'm not quite a mobile user but would this be painful on mobile devices?

What's your opinion on this? Any potential problems of this approach? Would it be annoying?

7
  • Can you state your reasons for using one time password over the common "static" alternative?
    – Assimiz
    May 21, 2015 at 13:05
  • 1
    Most pages already have such means of logging in, the "forgot password" function. Do you know how often I enter a password per day? I don't. I can type my most frequently used passwords blind in less than a second. It'll cost me some minutes to do it your way - more so if the email is stuck somewhere, or happens to go right to the spam folder.
    – Alexander
    May 21, 2015 at 13:45
  • 2
    @kavoir.com it is not the common reason to go for one time password (usually it is done due to extra security considerations). Yes, it would be annoying, if you ask me. Wouldn't you be annoyed by having to pick up a new key from the clerk every time you get into you house?
    – Assimiz
    May 21, 2015 at 13:54
  • 1
    I'd rather implement optional two factor auth. Preferably based on U2F and not simple one time passwords (HOTP/TOTP etc.). May 21, 2015 at 15:31
  • 1
    Note that this system doesn't really inherit the advantages of OTPs since you're simply delegating security to your users' email login, which may not be any more secure than a traditional password. Post this question on security.stackexchange.com to vet your security approach.
    – V Maharajh
    May 26, 2015 at 20:41

7 Answers 7

1

It's commonly used for online banking: http://en.wikipedia.org/wiki/Transaction_authentication_number. But then again, there is also a username and password required to get to the portal itself, since it's part two of a two-factor authentication.

That aside, I would like to see one-time-passwords being used more often, especiall for websites that are less security sensitive.

In my experience, users either

  • don't memorize passwords except for their most frequently used accounts which means they have to go through an often tedious "forgot passwort" process

  • pick simple passwords, which of course reduces data security

Even if well designed, many "forgot password" mechanics require you to come up with a new password (that matches the password rules), enter it twice and then go back to the login form and enter it again (if you haven't forgotten it already by then).

1
  • 1
    Banks use email based TANs? I've seen TAN lists, SMS TANs and hardware tokens, but never email. May 21, 2015 at 15:28
1

I'd say you are little ahead of times. I see two factor authentication being an industry norm when it comes to financial institutions, and big data hoarders like Google have started offering the pin based log in as well.

I liked the idea for the inherent security of it. So you get users on-board citing the security concerns, which would be perfectly valid ones. I still do not see use of it on sites like imgur or reddit where users are more casual and comparatively less stressed with credential management. It would be definitely annoying if every website starts doing that. Today many use lastpass, or chrome password manager. These would be obsolete, and you would be inviting user effort every time they log in. This is not going to go down well with them.

I said ahead of time because it is still not industry norm. Twitter is reportedly trying to get rid of passwords So are Microsoft and Yahoo. Even Google recently split their login screen for allowing disruptive modifications in future.

Having said that, I would tweak your proposal by taking email out of it. With email, for entering any system user will have to momentarily navigate away from it. She would go to a mailbox and we don't know if and when she will return back to the site quickly. Yes. I am talking about conversion rates, site retention etc.

Currently, Google has an authenticator app which allows a third party company like Amazon to add accounts and pair it with code generated using that. As you'll see more and more websites, applications opting for such tools, users will gradually be more inclined to trust the new ways.

Today, even if sell this to consumers of financial institutions citing security concerns, owing to the mental models of the users, you can not take out the traditional username-password combination anytime soon. Hence again, you are ahead of time.

1
  • The OP is not talking about two-factor. Just an annoying single factor. May 26, 2015 at 20:53
0

I think what you describe requires too much decision making from the user and will become cumbersome as time goes. The norm is to have a username and password,a and then have a one-time password as an optional supplementary means of security, with an option to remember a browser that the user successfully authenticates with the one-time password on, so as not to ask next time if he chooses to.

0

In your case if this one-time e-mail-pass is a must (and you agree on low level of security), you could send just a link (button style) with "Click here to sign in". There is no sens of action:

  1. copy pass from e-mail (no one will make an effort to remember it)
  2. paste it on your web/app

Such password and authorization system will be a poor experience on mobile.

In terms of security it is extremely low level and you should be aware of it. Anyone with an access to e-mail can break in with an ease. A one-time-password is used widely but:

  1. As a SMS message.
  2. As a push-message by app on mobile device.
  3. Generated random pass on mobile device and synchronized with web.
  4. As a single code from printed code list.

To use more human-centered passwords maybe try:

  1. Asking a common question from a list (Where were you born?)
  2. Clicking on some sequence of buttons or on image

I am very concerned about direction of security and data policy.

0

I like the one time password as an additional feature for when i am on mobile or forgot my password but saved it in password program on the computer for example. Then the link with a button sign me in would be great, especially on mobile. Slack has implemented this in a great way, have look at there solution.

0

One Time Password (OTP) is good option for quickly logging in the system and do the activity without going through the registration process. Its good for once in a while. For example, paying my mobile phone bill. Enter my number and send OTP on SMS. Login. Pay the bill. Next time, after a month, user can afford this cycle.

But imagine every time I am doing this to log in. It will be annoying, frustrating. There are better ways to handle passwords.

My solution is to get each user to select a very small number of truly random passwords, use the same passwords for many applications, and never write a password down. Admittedly, this is less secure than the hypothetical user who is able to memorize fifty different random passwords, but only a handful such people exist in the world.

Source

0

I have one-time pins in my app, and for mobile users we use a very small SMS code (4 numbers) in a message that is short enough so the user can see it without leaving the app, through the notification banner.

That way, he has to wait, but he knows/should know that the SMS will be there in the next 10 seconds and can straight up type the number.

It IS annoying to have to wait every time, but if it's for security reasons the user will understand and, for what it's worth, it's not THAT annoying :)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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