The problem with that is that the logic is broken. Microsoft cannot possibly know all phishing sites, especially for smaller things. By obfuscating the link the user can no longer verify it by themselves without clicking, but Microsoft will say it's safe. So the user is left with a false sense of security and are worse off.
It only works for huge sites ( e.g. mytwitter.lol phishing for twitter and similar), but drastically lowers the chance of less high profile phishing being caught.
That isn't by itself an argument against a good automated system -- I definitely like not having to sift through most of that garbage, but catching the 0.01% should be a routine practice, not something that seems like an insurmountable burden.
If you do so, in Outlook, there will be a pop that shows "Original URL: XXX". This allows users to make a determination for themselves whether the link is safe or not.
I don't trust myself enough to be 100% sure I can decode an URLencoded misleading mess perfectly all the time.
They already hid urls in the username of the url, like www.google.com.unholymessherethatscrollsoutoftheurlbar @ malignantdomainnotgoogle.blah
Bing indexes it. This is my first major security incident and I have no idea how to fix this without making everything totally shitty for the users.
The original post is just complaining that the malware scanning is visiting the links.
They come to the following conclusion
>This effectively makes all one-time use links like login/pass-reset/etc useless.
Which we all know is not true because sites like onetimesecret.com allow for entering a separate password to prevent this sort of thing when it does happen.
It would be an interesting discussion to talk about what Microsoft's whitelisting process looks like, but the original article doesn't seem to understand what is going on well enough to drive the conversation in that direction.
It's about trying to get to the core of the issue, not just the random speculation going on in the article and in this comment thread.
The point I was making is that someone should research this instead of relying on wild speculation as the basis for the conversation.
All pages with one click links should have no index follow or no index no follow. Your seo consultant (if you have one) should have advised you on this.
I am not saying this excuses the privacy violation but just suggesting there are things we can do...
Also, mail might not live on the same computer.
I should not be able to take over your life because I compromised your phone which has sms, TOTP app and email.
* use an interstitial page so that the actual activation is a POST request;
* send a confirmation code instead of a link
The password only makes this autentication less secure and it's not needed.
Recovery codes exist and are created at the time before recovery is necessary. But most people are going to lose their codes.
Who is going to remember what 3 things they picked out of 30 years ago?
There's also RFC 8058: https://datatracker.ietf.org/doc/html/rfc8058
Dunning-Kruger level of understanding: Never trust the client for anything ever, it's unreliable, everything must be off client.
Never mind the client is literally the interface into your system, so it being compromised is already game over for an application where the user is most vulnerable party you wanted to protect...
Deep understanding: Trusting the client requires a well thought out security model.
If the client is hacked in this case, they already have full control over what the user sees, they can cut out your remote check.
Maybe a good balance would be to hash the root of the URLs and compare those, or use fuzzy hashing on page contents, just so that the backend isn't getting a bunch of private urls that might accidentally get logged somewhere.
Trades detecting stuff hidden behind redirects for less liability on your backend, something to possibly consider depending on functional requirements.
1. User opens Outlook and types in their email and password.
2. The app requests the user's password hash from the server and checks it.
3. Outlook tells the server auth was successful and gets a session token.
The client has a much bigger issue to worry about if the client-side malware scanning has been compromised. Malware could modify the UI/network calls such that your server-side scanning displays a positive result anyway.
You have to trust the client to display information to the user at some point. Link malware scanning that job can safely be delegated to the client. Authentication cannot.
And also use the local client to scan unknown links? They probably dont want outsiders to have access to this code.