Chromebook Asking for Old Password

Question

Immediately after updating my chromebook to the latest dev version (Version 59.0.3071.25 dev), it has the normal sign-in prompt on boot, but once I enter my password and second factor (Yubikey), it then asks for the "old password for my Chromebook". I have not changed my Google password since 2012 (checked this on https://myaccount.google.com/security), and obviously that's the only password I've ever used to log into this Chromebook. I tried every other password I've used that wasn't with a password manager, and I've tried my actual Google password dozens of times, and tried them all even with caps lock both on and off.

Interestingly, it seems as though Google security thinks that I'm signing in from a Google Chromebook Pixel (2015) (edit: I'm not on a Chromebook Pixel, I'm on an HP Chromebook 13 G1); when I go to https://myaccount.google.com/device-activity, it mentions the Pixel as being last used last night, which was the last time I tried to sign in with my regular account; I can try again today to confirm, but I'm almost positive this is me and not someone with my account.

Other potentially-relevant info: I'm in developer mode, and I can access my chroot, I can access my Google account (from Guest mode).

I suspect this is a bug on the ChromeOS end, but if there's some way to just mount my home directory manually, I can save all my data on an external drive and wipe it and access my account normally again.

Answer 1

Sorry I have no complete solution for you, only a suggestion for a workaround at the end and some things I found out while poking around.

I was looking for how to mount the encrypted.block file I found but I can't find details except this bug report. There are no details about the encrypted storage in disk-format either but it looks like a very similar question has been asked before in Mount encrypted ChromeOS partition in Chrubuntu. I ran file on the encrypted.block file after mounting the stateful partition, but it just said data on my GalliumOS install. It looks like the encrypted storage on the stateful partition just uses ecryptfs in a particular way that I haven't seen before (though I do use ecryptfs for more than just per user encrypted home directories). It could also be possible that TPM is used to decrypt the partition, which would make sense, but I'm not sure about that.

Here are the important parts from mount with ecryptfs_sig and ecryptfs_fnek_sig edited:

/dev/mmcblk0p1 on /mnt/stateful_partition type ext4 (rw,nosuid,nodev,noexec,relatime,seclabel,commit=600,data=ordered)
/dev/mmcblk0p1 on /home type ext4 (rw,nosuid,nodev,noexec,relatime,seclabel,commit=600,data=ordered)
/dev/mapper/encstateful on /mnt/stateful_partition/encrypted type ext4 (rw,nosuid,nodev,noexec,relatime,seclabel,discard,commit=600,data=ordered)
/dev/mapper/encstateful on /var type ext4 (rw,nosuid,nodev,noexec,relatime,seclabel,discard,commit=600,data=ordered)
/dev/mapper/encstateful on /home/chronos type ext4 (rw,nosuid,nodev,noexec,relatime,seclabel,discard,commit=600,data=ordered)
/dev/mmcblk0p1 on /usr/local type ext4 (rw,nodev,relatime,seclabel,commit=600,data=ordered)

/home/.shadow/0b00d80cb6b214a4a8f2d0094a1de796a15a9623/vault on /home/.shadow/0b00d80cb6b214a4a8f2d0094a1de796a15a9623/mount type ecryptfs (rw,nosuid,nodev,noexec,relatime,seclabel,ecryptfs_sig=1234567890abcdef,ecryptfs_fnek_sig=f1234567890abcde,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs)
/home/.shadow/0b00d80cb6b214a4a8f2d0094a1de796a15a9623/vault on /home/chronos/user type ecryptfs (rw,nosuid,nodev,noexec,relatime,seclabel,ecryptfs_sig=1234567890abcdef,ecryptfs_fnek_sig=f1234567890abcde,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs)
/home/.shadow/0b00d80cb6b214a4a8f2d0094a1de796a15a9623/vault on /home/user/0b00d80cb6b214a4a8f2d0094a1de796a15a9623 type ecryptfs (rw,nosuid,nodev,noexec,relatime,seclabel,ecryptfs_sig=1234567890abcdef,ecryptfs_fnek_sig=f1234567890abcde,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs)
/home/.shadow/0b00d80cb6b214a4a8f2d0094a1de796a15a9623/vault on /home/chronos/u-0b00d80cb6b214a4a8f2d0094a1de796a15a9623 type ecryptfs (rw,nosuid,nodev,noexec,relatime,seclabel,ecryptfs_sig=1234567890abcdef,ecryptfs_fnek_sig=f1234567890abcde,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs)
/home/.shadow/0b00d80cb6b214a4a8f2d0094a1de796a15a9623/vault on /home/root/0b00d80cb6b214a4a8f2d0094a1de796a15a9623 type ecryptfs (rw,nosuid,nodev,noexec,relatime,seclabel,ecryptfs_sig=1234567890abcdef,ecryptfs_fnek_sig=f1234567890abcde,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs)

And here is the output of lsblk:

NAME          MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda             8:0    1   7.5G  0 disk 
└─sda1          8:1    1   7.5G  0 part /media/removable/SANDISK
loop0           7:0    0 581.6M  0 loop 
└─encstateful 253:1    0 581.6M  0 dm   /mnt/stateful_partition/encrypted
loop1           7:1    0 402.3M  1 loop /opt/google/containers/android/rootfs/root
loop2           7:2    0  48.8M  1 loop /opt/google/containers/android/rootfs/root/vendor
loop3           7:3    0     4K  1 loop /opt/google/containers/arc-removable-media/mountpoints/container-root
loop4           7:4    0     4K  1 loop /opt/google/containers/arc-sdcard/mountpoints/container-root
loop5           7:5    0     4K  1 loop /opt/google/containers/arc-obb-mounter/mountpoints/container-root
zram0         252:0    0   2.8G  0 disk [SWAP]
mmcblk0rpmb   179:48   0     4M  0 disk 
mmcblk0boot0  179:16   0     4M  1 disk 
mmcblk0boot1  179:32   0     4M  1 disk 
mmcblk0       179:0    0  29.1G  0 disk 
├─mmcblk0p1   179:1    0     2G  0 part /mnt/stateful_partition
├─mmcblk0p2   179:2    0    16M  0 part 
├─mmcblk0p3   179:3    0     2G  0 part 
├─mmcblk0p4   179:4         16M  0 part 
├─mmcblk0p5   179:5          2G  0 part 
├─mmcblk0p6   179:6         16M  0 part 
├─mmcblk0p7   179:7         23G  0 part 
├─mmcblk0p8   179:8         16M  0 part /usr/share/oem
├─mmcblk0p9   179:9        512B  0 part 
├─mmcblk0p10  179:10       512B  0 part 
├─mmcblk0p11  179:11         8M  0 part 
└─mmcblk0p12  179:12        16M  0 part

On second thought there is something you can try: dump the entire disk including the partition table (you may use gnome-disks from live media), get another computer and a spare disk to run ArnoldTheBbat's Chromium OS special builds, check that it runs without flaws and then copy your stateful partition (usually the biggest partition) over the stateful partition of this test setup. This should work in theory to recover your files, but I don't know which bug you have run into here.