I have a Samsung Galaxy S6 with device encryption enabled. I unlock my device with a secure password upon booting it, and then use a fingerprint afterwards. When I first enabled encryption (Lollipop), my device would ask for a decryption password as soon as it began booting. Since upgrading to Marshmallow, the phone boots up completely, but will not accept a fingerprint to unlock the device until the password is entered once.

The secure startup settings allow me to choose to require a password before boot (like it was previously), or not to require the password until the device has booted (the default now). The description on the settings page states:

In addition to using your fingerprint to unlock your device, you can further protect the device by requiring a password be entered before the device starts up. This helps protect data on lost or stolen devices.

What is the difference, from a security standpoint, between the two options?

I at first assumed that data at rest would be encrypted the same for both options, but the description seems to indicate that a pre-boot password increases security. Since the setting is easily switched back and forth I assume no underlaying changes are occuring to the device encryption when the setting is changed, but something must be changing if security is improved.

The fact the phone can fully boot without my password seems to indicate the data on the phone is actually decrypted without my password, and the password is merely protecting my fingerprints and access to the phone. In this case, how is the device encryption functioning as anything other than a lock screen if the phone is lost while powered on?

1 Answer 1


If the phone boots up without asking for a password, it is most likely not protected by encryption in the way you would expect.

In theory, it might not be encrypted at all. But as you note, that's not plausible if you can change between the two options on the fly. More likely, it is encrypted with a default password, meaning that anyone accessing the phone's storage outside the normal UI login procedure (e.g. by flashing a custom encryption-aware recovery like TWRP or via ADB) can access your data. Your password is then only used to provide entry to the user interface – not protecting you from outside access to the phone's storage.

If you need to enter your password for bootup, it is that password that is (hopefully) used for encryption, meaning that outside attacks should only be possible by cracking your password (provided that Samsung's custom implementation is cryptographically sound). You can check that encryption is active by trying to mount your data partition in TWRP.

It is surprising that Samsung doesn't clarify the fundamental difference between the two options. But then, Google themselves are possibly even more careless in Android's default implementation as indicated in this blog post.

The author states that on enabling accessibility services, all you get is a cryptic message that "your device won't use your lock screen to enhance data encryption" before the encryption password is reset to the default password – effectively disabling encryption for all practical purposes and giving anyone with a bit of technical understanding full access to your data. The Android encryption documentation seems quite proud about the default password encryption being "resilient against off-box attacks", but attackers will likely not care as long as they can access your data "on-box", ie. with the storage installed in your phone.

Whether Samsung's implementation uses Android's default behaviour described above or a proprietary way of switching between encryption passwords, it is quite likely that only one of the two options provides any meaningful protection that goes beyond using a password on a non-encrypted phone.

  • Thank you for your reply, the blog post you linked was very helpful. It seems that by choosing to only require a password after the device is booted, the device encryption key is changed to a default password which is common knowledge, providing good security against off-box protection but terrible on-box protection. I was also not aware of the implications of enabling accessibility access to apps, as described in the blog post. Nov 17, 2016 at 18:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .