4
$\begingroup$

I have come across a two factor login mechanism using Time based OTP (TOTP). TOTP (6 digits) is shown to the user in an app.

There are two ways of logging in.

Method 1:

User inputs the username and password. Then approves the login notification received in the TOTP app. There is no need to enter the TOTP in this case.

username = username
password = password

Method 2:

User enters the concatenation of the password and TOTP from the app as the password. No notification is received in the app in this case.

username = username
password = password + TOTP (6 digit)

The username and password are sent over TLS.

On the server side, I am assuming they split the last 6 digits from the password value received and check if it matches the TOTP (and then match the rest of the string with the stored password).

Else, they hash the complete password and match it with the value stored in the database (assuming passwords are not stored in plain text). If it matches, a notification is sent to the user's device.

What can be the possible issues or crytographical weaknesses in this system?

$\endgroup$
2
  • $\begingroup$ If the TOTP matches, then hopefully, you also check the password, right? You haven't specified that in the question $\endgroup$
    – user93353
    Oct 8, 2021 at 8:38
  • $\begingroup$ I am not aware of what is happening on the server side. But yes, giving a correct TOTP and wrong password does show an error stating that the username or password is incorrect; so they must be checking the password. I'll add this in the question. $\endgroup$ Oct 8, 2021 at 8:40

2 Answers 2

0
$\begingroup$

I am assuming

My #1 rule when it comes to security, assume the worst or don't assume anything at all (though I will admit I still make assumptions)

What can be the possible issues or crytographical weaknesses in this system?

The password could very well be stored in plain text, you just don't know. The fact that they are using TOTP in the first place is a good sign, but proves nothing about the rest of their security.

Some companies are proud of their security implementations and will straight up tell you if you ask, they may even have white papers detailing their standards.

Are there other telling things the company has made public about their service security? Do they use snakeoil red flag words like "military grade encryption" or "unbreakable" ? What is their policy regarding password complexity? Is their website using TLS 1.3?

I would suggest asking, if they are evasive or confrontational, that is probably a bad sign.

$\endgroup$
4
  • $\begingroup$ They don't have any public claims about their security. And they are using TLS 1.2. It is not possible to ask them the other details. That is why I've put up this question to the community to evaluate if this practice of appending two parameters can have possible security issues. Are there any previous cases where this has caused any issues? $\endgroup$ Oct 11, 2021 at 9:59
  • $\begingroup$ @YashDhingra when the length of one of them is fixed it is probably not an issue, but when the lengths are variable there can be severe issues. The presence of a required delimiter can also lead to issues, fixed length with no delimiter is more reliably split without issue $\endgroup$ Oct 12, 2021 at 2:56
  • $\begingroup$ Yes, the length of the TOTP is fixed (6 digits). This would mean that if they are not storing the passwords in plain-text and using prepared statements to sanitise the input, there doesn't seem to be much of an issue in this approach? Also, would it be better in any way to have a separate input for the TOTP rather than appending it with the password? $\endgroup$ Oct 12, 2021 at 7:11
  • $\begingroup$ @YashDhingra just from a UI/UX standpoint it makes more sense to have the TOTP as a separate input, there are indeed numerous technical measures that can be used to prevent the concatenation from causing any kind of security problem $\endgroup$ Oct 20, 2021 at 16:13
0
$\begingroup$

There are plenty of mistakes that you could suppose that a black-box process can make. Focusing on the challenges of supporting these two authentication methods, the challenge is that the user never explicitly indicates which method they would like to use. The server is left to infer that decision, based on the input it receives. Specifically, it's not clear if the value of the password variable is the user's password alone, or the user's password appended with a TOTP.

You might try checking if the value ends in 6 digits, and if so split it there. You'll find that users with a password that ends in 6 digits can no longer log in normally. Which means that you probably end up with code that checks both the submitted password and the submitted password minus the last 6 digits (if it matches that pattern). This is extra work that the server has to do, especially if it's using a slow password hashing algorithm (as is best practice) - it makes some logins take twice as long as they need to. But once the server has done this work, it will have determined if either version of the password is valid, and proceed from there. So an attacker does get 2 password guesses for the price of 1, but that's not much of an advantage.

$\endgroup$

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.