Amara

"Stop trying to authenticate, start controlling cost" reframed the whole problem for me. Caching alone would have removed most of what I was worried about.

The practical toolkit, in the order I would apply it:

Rate limit aggressively, per IP and globally. A public page has a predictable usage shape. Cap it there. This alone bounds your bill, which is the actual thing you are protecting.

Cache. If several users can get the same answer, the third-party service should be called once. In many cases this cuts paid calls by a factor of ten or more and simultaneously makes replay pointless, because the replay is served from your cache.

Set a hard spend ceiling with the provider, if they offer one. This is the only control that is guaranteed to work regardless of what anyone does.

Add friction proportional to abuse. A challenge for visitors who exceed a threshold, rather than for everybody. It does not stop a determined attacker; it removes the casual ones and buys you time.

Log and alert. You want to know within minutes, not at the end of the billing period.

The first thing to establish is which spreadsheet feature is in use, because two very different things share the word "password".

Sheet or workbook protection — the option that stops editing or hides structure — provides essentially nothing. The contents are not encrypted; it is an instruction to the application, and the underlying file can be read without it.

File encryption on open — where the file cannot be opened at all without the password — is real cryptography in current versions of the major office suites, and it is not trivially broken if the password is strong.

So the answer depends entirely on which one your team is using, and a lot of people believe they have the second when they have the first. That is worth checking before anything else, because if it is the first, this is not a debate about degrees of protection.

Two things worth noticing about the test itself, because they inform how much weight to give the findings.

A flood of unauthenticated requests as the opening move is not a competent assessment. A good tester scopes, coordinates and avoids volumetric effects precisely because taking the target down produces no findings and a lot of collateral. If the first phase brought your service down, either the tester was careless or the exercise was not what it was described as.

The findings are still worth reading. Whatever the process failure, if they found something real then it is real, and the person who reported it badly is not a reason to leave it unfixed. Triage it on the merits, separately from the conversation about authorisation.

Also worth taking seriously: the fact that this took you down is itself a finding. An unauthenticated request flood should degrade gracefully rather than affect other tenants. That is a rate limiting and isolation issue you now know about, and it is the most valuable thing to come out of the whole episode.

For your last question — what to use where you have a choice — the ordering is fairly settled:

1. A hardware security key or a platform passkey. Resistant to phishing by design, because the credential is bound to the site and cannot be handed to a lookalike domain. This is the only option on the list that survives a user being tricked.
2. An authenticator app generating time-based codes. No carrier involvement, works offline. Still phishable — somebody can ask you for the code — but a large improvement.
3. Push approval in the service's own app. Convenient, and vulnerable to approval fatigue if the prompts are frequent.
4. Text message. Better than nothing, and the thing to move off first.

One important extra step people miss: enabling a stronger factor does not help if a text message remains a valid recovery path. Attackers go around the front door. Check the account recovery settings, not just the login settings, and remove the number where the service allows it.

For the last part of your question — the honest answer for someone who genuinely needs this — the work moves entirely to the device.

• Use a device you have reason to trust, from a vendor with a verifiable update record and a security model you can read about. Trust in hardware is not binary but it is not uniform either.
• Keep it updated. The overwhelming majority of real device compromises use vulnerabilities that were patched.
• Reduce what is installed. Every app is a potential problem, and side-loaded software from unknown sources is the single largest risk factor for ordinary users.
• Use a separate device for the sensitive communication if the stakes justify it, doing nothing else on it.
• Verify contacts in person using the app's safety number or equivalent, which protects against a different attack — someone substituting themselves for your contact.

And be realistic about the threat. If your adversary is a well-resourced actor specifically targeting you, no consumer advice in this thread is sufficient and you need help rather than a checklist.

Two more practical breaks, both of which matter independently:

Most malware does not check. Detection logic is only present in a minority of samples — mainly the ones whose authors expect analysis. Commodity ransomware, credential stealers and browser-based attacks largely do not care, and those are what actually reaches people.

The valuable things are inside the virtual machine with you. This is the bigger point. If you do your work in a virtual machine, then your documents, your browser sessions, your saved passwords and your network access are all in there too. Malware that runs inside it has everything it wanted. Isolation from the host protects the host; it does not protect the data you put in the guest.

People imagine the virtual machine as a shield around them, when it is a wall around a room they are standing in.

There is also a plainer possibility that is worth holding open: it may not be about security at all.

Standardising on one browser reduces licensing complexity, support cost and internal application testing. "Security risk" is a phrase that ends discussion in a way that "we would rather support one thing" does not, so it gets used for decisions whose real justification is operational.

That is not necessarily dishonest — reducing variety genuinely does reduce risk — but it does mean the announcement should not be read as a technical assessment of the product.