Yesterday, Patrick, Toshio, Xavier, Jeroen and I spent about 2 hours speaking about the way to do 2 factors authentication for our web application. I will be trying to summarize here what its output/conclusions.
Workflow: ========= * User provides username and password - application sends username/password to FAS - FAS sends back an ACK-INFO-RECEIVED - application asks for OTP * User is prompt a new form for OTP something like (please bare my ascii art)
--------------------------------------- | | | OTP: [ ] | | | | [Cancel] [I don't have an OTP] [Ok] | ---------------------------------------
The `I don't have an OTP` and the `Ok` buttons are both simple submit buttons, sending the value of the OTP field. - application sends the content of the OTP field to FAS (whether there is something or not in the field) - FAS checks - does username/password match the DB - does OTP belongs to user - is OTP valid - FAS return Yay/Nay * user is logged in or not
The key ideas are: ================== * the authentication server does not provide an answer when username and password are submitted. Otherwise, $attacker has a way to find out the weakest accounts and from there brute-force them * the username, password and OTP are not sent in the same request (otherwise, if $attacker intercept this request, $it has all the info at once)
We will need to have a way for FAS and fedoauth to ensure that they are talking to each other, using signed message via the isitdangerous library might be a way to do that (and we would probably want to do it over https).
That does mean that web-app as well as CLI will have to behave in a similar manner, with two requests sent to fedoauth to log the user in.
As far as I remember this was the outcome of the discussion. As consequence, the pull-request [1] that was opened to add support for OTP on the BaseClient of python-fedora has been closed. The plan is to wait for FAS3 to have full OTP support and integration between fedoauth and FAS. By that time, the BaseClient will no longer be in used, we are moving towards OpenID and Patrick has been mentionning SAML recently. So when FAS3 is released and gets its OTP support, we will adjust the BaseOpenIdClient or the one that we are using.
[1] https://github.com/fedora-infra/python-fedora/pull/45
This email is meant to make sure we are all on the same page about this topic and that we can refer back to it in the future when the time will come to look at OTP for web-app again.
Please correct or ask for information on anything while it's still fresh in our mind :)
Cheers, Pierre
On Thu, Aug 07, 2014 at 05:33:38PM +0200, Pierre-Yves Chibon wrote:
The key ideas are:
- the username, password and OTP are not sent in the same request (otherwise, if $attacker intercept this request, $it has all the info at once)
What kind of attacker is able to only intercept this one request, but cannot intercept the second request as well? This assumed threat seems to lead to more complexity which might allow for more errors without an obvious gain in security from what I can see.
Regards Till
On Thu, Aug 07, 2014 at 11:44:03PM +0200, Till Maas wrote:
On Thu, Aug 07, 2014 at 05:33:38PM +0200, Pierre-Yves Chibon wrote:
The key ideas are:
- the username, password and OTP are not sent in the same request (otherwise, if $attacker intercept this request, $it has all the info at once)
What kind of attacker is able to only intercept this one request, but cannot intercept the second request as well? This assumed threat seems to lead to more complexity which might allow for more errors without an obvious gain in security from what I can see.
So I just discussed this with Kanarip again. The idea is to decouple the username/password from the OTP so that if you have 10 requests at the same time, then it's harder for the MITM to correlate which OTP refers to which username/password sent before.
To do the two requests and still have the correlation on the server side which OTP belongs to which username/password, Kanarip had two propositions: - Keep the connection open and send the second requests - Provide to back from username/password a one time token that will be returned with the OTP
On the other side, Kanarip did say it's all a matter of compromise and we just need to make a tradeoff on what we want and which risk we're ready to take.
Pierre
On Sat, Aug 09, 2014 at 07:12:58PM +0200, Pierre-Yves Chibon wrote:
On Thu, Aug 07, 2014 at 11:44:03PM +0200, Till Maas wrote:
On Thu, Aug 07, 2014 at 05:33:38PM +0200, Pierre-Yves Chibon wrote:
The key ideas are:
- the username, password and OTP are not sent in the same request (otherwise, if $attacker intercept this request, $it has all the info at once)
What kind of attacker is able to only intercept this one request, but cannot intercept the second request as well? This assumed threat seems to lead to more complexity which might allow for more errors without an obvious gain in security from what I can see.
So I just discussed this with Kanarip again. The idea is to decouple the username/password from the OTP so that if you have 10 requests at the same time, then it's harder for the MITM to correlate which OTP refers to which username/password sent before.
To do the two requests and still have the correlation on the server side which OTP belongs to which username/password, Kanarip had two propositions:
- Keep the connection open and send the second requests
- Provide to back from username/password a one time token that will be returned with the OTP
On the other side, Kanarip did say it's all a matter of compromise and we just need to make a tradeoff on what we want and which risk we're ready to take.
Oh one more remark, he said that if we send username/password/otp in one single request, we should ban time-based OTP
Pierre
infrastructure@lists.fedoraproject.org