9:50 a.m.
Dear all,
We are in the process of implementing 2 factor authentication in our web
application.
We already have some code written [1], reviewed and which seems to be fine from a
code point of view, however there seems to be still some discussion as to the
approach we should take from a logic/design perspective.
I will here try to summarize the different approach possible with pros and cons.
/!\ summary might be a little long :)
1) Ask for password+2fa token
Login page:
___________________________________________________
| |
| Login: [____________________] |
| |
| Password + 2 fa: [____________________] |
| |
|___________________________________________________|
Mechanism:
Application send login and password + 2 fa to the server that allows or deny
the login.
+ This is the current approach we have on the systems
+ A single request sent to the server
+ Simple
+ Attackers have no way to know if someone activated 2 fa or not
- Confusing for user that do not have or do not know about 2 factor
authentication
- No possibility to know what is wrong (Missing 2fa, wrong password or clock
skew too large?)
2) Ask for password and 2fa
Login page:
___________________________________________________
| |
| Login: [____________________] |
| |
| Password: [____________________] |
| |
| 2 factor: [____________________] |
| |
|___________________________________________________|
Mechanism:
Application send login and password and 2 fa to the server that allows or deny
the login.
+ Still similar to the current approach we have (can be made to mimic 1))
+ Still only 1 request send to the server
- Still confusing for the user that do not know / do not have 2 fa
- Still no possibility to know if you set up 2 fa and forgot about it or
misstyped your password or the 2 fa system is broken (clock skew too big)
3) Ask for password, validate, then ask for 2 fa is set up
Login page:
___________________________________________________
| |
| Login: [____________________] |
| |
| Password: [____________________] |
| |
|___________________________________________________|
Then:
___________________________________________________
| |
| This account has 2fa activated: |
| |
| 2 factor: [____________________] |
| |
|___________________________________________________|
Mechanism:
Application send login and password to the server that validates them, then
asks for a 2 factor if set.
- At minimum 1 request send to the server, more if 2 fa enabled
+ More user friendly as only the person with 2 fa enabled will have the 2 fa
token requested
+ You are able to know if you misstyped your password (which is also a -, see
below).
+ Attackers can brute force password, after that they might (or not) be blocked
by the requirement of 2fa.
4) Ask for password, check if user has 2 fa, ask for token, then validate.
Login page: see 3.1
Mechanism:
Application sends login and password to the server that checks if the user has
enabled 2 fa, if not authenticate user w/ login and password. If 2 fa enabled,
request 2 fa token and authenticate user w/ login, password and 2 fa token.
- At minimum 1 request send to the server, more if 2 fa enabled
+ More user friendly as only the person with 2 fa enabled will have the 2 fa
token requested
+ You are able to know if you misstyped your password (which is also a -, see
below).
- Attackers are able to know if you have 2 fa set up or not, and thus can
target users that do not have it enabled.
5) Application knows if user has 2 fa enabled or not.
Login page:
___________________________________________________
| |
| Login: [____________________] |
|___________________________________________________|
Then:
___________________________________________________
| |
| |
| Password: [____________________] |
| |
| This account has 2fa activated: |
| |
| 2 factor: [____________________] |
| |
|___________________________________________________|
Mechanism:
The application has its own login/password to connect to FAS and retrieve the
information whether the user has 2 fa enabled or not.
+ User friendly
- Attacker directly knows if user has 2 fa enabled or not
- 2 requests sent to the server (always)
- Application has login/password to FAS
- You are not able to know why your login failed (unless we make the server say
so)
I think this summarize the different approach available.
There is a separate issue that we will need to decide upon as well as some
point, regarding the order in which we check a user is authenticated (wrt
session_id), but this is a separate issue for the moment.
So which way do we decide to go?
Cheers,
Pierre
12:01 p.m.
On Thu, Sep 05, 2013 at 04:50:04PM +0200, Pierre-Yves Chibon wrote:
3) Ask for password, validate, then ask for 2 fa is set up
Login page:
___________________________________________________
| |
| Login: [____________________] |
| |
| Password: [____________________] |
| |
|___________________________________________________|
Then:
___________________________________________________
| |
| This account has 2fa activated: |
| |
| 2 factor: [____________________] |
| |
|___________________________________________________|
The biggest thing here is that attackers can't know that you have
two-factor authentication set up until they get the password right. I
think this makes it the most secure -- one additional request, in the
grand scheme of things, is not worth getting rid of this security.
This is the same for a form that asks for password + token code, but a
simple password + token code field raises too many questions for someone
who is logging in to an application and has no idea what a token code
is.
For reference, GitHub, Google, Dropbox, and Stripe all use this method
for web logins to their website with 2-factor-enabled accounts. I think
it's quickly become the best practice, as well as the most-agreed upon
practice.
Attackers can still brute force passwords with this method but that
threat is mitigated with things like CAPTCHAs (hard) and locking users
out after, say, 25 attempts, which should be enough...
--
Ian Weller <ian(a)ianweller.org>
12:10 p.m.
On 09/05/2013 01:01 PM, Ian Weller wrote:
On Thu, Sep 05, 2013 at 04:50:04PM +0200, Pierre-Yves Chibon wrote:
> 3) Ask for password, validate, then ask for 2 fa is set up
+1, my first instinct was this method as well, and yes it is something
that a lot of other sites with 2fa seem to be doing (two other examples
to add to your list are digitalocean and amazon aws).
The extra security seems worth it.
-Ricky
1:03 p.m.
On Thu, Sep 5, 2013 at 7:01 PM, Ian Weller <ian(a)ianweller.org> wrote:
On Thu, Sep 05, 2013 at 04:50:04PM +0200, Pierre-Yves Chibon wrote:
> 3) Ask for password, validate, then ask for 2 fa is set up
>
> Login page:
>
> ___________________________________________________
> | |
> | Login: [____________________] |
> | |
> | Password: [____________________] |
> | |
> |___________________________________________________|
>
> Then:
>
> ___________________________________________________
> | |
> | This account has 2fa activated: |
> | |
> | 2 factor: [____________________] |
> | |
> |___________________________________________________|
The biggest thing here is that attackers can't know that you have
two-factor authentication set up until they get the password right. I
think this makes it the most secure -- one additional request, in the
grand scheme of things, is not worth getting rid of this security.
This is the same for a form that asks for password + token code, but a
simple password + token code field raises too many questions for someone
who is logging in to an application and has no idea what a token code
is.
For reference, GitHub, Google, Dropbox, and Stripe all use this method
for web logins to their website with 2-factor-enabled accounts. I think
it's quickly become the best practice, as well as the most-agreed upon
practice.
Attackers can still brute force passwords with this method but that
threat is mitigated with things like CAPTCHAs (hard) and locking users
out after, say, 25 attempts, which should be enough...
-
what Ian says
+1
-Xavier.t
1:04 p.m.
On Thu, 05 Sep 2013 13:10:56 -0400
Ricky Elrod <codeblock(a)elrod.me> wrote:
On 09/05/2013 01:01 PM, Ian Weller wrote:
> On Thu, Sep 05, 2013 at 04:50:04PM +0200, Pierre-Yves Chibon wrote:
>> 3) Ask for password, validate, then ask for 2 fa is set up
+1, my first instinct was this method as well, and yes it is something
that a lot of other sites with 2fa seem to be doing (two other
examples to add to your list are digitalocean and amazon aws).
The extra security seems worth it.
I guess this option is ok with me.
kevin
1:51 p.m.
On 05/09/13 19:04, Kevin Fenzi wrote:
On Thu, 05 Sep 2013 13:10:56 -0400 Ricky Elrod
<codeblock(a)elrod.me>
wrote:
> On 09/05/2013 01:01 PM, Ian Weller wrote:
>> On Thu, Sep 05, 2013 at 04:50:04PM +0200, Pierre-Yves Chibon
>> wrote:
>>> 3) Ask for password, validate, then ask for 2 fa is set up
>
> +1, my first instinct was this method as well, and yes it is
> something that a lot of other sites with 2fa seem to be doing
> (two other examples to add to your list are digitalocean and
> amazon aws).
>
> The extra security seems worth it.
I guess this option is ok with me.
kevin
_______________________________________________ infrastructure
mailing list infrastructure(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Quite frankly, it is about time we get this enabled.
Excellent plan, hope we end up with it soon.
Thanks for the hard work all!
Regards,
Tristan
--
Tristan Santore BSc MBCS
TS4523-RIPE
Network and Infrastructure Operations
InterNexusConnect
Mobile +44-78-55069812
Tristan.Santore(a)internexusconnect.net
Former Thawte Notary
(Please note: Thawte has closed its WoT programme down,
and I am therefore no longer able to accredit trust)
For Fedora related issues, please email me at:
TSantore(a)fedoraproject.org
1:57 p.m.
On Thu, Sep 05, 2013 at 12:01:35PM -0500, Ian Weller wrote:
This is the same for a form that asks for password + token code, but
a
simple password + token code field raises too many questions for someone
who is logging in to an application and has no idea what a token code
is.
IMHO it would be nice if the password field can be used to enter both
password and token code at once to make login less annoying for 2fa
users and therefore more likely that it is used.
Regards
Till
2:22 p.m.
On Thu, Sep 05, 2013 at 08:57:33PM +0200, Till Maas wrote:
On Thu, Sep 05, 2013 at 12:01:35PM -0500, Ian Weller wrote:
> This is the same for a form that asks for password + token code, but a
> simple password + token code field raises too many questions for someone
> who is logging in to an application and has no idea what a token code
> is.
IMHO it would be nice if the password field can be used to enter both
password and token code at once to make login less annoying for 2fa
users and therefore more likely that it is used.
At least on the backend that will need to be supported. There are cases
where we'll want to run applications that we don't write ourselves that only
have a single field for password. For those situations, the backend will
have to be able to handle parsing a single password field for a combined
password+2fa.
I don't know if that needs to be expressed on the frontend but if it's
useful we might as well.
-Toshio
2:25 p.m.
On 05/09/13 20:22, Toshio Kuratomi wrote:
On Thu, Sep 05, 2013 at 08:57:33PM +0200, Till Maas wrote:
> On Thu, Sep 05, 2013 at 12:01:35PM -0500, Ian Weller wrote:
>
>> This is the same for a form that asks for password + token
>> code, but a simple password + token code field raises too many
>> questions for someone who is logging in to an application and
>> has no idea what a token code is.
>
> IMHO it would be nice if the password field can be used to enter
> both password and token code at once to make login less annoying
> for 2fa users and therefore more likely that it is used.
>
At least on the backend that will need to be supported. There are
cases where we'll want to run applications that we don't write
ourselves that only have a single field for password. For those
situations, the backend will have to be able to handle parsing a
single password field for a combined password+2fa.
I don't know if that needs to be expressed on the frontend but if
it's useful we might as well.
-Toshio
_______________________________________________ infrastructure
mailing list infrastructure(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
I have another idea. Could we not do a password check, and if the
password is correct, provide the 2fa interface, if then a user does
not enter the 2fa, an email is send to the actual user informing of a
failed login attempt, with the date and time and maybe IP ?
Does this sound more secure to anyone else ?
Regards,
Tristan
--
Tristan Santore BSc MBCS
TS4523-RIPE
Network and Infrastructure Operations
InterNexusConnect
Mobile +44-78-55069812
Tristan.Santore(a)internexusconnect.net
Former Thawte Notary
(Please note: Thawte has closed its WoT programme down,
and I am therefore no longer able to accredit trust)
For Fedora related issues, please email me at:
TSantore(a)fedoraproject.org
2:36 p.m.
On Thu, Sep 05, 2013 at 08:25:30PM +0100, Tristan Santore wrote:
On 05/09/13 20:22, Toshio Kuratomi wrote:
> On Thu, Sep 05, 2013 at 08:57:33PM +0200, Till Maas wrote:
>> On Thu, Sep 05, 2013 at 12:01:35PM -0500, Ian Weller wrote:
>>
>>> This is the same for a form that asks for password + token
>>> code, but a simple password + token code field raises too many
>>> questions for someone who is logging in to an application and
>>> has no idea what a token code is.
>>
>> IMHO it would be nice if the password field can be used to enter
>> both password and token code at once to make login less annoying
>> for 2fa users and therefore more likely that it is used.
>>
> At least on the backend that will need to be supported. There are
> cases where we'll want to run applications that we don't write
> ourselves that only have a single field for password. For those
> situations, the backend will have to be able to handle parsing a
> single password field for a combined password+2fa.
>
> I don't know if that needs to be expressed on the frontend but if
> it's useful we might as well.
>
> -Toshio
>
>
>
> _______________________________________________ infrastructure
> mailing list infrastructure(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/infrastructure
>
I have another idea. Could we not do a password check, and if the
password is correct, provide the 2fa interface, if then a user does
not enter the 2fa, an email is send to the actual user informing of a
failed login attempt, with the date and time and maybe IP ?
Does this sound more secure to anyone else ?
By another idea -- you mean unrelated, correct? If so, I'd think we might
consider just sending email on any failed login attempt, password or 2fa.
Successful password and failed 2fa would certainly be something to highlight
more to the user, though --
"If you did not attempt this failed login, you should consider your Fedora
Account System Password Compromised. Please change it in the Account System
and any other systems that you might be using it (contrary to best
practices)"
-Toshio
2:58 p.m.
On Thu, 5 Sep 2013 12:36:25 -0700
Toshio Kuratomi <a.badger(a)gmail.com> wrote:
By another idea -- you mean unrelated, correct? If so, I'd think
we
might consider just sending email on any failed login attempt,
password or 2fa.
Successful password and failed 2fa would certainly be something to
highlight more to the user, though --
"If you did not attempt this failed login, you should consider your
Fedora Account System Password Compromised. Please change it in the
Account System and any other systems that you might be using it
(contrary to best practices)"
I'd prefer to avoid email on failed password unless we had some rate
limiting. Otherwise it's a way to allow anyone to DOS your email box.
Also, if we send email to users we should point them to a wiki page/faq
about what to do or who to contact. Otherwise they will get confused.
kevin
7:23 p.m.
在 2013-9-6 AM3:25，"Tristan Santore" <tristan.santore(a)internexusconnect.net
写道：
I have another idea. Could we not do a password check, and if the
password is correct, provide the 2fa interface, if then a user does
not enter the 2fa, an email is send to the actual user informing of a
failed login attempt, with the date and time and maybe IP ?
Does this sound more secure to anyone else ?
Wow... that would be great. This is the most serious case we should care
about.
IMHO We should pretend to be "normal" when we meet such case like mailman
subscribe, but I think we also should notify users when $(TIMES) times
wrong password entered. $(TIMES) can be set by users, after limited times
if wrong password comes again we should block the IP.
My blog use plugin with my modification:
If attacker has entered wrong password for 1 times(I set it to 1 because
this case is suitable for me), then if attacker tries to storm my account
for the third time, its IP will be blocked 10000 mins. So I won't receive
too many emails about failed login attempt, but I don't know if Fedora
Infra wants to support this way...
9:58 a.m.
On Fri, 6 Sep 2013 08:23:06 +0800
Christopher Meng <cickumqt(a)gmail.com> wrote:
Wow... that would be great. This is the most serious case we should
care about.
IMHO We should pretend to be "normal" when we meet such case like
mailman subscribe, but I think we also should notify users when
$(TIMES) times wrong password entered. $(TIMES) can be set by users,
after limited times if wrong password comes again we should block the
IP.
My blog use plugin with my modification:
If attacker has entered wrong password for 1 times(I set it to 1
because this case is suitable for me), then if attacker tries to
storm my account for the third time, its IP will be blocked 10000
mins. So I won't receive too many emails about failed login attempt,
but I don't know if Fedora Infra wants to support this way...
I dislike lockouts like this because someone can spoof your IP and
block you from logging in.
kevin
3877
days inactive
3878
days old
infrastructure@lists.fedoraproject.org
12 comments
9 participants
participants (9)
-
Christopher Meng -
Ian Weller -
Kevin Fenzi -
Pierre-Yves Chibon -
Ricky Elrod -
Till Maas -
Toshio Kuratomi -
Tristan Santore -
Xavier Lamien