Add DATA_MFA_ENABLED to llRequestAgentData
Toothless Draegonne
For people running businesses in SL that may be worth real money, it could be very useful to know that their partners are at least carrying out the minimum of effort as far as account security is concerned.
I suggest making this information available as an extension to the llRequestAgentData function. This would let business owners know that people they hire have at least some risk-aversion sense and do not have accounts that are so easy to phish.
The DATA_MFA_ENABLED flag would only return a boolean value and no more. It would not return the type of MFA (in case of a future where multiple methods are available).
The only way I see that this may possibly be abused is that a malicious actor could specifically target people who do not have MFA enabled with phishing links. However at this point, and with regular phishing spams hitting groups and individuals all over the grid, the people who do not have MFA enabled should not be the reason to avoid providing an easy function to people who require trustworthy and risk-aware users to perform services for their money-making ventures in Second Life.
Log In
Lucia Nightfire
Can we also get DATA_PASSWORD_STRENGTH too? Asking for a stranger.
Snowlord Resident
no. it's no ones business what secondary measures one does or does not use for account security measures.
Toothless Draegonne
Snowlord Resident
If my business depends on your account security, then it is very much literally my business.
Snowlord Resident
Toothless to be honest, if you prefer that I don't do business with you if I don't have MFA enabled. noted.
Neon Zombie
I've had multiple issues with MFA not working properly and given the amount of phishing attempts people get in my real life job I can only imagine how much worse it would be with SL where bots scrape users data constantly.
I don't think giving the bot army a list of users that don't use MFA is a wise idea. The bots already have lists of users they can just check against and this would just give them an easier attack vector by narrowing down which accounts are easier to attack/gain control over.
ImGonna Nutmeg
I can only see this being more helpful than harmful if the account being checked had to accept some kind of script run-time permission for their MFA status to be determined. This way there is a barrier to just scanning every user freely.
Toothless Draegonne
ImGonna Nutmeg
Honestly the only thing a would-be attacker would learn if you had MFA enabled is that you aren't worth throwing phishing links at. Consider everything else that llRequestAgentData can get, including whether you are online regardless of whether you are hiding this information on your normal profile, and you can probably see how a permission check would be somewhat pointless.
If you knew just how much information a script can already get from any user at any time, I get the distinct feeling that you would be rather shocked.
ImGonna Nutmeg
Toothless Draegonne
I'm very aware of how much data in-world scripts can and cannot get about an avatar without their permission, and online status via
llRequestAgentData
is nothing and doesn't carry security risks.Now I'm no cybersecurity researcher, but exposing MFA status freely should be treated with at least a bit more care than that. My understanding is that it's similar to asking for a function that returns the length of someone's password: seemingly innocuous on it's own, but technically reduces the complexity of (or time to execute) an attack if known to the attacker.
The only precedent I'm aware of for even knowing other users' MFA status is for enterprise software use where many users are accessing a common set of resources, and administrators want to enforce a common standard of security similar to your original rationale. Second Life just doesn't currently have any concept of shared ownership that neatly fits that use case.
Nyx Onyx
I don't know that I can support this, because I personally choose not to have MFA enabled until LL has backup / extra methods to the current TOTP solution. And I wouldn't want to be excluded for that reason.
Security rests on multiple pillars, and SL fails at accessibility (great at keeping people out, but also keeping the right people out when the current method fails for different reasons). LL could use a variety of industry standard methods, but for one reason or another have chosen not to.
I am risk aware, which includes the risk of not being able to access my account.