GrapheneOS – Break Free from Google and Apple
blog.tomaszdunia.pl951 points by to3k 11 hours ago
951 points by to3k 11 hours ago
Been using this for about a year on a p9 pro. It works very well. I hear the google tap to pay does not work, but I've never tried it. However Vipps with their tap to pay works fine. BankID works but not with biometric login, which some things require IIRC. And for some reason DnB private works fine, but you are not allowed in on the corp app.
It's mind boggingly stupid that they lock down apps like this, when you can just open the thing in a website anyway. I can use my bank on some linux distro, crazy that they trust me since it is not Windows - the truly secure OS!
Knew about those things before I started, so all in all I'm pretty happy. I'd recommend NOT using different users for different things (I started with banking etc in one profile, that ended up being a huge PITA and according to their docs it is mostly security theater anyway). Happy tinkering!
A collegue of mine was tech lead at a large online bank. For the mobile app, the first and foremost threat that security auditors would find was "The app runs on a rooted phone!!!". Security theater at its finest, checkboxes gotta be checked. The irony is that the devs were using rooted phones for QA and debugging.
Meanwhile, it's probably A-OK for the app to run on a phone that hasn't received security updates for 5 years.
I don't get it. If they're worried about liability, why not check the security patch level and refuse to run on phones that aren't up to date?
I'm guessing it's because there are a lot of phones floating around that aren't updated (probably far more than are rooted), and they're willing to pretend to be secure when it impacts a small number of users but not willing to pretend to be secure when it impacts many users.
> If they're worried about liability, why not check the security patch level and refuse to run on phones that aren't up to date?
Google doesn't provide an API or data set to figure out what the current security patch level is for any particular device. Officially, OEMs can now be 4 months out-of-date, and user updates lag behind that.
Your guess is good, but misses the point. Banks are worried about a couple things with mobile clients: credential stealing and application spoofing. As a consequence, the banks want to ensure that the thing connecting to their client API is an unmodified first-party application. The only way to accomplish this with any sort of confidence is to use hardware attestation, which requires a secure chain-of-trust from the hardware TEE/TPM, to the bootloader, to the system OS, and finally to your application.
So you need a way for security people working for banks to feel confident that it's the bank's code which is operating on the user's behalf to do things like transfer money. They care less about exploits for unsupported devices, and it's inconvenient to users if they can't make payments from their five-year-old device.
And this is why Web Environment Integrity and friends should never be allowed to exist, because Android is the perfect cautionary tale of what banks will do with trusted-computing features: which is, the laziest possible thing that technically works, and keeps their support phone lines open.
There's definitely some way of telling, Enterprises can block sign in with no recent updates in Microsoft authenticator or whatever app they use.
All good points. Thanks for that!
I'm not an Android developer, but I was thinking they could use something like the android.os.Build.VERSION.SECURITY_PATCH call to get the security patch level. Maybe that's not sufficient for that purpose, though.
Sure, there is enough information available to the app to determine what OS version and patch level it is running under. The issue is, the app would need to communicate this to the bank via an API, and the bank wants to trust the app in the first place in order to rely on this information.
Even then, two things turn out to be true:
- Banks don't actually want to put in the effort and deal with angry customers with slightly-out-of-date devices.
- All the credential-stealing malware on Android works perfectly fine on stock, unmodified, non-rooted OS images anyway. They just need to socially-engineer the user to grant accessibility permissions to the malicious app.
ive seen: -"but ios can be jailbroken and it doesnt have an AV!" while the MDM does not allow jailbroken devices, and they also allowed sudo on linux.
auditors are clueless parasites as far as im concerned. the whole thing is always a charade where the compliance team, who barely knows any better tries to lie to yhe auditor, and the auditor pick random items they dont understand anyway. waste of time, money and humans.
at best it's "cover your ass security" so when you do get pwned you can say you went through an "accrediting auditor" - blah blah blah.
Agreed on everything you said. Just wish there was a more efficient way to do things :/
As long as copying some numbers, printed on a piece of plastic, into an online order form is all the authentication that is needed for a transaction, anything more than that is inherently security theater.
That’s why for most transactions I do with a credit card in my country, you need an extra validation with the mobile app. It is mostly American websites that do not enable this functionality.
Yes, because we don't want these stupid locked down apps. Credit cards give buyers many protections, it's very easy to dispute an illegitimate transaction.
Yeah that's the first thing a pentest will complain about, had the same problem too. I pushed back enough so that it's trivial to bypass but the bank and pentesters also agreed with me that it's security theater or else I would never had the chance.
I always ask them if they have root/admin on their computer. Then follow up playing dumb with "shouldn't we lock out PCs too?". Watching them stammer is worth the 30 second aside.
> Then follow up playing dumb with "shouldn't we lock out PCs too?".
Unfortunately, some banks do, for various functionality; there are many things you can do via bank apps and not typically via their website.
Locking down PCs is easy: just set a random password.
Just blow the right hardware fuses and secure boot will be forced with a key that doesn't (or can't) exist.
Who do we lobby to get this removed from the auditors checklists? This is a solvable problem but it’s political. And if we don’t solve it personal computing is at risk.
Start by calling (or visiting the area office of) your senator and congressman. If you are reasonably articulate, they engage and listen. Doesn't matter if the listener is not a techie; they will ask questions around policy and why it affects constituents.
This is 1000x more useful than online petitions or other passive stuff. Politicians know that one person to have taken the effort to do this, means 1000 others are feeling the same thing but are quiet.
Oh how I fucking wish "security" wasn't a stupid cargo cult checkbox list 3/4 of the times.
Unfortunately, the rot runs too deep.
Your password must be between 8 and 12 characters, and must have lowercase, uppercase, numbers, and punctuation.
Pick up the can!
My favorite is when it must have punctuation, but certain punctuation is silently banned, so I have to keep refreshing my password generator until it gives me an acceptable combination.
I came across a "special character" requirement while creating an account. The client validation was not the same as the server validation. The client proceeded as if my account was created, but it never was. The client functioned without an account until it was closed. I asked the creator what their app's problem was, why did I need to keep resetting my password, then be told that I don't have an account, and have to create it anew.
They would not believe I was creating an account and using the device, because their own logging was so terrible.
I had to send them a screen recording from me using this abomination, and only then was I told "you're using the wrong special characters". They helpfully gave me some examples of allowed special characters, which then would pass the server validation.
I wish they would have gotten rid of the account requirement, as the device and client software seemed to work fine without them.
Somewhat unrelated, is there any technical reason certain punctuation might be banned? I can understand maybe not allowing letters with diacritics or other NON-ASCII chars but why would a system reject an @ sign or bracket > for example?
Depending on the protocol they can be url encoded or even helpfully html encoded; the same password can be used over different protocols. It's the best to not use punctuation by default (length supplies more entropy than charset), I add -0 at the end to make dumb password policies happy.
Often, the same ones with limited punctuation also have length limits, so maximizing the character options is the only way to maximize entropy.
A lot of the restricted stuff is cargo-cult fear of symbols that could be used in SQL-injection or XSS attacks.
A properly-coded system wouldn't care, but the people who write the rules have read old OWASP documents and in there they saw these symbols were somehow involved in big scary hacks that they didn't understand. So it's easier to ban them.
Having more than just alphanumeric characters widens the domain of the password hash function, and this directly increases the difficulty of brute-force cracking. But having a such a small maximum password length is... puzzling, to say the least. I would accept passwords of up to 1 KiB in length.
With rainbow tables, even 11-character simple passwords like 'password123' can be trivially cracked, and as the number of password leaks show, not everyone is great at managing secrets and credentials.
It's easier for me to remember really long passphrases than even short alphanumeric strings - small maximum password lengths set my teeth on edge. The passwords should be getting hashed anyway right?
The problem is that you never really know what a website operator does with your credentials. Ideally, you have both a unique email and a unique password for each site, because sadly credential stuffing [1] is a thing.
I bet the rationale would be "anything over 12 characters will be too hard to remember and people will just write down the password."
But it's a maximum. It prevents people that want to use passphrases from doing so.
I think we (whoever we is) should start normalizing the concept of passphrases; on sign-up screens they should show the benefits of a passphrase. I'm surprised that Googles PW generator does not use passphrases, and I don't know about ios because I haven't tried theirs yet.
I started using passphrases after I saw this xkcd https://xkcd.com/936/
When I'm trying to log into something on a device that has a terrible keyboard, like a TV or giant touchscreen, it's a lot easier to type words I know than gibberish.
Until the late 2010s, the AD account password at my financial institution employer was capped at 12 characters because, for a subset of workers, AD creds were sync'ed to a mainframe application that could only support that many characters.
I recommend all my friends and family to use a password manager like Bitwarden, and if they can't do that for some reason, at least use a 3-word passphrase separated by a hyphen.
The amount of times people have complained to me that this doesn't work because of low max-chars on passwords is insane.
One time I had to reset my password with the power company - they had such a system, and the lady had to read me something like:
Uh4zB4DP55WD!
Apparently I was a bit salty with the system when I set it.
The fact that she shouldn't have even been able to look up the password in the first place due to hashing was lost on her.
That's pretty funny on a few levels, not in the least that they required a "secure" password like that but stored them in plain text.
I regularly conduct transactions at the branch of my local bank wherein they ask me for no credentials whatsoever. I also once forgot to bring my account number with me and the teller said "no worries, I'll look it up for you." Kind of horrifying.