Menu: Sleep option does not lock PDDBs

[kop316]

When I use the Sleep option on the menu, I wake up the device and the PDDBs that I had unlocked are still unlocked. However, when I type sleep now in Shellchat, the device shows a different sleep mode and when I wake it up, all of my PDDBs are locked.

With my other devices, when I hit sleep, by default I am required to enter a password to get access to the device again, and I would expect similar behavior in Xous. The sleep now function is similar to what I would expect versus the menu option now.

Does it make sense to use sleep now as the default sleep behavior, or maybe alter what it shows as sleep, i.e. sleep but don't lock PDDB or something similar?

[bunnie]

This is a good question.

There isn't a re-PIN screen right now. It's something that is useful to counter the scenario of theft or evil maid activity.

The tension is between encouraging people to use strong passwords and asking them to punch it in all the time. The PDDB was built with the option to auto-unmount secret Bases every time you went to sleep, but when I was testing that I basically found myself cursing the system and passive aggressively picking shitty passwords for everything because it gets very annoying to have to re-mount multiple secret Bases every time you walk away.

Probably the right solution to this is to offer some user configuration option, but with the default option set to "less annoying" (I really don't want a repeat of e.g. the Windows 8 experience where every two UX interactions a security notice would come up -- sure, they put security first, but, users just turn it off if it gets annoying).

This is probably a very long-term project, which starts with just figuring out what the right user experience is. There's going to be a lot of opinions on this, but maybe it's not too early to start the discussion. I'd probably give this about 2-3 releases before we see any features like this making it into the system, because any rework done of this nature is going to hit a lot of core security elements and I don't want to do it twice, and I also don't want to annoy users into not using the device anymore.

[kop316]

For one use case: My general workflow has the "strong" password, but this is only applied on boot up. Afterwards, I have a much weaker "wake up" password. This way, when I want to lock my sensitive electronics, I have the option of just putting it to sleep/locking the device (and being able to use the weaker password to unlock), or I can completely power it off and then require whatever stronger passwords I need.

I have generally found this to be a useful compromise, as like you said, I can have a simpler password for most normal usage, but I then know I can erase any sensitive keys when I am worried about an adversary (e.g. going though an airport, customs, etc.).

[bunnie]

I've converted this to a discussion, given the longer-term nature of this request.