Multi Factor Auth for viewer login
Brad Kittenbrink
Hello opensource-dev,
I want to give everyone more details about the MFA (Multi-Factor Authentication) login changes that Monty mentioned were deployed recently. We are beginning to add MFA protection to the viewer by integrating the existing web MFA authentication methods (Introducing Multi-Factor Authentication for your Second Life Account!) to the viewer login process.
We can now discuss what is needed to add support for it to various viewers.
The idea is that viewers which are MFA capable will add 2 new parameters (token & mfa_hash) to their login requests. When a login attempt needs a token, the failed login response will have its reason field set to mfa_challenge, and the viewer should handle this by prompting the user for an authenticator token and retrying the login attempt with that token attached. The login server will validate that token and if that succeeds, will allow the login and return an mfa_hash value that will be valid for 30 days.
I've posted the full protocol details here: https://wiki.secondlife.com/wiki/User:Brad_Linden/Login_MFA
The login server is now enforcing MFA only on MFA capable viewers according to the users preferences at https://accounts.secondlife.com/mfa/status. Viewers that are not MFA capable will not be blocked from logging in yet. We have planned a grace period for non-MFA-capable viewers to allow for time developing and testing these features as needed. When the grace period ends later this year, then users' MFA preferences will begin being enforced on all viewers attempting to log in.
Please let me know if anything is unclear or you have questions.
Thanks,
Brad Linden
--
Henri Beauchamp
> We can now discuss what is needed to add support for it to various viewers.
>
> The idea is that viewers which are MFA capable will add 2 new parameters
> (token & mfa_hash) to their login requests. When a login attempt needs a
> token, the failed login response will have its reason field set to
> mfa_challenge, and the viewer should handle this by prompting the user for
> an authenticator token and retrying the login attempt with that token
> attached. The login server will validate that token and if that succeeds,
> will allow the login and return an mfa_hash value that will be valid for 30
> days.
>
> I've posted the full protocol details here:
> https://wiki.secondlife.com/wiki/User:Brad_Linden/Login_MFA
released on 2022-02-12).
For now, the viewer got MFA disabled by default (via an "UseMFAinSL" debug
setting), but can be enabled by the user; that setting will also get auto-
enabled when the login server will refuse non-MFA capable viewers
("UseMFAinSL" is automatically set to TRUE should a "mfa_challenge" login
failure response be received), meaning the transition will be transparent
to users.
HOWEVER: I could not test this code at all, by lack of a testing ground
(and a smartphone to test it with a SL account)... Which brings me to:
> Please let me know if anything is unclear or you have questions.
at least on Aditi, for testing purpose) ?
Regards,
Henri.
Brad Kittenbrink
Question: when will (plain) email MFA be made available (and if anything,
at least on Aditi, for testing purpose) ?
Henri Beauchamp
> 1) Aditi is unfortunately not a very effective testing environment for this
> due to the way that web MFA works. It is linked to email verification
> which is not functional on aditi. This is one of the reasons that MFA is
> so far only being enforced for viewers that are MFA capable, to allow for
> testing development viewers against the agni login servers without
> interfering with any other viewer logins.
- What about old clients that are not maintained any more ?... Why would
they be bared from SL login after the grace period *as long as the user
did not enable MFA on their account* ?
- How to bisect regression bugs after the grace period is over, when the
said regression was introduced in an old version of a given client/viewer
that did not have MFA enabled ? This is a very concrete problem for me
since I already had to test very old versions of my viewer on today's grid
to be able to find in which release some bugs got introduced.
> 2) We are not currently working on implementing additional authenticator
> methods such as email MFA, but we are aware that there is a lot of interest
> in them. When we do begin work on other methods, email will likely be near
> the top of the priority list.
MFA. I.e. SL's website simply sends the plain text token to the resident's
verified email: you do have two factors authentication (viewer or website
on one side, and verified email on the other): problem solved and no need
for fancy third party application, smartphones and whatnot !
> 3) If anyone doesn't want to use a smartphone app for testing, I recommend
> using PyOTP (https://pyauth.github.io/pyotp/#working-example) which works
> very nicely with 2 lines of code. If you do so, I recommend storing your
> secret keys only in a secure store such as your operating system's keychain
> or the equivalent.
account ? Any recipe, please ?
On the page you link to, they still mention the use of smartphones, Google
authenticator app, barcodes, and state that "OTPs involve a shared secret,
stored both on the phone and the server", all things I cannot deal with
without a smartphone... O.O
Henri.
Brad Kittenbrink
- What about old clients that are not maintained any more ?... Why would
they be bared from SL login after the grace period *as long as the user
did not enable MFA on their account* ?
- How to bisect regression bugs after the grace period is over, when the
said regression was introduced in an old version of a given client/viewer
that did not have MFA enabled ?
...
Err... How am I supposed to use this thing to log into SL with an MFA-enabled
account ? Any recipe, please ?
Henri Beauchamp
> My apologies for not making this clear. No clients will be barred from
> logging in. They will simply fail to log in mfa-enabled accounts after the
> grace period ends.
> If you want to make an effective case for why future feature work
> should be prioritized, I think Jira is the right venue to do that.
every session, even after you ticked the "Remember login" check box for
the 1000th time...
Then I might use the JIRA again, like I did in the (distant) past, before
it got broken... :-/
Oh, also, please allow TPV developers at least *read* access on all JIRA
issues (but security-related ones, of course): it is *extremely* annoying
to see references to such issues in LL's git repo commits and not be able
to know what they actually all about ! :-(
> The 3 lines of code found at that link are the recipe. By my reading of
> that page, the mentions of smartphone apps are only there to support your
> understanding of how to use PyOTP to mimic their functionality. It is not
> required to run them to follow that recipe but those who wish can compare
> the results as described.
>
> The secret key you need can be found by starting the process of enabling
> mfa on your account on secondlife.com
> enabling MFA on your account you will need to confirm by entering 2
> subsequent codes generated by the .now() method into the web page. I
> recommend you either save that secret key in some secure storage method, or
> use it to disable MFA on your account after you finish testing to avoid
> getting locked out of your account and needing to go through a recovery
> process.
confusion and cluelessness... Here is the full, detailed recipe (some new
material for the MFA Wiki page ?):
1.- Create a test SL avatar (I created "TestMFA", so that name is now
taken :-P).
2.- Verify the email for that new avatar.
3.- Download the 'pyotp' Python module: 'pip3 install pyotp' or maybe
'pip install pyotp', depending on your Linux distro.
4.- Launch Python 3 ('python3' or perhaps just 'python') in a terminal,
then type:
import pyotp
5.- With your web browser logged in the test avatar account on SL website,
browse to https://accounts.secondlife.com/mfa/status and enable MFA
there. You are presented with a QR-code (doh !), but thankfully the
secret key you need is given as a 16 characters text below. Use it
to initialize pyotp by typing in the python terminal:
t = pyotp.TOTP('THATSECRETKEY123')
6.- Do as Brad said: continue to the verification step on the SL web site
and after arriving on the confirmation form, type in the python
terminal:
t.now()
which prints a six digits number. Enter that number (e.g. 012345 in
the first input box on the website, then go back to the python
terminal and type:
t.verify('012345')
If it replies "True", you need to wait a bit: type the Up key and
ENTER again to retry until it says "False", at which point you type
't.now()' again, and use the new six digits number it gives you for
the second input box in the SL web site, at which point you can
validate the form and should be all set.
7.- Log in with your MFA-enabled viewer and your test avatar: it will
complain that it needs a MFA token. Go to the python terminal and type
once more 't.now()' to get a new token for the viewer login.
My observations:
- I really needed a test (thank you Brad !), because I found two bugs (a
crash bug because I assumed that the MFA hash was a MD5 sum and used a
buffer that was too small to encrypt it, and a MFA hash bad retention
bug that caused it to get forgotten after the second successful login,
because I assumed that the "mfa_token" reply was always returned by the
login server on successful MFA login while it is only returned when you
pass a non-empty "token" login parameter), and an annoyance (double
notification, because I added a notification on MFA login failure while
the SL login server already sends an equivalent error message that also
ends up in an alert box).
The next release of the Cool VL Viewer (due on next Saturday) will have
everything fixed and working fine.
- The MFA enabling process on SL site is extremely weak: while you need
a verified email to be able to go to the MFA enabling page, you do not
have to confirm (via a validation link) the MFA enabling via that verified
email; you are only notified via email that MFA was enabled successfully
and that if it was not your action, you need to contact support: how you
do this after some pirate stole your account and enabled MFA on it, also
making you unable to prove you are the account actual owner is yet not
explained in that email... ROFLOL !
- The chosen MFA protocol itself is weak: why relying on an external and
offline application (basically a fancy hash generator with the "secret"
as the -permanent, never renewed- seed and the current time as the
variable) and time-based token, when you have verified email that is a
much stronger way to ensure that the person login in is indeed the legit
account owner ???
Not implementing email-based MFA in the *first place* is totally beyond
me !
Regards,
Henri.
Argent Stonecutter
> - The chosen MFA protocol itself is weak: why relying on an external and
> offline application (basically a fancy hash generator with the "secret"
> as the -permanent, never renewed- seed and the current time as the
> variable) and time-based token, when you have verified email that is a
> much stronger way to ensure that the person login in is indeed the legit
> account owner ???
Personally I would rather LL supported both kinds.
Email based challenges are way down the list alongside SMS and Apples "you have to have an iPhone" scheme (which seems to be a proprietary challenge-response scheme that only works on iOS devices).
Henri Beauchamp
> Email based challenges are way down the list
In the case of a *verified* email, this is by far a better MFA method
than relying on that "TOTP protocol" which basically anyone can run on
any device, connection-less (i.e. without any active connection with
the domain you are identifying with), and which does not guarantee the
least that the person running it is a legit person (it only merely
proves that they have the "shared secret" in their possession, which
they could just as well have stolen together with your password)...
But I personally do not really care, since I won't use MFA myself
anyway; I rely on strong, pseudo-random generated passwords and disk
partitions encryption to store their hashes: in over 4 decades of
computing, I never had a single of my accounts/passwords cracked or
stolen.
Henri.
Tonya Souther
--
Archives of earlier incarnations of this list are at https://list-archives.secondlife.com
---
You received this message because you are subscribed to the Google Groups "opensource-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opensource-de...@lists.secondlife.com.
To view this discussion on the web visit https://groups.google.com/a/lists.secondlife.com/d/msgid/opensource-dev/7ADA57FD-6F47-46FD-BA71-D4548FBD0FB6%40gmail.com.
Coyot Linden (Glenn Glazer)
>
> I would have thought Apple's protocol, alongside Google's "tap yes on
> your Android phone", would be pretty good, though. SMS is right out,
> and so is email: someone who is going to hijack your SL account is
> going to hijack your email too.
email and SMS because they have baked in time sensitivity: if you don't
tap or enter the pad number in time, it expires and drastically limits
the amount of time that Mallory has to work with. Email and SMS do not
have this by default and, as you say Tonya, are open to external attacks
that can take arbitrary amounts of time to achieve.
Best,
coyot
Henri Beauchamp
With the prerequisite that:
1.- SL website won't allow to change your verified email address without
confirming that change via a link sent to the current verified email
account (not sure if it is already the case or not: I did not try).
2.- SL website does not allow enabling MFA without the same type of
verification (which is not currently the case, sadly).
Then someone stealing your SL account password cannot:
a.- Change the associated email.
b.- Enable or change MFA on the existing account even without a need to
change that email.
Point 'a' and 'b' also ensure that email-based MFA cannot be high-jacked
when already enabled before your password got stolen.
As for the "time sensitivity" of the TOTP method chosen by LL, it is a
*joke* since as long as you got the "shared secret" (*) they can generate
new tokens every second if they so wish, using the three-liners code
in PyOTP...
Henri.
(*) which someone able to steal your email will likely also have: all
they have to do is to steal your user_settings/ directory contents
and the "unique Id" of your computer so to reuse the "secure"
database with a (slightly) hacked viewer on their own computer.
fuer...@gmx.net
Tonya Souther wrote:
>I'd be surprised if the whole architecture wasn't pluggable, myself, and once the basic setup is done and proven, other kinds of MFA can be added easily enough. Me, I use both Yubikey and TOTP (via LastPass Authenticator, so I don't lose the keys when I switch phones).
>I would have thought Apple's protocol, alongside Google's "tap yes on your Android phone", would be pretty good, though. SMS is right out, and so is email: someone who is going to hijack your SL account is going to hijack your email too.
Absolutely not. Typical attackers with their phishing campaigns in SL usually don’t care for email, they are usually just after the L$. I don’t know how many people are still using the same password everywhere, but even if they do, the SL website or the viewer do not show the email address anywhere.
So, it’s an absolute uncommon scenario, that an attacker that hijacks someone’s SL account would also be able to hijack the victim’s email account.
Even with intensive soliciting of the hijacked user’s contacts that’s an atypical scenario, attackers don’t waste time, they usually just try to quickly phish some credentials with fake SL login websites that they spread in groups, and try to get out as many L$ as they can, as quickly as possible. That’s the main risk that needs to be mitigated, that I see happening every other month.
Email based 2FA is just about right. LL just needs to be careful that they don’t get banned by the email providers for too many bounced emails, like they got banned by United Internet (“1&1”) in Germany a couple of years ago. It took nearly two years to convince them to lift the ban.
Martin RJ
On Sun, Mar 13, 2022 at 12:55 PM Argent Stonecutter <secret...@gmail.com> wrote:
On 2022-03-08, at 12:19, Henri Beauchamp <sl...@free.fr> wrote:
> - The chosen MFA protocol itself is weak: why relying on an external and
> offline application (basically a fancy hash generator with the "secret"
> as the -permanent, never renewed- seed and the current time as the
> variable) and time-based token, when you have verified email that is a
> much stronger way to ensure that the person login in is indeed the legit
> account owner ???
There are basically two MFA systems that are "best practice". These are open TOTP protocols (Google Authenticator, 1Password, etc... a logical descendent of the old RSA hardware keys) and open hardware challenge-response protocols (Yubikeys, FIDO, ...).
Personally I would rather LL supported both kinds.
Email based challenges are way down the list alongside SMS and Apples "you have to have an iPhone" scheme (which seems to be a proprietary challenge-response scheme that only works on iOS devices).
--
Archives of earlier incarnations of this list are at https://list-archives.secondlife.com
---
You received this message because you are subscribed to the Google Groups "opensource-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opensource-de...@lists.secondlife.com.
To view this discussion on the web visit https://groups.google.com/a/lists.secondlife.com/d/msgid/opensource-dev/7ADA57FD-6F47-46FD-BA71-D4548FBD0FB6%40gmail.com.
--
Archives of earlier incarnations of this list are at https://list-archives.secondlife.com
---
You received this message because you are subscribed to the Google Groups "opensource-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opensource-de...@lists.secondlife.com.
To view this discussion on the web visit https://groups.google.com/a/lists.secondlife.com/d/msgid/opensource-dev/CA%2BBE2c419VJV0DN%3DxNUm6%2BpxAGn7aBbryVeMZ0hga%2BK4gr1rfw%40mail.gmail.com.