Skip to main content

Google Made Android 7 Encryption Passwords Easier To Brute-Force

TWRP custom recovery project lead developer Ethan "Dees Troy" Yonker discovered that Android 7 stores a file that shows information about how encryption passwords are composed. This file could make it easier for someone to brute-force their way into phones running the mobile operating system, code named Nougat.

Yonker found a “device_policies.xml” file in the /data/system/ folder that reveals encryption password information such as:

<active-password quality="131072" length="4" uppercase="0" lowercase="0" letters="0" numeric="4" symbols="0" nonletter="4" />

This means someone who has your phone and is trying to unlock it by brute-forcing its encryption password could do it significantly faster now. The attackers would not only be able to configure their password cracking tool to avoid searching for uppercase letters and symbols, for example, but they’d also know not to bother searching for shorter or longer passwords than necessary. Thus, the process could be less time-consuming and more precise.

Android 7’s More Vulnerable File-Based Encryption

Google introduced file-based encryption in Android 7, arguably for little benefit. The company said file-based encryption is necessary to help alarms survive a random phone reset or to let some apps display information even when a device is locked. However, when Google introduced this change, I expressed skepticism about it because it could allow for new ways to unlock a device and bypass its encryption thanks to new security vulnerabilities.

It seems that we may now be seeing the first kind of these vulnerabilities, and more may appear in the future. According to Yonker, the password information can be accessed on devices that use the password-less file-based encryption. However, if the old-style full disk encryption was used, this information would only be available after the password has already been entered.

According to pseudonymous security expert The Grugq, both of Android’s encryption methods are weaker than what you can find on iOS, because all of the phone's data is unlocked even if you use full disk encryption. On iOS, the accessible data is more limited even after the phone is unlocked.

Latest iOS Version Also Vulnerable To Fast Password Cracking

However, the latest version of iOS also made it much easier to brute-force its passwords for encrypted backup data when it switched to a new password verification mechanism. Apple promised a fix once the revelation was made public by Elcomsoft, a mobile forensics tool company.

It’s unclear whether the problem in Android 7 was a simple blunder on Google’s part or if there's another reason for it. However, there are probably few good reasons for storing information about the encryption password's composition in the OS. We’ve contacted Google for an explanation and we’ll update this post when we get a reply.

  • tom10167
    The apple thing is wildly overblown, going from ten million years to 1 million years is still in the unbreakable range. Knowing the exact parameters like in androids issue is a crippling blow.
    Reply
  • LinuxUser7634
    Sure, that would work..if they already have access to you phone while unlocked and can read that file.
    Reply
  • nutjob2
    Having restrictive rules for passwords like maximum length is idiotic, making them machine readable is beyond idiotic.
    Reply
  • none12345
    Hrm at first i was like wtf, they are storing the signature of your password.

    But, i dont think thats what this is, it looks more like a 4 didget pin number rule for something. Just going by the file name, taht would suggest its a ruleset for seomthing, not a user signature. And if thats the case, then everyone already knew it was a numerica 4 didget pin number.

    If it is a signature of your password tho, thats quite bad.
    Reply
  • tigerwild
    None12345, I think you missed the point. Sure a signature would allow anyone to use a rainbow table to immediately look up your password, but the real issue is THERE IS NO REASON to ever store the fundamental structure of the password or its hash value in an unencrypted mannor. Doing so shows that someone has intentionally left it there to make brute forcing the password orders of magnitude easier and thus faster.
    Reply