1) Stop making "chat in group" a default permission for the Everyone group. If a group mod toggles this on, a warning should be displayed "this will expose your group chat to URL scammers and phishing attacks." Instead, create a second group tier, similar to Officers called "Verified" that does allow chats to be sent to the group. The idea is to reinforce the idea that group management is tiered (much like Discord) and that there's no shame in not letting looky-lou's that join your group because they found it chat with members you invited to the group specifically.

2) Flag links to non-Linden Lab domains as suspect. This is currently done by some TPV's such as Alchemy, where the 'legit' URL's are preceded by the Linden "Hand" icon in the chat display. Perhaps allow for other domains (Primfeed, imgur, social media) to be 'whitelisted' in the viewer but include only the LL domains by default. Any link NOT verified as legit by the viewer would get a warning dialog and not open in the viewer's browser window.

3) Disallow 'hyperlinking' URL's to text as a default - only allow certain roles in a group to do it. Currently this is allowed for everyone, and is sometimes used creatively to hide a scammer link behind something that looks legit. Note: you currently cannot disguise one URL as another - that pattern is disallowed.

4) Employ AI and human CS teams to find the "spoke and wheel" botnets that exist - typically a scammer will use disposable alts or compromised accounts to do the advertising, and then 'collect the winnings' on a main account. These Linden payoffs from many accounts to one account could be used to trace the actual scammers in near real time. It would possibly expose legit club and business owners that use a 'banker' alt to consolidate their work and income, but being revealed in such a pattern would not necessarily mean an automatic ban, and "known good" operators and their alts could be white-flagged. (I say "and their alts" because new accounts suddenly sending Lindens and items to a 'legit business' might indicate that the operator has either fallen victim to a scam or decided to join the Dark Side themselves.) This is basically what the forensic bookkeepers in the FBI did to reveal organized crime, "follow the money".

Beatrice Voxel I have to say I usually agree with your ideas on this site, but this time I feel like this was a huge overkill. Maybe I don't take this problem seriously enough, but this comes up here like every day and the same suggestions are being pushed each time - these you wrote here now too. My problem with these so-called "countermeasures" is still the same, they suggest removing essential functions, applying more restrictions and justifying discrimination. All the opposite of what SL is supposed to be about.

1) Some groups have been doing this forever. RP groups where chatter (like ATC) is supposed to be restricted to the RP, and also some rental, store and event groups only working one way through notices. That is where it is a good idea. Otherwise it is just an extra step in setting up a group which most people would fail at, and they might rather allow other powers in the everyone role as well if they won't be sure what is needed to enable group chat. Pointless anyway, if any group owner wants to implement this idea, they can do it anytime on their own and take all the time to "verify" their members.

2 and 3) This comes up so often and it is still the worst of all of these suggestions. Flag links automatically if they're not on a list of a select few websites? Who will maintain these whitelists? Who will decide which website will be allowed and which not? And then the hyperlinks. This is what would kill group chats the most. I want my hyperlinks fully functional so I click them and they work, and I can decide which I want to click on. Don't take them away from me just because some people can't be careful enough. It is not bad enough that we don't have link previews (like image previews) in the chat, in one word it's primitive, let's go back to the level of 1990 and have to copy-paste addresses manually or something? The next step: don't turn on your computer so you will be safe from clicking on scam links. One step further: let's go back in time to 1980. Has anyone clicked on a malicious link back then? Sarcasm aside, this would just ensure more people would avoid chatting in groups. I and some others already avoid groups where the moderators don't allow posting links. It's a stupid overkill. Most of us are reasonable and honorable adults, don't take things away from us because others are not.

4) Why flag money transactions in a way that can flag legitimate club owners, creators or just about anyone, too? Why not just follow the money in the cases when someone had it stolen from them? This would turn SL into a police state instantly, where people legitimately transferring money among their accounts wouldn't be their own business anymore and anyone could be suspended for the duration of an investigation just because a bot flagged them for transferring too much (or any) money between accounts. This already happens to people over billing issues which happen by LL's fault and that is bad enough. No need for more options to mistreat people who haven't done anything wrong.

"I think LL is shifting the burden of account security to the residents"

I don't know about others but I have learned a long time ago that if I'm in danger or distress, I can't expect anyone to protect me. If I need to rely on someone else in such a situation, I'm as good as dead. In this case, I was fine without MFA and never felt like anyone could steal my account, and I did my best (and still do) to ensure that, but I was very happy when MFA was implemented. It's the least you can do to protect your account and then basically the burden of account security is on the MFA to work properly, if someone not to do this and then to click the 6 millionth "free crap that's obviously not a thing but come click" link and then to enter their login credentials on that website, how can you be sure anything else can be done to keep them safe?

However, here are some ideas that can help in the long run:

1: Make sure MFA and the login servers, etc work properly, as in they both keep our accounts safe and don't make login troublesome for us, so that people would not weigh the risks against using MFA because it is uncomfortable or a lot of trouble. Act on https://feedback.secondlife.com/feature-requests/p/relax-account-security-and-add-trusted-devices so that we wouldn't have to log in the same account on websites several times a day when switching between two or more devices if we use these devices every day, make it an account option at least that the viewer login is exempt from a MFA challenge indefinitely if there is no login attempt from another IP address or device. Once it runs as smoothly and reliably as with other platforms, most people won't reject the idea of using MFA.

2: Educate the users on MFA and the risks of scams. It is in progress, I see it every time on the FS login screens, but it still happens that we're talking about MFA in a group and someone asks "what is MFA?" It is scary, if some people still haven't heard about it, it's either still not emphasized enough or they really avoid information even if it's out there in front of them.

3: Track down the scammers faster. This is where I agree with your last point in the way that AI could be used, but in my opinion it would be better to monitor links in group chat as well as logins and transactions to find suspicious links and patterns like one of those links was just posted multiple times and then logins to accounts from machines and IP addresses happened that are usually not used for those accounts. Go after specific patterns. The same scam link goes around for so long, it is really bad to watch. Finding such patterns must be fairly easy for AI and then these links could be blacklisted and prevented from being delievered to the recipients, as well as flagging the sender to account operations so they can investigate.

I just really don't get it when people want to impose more restrictions instead of these proactive solutions. Personally, I just don't want more disadvantages disguised as "protective features" that don't protect me at all, as I was already sufficiently protected. Some people in the comments here amazed me with how far they went to protect their accounts and I really like it. If they could do that, everyone could do the bare minimum, which in most cases would be just enough.

AlettaMondragon Resident All fine and good, except, having dealt with IT and security for most of my adult life (including back in the late 80's when modems and bulletin boards were a thing) there's ALWAYS going to be someone who does the Dumb Thing.

That BBS system operator that didn't quarantine the uploads (and spread a virus to their subscribers).

That executive who clicked the wrong link in an email (and opened up a backdoor to the network).

That grandma that fell for a tech support scam (and spent her life savings "reimbursing" the sweet tech for her fat fingered mistake).

That user who clicked thru a 'Free Stuff!' form (and had their account turned into Yet Another Untraceable Spam Bot).

My point about AI doing pattern searching isn't just to reveal the bots, but reveal who the bots report to. That's an extremely crucial step - without it, it's an endless game of whack-a-mole.

As for link restrictions, it's really simple to do domain resolution scanning - OpenDNS has been doing it for over a decade. Typically it's completely transparent to users ... until they try to go someplace in the dark shadows and that's when the service says "um, no, that domain's on the naughty list." Yes, you do have to be judicious about what gets blocked and what doesn't, but this is the entire business model - cache what domain a user looks up, send a page request, read the resulting page, and categorize it. With AI able to sift and summarize, it's even easier, and it's all behind the scenes, no handcuffs, no restrictions, just a little flag on the URL being posted. What Alchemy does now JUST flags the Linden Labs domains, that's it. But a viewer (not server!) blacklist or whitelist lets the user decide how much risk they want to take. That part I think was unclear.

moon Shade During SL22B Philip talked about giving group owners the ability to block links from chat or only allow moderators to post them, but I've heard nothing on it since. Not a word.

Beachy Piers Maybe technically it's a bear to implement or something? But yeah, giving group owners more control on how their groups get used by members would seem like an obvious place to start.

EmpressLuna Moonchild I totally agree with that. It's hard to understand why we cannot have at least the option of having backup keys. This avoids the issue of a phisher who just captures our session data, logs in, changes the email address, and requests a link for 2FA to be removed. That's way too insecure IMHO. The point of backup keys is to allow you to still log in without a working authenticator app (or device) but not rely on email/SMS which have been compromised (or simply changed to different things, at the whim of the phisher).

So, backup keys are a must.

Gwyneth Llewelyn And one argument by the OP was to reduce the burden on support... Giving you an independent backup method would also do this.

Nyx Onyx definitely true!

To be perfectly honest, in order to keep all my backup keys from all services I've ever subscribed to, I store them away on a remote, multiple-encrypted, virtually-unhackable service (Keybase), which I can access from anywhere — but nobody else can :)

But of course anyone can use those 'Safe Vaults' built into OneDrive, Google Drive, Dropbox, and others of their ilk, which are allegedly 'safe enough', for the same purpose.

Or if you are a command-line geek, just PGP-encrypt everything you save locally — and keep your private key inside a YubiKey or similar device :)

EmpressLuna Moonchild Totally agree, I have written a request here about some aspects of this problem but as surprising as it is (not), they didn't even address it. It's not like it's not worth using MFA this way, but it definitely results in some annoying situations.

Gwyneth Llewelyn Again I will refer to the CIA Triad and the ISO 27001.

It's up to the interested parties (the user in this case, for the most part) to make a determination on how to weigh the factors of security, and determine how important the information / account is.

LL currently have a thing in place that doesn't put as much weight on the 'A factor' in their MFA solution as I require, so I will at the moment choose to manage my credentials for a regular login and be as careful as I can in other ways. This includes being careful with links and at login prompts, but also that my payment method is linked to Paypal that in turn is associated with a credit card that has a very low limit, and I have an alt as a deposit for my L$.

If someone gets access to my account, the damage they can do is quite limited, and most of the damage should be possible for LL to restore. Losing access to my account due to MFA failure (lost device / corrupted app / errors on the LL side / whatevere else) and having to wait to get on SL until LL gets around to my ticket is not alright with me, not when it's the ONLY backup method. It's good to be able to fall back on support when the curently non-existing backup methods don't work for whatever reason, but it should not be the one and only way.

I mentioned some possible backup methods in an earlier comment. If a backup method is used that is insecure by its very nature (sending codes via e-mail or SMS for example), it should be combined with something (this is called layering security). This layering could include a knowledge test, as well as automated tests such as comparing the subnet you're connecting from with where you usually connect from and assign a score to that depending on how often you connect from that subnet.

I would consider Passkeys an alternative primary method rather than a backup method, but effectively TOTP generator apps and Passkeys will as alternatives serve as backups as well, if both are enabled.

This post turned into a longer one than I intended, sorry. I do recommend a read about the CIA Triad and ISO 27001. You can have your favourite LLM summarize them for you.

why so much ChatGPT... you got to love the AI — line

Gwyneth LlewelynThis is a joke right?

A combination of a client certificate containing a digital fingerprint, randomly seeded with, say, a TOTP 6-digit-number generated locally, provide a means to exclude third-party "replay" attacks. The idea would be that, once an avatar is first created, it gets a client certificate emitted by LL, based on its hardware fingerprint, as well as the number in the TOTP authenticator; now valid tokens would be returned encrypted with the user's private key from the client certificate issued by LL. Since TOTP changes every 30 seconds (within a margin), that means a potential attacker intercepting communication would have about that time to wreak havoc — depending on how sophisticated their tools are, this might be enough, or LL might build in an extra layer of security (e.g. no L$/item transactions allowed before the first minute has elapsed — which a "regular" user will not really notice, since this is also around the time you'll have to wait for things to rezz anyway).

The major issue with this approach is that changing keys and making sure both parties (client and SL Grid servers) are aware of which keys are valid, as well as additionally encrypting everything, requires expensive computational resources — hardly something you'd like to have to add to lag. Moreover, every 30 seconds, there would be a "hiccup", until the server generates a new pair of keys. A slightly faster option than full encryption would be just to add a hash as signature — hashes are reasonably fast to compute (although this would need to be stress-tested), and they should provide the two parties enough proof that the communication hasn't been intercepted, at the cost of making the hcommunication less secure (even taking into account that most — not all! — communications between viewer and grid are already encrypted).

I'm not claiming that this is a perfect solution, though, and I actually worry about the overhead costs of generating new pairs of keys twice per minute. Theoretically speaking, such keys could be pre-generated in advance, at least on the server's side — given the 'secret seed' shared by client and grid via TOTP, you can safely generate 'future' keys in advance, and use things like, say, teleporting or searching through inventory, when user attention does not require near-real-time attention, to generate more keys and place them in a buffer. This work, but, of course, any 'future keys' generated on the viewer would be theoretically susceptible to being stolen by the scammer/phisher.

Another possibility would be to use this mechanism only for "sensitive" communication, not for simple things like tracking an avatar's position. Second Life has for almost two decades relied on 'capabilities'. These are requests made by the viewer on behalf of the user to 'do' things: they're more fine-grained session keys, if you wish, but which only unlock a specific 'thing', not the whole range of accesses.

For instance, suppose you wish to have a look at your avatar's inventory. For that, your username must have the authorisation to do so (obviously!). So the viewer requests that capability from the grid, which will check if your username is, indeed, allowed to view your avatar's inventory. Once that is confirmed, the capability is sent back to the viewer, and, from that moment onwards, until the capability expires, your viewer can continue to look at your avatar's inventory.

The same applies for a lot of things, such as requesting access to enter a parcel, or to teleport, to fly, to engage in transactions, even to log in — for each case, the grid will need to see if you're properly allowed to do so, and the viewer will need to retrieve the appropriate capability to get granted access.

While this seems a bit awkward, the point here is that accessing the core authentication servers requires precious time, and may be a resource-intensive operation. Consider someone in a private chat: you wish that only those people whom you gave access to join the conversation have access to the messages there. In theory, therefore, every time a message is sent, the grid server theoretically ought to look up your avatar's username, everybody else's username, and make sure, on the database, that everybody has given permission to everybody else to read the messages — because you cannot just 'assume' people will give each other permission 'forever'. People might get kicked out of the conversation, muted, banned, or something like that. So the system has no choice but to check if every condition is still valid redistributing a message to others.

This would be a major pain to do with 50 thousand simultaneously logged in users, all relying on chat — public or otherwise — to be 'immediate' (i.e., taking less than 200 ms to appear) but also 'secure' (i.e. nobody else can listen in to the conversation unless explicitly allowed to). Such requests would flood the database, stall it, possibly crashing the database server(s), and so forth. And that's just for !

Instead, when the communication is established, each participant's viewer requests a capability to join the conversation. The system checks for such permission . Now the viewer only needs to send the messages with the granted capability — the grid 'knows' that person is cleared to chat, and with whom, so it doesn't need to bother with constantly requesting permission to do so. All parties can independently confirm that the capability was granted and signed by LL's servers and is therefore valid. If someone is muted suddenly, their capability to continue to chat will instantly get revoked, and all parties can confirm that the revocation order is a legitimate one.

Now, I'm not quite sure if capabilities have an automatic expiration date (I suppose they do!), but since there will be a period of time required to retrieve the conversation's capabilities, before the conversation can, in fact, be initiated, I suppose that this could be combined with the before-mentioned security service as well. In other words: to request for a capability, the user needs to send a request signed with LL's public key for that communication — and get a signed reply, this time encrypted with the user's own personal private key.

And perhaps this is something that happens — I don't know, I'd have to look for that in the code. If it already does, great, one problem less! If not, it's a question of adding the extra encryption/digital signing (even the request for requesting capabilities might be encrypted that way!).

Obviously, LL may additionally build a safety mechanism: if such requests are made, say, ten times, and all the responses are invalid, it's reasonable to assume that either the user's clock is completely off the mark (over one minute), or that the user doesn't have the correct TOTP authorisation app. Either way, they may get kicked out by the grid with a warning message that a user would have no problem in following up — but a phisher/scammer cannot.

That effectively means locking out any potential phisher who have logged in by stealing all authentication data and retrieving all session keys etc. — at worst, they'll be able to be in-world for a minute or so. But the suspicious activity could be flagged: the phisher's system would have been fingerprinted, their approximate location identified (it matters little if they use a proxy, a VPN, or even Tor — what matters is that this will be the 'usual' location for that user, neither will it be the same machine), and the legitimate user may be warned (granted, if they changed the email address, such information might be captured as well... but at least the user may get an in-world IM, the next time they've logged in, and explain them what to do).

So, phishers will target a different surface instead: the Marketplace or the user's account. Let's start with the Marketplace, which is perhaps easier to understand how this safety mechanism might work. Also consider the typical human being using the Marketplace, as opposed to a scripted attack.

If the same technique is used for changing email addresses, then the user's email will also be protected. Again, the Web server and the client's TOTP application share a common seed, which the phisher can't know. The Web server doesn't even need to ask the user for entering a new code when changing email addresses — they can simply calculate the correct code at the moment of submission, send back a new client certificate (or something equivalent) which will only work if you know that seed, and refuse anything else. The best that the phisher can do is to try to TOTP by requesting a reset link by email — but that means intercepting the user's mailbox hacking into their SL!

What this means is that in order for a scammer to completely bypass everything, they will have no choice but to 'take over' the user's computer using some sort of malware. While the TOTP app might still be inaccessible, what the scammer must do is simply to check what keys are being sent and received every 30 seconds, and use exactly the same ones for requesting capabilities of their own. As soon as a change of keys is detected, these have to be instantly relayed to the phisher as well — over a secure channel established between the user's computer and the phisher's, which keeps the exchange of keys in sync with them.

But that's not phishing/hacking any longer. That's maliciously hacking someone's system with a virus or a Trojan. And is possible, of course, but it also means that the virus protection software will kick in and alert the user about a security vulnerability; not to mention that creating a new virus from scratch, for a specific use-case only (e.g., only attacking SL accounts), requires much longer to implement and is way harder to set up than a simple "phishing website".

It's something completely different, and TOTP is not meant to be a solution to deal with computers under remote control by a malicious hacker.

That said, the above comments are a description of an oversimplified solution. In effect, you cannot use TOTP to generate new encrypted keys based on the next number to be displayed. While the can do that, the 'secret seed' is shared with the TOTP , and with the computer(s) it's used with, or it would be pointless — 'secret seeds' stored in a computer be hacked if the computer is compromised. But TOTP inside an independent device means that the hacker has now to compromise the device the computer used for logging in — and that means understanding the relationship between the two devices — which will share data (it's the human user, after all, who types the 6-digit TOTP number manually... and you still can't hack human brains directly 😂).

Nevertheless, there methods for cryptography using rotating keys at short intervals, which cannot be easily 'hacked', even by a phisher who captures the first communication with the first, well-known pair of keys, and just replays them over and over again. HTTPS traffic, for instance, to be , uses a shared secret for encryption and decryption, because symmetrical cryptography is faster than assymetrical (i.e., public key/private key) cryptography. The way to make HTTPS secure is simply to generate a new shared secret every few seconds — and for , cryptography is used, with a public/private key pair. But you can transfer huge chunks of data at so-called 'wire speed' just using the secret key. The weakness of things such as relying only on HTTPS is that a malicious hacker will not bother to attack the stream of data itself, but rather the endpoints: if they learn about the secret key change at the same time as the user, they can 'listen in' for as long as they want. Better: if they grab the key from either endpoint, they can generate 'secret seeds' as they like, and 'take over' communications. But hacking into a personal computer using a targeted virus for this purpose is for amateurs and script kiddies!

EmpressLuna Moonchild hah — I love when people that I use ChatGPT, a tool that I use for long texts, because for long texts, who needs AI?? All you need is one brain, two hands with several fingers, and time...

Kyrah Abattoir I hope not, since I'm not really well-known for my sense of humour, although I find it amusing that you it's a joke. Tell me, what's so funny about it?

Gwyneth Llewelyn Based on the use case, a twice per minute key rotation might be serious overkill. I worked for a company supporting a distributed app (streaming live TV, national and local) and their key rotation was set at 5 minutes for backend security and 30 minutes (!) for content. Apparently the management overhead of keeping track of multiple keys for each of 600+ channels added enough infrastructure to make the system rather ... unwieldy ... should the databases that stored the keys lose connectivity. And it did happen - fiber cuts that affected national to local links often meant that while we could shunt to higher cost networks to get the video through, the latency on those nets was enough to throw the key timings off and the customers couldn't watch it anyway!

Point of the anecdote is this: There's a balance between operability, where the user doesn't notice security overhead affecting the service, and security, where the user is completely protected but the security overhead affects the service itself. LL would need to determine where the sweet spot is for most accounts, not so often that the service is lagged, but not so rarely that a breach causes significant losses.

Gwyneth Llewelyn Your eloquence is commendable, but that's about it.

Gwyneth Llewelyn Thanks for the support and explaination, I

know its just a layer of additional protection and no 100% safty.

Also there is a ticket arround for Groups to filter these sites, so people dont need to do it by themself.

The next puzzle in our game is the uprise of Omnifilter - I tested it already in the Firestorm Beta. I personaly filtered out all ".shop" and all ".herokuapp" links that were mostly used. As well as fake marketplace links. - Downsite is at the moment i dont see the scam link anymore to take further action for abusive reports.

Obviously, having a "fake login page" allows scammers to be even more sophisticated: not only will they easily capture the validated session token, but they will also get the username and the password. So, to delay detection, they can keep the password as it is — just change the email address and remove 2FA. Since 2FA, once used, can be stored locally for 30 days without being bothered again, it will be a while until the user figures out that they had their email address changed and 2FA removed, because, so long as their password continues to work, they have no reason to suspect anything...

Scammers be even more sophisticated. In order to prevent the accidental revealing (either to prying eyes or malware), LL does not show what the email address is: it just shows the bare minimum for a human to recognise that address. Suppose that my email address is "fabulous.username@yahoo.com", one that the user will have set up just for SL, for instance. LL will obfuscate the address and show it just as — enough for the user to remember what the email address is, impossible to reconstruct the original email address from it.

eWhat the scammer only needs to do is ty o replace the email address with — one that they have set up for this purpose — and that's it. The user will just check if their email address is the correct one, see the obfuscated string, and assume that nothing has been changed.

Since the vast majority of users will use , , etc., all the scammer needs to do is to register 26 addresses with each of those providers, each starting with a different letter of the alphabet. This should cover 99% of all email addresses used for logging in to SL, thus baffling the user — even if they change something and expect to receive an email from LL, they will just assume it went straight into spam, since the obfuscated address will look exactly as it always did.

It's only when L$ starts disappearing or tickets fail to get an answer from LL that someone might really wonder what's going on, but by then, it's far, far too late.

Gwyneth Llewelyn to be fair you will get a message that your email adress got changed - but yeah that case is not impossible.

Chrissy Skydancer that's actually a very good first start!

But one can go a bit further than that, i.e., instead of relying solely on manual filters, use something automated. There are plenty of online lists of 'bad' IP addresses and URLs from well-known malicious sources, and discussions on which service to use:

And here are some lists of more and more sites/services providing anti-scam prevention/identification (some old, some new, some outdated, pick one!):

However, I'd like to suggest the following, paraphrased from Reddit:

> Short version: Stop what you are doing and subscribe to a threat intelligence service, instead.

I believe that's sound advice for the Omnifilter developers: you should not be reinventing the wheel — at least, not regarding URLs, i.e., anything non-specific to SL. Filtering objects, avatar names, teleport requests, etc., that makes lots of sense, since they're specific to SL; URLs, well, no 'filter'-based approach will really work.

For example, filtering out URLs may have two unintended results:

Similarly, things like blocking IP addresses from, say, Russia, thinking that will keep most scammers out is a fallacy: most scamming sites are actually located in the United States, simply because the US hosts most sites in the Internet (and aye, even Russian scammers use US sites... more than you might imagine)!

This is to say that Omnifilter isn't an tool! It's a start, of course, and would be 90% effective in, say, 2004. But this is 2025 (almost 2026!) and scammers have wildly more sophisticated tools at their disposal that can defeat the most complex 'filtering' systems.

As many of the above links show, you'll really need a considerable amount of Machine Learning (ML) to deal with current-generation scamming/spamming websites. This is not for the faint of heart to develop from scratch as a side-project; it's a multi-million approach taking teams of cybersecurity specialists and ML scientists years to complete; nobody around here has that amount of disposable income to invest into such a monster. Instead, you should simply rely on those who that kind of R&D and sell subscription services — but often offering a free tier which will be already better than any naïve 'filtering' solution.

Chrissy Skydancer well, I'm learning something new every day, I can't recall ever receiving such a message — then again, the last time I changed email addresses was in May 2006 😂 so I might have missed that tiny detail!

Gwyneth Llewelyn This actually makes a lot of sense. I'd go one step further - LL can subscribe to DNS Resolution Filter services (OpenDNS) that tag and flag at the domain level, not just on the domain name itself, but heuristically by -content- found on the domain. I've used OpenDNS for years as a DNS resolver, and all devices on my subnet (computers, phones, smart appliances) get a blank page if they try to access any sites that OpenDNS filters based on my criteria.

This means that while a user might fall victim to a link, their access of that link is interrupted at the DNS resolution stage, they get a warning page instead (from either OpenDNS directly, or a HURL to a Linden Labs page) saying, "This might not be a good idea to proceed, here's why".

The trick of course is to get OpenDNS to survey/categorize the domains being used, but one use case for AI is to sample the pages people are accessing via a service and assigning them various tags based on the content retrieved. A few hits to a phishing page would be all it takes for such an AI to flag it as "phishing."

Nyx Onyx Yeah, this is the right answer. While Google Authenticator and other TOTP generators are good, passkeys are the way to go.

At least LL isn't stuck in the 2000s like the USPS, which only does 2FA via SMS or email...

Tonya Souther well, 2FA via SMS/email is better than nothing at all...

Gwyneth Llewelyn No, not really. Security experts are pretty much unanimous in recommending that people do away with that. They're just too easy to hijack.

Tonya Souther I won't disagree with you; I personally prefer passkeys as well (and I also like YubiKeys!). SMS/email is far more cumbersome!

Emails also have this nasty habit of getting flagged as spam... or greylisted... which means that they may be too short-lived in order to appear on your mailbox in time for logging in (SMS is technically instantaneous, but... in practice, it can be subject to delays as well, depending on the operators involved).

Also, TOTP can, at best, protect the procedure, but, once you're "in", you need a different mechanism to continue the transaction secure. A phisher can easily replay a captured TOTP.

Although I wonder if they can't just rely on the session data received after all levels of authentication have been completed on a fake, proxy page... in theory, passkeys may be 'as safe as' anything else (or nothing at all) if someone just types things on a phishing website, unaware that everything they do is being captured to be used later...

EmpressLuna Moonchild Just want to say thank you because a lot of folks don't seem to understand this part, so thank you for sharing this info.

Thank you as well! I've explained a bit further why 2FA doesn't work (at least in the way it's implemented right now); it seems to me that LL can do a small change just to avoid token hijacking and make 2FA more robust that way.

All right, so it wasn't 'just a bit further'. It was 'so much' that people now think I use ChatGPT to write things lol

(Disclaimer: I actually train LLMs for a living, or, rather, as part of the gig economy...)