Few important security things that should be done to FP

To keep it brief:

  1. One should be able to enable “scramble keypad”. There are numerous easy attacks to pick up the PIN typed in the phone by watching the fingerprints/markings on the screen, if you get access to the phone at some point. Scrambling the keypad would disable this attack mode completely. Its is normal to have this keypad scramble option in all major Android phones today.

  2. One should be able to prevent access to shortcuts/pulldown menu completely when phone is locked. Now the only option is to remove items from there to prevent someone tampering with them (like putting the stolen phone to airplane mode to prevent its tracking etc. or enabling NFC to use wallet etc.). I know the attacked can just remove the battery to shutdown the phone, but the attacker might not know that.

  3. PIN should be able to be asked when powering down the device. I know the attacked can just remove the battery to shutdown the phone, but the attacked might not know that.

  4. SD card arrached to the phone should be encrypted or atleast allowed to be encrypted. Now they are not. This is a major issue in security perspective.

  5. Hopefully at some point one could add additional security in terms of atleast critical things or applications in the phone: Require BOTH fingerprint & pincode to complete the required security critical action. This would make it much more harder for attacked to bypass protections by for example shouldersurfing your PIN or forcing you to use your fingerprint. Similiar to Apples stolen device protection updates have done.

3 Likes

Concur on all points, albeit with tweaks (also brief):

  1. Scramble keypad: Also restore the letters (2/ABC, 3/DEF, etc), as some people memorise phrases rather than (long) strings of digits.

  2. Disable shortcuts/pulldown when locked: Agree, but things like the Torch (light) having rapid PIN-free access must be possible (if desired/configured).

  3. PIN to powerdown: Concur, but requiring PIN(/fingerprint) should be optional. And not just powerdown, but also for reboot (restart).

  4. Encrypted SDcard; YES, please! Especially if, as an example, you have a Linux system and hence can handle LUKSv2 encryption, thus preserving SDCard transportability.

  5. Other… no comment.

Items 1 and (especially) 4, scrambled keypad and (especially) encrypted transportable SDcard, are my main wants from this list.

My own 2 cents worth:

  1. Keypads are 3rd party apps (Google in this case), so you’re free to pick a better one…
  2. Agree.
  3. I don’t agree, for the reason you mentioned yourself. Besides, stolen phones are never powered down, because if you do that you will be asked the SIM code and the screen lock code. It’s easier to hack the phone while it is running, and after that it’s yours. As a result, the only one annoyed by a shutdown PIN would be the legitimate owner…
  4. Agree-ish. The issue here is that you have configured the SD card in “sharing” mode, which means it should be readable in another device, which obviously precludes encryption… SD cards configured as memory extensions are indeed encrypted.
  5. I don’t see the point. First of all if somebody is forcing you to unlock it, no amount of passwords and checks will help (if you want to preserve your “physical integrity”)… Also, hacking a phone is done via software, the various PINs, passwords and fingerprints are just mild deterrents, mostly to keep off the nosy spouse/office colleague. In real life they just lower the resell value of the stolen phone, since you’d have to factor in the cost of jailbreaking it.

“Sharing” does not preclude encryption. The problem (I presume) is other devices/systems have different encryption mechanisms. Except… that presumes I want to share with something I don’t know.

In my case, I know EXACTLY what I will be sharing the SDcard with: My Linux system (which can probably be generalised to any modern Linux system). As such, the encryption I want is (ultimately) LUKSv2. I concur, that is probably useless on Windows, and possibly also on MacOS and at least some other Android devices. But that uselessness for things I do not care about is not a reason to deny encryption to everyone… The current situation is lowest-common-denominator thinking, that is, anything “more” is “useless” because someone may be unable to use it.

Another way to look at it is, last I checked, the SDcard had to be (V?)FAT(32?), which again is lowest-common-denominator, but again a horrible choice for both Android and Linux, and very probably also a bad choice for MacOS… it’s ancient insecure inefficient M$-Windows/DOS junk. If you “need” to use some-FAT, well… Ok. But not everyone “needs” to use it, and some do not want to use it.

In addition, of course I may have (and indeed I did try this a long time ago), “configured” the SDcard on another system (Linux). My FP3 (Android 11 at the time) insisted on reformatting the SDcard, which is simply horseshite.

they mean the lockscreen PIN keypad, which can’t be changed with an app.

3 Likes

Let’s agree to disagree.
Encryption standards are all different and incompatible: BitLocker, LUKS, FileVault (to only quote the OS-tied ones), they are all incompatible, and for most tied to a specific OS.
(LUKS is kind of an exception, but most people will be using BitLocker anyway: Android can’t start encrypting stuff, knowing all Windows users out there won’t be able to access their files!)

And then there is the issue of the passkeys: You won’t give some acquaintance/colleague your private encryption keys just so he can watch some funny cat video…
The opposite of security is convenience. Serious disk encryption (not the kind used to hide your pr0n collection from your parents/spouse…) is an encryption you don’t share the passkeys with world & dog, which as a result means the encryption is not shared. Sharing files yes, sharing encryption no. :man_shrugging:

In your case (your phone and your computer) obviously the sensible choice would be to configure the SD card as internal memory extension (so it gets encrypted by Android), and simply transfer your files from one to the other using USB/Bluetooth/WiFi/Something. Unfortunately configuring the SD card as internal memory extension creates problems (with the FP4). :man_shrugging:
.

As about using exFAT for SD cards and USB sticks above a given size), this is actually the sensible choice. Full disk file systems have a huge overhead (versioning, indexing, and all that), which you wouldn’t want or need on those small capacity disks.
Horses for courses, using ext4 for an SD card would make as much sense as using UDF for your computer disks… :laughing:

Besides, SD cards need a special formatting tools, because of over-provisioning, wear leveling and other specific requirements. Using the standard OS formatting tools is bad for those supports, SD cards should not be be (re)formatted without special tools.
The SD Association is offering a free SD card format tool (Win/Apple) on their website: SD Memory Card Formatter for Windows/Mac | SD Association (Yes, no Linux version…)

:face_with_open_eyes_and_hand_over_mouth: I stand corrected.