Most active commenters
  • themacguffinman(8)
  • dathinab(7)
  • Dylan16807(3)

←back to thread

656 points EthanHeilman | 29 comments | | HN request time: 1.106s | source | bottom
Show context
staticassertion ◴[] No.30102061[source]
This is pretty incredible. These aren't just good practices, they're the fairly bleeding edge best practices.

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.

replies(15): >>30103088 #>>30103131 #>>30103846 #>>30104022 #>>30104121 #>>30104716 #>>30104840 #>>30105344 #>>30106941 #>>30107798 #>>30108481 #>>30108567 #>>30108916 #>>30111757 #>>30112413 #
c0l0 ◴[] No.30104121[source]
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.

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.

replies(16): >>30104148 #>>30104166 #>>30104241 #>>30104603 #>>30105136 #>>30106352 #>>30106792 #>>30107048 #>>30107250 #>>30107515 #>>30108070 #>>30108409 #>>30108716 #>>30108754 #>>30109550 #>>30123243 #
tablespoon ◴[] No.30105136[source]
>> 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.

> 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.

replies(3): >>30106237 #>>30107608 #>>30113041 #
shbooms ◴[] No.30106237[source]
I think from the viewpoint of a business/enterprise environment, yes you're right, context-aware authorization is a good thing.

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.

replies(5): >>30106924 #>>30109468 #>>30109782 #>>30109940 #>>30116202 #
1. btbuilder ◴[] No.30106924[source]
I think browser-based streaming is the only scenario impacted. Apps can already interrogate their platform and make play/no play decisions.

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.

replies(2): >>30107126 #>>30109211 #
2. dathinab ◴[] No.30107126[source]
Well, the fact that I can't do credit card payments for some banks if I don't have an iphone or non rooted, google android phone is a problem which already exists.

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.

replies(3): >>30107589 #>>30108288 #>>30109271 #
3. ryukafalz ◴[] No.30107589[source]
This should be obvious from your comment but I think it's worth calling something out explicitly here: a bank that does that is mandating that you accept either Apple's or Google's terms of service. That's a lot of power to give to two huge companies.

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

replies(3): >>30110127 #>>30113234 #>>30115822 #
4. pishpash ◴[] No.30108288[source]
It does seem like a privilege escalation in the reverse direction, allowing banks to escalate a decision about security into one about devices. They should not have that power, and it's far from the only solution.
5. 0xedd ◴[] No.30109211[source]
Cars come with AndroidAuto (and whatever is for iOS). Only apps signed by Google can communicate with AndroidAuto. I don't want to use a Google phone or app to display OSM on my car's media screen. Why is this legal?
replies(1): >>30109637 #
6. themacguffinman ◴[] No.30109271[source]
> but attackers which pulled of a privilege escalation tend to have enough ways to make sure that non of this detection finds them

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.

replies(3): >>30112794 #>>30118449 #>>30118786 #
7. chipotle_coyote ◴[] No.30109637[source]
Once you're talking about interactive information displays in cars that can be accessed while the vehicle is in motion, traffic and highway safety regulations start cropping up. When you ask "Why is this legal," try rephrasing it to, "Why is it legal for companies to make it so difficult to play Doom on my BMW's touch screen," and you will probably arrive at the answer.
replies(1): >>30112597 #
8. lotsofpulp ◴[] No.30110127{3}[source]
That is a job for the government. They should have made electronic payments and electronic accounts for everyone a utility many years ago.
replies(1): >>30112781 #
9. HPsquared ◴[] No.30112597{3}[source]
Also, "why is it illegal to sell cars that can play Doom while driving"
10. franga2000 ◴[] No.30112781{4}[source]
This 10000x! A bank account is sure as hell more of a utility than a landline!

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).

11. Dylan16807 ◴[] No.30112794{3}[source]
That might at least be half a reasonable argument if they didn't all allow desktop logins that could be stuffed with malware.

> 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.

replies(1): >>30119819 #
12. floatboth ◴[] No.30113234{3}[source]
What bank doesn't have a regular web app?
replies(2): >>30113527 #>>30114794 #
13. duckmysick ◴[] No.30113527{4}[source]
In the future banks may start accepting connections only from a handful of approved browsers. Similarly to how 4k steaming on Netflix is not available on all browsers.
14. dathinab ◴[] No.30114794{4}[source]
It's about the EU mandated 2FA auth for online shopping.

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.

15. jgerrish ◴[] No.30115822{3}[source]

  I think we'd do well to provide the option to use open protocols when possible.
Of course, the PR copy just writes itself, doesn't it? AD administrators, Apple and Google, banks and everyone else can benefit from context aware authorization.

If the state of your phone is stolen or "compromised", you want immediate Peace of Mind.

Even if it's just misplaced, having that kind of flexibility is just great.

16. dathinab ◴[] No.30118449{3}[source]
> privilege escalation in the first place.

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

replies(1): >>30119847 #
17. dathinab ◴[] No.30118786{3}[source]
As a side note the attack scenario you describe works without needing any rooting or anything it already exists and isn't detected by their security mechanism.

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).

replies(1): >>30119921 #
18. themacguffinman ◴[] No.30119819{4}[source]
In practice, many credit unions/banks will only support recent versions of major desktop browsers (ie. the big three: Chrome, Firefox, Safari) which are known to mandate a good level of security. These browsers will usually have their own OS requirements. For eg Safari is tied to macOS versions directly while Chrome will drop support for older unmaintained operating systems like Windows XP.

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.

replies(1): >>30120681 #
19. themacguffinman ◴[] No.30119847{4}[source]
You're right, many secure apps don't go far enough in blocking Android releases that are probably too old & vulnerable. Not all apps are perfect, but blocking rooted and ancient devices is a start.
replies(1): >>30121754 #
20. themacguffinman ◴[] No.30119921{4}[source]
> As a side note the attack scenario you describe works without needing any rooting or anything it already exists and isn't detected by their security mechanism.

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"?

replies(1): >>30121694 #
21. Dylan16807 ◴[] No.30120681{5}[source]
So require I have an up to date browser on my phone. Don't require that I haven't rooted it when every desktop is in an equivalent security state. That's not enough to be "unusually vulnerable".

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.

replies(1): >>30124187 #
22. dathinab ◴[] No.30121694{5}[source]
> installations by default

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.

replies(1): >>30124291 #
23. dathinab ◴[] No.30121754{5}[source]
No, it's starting at the wrong end and not in any relevant way provide an improvement.

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).

replies(1): >>30124441 #
24. themacguffinman ◴[] No.30124187{6}[source]
So what if the desktop is in a worse state? Mobile is still a common threat surface that supports stronger security measures. Unusual is relative, mobile is much more secure by default. It makes no sense to weaken the security posture for mobile users just because the desktop/web doesn't allow a stronger one.

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.

replies(1): >>30124364 #
25. themacguffinman ◴[] No.30124291{6}[source]
Only on Android is it so simple to sideload, and even then there are lower level app capabilities that require root even for sideloaded apps.

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.

26. Dylan16807 ◴[] No.30124364{7}[source]
> It makes no sense to weaken the security posture for mobile users just because the desktop/web doesn't allow a stronger one.

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.

27. themacguffinman ◴[] No.30124441{6}[source]
> There is nothing inherently less secure about an rooted device.

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.

replies(1): >>30125896 #
28. dathinab ◴[] No.30125896{7}[source]
You having root access doesn't any arbitrary application on your phone has root access. So no. It is not inherently less secure.

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.

replies(1): >>30142684 #
29. themacguffinman ◴[] No.30142684{8}[source]
For the last time, yes it is inherently less secure. You gain root access by disabling/weakening the OS' built-in protections against root access.

> 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.