Well, I ordered my first iphone last week.
if I have a choice between a walled garden with ads and a walled garden without, the outcome us easy to guess.
Android may soon restrict on-device ADB
491–500 of 536 posts
Re: Android may soon restrict on-device ADB
#492Earlier quoted context omitted.
They're better in some ways. They don't rely on a secret with low entropy which is really brute forceable. They can't be used on a phishing site because the URL is part of the secret. Even when you authenticate to a fake site you don't give them the ability to authenticate as you until you change the secret (like you do when you give them your password) They also have 2fa built in. No need for a separate app, enterin…
That's why I mentioned "and also enabling authorised access to that same resource". Passkeys are great at preventing unauthorized access. But that comes at the expense of preventing authorised access. For example, using another device or even moving to another device. Replacing a stolen or damaged device is also nearly impossible with a reasonable quantity of Passkeys.
Well that's why they can sync between devices. I don't really see the problem.
Even if you don't like to rely on big tech (google/apple), I don't either, there are many options now for full FOSS implementations like bitwarden and KeepassXC.
If you use a yubikey as a passkey then yes, that's not a great option also because most services don't allow you to enroll more than one passkey. But with bitwarden that doesn't matter.
Re: Android may soon restrict on-device ADB
#493Earlier quoted context omitted.
Exactly. At work I now have to MFA and type a random code every time I want to book a desk. It kills the session after 30 minutes. It's ridiculous. If an attacker ever got hold of it, they could... book a desk at that shitty office for me. Whoopty doo what horror. The same with logging my hours in a different system. I only use those systems for those things, nothing else. Security is important for things that actual…
One insider threat actor might book a previously unbugged desk, bug it with multi-antenna keystroke logger (making and breaking resistive connections across parasitic capacitance nodes, changes the direction dependent EM scattering function). One can correlate acoustic key press detection with changes in scattering, unsupervised. Fixed desks are way more secure than promiscuous desk multiplexing.
An insider threat actor can just do that without booking the desk. They just go in on a quiet day and sit down, nobody checks whether a desk is booked unless they themselves need to sit there.
Re: Android may soon restrict on-device ADB
#494Earlier quoted context omitted.
Yes but the balance has shifted a lot. I remember working at a major company where important systems had an admin password of " 123". That was stupid. I asked to change it but the answer was no because too many people would have to be told the new password. That was too much in favour of convenience and I'm surprised they never got pwned in the worst way. These days the balance has swung way too much in favour of sec…
Given cyber attacks are more rampant than ever, it’s hard to argue that security has gone too far the other way.
Shifting the balance towards security doesn't always improve the overall security stance. What you get is people getting sick of all the stupid hurdles and working around it. Using shadow IT. I find myself doing that too. For example, I was at a highly secured facility one time as a vendor to do a software upgrade. Blocked USB ports, severely reduced internet access etc. So I couldn't do the upgrade, I wasn't even allowed near the server. Nor could I connect my laptop to their network. All sensible precautions but how do I then upgrade the server software?
So what happened? Someone from IT came and said: "Oh yeah that always happens, just give me a USB stick and I'll stick it in the server". Which he did, no virus checking etc. This is the problem with processes that are too strict. They leave out usecases (often under a misguided "80/20 pareto" rule) and then people will figure out their workaround in unpredictable ways which you have no control over.
And most of the big hacks now are because of the move to cloud SaaS, especially salesforce instances are constantly being hit. Simply applying RBAC rules would fix that and not even interfere with anyone's job because the idea of RBAC is making sure that everyone can do just what they need to do their job and nothing more. But nothing LESS either. And of course some monitoring. If a local callcenter agent suddenly starts accessing 10.000 accounts per day instead of 20 a day, then yeah really you should be on the ball.
Re: Android may soon restrict on-device ADB
#495Earlier quoted context omitted.
Given cyber attacks are more rampant than ever, it’s hard to argue that security has gone too far the other way.
Shifting the balance towards security doesn't always improve the overall security stance. What you get is people getting sick of all the stupid hurdles and working around it. Using shadow IT. I find myself doing that too. For example, I was at a highly secured facility one time as a vendor to do a software upgrade. Blocked USB ports, severely reduced internet access etc. So I couldn't do the upgrade, I wasn't even al…
> Shifting the balance towards security doesn't always improve the overall security stance.
What youre complaining about isn’t security. It’s security theatre. Which is bullshit
> What you get is people getting sick of all the stupid hurdles and working around it. Using shadow IT. I find myself doing that too.
Unfortunately it’s people like yourself who implement shadow IT that end up forcing security and infra teams to add those annoying bureaucratic hurdles to force people in line.
But you do raise a point that I’ve often argued: good security needs to make it easy for people to do the right thing.
Unfortunately that takes a lot of time, effort, and investment to get right.
> And most of the big hacks now are because of the move to cloud SaaS, especially salesforce instances are constantly being hit.
lol no. That’s not even the tip of the iceberg.
> Simply applying RBAC rules would fix that and not even interfere with anyone's job because the idea of RBAC is making sure that everyone can do just what they need to do their job and nothing more.
Salesforce already has RBAC.
Also RBAC doesn’t prevent you from being hacked. It just limits the blast radius of what is exposed when you do get hacked. It also makes it harder for those who “know enough to be dangerous” to do the wrong thing. Like the shadow IT shenanigans you’ve admitted to.
Re: Android may soon restrict on-device ADB
#496Earlier quoted context omitted.
My wife's insurance provider requires SMS 2FA, which is incredibly annoying for this reason - there's no way for me to submit my massage (or w/e) benefits even though my wife hates dealing with insurance admin and I have the login info and am authorized to do so - I have to wait until my wife is home and then get her to read off an SMS code for me.
But that's the thing: SMS can be auto-forwarded without that much effort. Definitely without rooting your phone. I don't recall if there is any built-in functionality for this, or at what granularity, but in the past I had a Tasker profile specifically meant to forward very specific SMS 2FA codes. Now try that with a bank/vendor app. Or any other communication app. Nowadays, many don't even put the message body into…
Yes, proprietary app-based authentication is the worst possible authentication scheme, but thankfully I don't need to use any services that insist on that.
Re: Android may soon restrict on-device ADB
#497Earlier quoted context omitted.
Because you know, the actual solution would be to have more granularity in authentication process than "allow whole device to attach to ADB", but that would be like, difficult... so they're not going to so that. Right now any app on my PC connected to ADB could manipulate my phone then, and that's somehow not a CVE?
Is it a CVE that an app running on my PC could actually be running under GDB? It's the entire purpose of these tools.
Mind you, I'm not arguing for the CVE, just complaining that the current thinking is very selective.
Re: Android may soon restrict on-device ADB
#498Earlier quoted context omitted.
Allowing strangers to run adb commands on your phone without your consent is about as bad as a compromise can get. Your keyboard can be replaced with a keylogger and all of your data can be stolen without your knowledge by simply connecting to the wrong wifi network.
I agree with user TeMPOraL in his comment. Those who aren't trapped in tunnel-vision, know the app permissions themselves have ALOT of access to all data on your device and users give the apps these permissions. Should we say that every app is a CVE? The real reason any Google dev wants ADB gone is to close open source and lock down the OS to Google sign-ins and a proxy proprietary closed source eco-system. ADB is th…
> So the argument "this app can bypass OS security through ADB and is therefore a CVE" is not valid
That's not the argument. What gave you the impression that this is what the CVE was about? I'm really confused.
The CVE is "Your android device allows any hacker on your wifi to install/remove apps on your device and steal your private information, unauthenticated"
Re: Android may soon restrict on-device ADB
#499Haven’t used Android in forever but…Isn’t ADB the only way to do real backups?
Re: Android may soon restrict on-device ADB
#500Earlier quoted context omitted.
That's why I mentioned "and also enabling authorised access to that same resource". Passkeys are great at preventing unauthorized access. But that comes at the expense of preventing authorised access. For example, using another device or even moving to another device. Replacing a stolen or damaged device is also nearly impossible with a reasonable quantity of Passkeys.
Well that's why they can sync between devices. I don't really see the problem. Even if you don't like to rely on big tech (google/apple), I don't either, there are many options now for full FOSS implementations like bitwarden and KeepassXC. If you use a yubikey as a passkey then yes, that's not a great option also because most services don't allow you to enroll more than one passkey. But with bitwarden that doesn't m…
KeepassXC now supports Passkeys? All right then, I accept that argument. I do use Keepass and compatible programs.