I’ve looked into this very promising product as a replacement for some other products we have but wonder if the following will be able to do in the future. I’ve not found a way to get it to work as of right now but please correct me if I’m wrong.
Radius request get sent with username & phonenumber(NAS would think this i a password)
Privacyidea checks both username & phonenumber against AD/LDAP
If step 2 is ok a privacyidea sends out an SMS to the user with an OTP and a Radius challenge to the NAS
User enters ADpassword+OTP to the challenge
Privacyidea checks so that the ADpassword is correct and also of course that the OTP is correct
Yes, that is the whole point. Much of security today is according to me backwords. Today you present username+password on the web for anyone to brute force. Then when the attacker has got the right user+pass combo the only thing left is to get a hold of an SMS and they are in.
So in this case instead of presenting username & AD password directly on the web for anyone to brute force we present 2 fields with semi common known values.
e-mail is of course known by anyone but username should be kind of unknown, and also possible to change if needed while the e-mail will always be the same.
phone number is of course also semi known by anyone also but when combined with username it should be low risk of a webrobot guessing the correct combination, hence we don’t get SPAM OTP SMS to the user.
And finally, when the user get past the first login prompt and enters OTP+ADpassword it is a much higher probability we have the correct user on the other end.
If an attacker is able to “guess” my username, he will also be able to guess my phone number.
MY phone number can be guessed, because it is in the footer in all mailing lists.
Other peoples phone numbers might be guessed, because they have an interesting way of using their smartphone.
Maybe I am wrong, this is just my perception.
You also could use an OTP PIN, so that the attacker can not brute force or lock an AD password.
privacyIDEA is cabable of managing OTP pins per tokens. You can (somehow) configure, that PINs would not get locked.
What is your application you are protecting with privacyIDEA. If you are talking of RADIUS I guess it is a VPN?
To me it somehow sounds odd, that an SMS should be triggered by public information. At least public to all the users in the network. If I had a colleague I wanted to annoy, I would grab his phone number from AD (probably I would fetch it from the internal phone book!) and trigger thousands of SMS. This does not sound quite right to me.
(EDIT: We know that SMS sucks — point proven again.
Yes it could be for any service that must be accessible from internet, therefor it is also very important that it is brute force resistent.
I agree that SMS isn’t the best option for everything but it is also very easy to roll out to for an example temporary external users.
Annoying people with hidden SMS has been possible for very long so that is always a problem as long as you have a mobile phone. The important thing with the first factor (username&phone number) is not to authenticate but to avoid webrobots trying all kind of combinations. Combining username&phonenumber should be enough for that. And the second factor is actually where the user gives out the OTP+Password and does the authentication in one big step and not in several small ones which attackers love.
An extra PIN code for a user is of course another alternative but
a, the PIN is just as exposed to brute force as a password
b, the user has to remember one more thing. People seldom forget there mobile phones.
I totally agree that it exist more secure solutions than SMS that should be used where appropriate but think about it, this approach is really making the best out of an SMS solution.
User does not have to remember anything else than their normal password and also not bring any other device than their phone
It is brute force resistent. A problem with many applications is that as soon as you allow AD username+password directly from internet a brute force attack is possible in more than one way
It makes it more complicated for an attacker since authentication is done in one big step and not in several small ones
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 username and 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 username and password+OTP and is let in.
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?
An empty password will probably be found by webrobots and then initate unnessecary SMS to the end user. But using the phone number as PIN is working and that was the first thing i tried with privacyidea. I however encountered 2 problems but I’m sure some one or both of them can be solved.
1, autoenrollment of a token was not possible, but I didn’t manage to get the PIN code to dynamically be collected from the LDAP and saved to the user
2, if we change phone number in AD/LDAP then I guess the PIN would need to be manually updated in privacyidea. So a better approach would ofcourse be to always ask the AD/LDAP.
But even if the above gets solved. Maybe the other problem to authenticate a challenge as ADpassword+OTP is harder to solve out of the box?
I’m not sure I’m following the idea about disabling radius challenge. Do you mean that the radius NAS will probably show something like “you’ve entered wrong username/password” the first time but at the same time an SMS will be sent and the user can try to login again with ADpassword+OTP and then the next time it will work? If that’s the case it would of course be a work-around but a more appropriate user friendly scenario would of course be to present the user with a challenge login page.
Coming back to the question, what should be the “PIN” to trigger your challenge:
If you could specify a script or a module where you code the verification of the PIN, you would gain this flexibility. Such a script could simply verify the PIN part in the way you want it to be.
Thus you could choose between otppin=none, otppin=userstore, otppin=pin or otppin=script.
(If you are still evaluating or using privacyIDEA)
I feel like you are trying to over-engineer this. Whatever your authentication source is, it should have brute-force counter-measures configured for it. AD and PrivacyIDEA have these baked into them.
MFA essentially allows you to post username/passwords in public and still have a secure application. The only way to gain access at that point is A. gain access to the user’s authentication token or B. brute force the OTP. Brute forcing a 6 digit token, like Google Authenticator provides, is literally a 1 in a million shot. If you configure token lockout at 10 fails, the attacker has 30 seconds to make a 1/10 guess. The likelyhood is incredibly small.
Stepping back into the real world, username/password combos aren’t as easy as being publicly posted for all to see (though we know users reuse passwords and other sites are breached regularly). So MFA allows you to add a layer of security in the event that A. User gets phished (assume they will) or B. User reused a password from a breached site. If either A. or B. occur, your site is still secure. In addition, if someone attempts to brute force and a token lockout occurs, an administrator should have a mechanism configured to alert the user or an administrator of the token lockout. At this point, the user is notified and should be directed to change their password.
— point proven again.
but a more appropriate user friendly scenario would of course be to present the user with a challenge login page.