2

I’m looking for Term Or Some platform for managing Password Authentication with this way : Password construct from 2 Part , First one is static and you can make it and second Part Generate From TOTP System as an example :

In 13:00 Jinx password for login Is Abc627028 And in 13:01 Jinx Password for login Is Abc002839

As you can see First part is static and for jinx user always Abc and second Part is dynamic send to Jinx with expiration time

I don’t Need to chains , for example first authenticate user with A static password and then ( if static password correctly) send TOTP to it for Second Step Authentication. I don’t what’s that term , some things like Multi Factor Authentication just in One Step.

1
  • You can create two fields in the form, one for the static part (the password) and one for the dynamic part (the TOTP), and send everything in one step.
    – ThoriumBR
    Commented Mar 8, 2022 at 21:17

3 Answers 3

0

The typical way you do this is with two forms on the login page. You can simply allow the user to enter the password in one and then store the TOTP code in the other. Then, the user can send both at the same time when they submit the form.

Some systems do provide both items in the same field, either in web form, or over a connection like SSH, but this makes it hard to use password managers, which are a best practice and should be encouraged. Using a dedicated field for the TOTP code is much better from a user experience perspective and is simpler to handle on the server side as well.

I would also encourage you to support WebAuth if you're using a website, since this allows users to use secure and convenient methods for a second factor, like security keys (e.g., Yubikeys), Touch ID, Windows Hello, or their phone's unlock mechanism. WebAuthn, unlike TOTP, is also resistant to phishing.

2
  • Tanks for your guidance , but I saw this approach in an Enterprise Organization Used for Vpn password, they designed a application delivered TOTP and you have to append that at the end of your static section of chosen password , I was attracted to that , and now looking for some things like this , but in the end I accept and many tanks for all of your opinions
    – learner
    Commented Mar 8, 2022 at 23:29
  • Sure, I think it's a tool that some environments use, but I'd actually say it's an anti-pattern and should be avoided. It's better than not having 2FA, but it's much worse than using a regular 2FA solution.
    – bk2204
    Commented Mar 9, 2022 at 22:18
0

You could do as this, but this would violate the Principle of Least Astonishment:

The principle of least astonishment (POLA), aka principle of least surprise (alternatively a law or rule), applies to user interface and software design. It proposes that a component of a system should behave in a way that most users will expect it to behave. The behavior should not astonish or surprise users.

If your password system expects users to have a second factor, users will expect the a 2FA field somewhere to enter the 2FA token.

If you have only one field and the user have to concatenate the password and the token before entering the data on the field, most users will get confused when their password is denied (because they didn't read the field description and didn't entered the 2FA after the password). Combine this with a system to lock out users when they enter an incorrect password a few times and you lock out a lot of your userbase.

This will confuse password managers too. I don't know a password manager that have an easy way to input both the password and the token on the same field. You could alter an opensource password manager to do that, but don't expect your users to do the same.

0

As bk2204 explained it's a better design¹ to provide two fields. So, why is this "concatenate password with OTP" format used?

Most applications don't support an OTP factor. And if they do, it is a separate OTP per application. But the main password is checked centrally, almost always against a LDAP server (generally Active Directory) so all services share the same password.

If we change that authentication server to treat the password field as two parts (in your example, by the last six characters, other implementations use a separator between the parts), then all systems using that authentication backend automatically benefit from MFA. Remember that passwords should be opaque. The applications are oblivious to the change, as they are still just passing "a username" and "a password" to the backend for validation.

An implementation of this concept is the otp module of OpenLDAP: With this module, users would use their password, followed with the one-time password in the password prompt to authenticate.

¹ from a security point of view, it's irrelevant whether there is a dedicated OTP field or not. You could even pack username, password and OTP on a single field.

You must log in to answer this question.

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