store the password only in hashed form

[stapelberg]

Currently, the password of a gokrazy instance is included in the root file system in the /etc/gokr-pw.txt file.

It would be better if the password would only be stored in hashed form. That’s still sufficient for verifying the password, but it stops lateral movement if one gokrazy device gets compromised and multiple devices share the same password.

I have some proof of concept code for using PBKDF2 with SHA256 the same way that OWASP recommends and Django does by default.

Before we can make the switch, we need to update the following users of gokr-pw.txt:

• selfupdate does a full update, should get the password via a flag
• mkfs triggers a reboot
• breakglass displays the build timestamp

The latter two should use an API that is only provided on localhost.

To figure out at pack-time if the included packages are recent enough, we can examine their source using PackageDir:

       gokrazySrcDir, err := packer.PackageDir("github.com/gokrazy/gokrazy")
       if err != nil {
               return err
       }
       log.Printf("gokrazy src dir: %q", gokrazySrcDir)
       // TODO: read filepath.Join(gokrazySrcDir, "gokrazy.go") and check if gokr-pw.hash matches
       // if yes, skip writing gokr-pw.txt:

[damdo]

Sounds like a great idea! :)

It would be better if the password would only be stored in hashed form. That’s still sufficient for verifying the password, but it stops lateral movement if one gokrazy device gets compromised and multiple devices share the same password.

Also it would be beneficial in cases where an attacker attains a copy of a gokrazy update/disk image (gaf/img).

While we think about designing this and how to migrate existing instances to the new hashed approach, would it make sense to extend the scope to also making it possible to change/rotate the gokrazy's HTTP password without re-flashing but rather also via OTA (for both push and pull)?

[stapelberg]

While we think about designing this and how to migrate existing instances to the new hashed approach, would it make sense to extend the scope to also making it possible to change/rotate the gokrazy's HTTP password without re-flashing but rather also via OTA (for both push and pull)?

Yeah, I had that in the back of my mind, too. I think the gokr-pw.hash file could contain multiple entries. I’m not entirely sure yet what the user interface should be for rotating the password (how does one specify the new/old passwords?), but the mechanism of just storing multiple valid hashes seems simple enough to me :)