I did not want to start a discussion about SMS.
So you are saying:
In case of the first step being the
username and the
password, an attacker could easily try all combinations, and if he gets to the second step, he knows that he has found the password of the user.
In contrast to this, if the user has to enter
mobilenumber in the first step and if he is let through to the second dialog, he only knows the phone number of the user. And guessing the password in combination with the OTP would be too hard for him.
But then - why not simply enter only the username and an empty password in the first step. Or enter the username with a PIN like “+1 892 91283 3023” in the first step?
So the problem arises from the fact, that showing the second login window actually tells the attacker, that he has found the right password. So the user must not enter the password in the first dialog
But then he can only enter well-known things in the first dialog.
Well, here is something which you can do with privacyIDEA today, and which does not implicate the mentioned problem.
You could simply deactivate challenge response (internally: do not use transaction_ids):
- User enters Username and Password in the first dialog
- RADIUS request is sent with username and password
- privacyIDEA checks, that password is right and returns an authentication failure (with the transaction_id for challenge response). The password is right, the SMS with the OTP is sent anyways.
- The RADIUS server does not use the transaction_id, but simply returns an
Auth_Reject (No Auth_Challenge included!)
- The user sees the same login window again. Now he enters
password+OTP and is let in.