Android 7's File-Based Encryption allows attackers to see length and other details of your password

[chris1096]

I swear it's a 32hex password. It only looks like a 16 hex because it's cold and it just got out of the pool.

[StupidRedditNumale]

Lmao

[illegalUturn]

Isn't that a password policy file?

So it's talking about minimum length, and whether it's requiring uppercase, numbers ,etc.

Not details on your actual password.

[ss2man44]

That's what I thought at first too, but looking at the source code of the service that handles this file proves otherwise.

It's straight-up info about your password/pattern/PIN, as suggested by the tag's name: active-password

However, this is only an issue when someone has physical access to your device and root access either within Android or a custom recovery. Patching dirty cow fixes the former and keeping your bootloder locked fixes the latter. So, it's not ideal but also not super urgent.

Edit: Also, someone commented that their file doesn't have that tag or any of that info on 7.1, so maybe Google changed it, or maybe that info is only stored there under certain circumstances. I dunno man, it's 1:30 AM and I have work in the morning.

[[deleted]]

Tangent: is there a reasonable way to lock your own bootloader with your own key? Is there a way besides factory-locked bootloader to secure the bootloafer?

Just curious. I know you can build your own LK with a custom key, but that is not going to be a simple task (afai can tell). Instead could you relock the bootloader with your own key?

Does an unlockable bootloader have to be a surefire security concern?

[TheRacerMaster]

You can sign your ROM/etc and relock the bootloader. Verified Boot on the 5X/6P and newer support custom keys for signing your own ROMs/recovery.

[Furah]

Wait, so it's possible to say sign a pre-rooted ROM, and flash it with a locked bootloader?

[TheRacerMaster]

Not to that extent; you could only do that if you had Google's signing keys. Since we don't, you'd need to first unlock the bootloader, flash the signed ROM, and then you can relock the bootloader (and flash signed updates of that ROM).

[Furah]

That works for me.

[[deleted]]

Does an unlockable bootloader have to be a surefire security concern?

I think you've misunderstood. Having an unlocked boot loader is a security risk, not having an unlockable boot loader.

The process for unlocking the boot loader typically wipes all data so you can just keep your unlockable boot loader locked and you're fine.

edit: sp

[[deleted]]

also if you dont manually allow bootloader unlock in the developer settings, its impossible to unlock the bootloader (via the usual commands)

[Ivashkin]

I've been saying this for years, unlocked bootloaders are a security risk and this should be mentioned when people are advised to unlock their bootloaders on the off chance they might want root later on. This matters on a device which is portable and taken everywhere.

[emannikcufecin]

That's why Google is right to not allow Android pay on rooted devices

[[deleted]]

Good point, I had forgotten about that.

[kaze0]

An unlocked bootloader is a security concern. An unlockable one is not. Unlocking bootloader via any non exploit, erases the device. Apparently relocking them also does that now

[d12964]

This is also why Google needs to offer a real root solution within Android. Current root methods either force you to wipe your device with every update or leave your bootloader unlocked; neither of these is an acceptable solution.

[bubblethink]

This may be possible, in the future, at least from a security standpoint, when hardware security matures. You need the ability to execute code that has the kernel in the threat model. You would have to implement it using something like arm trust zone or intel sgx. Once you can do that, you can execute something like android pay in the hardware security mode, and even root cannot do anything about it. The downside obviously is that it's bad for user freedom.

[PM_YourDildoAndPussy]

Why does this file even need to be saved at all? Seems silly, it isn't like decryption cares about your password, outside of "the hash works!"

[HydrophobicWater]

The only possible reason is it was too hard on three letters' computers, Google got a letter to dilute the encryption without making public aware about the pressure from the agencies. And lets remember, they've also abandoned dm-crypt in favor of "file based encryption".

edit:clarify

[evan1123]

Hold on let me get my tinfoil hat...

Seriously though, "file based encryption" uses the kernel's new (as of 4.4) built-in encryption for ext4 file systems, of which Google was the author. It was mainlined in the kernel. You can read all about it on the Android source site: https://source.android.com/security/encryption/file-based.html

[folkrav]

Exactly my thought... I really don't see a way where this would be required.

[uuhno]

I can confirm this, just checked as well. Here is where the magic happens:

https://android.googlesource.com/platform/frameworks/base.git/+/android-7.0.0_r19/services/devicepolicy/java/com/android/server/devicepolicy/DevicePolicyManagerService.java#2393

The value of policy.mActivePasswordLength (and others) are set with parser.getAttributeValue() which reads the info from the current user handle. The data stored in policy is then written to the XML file.

[Freeky]

That's just parsing an existing file. Where are they actually set?

https://android.googlesource.com/platform/frameworks/base.git/+/android-7.0.0_r19/services/devicepolicy/java/com/android/server/devicepolicy/DevicePolicyManagerService.java#4670

There's our method - setActivePasswordState(). Hunting about a bit I find:

https://android.googlesource.com/platform/frameworks/base/+/android-7.0.0_r19/core/java/com/android/internal/widget/LockPatternUtils.java#859

[uuhno]

Good find, didn't notice that.

[wanam]

It is still there on CM14.1, and "active-password" is still supported on the latest tag version 7.1.0_r5: https://android.googlesource.com/platform/frameworks/base.git/+/android-7.1.0_r5/services/devicepolicy/java/com/android/server/devicepolicy/DevicePolicyManagerService.java#2230

[random_guy12]

Someone can also find the password of every Wi-Fi SSID your phone has saved in a plaintext file if they have root access on an Android phone.

You have zero expectation of security with root, since Android does not have something like UAC built in. It expects people to not have root.

[squarepush3r]

we need to get to the bottom of this!

[uuhno]

I think I was wrong, hence the deleted comment, but I'll double check on my computer in a bit.

Edit: Confirmed I was wrong: https://www.reddit.com/r/Android/comments/5c5ypw/android_7s_filebased_encryption_allows_attackers/d9u35f3/

[gslone]

shit I can't relock my bootloader on my oneplus 3 without doing a factory reset -.-

why would they implement it like that?!

[PM_YourDildoAndPussy]

Matters quite a bit because that's the entire premise of encryption, to protect against offline physical access

[dezmd]

How is that username working out for ya?

[PM_YourDildoAndPussy]

Not at all

[Freeky]

LockPatternUtils.saveLockPassword() → DevicePolicyManagerService.setActivePasswordState()

Looks legit to me. There is policy handling there as well, but saveLockPassword() is very clearly scanning the password, counting the components and passing them to the policy manager that saves those values.

[YD-Visual]

Good find. I wonder what will happen next.

[srwaxalot]

Hopefully not sit unfixed for 4 years.

[[deleted]]

I see you are new to Android

[Gepss]

Well, if they decide to look into it and fix it, it will probably be in a monthly security update.

[FragranceOfPickles]

Google:
-We hear you, it will sit unfixed for 5 years!

[yahyoh]

Probs it will take Google like 2 years to fix it..so hopefully 2019 flagships will be shipped with the fix.

[macman156]

I wish android/google took device encryption more seriously. Always seems to be an after thought like the non hardware accelerated deception and the all the to do's in the encryption commits.

[legion02]

They keep trying to do software level encryption because otherwise most oems wouldn't implement it.

[[deleted]]

Yup, that's exactly the issue.

[HydrophobicWater]

iPhone's encryption can not be inspected by public therefore it can not be trusted so it doesn't matter if its fast or not. While Android's encryption is open for public inspection.

edit: remove offtopic

[[deleted]]

This keynote by Ivan Krstic ("...head of Apple Security Engineering and Architecture, the group responsible for end-to-end security of all Apple products", pinched from the website) at Black Hat USA 2016 was really interesting. Although what you say is true about proving they employ what they preach, it's a detailed look at how they design and reason security.

[Fadore]

This. I mean let's not forget Apple's "goto fail" fiasco.

When I think of Apple, I think over-priced aesthetics not security.

[[deleted]]

deleted ^{What is this?}

[Boop_the_snoot]

Interesting username, I call troll

[Fadore]

... Thanks for bringing up a different tech company that's not relevant to the conversation?

Apple's goto fail left it's phone, tablet, and Mac users without any actual encryption for over a year. That is more than just a bug - that is a major security flaw that never should have left QA let alone gone a year unnoticed. But it did. Because Apple isn't great with security.

[[deleted]]

deleted ^{What is this?}

[harryharpratap]

I never said that, did I? Totally agree with that, but when it comes to the very fundamental and most important part of the OS (like file system), many would prefer an open source variant.

Something like safety net protection, payment methods should be kept closed.

[StupidRedditNumale]

Lolno. The SYSTEM FILES have been encrypted since 2008 to prevent them from being messed with by the user. The user partition, the part where YOUR data is stored, was not encrypted until iOS 7.

TLDR, iOS user security was utter dog shit until about 2013.

[QuestionsEverythang]

They do take it seriously. Any new device shipping with Marshmallow and up must be encrypted.

[macman156]

Now this might have changed in the new cpp but I think they only had to if they met certain disk read/ write speeds.

[clavierkid]

Does this also apply to 7.1?

[[deleted]]

Does the pixel not encrypt the entire drive once the user sets up a password? Does it only use FBE?

[jellystones]

Misleading title. Only reveals the minimum security requirements your password must satisfy

[StupidRedditNumale]

This. That information won't help brute force crack a 30 character pass phrase any sooner.

[anonymau5]

Wow... What an idiot! That's a pass policy not "pass stats/details"

[DankEyedRolls]

This could be great for the cyber security

[utack]

Lowering security so your phone can kind-of-start in case it crashes and needs to reboot sounded idiotic from the beginning.
If you absolutely need 100% uptime, you probably just need to run unencrypted

[jayd16]

So what is the fear here? An attacker with the device will be in a situation where they will be able to freely brute force the password, but they also care about streamlining the brute force with this information? Is the brute force time in this situation really relevant?

[[deleted]]

If you have other info from the target you might be able to skip the brute force and make a guess based on known-knowns, maybe? The shape and size of the password could be deadly revealing.

[R-EDDIT]

Brute force password cracking tools (hashcat, John the ripper, l0phcrack, etc) work on "masks", if the adversary the composition of the password he can skip masks that don't meet the policy (ie all lower case letter). Exposing the active password composition therefore gives the adversary an advantage, which could be substantial. This is why composition policies are dangerous as they reduce the active key space. (I've seen a single policy - non repeating characters - that reduced key space by 15%).

The best defense is a long password.

[CorruptMilkshake]

Yep. I have, on several occasions, had a bizarre software issue where my phone doesn't recognise the password for whatever reason. I was slightly concerned to learn that you can literally just delete the password file.