1. No more SMS and TOTP. FIDO2 tokens only.

2. No more unencrypted network traffic - including DNS, which is such a recent development and they're mandating it. Incredible.

3. Context aware authorization. So not just "can this user access this?" but attestation about device state! That's extremely cutting edge - almost no one does that today.

My hope is that this makes things more accessible. We do all of this today at my company, except where we can't - for example, a lot of our vendors don't offer FIDO2 2FA or webauthn, so we're stuck with TOTP.

Banks and media corporations are doing it today by requiring a vendor-sanctioned Android build/firmware image, attested and allowlisted by Google's SafetyNet (https://developers.google.com/android/reference/com/google/a...), and it will only get worse from here.

Remote attestation really is killing practical software freedom.

Detecting changes — and enforcing escalation in that case — can be enough, e.g. "You always uses Safari on macOS to connect to this restricted service, but now you are using Edge on Windows? Weird. Let's send an email to a relevant person / ask for a MFA confirmation or whatever."

You just described the usage pattern of a pilot with a family, a truck driver, a seaman, etc.

It’s only unusual if your definition of usual is “relatively rich, computer power user”.

I travelled a lot for work, and never had issues with account access. Nor did my wife ever have issues related to accounts. We don't share Google accounts though. It sounds like that user has personal accounts being used by three people for business use... Which isn't "A seaman and his family".

Yes. Everyone having their own distinct accounts is a property of high computer literacy in the family.

Many of my older extended family members have a single email account shared by a husband and wife. Or in one case the way to email my aunt is to send an email to an account operated by a daughter in a different town. Aunt and daughter are both signed in so the daughter can help with attachments or “emails that go missing”, etc.

> Which isn't "A seaman and his family".

The seaman in this scenario has a smartphone with the email signed in. It’s also signed in on the family computer at home. Both the wife and him send email from it. Maybe a kid does to from a tablet. This isn’t that difficult.

> They will just print it (or have someone print it for them) beforehand.

Yes, they will do that precisely because they do not trust technology to work for them because it frequently does not! I have family members like this. I log in to their accounts on my devices for various reasons. Even worse, I run Linux. We run in to these problems frequently. Spend time helping technically illiterate people with things. While doing so, make a concerted effort to understand why they say or think some of the things that they do.

Edit to add, I find it amusing that you make fun of his seaman example. Almost that exact scenario (in terms of number of devices, shared devices, and locations) is currently the case for two of my relatives. Two! And yet you ridicule it.

Or a more recent example: my father forgot to bring his Android phone back abroad which subsequently locked him out of his account/services; had to wipe it for him to get his access back.

If you don't own your own device and rely on third-party devices to access the service, good luck to you...

Google's login protection mechanisms seem to be satisfied by TOTP usage, and you won't be locked out anymore (or at least much less likely to be).

And for many of the SaaS that we use, TOTP doesn't help you avoid the security lock outs.

Much appreciate the suggestion!

Some services already thinks like that, like I think discord.

It has been a long, slow but steady march in this direction for a while [1]. Eventually we will also bind all network traffic to the individual human(s) responsible. 'Unlicensed' computers will be relics of the past.

[1] https://boingboing.net/2012/01/10/lockdown.html

> I think 3. is very harmful for actual, real-world use of Free Software. If only specific builds of software that are on a vendor-sanctioned allowlist, governed by the signature of a "trusted" party to grant them entry to said list, can meaningfully access networked services, all those who compile their own artifacts (even from completely identical source code) will be excluded from accessing that remote side/service.

Is that really a problem? In practice wouldn't it just mean you can only use employer-provided and certified devices? If they want to provide their employees some Free Software-based client system, that configuration would be on the whitelist.

But I think the point of your parent comment's reply was that the inevitable adoption of this same techonology in the consumer-level environment is a bad thing. Among other things, it will allow big tech companies to have an stronger grip on what software/platforms are OK to use/not use.

If your employer forces you to, say, only use a certain version of Windows as your OS in order to do your job, that's generally acceptable to most people.

But if your TV streaming provider tells you have to use a certain version of Windows to consume their product, that's not considered acceptable to a good deal of people.

It's just subtle enough (e.g. lower definition but will still play) and most people use "secure" enough setups that only techies, media gurus, or that one guy who's still using a VGA monitor connection end up noticing

They are also already limiting (weakly) the max number of devices that can playback which requires some level of device identification, just not at the confidence required for authentication.

Worse supposedly this is for security, but attackers which pulled of a privilege escalation tend to have enough ways to make sure that non of this detection finds them.

In the end it just makes sure you can't mess with your own credit card 2FA process by not allowing you to control the device you own.

I think we'd do well to provide the option to use open protocols when possible, to avoid further entrenching the Apple/Google duopoly.

You need a bank account to do basically anything and yet consumer banking is largely unregulated (in the consumer relation sense, they are regulated on the economic side of course). Payments take upwards of 24h and only during work hours (?!?), there are no "easy switch" rewuirements, mobile apps use shit like SafetyNet and I've had banks legit tell me "just buy a phone from this list of manufacturers"... PSD2 is trash that only covers B2B interoperability and mandates a security method that has been known as broken since its invention (SMS 2FA).

E.g. with an credit card.

Due to the way it integrates into websites (or more specifically doesn't) classical approaches like SMS 2FA (insecure anyway) but also TOTP or FIDO2 do not work.

Instead a notification is send to a preconfigured app where you then confirm it.

Furthermore as the app and payment might be on the same device the app uses the fingerprint reader/(probably some Google TPM/secrets API idk.).

Theoretically other approaches should work, but practically they tend to not work reliable or at all in most situations.

Technically web based solutions could be possible by combining a FIDO stick with browser based push notifications, practicality they (Banks) bother or there are legal anoyences.

The point of these restrictions is to ensure that your device isn't unusually vulnerable to privilege escalation in the first place. If you let them, some users will root their phone, disable all protections, install an malware-filled Fortnite apk from a random website then stick their credit card company with the bill for fraud when their user-mangled system fails to secure their secrets.

You want to mod the shit out of your Android phone? Go ahead. Just don't expect other companies to deal with your shit, they're not obligated to deal with whatever insecure garbage you turn your phone into.

> they're not obligated to deal with whatever insecure garbage you turn your phone into

Banks probably should be obligated to let you connect over standard protocols.

Any system can have malware. That's not the point. To repeat my point again: client restrictions are about making sure user devices are not unusually vulnerable to malware. For example, any Windows device may be infected with malware, but if you're still running Windows XP you're vulnerable to a much larger variety of known malware and more severe exploits. Hence why businesses will want to support only modern versions of eg Chrome which itself will require modern versions of operating systems.

I'm not asking to use a 10 year old version of android that no modern browsers support any more and is missing many security features.

I guess you also think Android/iOS should just get rid of app permissions because users could just use similar software on their desktops without any permissions gating?

Edit: Android/iOS are increasingly popular platforms, the security they pioneer far exceeds their desktop predecessors and has improved the average security posture of millions of mobile-focused users.

The motivation is not "just" that, or for fun, the motivation is that users should be allowed to control their own devices. And have them keep working.

> I guess you also think Android/iOS should just get rid of app permissions because users could just use similar software on their desktops without any permissions gating?

I want it to work... exactly like app permissions. Where if I root it, I can override things.

> Android/iOS are increasingly popular platforms, the security they pioneer far exceeds their desktop predecessors and has improved the average security posture of millions of mobile-focused users

Having that kind of sysadmin lockdown is useful, but if I want to be my own sysadmin I shouldn't be blacklisted by banks.

Also this is about the second factor in 2FA not online banking.

Which you can do on a completely messed up computer.

I'm also not asking to be able to do pay contactless with a degoogled Android phone.

Similar I'm but asking to not have 2FA, you can use stuff like a FIDO stick with your phone.

Most of this "security" features are often about Banks pretending to have proper 2FA without a second device... (And then applying them to other apps they produce, too).

Android will block non-Play-Store app installations by default, and root is required for lower level access/capabilities that can bypass the normal sandbox.

I'm honestly not sure what you're saying about 2FA in the rest of your comment, it's kind of vague and there are some possible typos/grammar issues that confuse me. What exactly are you referring to when you say "pretending to have proper 2FA"?

No, you basically have to click on ok once (or change a setting, depending on phone), either way it doesn't require root, and doesn't really change the attack scenario as it's based one someone intentionally installing an app from an arbitrary not-trusted source.

> root is required

Yeah, like privilege escalation attacks. As you will likely find in many compromised apps. And which on many Android phones work due to vendors not providing updates after some time. And many other reasons.

> What exactly are you referring to when you say "pretending to have proper 2FA"?

EU law says they need to provide 2FA for only banking.

Banks often don't do that for banking apps as it's inconvenient. Instead they "split the banking app in two parts" and maybe throw some finger pint based auth mechanism in and claim they have proper 2FA auth. (Because it's two app processes running and requires the fingerprint.) Through repeatedly security researchers have shown that its not a good idea.

Additionally they then require you to only use your fingerprint, not an additional password....

Either way, the point is that secure online banking doesn't requires locked down devices in general.

Good security is layered. Just because privilege escalation attacks are sometimes possible without root doesn't mean you throw open the floodgates and ignore the threat of root. The point of banning rooted devices is that privilege escalation attacks are much easier in rooted devices.

Of course online banking doesn't require locked down devices, but online banking is more secure in locked down devices. I don't see why banks should weaken their security posture on root just because they aren't perfect in other areas.

it fails to do so in many ways, including not blocking old, no longer maintained, known to be vulnerable android releases

it also has little to do with moding and more with having a proper working free marked which allows alternatives besides Google and Apple

Checking for an too old & vulnerable is where you start.

And then you can consider to maybe also block other stuff.

There is nothing inherently less secure about an rooted device.

Sure you can make it less secure if you install bad software, but you can also make it more secure.

Or you just need to lower the minimal screen brightness for accessibility reasons.

Your claiming it's ok to take the agency from people away to decide over a major part of their live (which sadly phones are today) because maybe they could act irresponsible and do something stupid.

But if we say that is ok, then we first need to start to ban cars, because you could drive into a wall with it, and knifes, also no way to have a bath tube you could drown yourself.

And yes that is sarcastic, but there is a big difference between something being "inherently insecure" (driving without belt) or by default is in no way less secure as long as you don't go actively out of your way to make it less secure (by e.g. disabling security protections).

This is clearly wrong, rooted devices are much more insecure because they enable low level access to maliciously alter the system. Malware often requires root and will first try to attempt to attain root, which of course isn't necessary if a user has manually unlocked root themselves.

> Your claiming it's ok to take the agency from people away to decide over a major part of their live (which sadly phones are today) because maybe they could act irresponsible and do something stupid.

No one is taking away any user's agency. Users are free to root their phones if they wish (many Android phones at least will allow it), but companies are also free to deny these users service. Users are free to avail themselves of any company's service on a non-rooted phone. "Not using rooted phones to access anything you like" is hardly a major loss of agency.

Phone insecurity is very dangerous IMO, much more dangerous really than bathtubs or perhaps knives. You could argue that vehicles are similarly very dangerous and I'd agree. I don't think we're very far off from locked down self-driving cars. Unfortunately we're not there yet with self-driving tech and the current utility of vehicles still outweighs their immense safety risks. You can't really say that about rooted phones. The legitimate benefits of a rooted phone are largely relevant to developers, not the average user, and most users never attempt to tinker with their phone.

If you can't proceed with a normal life after you root you phone you are NOT free to do so but instead get punished when doing so.

> If you can't proceed with a normal life after you root you phone you are NOT free to do so but instead get punished when doing so.

Freedom to root doesn't mean freedom from the consequences of rooting. Banking apps are hardly necessary for a normal life, and neither is rooting.

And this has happened before, with Intel ME that was and still is useful if you have a fleet of servers to manage but a hell of a security hole outside of corporate world.

And now that Windows 11 all but requires a working TPM to install (although there are ways to bypass it for now), I would not be surprised if Netflix and the rest of the content MAFIAA would follow their Android approach and demand that the user have Secure Boot enabled, only Microsoft-certified kernel drivers loaded and the decryption running in an OS-secured sandbox that even a Local Administrator-level account can access.

This is already the case with Netflix -- 4k video content cannot be played on Linux.

That's fine for employees doing work for their employers. It's not fine for personal computing on personal devices that have to be able to communicate with a wide variety of other computers belonging to a wide variety of others, ranging from organizations like banks to other individuals.

Depends what you think big corporations' centrally managed IT equipment is like.

Theoretically, it could mean you get precisely the right tools to do your job, with the ideal maintenance and configuration provided effortlessly.

But for some organisations, it means mandatory Internet Explorer and Flash for compatibility with some decrepit intranet, crapware like McAfee that slow the system to a crawl, baffling policies like not letting you use an adblocker, and regular slow-to-install but unavoidable updates that always happen just as you're giving that big presentation.

I'd feel 100% differently about this stuff if the NSA or some other cybersecurity gov arm making these rules used their massive cybersecurity budgets to provide free MFA, TLS, encrypted DNS, etc., whether US gov hosted or via non-profit (?) partners like LetsEncrypt.

OSS & free software otherwise has a huge vendor tax to actually get used. As is, this feels like economic insecurity & anti-competition via continued centralization to a small number of megavendors. Rules like this should come with money, and not to primes & incumbents, but utility providers.

Sure, our team is internally investing in building out a lot of this stuff, but we have security devs & experience, while the long tail of software folks use doesn't. The gov sets aside so much $$$$ for the perpetual cyber war going on, but not for simple universal basics here :(

https://reproducible-builds.org/

Agreed that people should have the freedom to modify their software though.

https://developer.android.com/training/safetynet/attestation

No one wants to reproduce an attestation. If you could, it could be copied, and if you can copy an attestation any hardware could send it to prove it was something else - something the other end trusts, rendering is useless for it's intended purpose.

However, the attestation is attesting the hardware you are running on is indeed "reproduced", as in it is a reliable copy of something the other end trusts. It could be a device from Yubi Key and in effect you are trusting Yubi Corp's word on the matter. Or, it could be an open source design everybody can inspect, reproducibly rendered in hardware and firmware. Personally, I think trusting the former is madness, as is trusting the latter without a reproducible build.

https://reproducible-builds.org/docs/embedded-signatures/

But attestation can mean a lot of things and isn't inherently in conflict with free software. For example, at my company we validate that laptops follow our corporate policy, which includes a default-deny app installation policy. Free software would only, in theory, need a digital signature so that we could add that to our allowlist.

Presumably (hopefully) these are corporate-owned devices, with a policy like that. Remote attestation is fine if it's controlled by the device's owner, and you can certainly run free software on such a device, if that particular build of the software has been "blessed" by the corporation. However, the user doesn't get the freedoms which are supposed to come with free software; in particular, they can't build and run a modified version without first obtaining someone else's approval. At the very least it suggests a certain lack of respect for your employees to lock down the tools they are required to use for their job to this extent.

In the case of client attestation, this is how we get "Let Google/Apple/Microsoft handle that, and use what they produce."

And as a end state, leads to a world where large, for-profit companies provide the only whitelisted solutions, because they're the largest user bases and offer a turn-key feature, and the market doesn't want to do addition custom work to support alternatives.

My vanilla LineageOS install fails but I can root with Magisk, enable Zygisk to inject code into Android, edit build properties, add SafetyNet fix and now my device is good to go?

It's crazy to think the workaround is "enable arbitrary code injection" (Zygisk)

Currently, you'd have to do find an unlocked phone, hope there is a downloadable factory image, re-flash, re-lock, re-install to run whatever needs attestation. Potentially using something like Android's DSU feature, this could all be a click or two, and you could be back running Lineage with a restart.

The hole in this reasoning is that you don't need the app; you can just sign into the bank's website from the mobile browser, and get all the same functionality you'd get from the app. (Maybe you don't get a few things, like mobile check deposits, since they just don't build features like that into websites for the most part.) The experience will sometimes be worse than that of the app, but you can still do all the potentially-dangerous things without it. So why bother locking down the app when the web browser can do all the same things?

> I’d be a bit pissed if Netflix took my money but didn’t run where I wanted it

I actually canceled my HBO Max account when, during the HBO Now -> HBO Max transition, they somehow broke playback on Linux desktop browsers. When I wrote in to support, they claimed it was never supported, so they weren't obligated to care. I canceled on the spot.

Secure attestation about device state requires something akin to Secure Boot (with a TPM), and in the context of a BYOD environment precludes the device owner having full control of their own hardware. Obviously this is not an issue if the organization only permits access to its services from devices it owns, but no organization should have that level of control over devices owned by employees, vendors, customers, or anyone else who requires access to the organization's services.

It seems like the sensible rule of thumb is: If your organization needs that level of control, it's on your organization to provide the device.

Suppose the course I've been studying for the past three years now uses $VideoService, but $VideoService uses remote attestation and gates the videos behind a retinal scan, ten distinct fingerprints, the last year's GPS history and the entire contents of my hard drive?¹ If I could spoof the traffic to $VideoService, I could get the video anyway, but every request is signed by the secure enclave. (I can't get the video off somebody else, because it uses the webcam to identify when a camera-like object is pointed at the screen. They can't bypass that, because of the remote attestation.)

If I don't have ten fingers, and I'm required to scan ten fingerprints to continue, and I can't send fake data because my computer has betrayed me, what recourse is there?

¹: exaggeration; no real-world company has quite these requirements, to my knowledge

1) The requirements themselves. These are different for consumer vs employee type scenarios. So general, I'd prefer we err on the side of DRM free for things like media, but there are legitimate concerns around things like data privacy when you are an employee of an organization handling sensitive data.

2) Presuming there are legitimate reasons to have strong validation of the user and untampered software, we have the choice of A) using only organization supplied hardware in those case or B) using your own with some kind of restriction. I'd much prefer to use my own as much as possible ... if I can be ensured that it won't spy on me, or limit what I can do, for the non-organization specific purposes I've explicitly opted-in to enable.

> I'm uncomfortable letting organisations have control over the software that runs on my hardware.

I'm not, if we can sandbox. I'm fine with organizations running javascript in my browser for instance. Or running mobile apps that can access certain data with explicit permissions (like granting access to my photos so that I can share them in-app). I think we can do better with both more granular permissions, better UX, and cryptographic guarantees to both the user and the organization that both the computation and data is operating at the agreed level.

I use LineageOS on my phone, and do not have Google Play Services installed. The phone only meaningfully interacts with a very few and most basic Google services, like an HTTP server for captive portal detection on Wifi networks, an NTP server for setting the clock, etc. All other "high-level" services that I am aware of, like Mail, Calendaring, Contacts, Phone, Instant Messaging, etc., are either provided by other parties that I feel more comfortable with, or that I actually host myself.

Now let's assume that I would want or have to do online/mobile banking on my phone - that will generally only work with the proprietary app my bank provides me with. Even if I choose to install their unmodified APK, (any lack of) SafetyNet will not attest my LineageOS-powered phone as "kosher" (or "safe and secure", or "healthy", or whatever Google prefers calling it these days), and might refuse to work. As a consequence, I'm effectively unable to interact via the remote service provided by my bank, because they believe they've got to protect me from the OS/firmware build that I personally chose to use.

Sure, "just access their website via the browser, and do your banking on their website instead!", you might say, and you'd be right for now. But with remote attestation broadly available, what prevents anyone from also using that for the browser app on my phone, esp. since browser security is deemed so critical these days? I happen to use Firefox from F-Droid, and I doubt any hypothetical future SafetyNet attestation routine will have it pass with the same flying colors that Google's own Chrome from the Play Store would. I'm also certain that "Honest c0l0's Own Build of Firefox for Android" wouldn't get the SafetyNet seal of approval either, and with that I'd be effectively shut off from interacting with my bank account from my mobile phone altogether. The only option I'd have is to revert back to a "trusted", "healthy" phone with a manufacturer-provided bootloader, firmware image, and the mandatory selection of factory-installed, non-removable crapware that I am never going to use and/or (personally) trust that's probably exfiltrating my personal data to some unknown third parties, sanctified by some few hundreds of pages of EULA and "Privacy" Policy.

With app stores on all mainstream and commercially successful desktop OSes, the recent Windows 11 "security and safety"-related "advances" Microsoft introduced by (as of today, apparently still mildly) requiring TPM support, and supplying manufacturers with "secure enclave"-style add-on chips of their own design ("Pluton", see https://www.techradar.com/news/microsofts-new-security-chip-...), I can see this happening to desktop computing as well. Then I can probably still compile all the software I want on my admittedly fringe GNU/Linux system (or let the Debian project compile it for me), but it won't matter much - because any interaction with the "real" part of the world online that isn't made by and for software freedom enthusiasts/zealots will refuse to interact with the non-allowlisted software builds on my machine.

It's going to be the future NoTCPA et al. used to combat in the early 00s, and I really do dread it.

Yes, but for government software this is a bog-standard approach. Not even "the source code is publicly viewable to everyone" is sufficient scrutiny to pass government security muster; specific code is what gets cleared, and modifications to that code must also be cleared.

I hold the reverse view. The only security token I'd trust is the only thing that isn't open is the private keys the device generates when you press the reset button. The rest meaning from the CPU up (say RISC-V) and the firmware must be open to inspection by anybody. In fact, it should also be easy to peel away the silicon protection so you can see everything bar the cells storing the private keys. The other non-negotiable is the thing that computes and transmits the "measures" of the system being attested to (including it’s own firmware) can not be changed - meaning no stinking "security" patches are allowed at that level. If it's found broken, throw it away as the attestation is useless.

The attestation then becomes the device you hold is faithful rendering / compiling of open source design document X by open source compiler Y. And I can prove that myself, by doing building X using Y and verifying the end result looks like the device I hold. This process is also known as reproducible builds.

What we have now (eg, YubiKeys) is not that. Therefore I have to trust Yubi Corp. To see what that's a problem, see the title of this story. It has the words "Zero-Trust" in it.

In reality of course there is no such thing as "Zero-Trust". I will never be able to verify everything myself, ergo I have to trust something. The point is there is a world of difference between trusting an opaque black box like Yubi Corp, and trusting an open source reproducible build, where a cast of random thousands can crawl over it and say, "it seems OK to me". In reality it's not the ones that say "it seems OK" you are trusting. You are trusting the mass media (places like this in other words), to pick up and amplify the one voice among millions that says "I've found a bug - and because it's open I can prove it" so everyone hears it.

So to me it looks to be the reverse of what you say. Remote attestation won't kill software freedom. Remote attestation, done in a way that we can trust, must be built using open source. Anything less simply won’t work.

Which will continue marching forward without pro-user legislation. Which is extraordinarly unlikely to happen since the government has vested interest in this development.

Luckily, it's a dwindling power and Europe fights and penalizes large organizations breaching market "morals".

If you want to use free software, only commect to Affero GPL servces and don't use nonfree services, and don't consume nonfree content.

This depends on how far down the rabbit hole you want to go, if it was secureboot, only signed processes can run, would that make you feel better ? If it doesn't.. what would ?

Valve has taken a less heavy-handed approach and let users have more freedom over their client and UI, but they also have a massive bot problem in titles like TF2.

I can’t connect to my work network from a random client, and it will throw flags and eventually block me if I connect with an out-of-date OS version.

I can’t present any piece of paper with my banking data and a signature on it and expect other parties to accept it. I have to present it on an authorized document.

I guess money may be the common denominator here.

No, it isn't. It's a way for corporations and governments to restrict what people can do with their devices. That makes sense if you're an employee of the corporation or the government, since organizations can reasonably expect to restrict what their employees can do with devices they use for work, and I would be fine with using a separate device for my work than for my personal computing (in fact that's what I do now). But many scenarios are not like that: for example, me connecting with my bank's website. It's not reasonable or realistic to expect that to be limited to a limited set of pre-approved software.

The correct way to deal with untrusted software on the client is to just...not trust the software on the client. Which means you need to verify the user by some means that does not require trusting the software on the client. That is perfectly in line with the "zero trust" model advocated by this memo.

Everything you said cannot be further from the truth.

I'd also hope that businesses care about more than 80% of attacks, preferably they should care about 100% of attacks. Hence, pre-approved software restrictions.

there are specific contexts where you want to distribute information as widely as possible, and in those contexts it makes sense to allow any software versions to access the information. but for contexts where security is important, that means verifying the client software isn't compromised.

A remote system asked to promise it's what it says it is: the illusion of security.

Jailbreaking, DRM, etc are all evidence of this illusion.

I worked at a place that only allowed "verified" software before and it's an ongoing battle to keep that list updated. Things like digital signatures can be pretty reliable but if you're version pinning you can make it extremely difficult to quickly adopt patched versions when a vulnerability comes out.

They even call out the fact that it's a proven bad practice that leads to weaker passwords - and such policies must be gone from government systems in 1 year from publication of the memo. It's delightful.

(Graphical keyboards are an old technique to try to defeat key loggers. A frequent side effect of a site using a graphical keyboard is that the developer has to make the password input field un-editable directly, which prevents password managers from working, unless you use a user script to make the field editable again.)

But maybe they didn't bother giving much more effort to better passwords because they really don't want those to stick around at all and good for them. Password managers themselves are a bandaid on the fundamentally bad practice of using a symmetric factor for authentication.

> Verifiers SHOULD NOT impose other composition rules (mixtures of different character types, for example) on memorized secrets

Earliest draft in Wayback Machine, dated June 2016. Lots of other good stuff from 800-63 dates back this early too.

https://web.archive.org/web/20160624033024/https://pages.nis...

[1]: https://github.com/usnistgov/800-63-3/pull/576

The former usually means something between nothing at all and “you can do it but you have to write paperwork that no one will actually read in detail, but someone will maybe check the existence of, if you do”.

The latter means “do it and you are noncompliant”.

See also https://datatracker.ietf.org/doc/html/rfc6919

The essential purpose of my comment was only to correct my parent on the date.

By the time we implement any of these things, if ever, they certainly won't be. I work on military networks and applications, and it's hard for me to believe that I'll see any of this within my career at the pace we move. This is the land of web applications that only work with Internet Explorer, ActiveX, Siverlight, Flash, and Java Applets, plus servers running Linux 2.6 or Windows Server 2012.

The idea of "Just-in-Time" access control where "a user is granted access to a resource only while she needs it, and that access is revoked when she is done" is terrifying when it takes weeks or months to get action on support tickets that I submit (where the action is simple, and I tee it up with a detailed description of whatever I need done).

I too have no faith of seeing this stuff implemented anytime soon...

[1] (Authority to Operate, basically approval from the highest IT authorities to utilize something on a DoD network)

To be clear, I don’t have a better solution. But all the second factor stuff is fundamentally broke when you are likely to need access to the service most.

I don't want the consular officials to be unable to authenticate me in a foreign country because I lost my phone, or for my bank to be unable to release funds because I don't have their card or my Security Key, but I feel 100% OK with losing access to Gmail or Hacker News, or whatever for say a few days until I can secure replacement credentials.

As for lost luggage, I carry mine on my keychain, another one in the laptop itself (USB-C Yubikey) and one in my safe at home - if all three are ever destroyed or lost I also have backup codes available as password protected notes on several devices.

Banks aren't going to want to implement any changes that cost more (in system changes and customer support) than the fraud they prevent.

edit: The source of my claim that governments tend to extend surveillance is pretty well documented I believe. So much so that I believe it is worthy to insert the problem into debates about anything relating to security. Because security often serves as the raison d'être for such ambitions.

It's even worse with texted codes because it's inherently credible in the moment because the message knows something you feel it shouldn't --- that you just got a 2FA code. You have to deeply understand how authentication systems work to catch why the message is suspicious.

You can't fix the problem with user education, because interacting with your application is almost always less than 1% of the mental energy your users spend doing their job, and they're simply not going to pay attention.

The issue with TOTP is that it’s usually not rate limited. Just sit there guessing codes and you’ll eventually get in.

Ordinary users think the fact your phishing site accepted their TOTP code is actually reassuring. After all, if you were a fake site, how would you have known that was the correct TOTP code? So this must be the real site.

The only benefit TOTP has over passwords is that an attacker needs to use it immediately, but they can fully automate that process so this only very slightly raises the barrier to entry, a smart but bored teenager can definitely do it, or just anybody who can Google for the tools.

Worse, TOTP involves a shared secret, so bad guys can steal it without you knowing. They probably won't steal it from your bank because the bank has at least some attempt at security, but a lot of other businesses you deal with aren't making much effort, and so your TOTP secret (not just the temporal codes) can be stolen, whereupon all users of that site relying on TOTP are 100% screwed.

Notice that WebAuthn still isn't damaged if you steal the auth data, Google could literally publish the WebAuthn authentication details (public key and identifier) for their employees on a site or paint them on a huge mural or something and not even make a material difference to their security - which is why this Memo says to do WebAuthn.

https://blog.trezor.io/why-you-should-never-use-google-authe...

Edit - sorry that this is really an ad for the writer's products. On the other hand, there's a hell of a bounty for proving them insecure / untrustworthy, whatever your feelings on "the other crypto".

If someone just put a fake domain that proxies everything between you and the server (with fake domain with HTTPS... which he social engineered you to get on)

Looks like FIDO2 2FA only sign the challenge response against the server certificate available locally (= the phishing domain) so just passing it to the original server will fail. Also, the attacker can't just re-sign the challenge response after you, because the challenge was sent from the original server already encrypted with the public key of the user (stored from the registration phase). So only the registered user can see the challenge and respond to it.

This leaves only 2 options to do a phishing attack: 1) Get a valid certificate for the original domain [1] 2) force downgrade the user to old TOTP [2]

[1] https://security.stackexchange.com/q/157756/69837

[2] https://eprint.iacr.org/2020/1298.pdf

SMS are bad due to MITM and SIM cloning. In EU many banks still use smsTAN, and it leads to lots of security breaches. It's frustrating some don't offer any alternatives.

However, is FIDO2 better than chipTAN or similar? I like simple airgapped 2FAs, but I'm not an expert.

When you use WebAuthn to sign into an site the browser takes responsibility for determining which site you're on, cutting out the whole phishing problem of "Humans don't know which site it is". The browser isn't reading that GIF that says "Real Bank Secure Login" at the top of the page or the title "Real Bank - Authenticate" or the part of the URL bar that says "/cgi-bin/login/secure/realbank/" it is looking only at the hostname it just verified for TLS which says fakebank.example

So the browser tells your FIDO authenticator OK, we're signing in to fakebank.example - and that's never going to successfully steal your Real Bank credentials because the correct name is cryptographically necessary for the credentials to work. This is so effective crooks aren't likely to even bother attacking it.

The reason this was so "easy" for Google (and some other companies, like GitLab[1]) to realize most of these goals is that they are a web-based technology company - fundamentally the tooling and scalable systems needed to get started were web so the transition were "free". Meaning, most of the internal apps were HTTP apps, built on internal systems, and the initial investment was just to make an existing proxied internal service, external and behind a context aware proxy [1].

The hard part for most other companies (and the DoD) is figuring out what to do with protocols and workflows that aren't http or otherwise proxyable.

[1] https://cloud.google.com/iap/docs/cloud-iap-context-aware-ac...

[2] https://about.gitlab.com/blog/2019/10/02/zero-trust-at-gitla...

This is a windfall for Gov't contractors.

Pre-Zero-Trust days seemed safer. Copying production data to a laptop wasn't allowed. Instead, each SRE had their own Linux VM in the data center, accessible from home and able to run the scripts (with connectivity to the enterprise application). This prevented a whole class of realistic attacks in which a laptop (while unlocked/decrypted) is taken by an adversary. Admittedly, in return, we're protected from a possible, but less likely, attack in which a Linux VM is compromised and used for lateral movement within one segment of the enterprise network. (An enrolled device has to be in the user's possession; it can't be any machine, Linux or Windows, in the data center or office.)

The only people who love this are our enterprise application vendors. Our bosses are paying them a TON more money to implement new requirements where, in theory, all possible types of data analysis can be done directly within the enterprise application. No more scripts, no more copying of data. No more use of Open Source. And, of course, people from these same enterprise application vendors advise the government that Zero Trust must be a top priority mandate.

Nobody cares. It just gets postponed forever.

If FedRAMP qualification is tied to IPv6 support, you'll see every major contractor and cloud provider support it promptly.

If you look at the recent updates for cloud providers - AWS and GCP support for IPv6, Kubernetes going dual stack by default - you can see that this memo had a substantial impact.

Sometimes these things take time, but in this case, the recent memo you link to lit a fire under everyone.

Azure is so far behind on this it's silly.

I think in 2019 I was able to use IPv6 VNETs.

Btw - I'd love to see the people who put this memo together re-evaluate the ID.me system they're implementing for citizens given how poor the identity verification is.

ID.me supports WebAuthn (or maybe U2F? In this context it doesn't matter) but importantly it does identity verification so it can determine whether I am a US citizen, whether I'm a tax payer, and if so which one.

Now, perhaps the US Federal Government should own the capability to do that instead of a private company. But, so far as I can tell, they do not and login.gov is not such a thing.

https://www.theverge.com/2022/1/26/22903437/id-me-facial-rec...

Login.gov also supports WebAuthn.

TOTP is a great security enhancement, and while phishable, considerably raises the bar for an attacker.

The fact that TOTP is mentioned as a bad practice in this document is an indicator that this should not be considered a general best practices guide. It is a valid best practice guide for a particular use case and particular user base.

This can be solved with DANE, which is based on DNSSEC. When properly configured, the sending mailserver will force the use of STARTTLS with a trusted certificate. The STARTTLS+DANE combination has been a mandatory standard for governmental organizations in the Netherlands since 2016.

https://stats.dnssec-tools.org/images/domains.svg

It's deployed on many more domains than MTA-STS.

Finally! Maybe the places I've worked will finally listen. But I stopped reading TFA to praise this, so back to TFA.

Just one example where I work is a prohibition against emailing certain types of documents or data to others in the company (which is mostly Word & Excel docs) Which seems reasonable, but the accepted solution is to use the built in encryption of MS Office to secure the file with a password and then email the file. And then send the password in another email. Honestly, that's supposed to be the protocol. The policy also hasn't been amended in any way to account for implementing Google docs & sheets, which can be accessed with the same credentials used for email or opened on any unattended employee's machine if they left a Gmail tab open (along with anything else in their Google drive). And regardless of any of these rules, almost no one follows them. I do-- I have to, I'm a data custodian so I can't violate the rules, but it annoys people.

0: trade only works if the sum of your trust in the legal system, intermediates, and counterparts reaches some threshold. The same is true of any interaction where the payoff is not immediate and assured, from taxes to marriage and friendship, and, no, it is not possible to eliminate it, nor would that be a society you’d want to live in. The only systems that do not rely on some trust that the other person isn’t going to kill them are maximum-security prisons and the US president’s security bubble. Both are asymmetric and still require trust in some people, just not all.

When we talk about trust we often mean different things:

* In cryptography and security by "trust" we mean a party or subsystems that if they fail or are compromised then the system may experience a failure. I need to trust that my local city is not putting lead in the drinking water. If someone could design plumping that removed lead from water and cost the same to install as regular pipes than cities should install those pipes to reduce the costs of a trust failure.

* In other settings when we talk about trust we are often talking about trust-worthiness. My local city is trustworthy so I can drink the tap water without fear of lead poisoning.

As a society we should both increase trustworthiness and reduce trust assumptions. Doing both of these will increase societal trust. I trust my city isn't putting lead in the drinking water because they are trustworthy but also because some independent agency tests the drinking water for lead. To build societal trust, verify.

I know tech operates on different definitions/circumstances here. That’s why the word ”zero” is so wrong here, because it seems to go out of its way to make the claim that less trust ks always better.

Call it “zero misplaced trust” or “my database doesn’t want your lolly”, whatever.

People extend your exact trust assertions to their networks, and bad actors exploit it to effect a compromise. A corporate network cannot be like your home. Zero Trust says that you should assume anything, and anyone, can be exploited - so secure appropriately.

Per your analogy, what would you do if your invited houseguests, unbeknownst even to themselves, wore a camera for reconnaissance by a 3rd party? What would you do if these cameras were so easy to hide that anyone, at any time, might be wearing one and you couldn't know?

You would have to assume that anyone that entered your home had a camera on them. You would give them no more access than the bare minimum needed to do whatever they were there to do (whether eat dinner or fix your sink). You'd identify them, track their movement, and keep records.

Your term, "Zero misplaced trust," assumes that you can identify where to place trust. Did you trust that system you had validated and scanned for 5 years...until Log4shell was discovered? Did you trust the 20-year veteran researcher before they plugged in a USB without knowing their kid borrowed it and infected it?

Zero Trust is a response to the failure of "trust but verify."

100% agreed. My first thought upon seeing the title of the article was "and we trust that you did read it?"

The term "zero trust" certainly has a very dystopian connotation to me. It reminds me of things like 1984.

Words matter. If nothing else, laypersons hear these terms and shape their understanding assuming based on what it sounds like.

> “discontinue support for protocols that register phone numbers for SMS or voice calls, supply one-time codes, or receive push notifications."

... necessarily means TOTP.

Could be argued "supply" means code-over-the-wire, so all 3 being things with a threat of MITM or interception: SMS, calls, "supply" of codes, or push. Taken that way, all three fail the "something I have" check. So arguably one could take "supply one-time codes" to rule out both what HSBC does, but also what Apple does pushing a one-time code displayed together with a map to a different device (but sometimes the same device).

I'd argue TOTP is more akin to an open soft hardware token, as after initial delivery it works entirely offline, and passes the "something I have" check.

TOTP apps are certainly better than getting codes via SMS, but they're still susceptible to phishing. The normal attack there is that the attacker (who has already figured out your password) signs into your bank account, gets the MFA prompt, and then sends an SMS to the victim, saying something like "Hello, this is a security check from Your Super Secure Bank. Please respond with the current code from your Authenticator app." Then they get the code and enter it on their side, and are logged into your bank account. Sure, many people will not fall for this, but some people will, and that minority still makes this attack worthwhile.

A hardware security token isn't vulnerable to this sort of attack.

I'd expect it to be any mechanism that doesn't do mutual authentication. In other words the authentication not only proves to the service your "you", it also proves to you the service is the one you think you are authenticating to. And it does that reliably even in the face of a MITM attack.

It's damned hard to do, and obviously none of SMS, TOTP and passwords do it. https + passwords was supposed to do it and technically does do it, but in practice no one looks at the domain name. Email + DKIM could do it, but no email client shows you outcome of DKIM auth and again no one would look at that anyway.

WebAuthn / FIDO2 does do it. It's undoubtedly the best option right now, but until tokens that open source + reproducible build right down to the metal, they aren't "Zero-Trust". You are forced to trust Yubi or Google or whatever as the tokens they give you are effectively black boxes. Worse, because an open source token means "easily build-able many companies" and thus means "WebAuthn tokens become a commodity", I expect Yubi to fight it to their dying breath.

Or push, or other supply of a code from somewhere. It's just oddly worded, sounding like the code in all 3 cases is coming over the wire.

Granted, phishing is a diff story, but in practice, I see Yubikeys permanently inserted to their laptop hosts, requiring even less intervention.

"This project is proof-of-concept and a research platform. It is NOT meant for a daily usage. The cryptography implementations are not resistent against side-channel attacks."

A bunch of situations aren't going to end up with a separate physical authenticator anyway, they'll do WebAuthn, which in principle could be a Yubico Security Key or any of a dozen competitor products - but actually it's the contractor's iPhone, which can do the exact same trick. Or maybe it's a Pixel, or whatever the high-end Samsung phone is today.

That's what standardisation gets us. If CoolPhone Co. build a phone that actually uses a retina scan to unlock, they can do WebAuthn and deliver that security to your systems without you even touching your software. And yes, in the Hollywood movie version the tricky part is the synthetic eyeball so as to trick the retina scanner, but in the real world the problem is after you steal the ambassador's CoolPhone she can't play Wordle and she reports the problem to IT before you can conduct your break-in, synthetic eyeball or not.

The various auth apps are problematic because they usually come with some kind of requirement for intune or similar to do remote attestation. That's a weird place for the government to be with contractors, since a lot of those contacts don't have language requiring that contractors have a phone at all, much less that they allow the federal government to MDM it.

It could be providers other than yubico, but it won't be.

Encrypted messaging has been a complete failure; there is no need to single out email. I suspect the reason is more or less the same in all cases. Users have not been provided with a conceptual framework that would allow them to use the tools in a reasonable way. If the US federal government can come up with, and promote such a framework the world would become a different place.

BTW, the linked article is mostly based on misconceptions:

* https://articles.59.ca/doku.php?id=pgpfan:tpp

Can you elaborate on why you see it this way? WhatsApp has been wildly successful, my very non-technical in-laws use Signal for their family's conversations, and other messaging platforms are jumping on the bandwagon.

As far as I can tell, if we lose encrypted messaging at this point, it will be due to government action or corporate rug-pulling, not because it failed to catch on. Whereas encrypted email really hasn't caught on anywhere.

You only get effective end to end encryption if you can verify that you are talking to who you think you are talking to. Otherwise the people that are running the system can cause your messages to take an unencrypted detour and thus be able to read them. This is often called a man in the middle attack. Verifying identities normally means checking some sort of long identity number. Very few people know how to do that in an effective way.

For example: in a usability study involving Signal[1], 21 out of 28 computer science students failed to establish and maintain a secure end to end encrypted connection. The usability of end to end encrypted messaging is a serious issue. We should not kid ourselves into thinking it is a solved issue.

PGP in a sense is actually better here in that it forces the user to comprehend the existence of a key in a way where it is intuitively obvious that it is important to know where that key came from.

[1] https://www.ndss-symposium.org/wp-content/uploads/2018/03/09...

The Signal study showed that the majority of people were unable to understand Signal's security features, but not that the security model is broken. The question at hand isn't how many people are using it wrong but how many people are using it right that never could have managed to do so with PGP keys. If even 10% of Signal's users successfully maintain a secure channel, you're looking at around 5 million people, most of whom probably would not have been able to set up secure messaging without Signal.

Do we still have work to do? Of course! But that doesn't mean that we've failed in our efforts so far.

[1] https://www.usenix.org/legacy/events/sec99/full_papers/whitt...

[1] https://people.eecs.berkeley.edu/~tygar/papers/Why_Johnny_Ca...

Its simple amazing.

Oh, and if you choose to not participate in this system, enjoy trying to find out the results of your covid test :-) (I ended up getting a Buypass card, but they officially support only Windows and macOS.)

First, in the days before mobile bank-id, they sent windows-only hardware as I recall. Then came the days of letters/cards/hardware getting lost in the mail.

I gave up on it in the end. I have multiple things (banking-wise) I no longer have online access to because of it.

If you're going to make one system to rule them all you need to make sure the logistics actually work.

It's a very frustrating situation. Worst of both worlds.

[0]https://www.tsa.gov/real-id

1) No verification that the user trusts that particular bank to perform this service. Most banks just deployed BankID for all their customers.

2) No verification between bank and government ensuring that particular person can be represented by particular bank. In principle a bank could inpersonate a person even if that person have no legal relation with that bank.

3) Bank authentication is generally bad. Either login+SMS, or proprietary smartphone applications. No FIDO U2F or any token based systems.

Fortunately, there are also alternatives for identification to government services:

1) Government ID card with smartcard chip. But not everyone has a new version of ID card (old version does not have chip). It also requires separate hardware (smartcard reader) and some software middleware.

2) MojeID service (mojeid.cz) that uses FIDO U2F token.

Disclaimer: working for CZ.NIC org that also offers MojeID service.

Ad #3: FIDO is basically unusable for banking. It's designed for user authentication, not transaction signatures which banks need (and must do because of the PSD2 regulation).