While we are on this topic, I wonder how much effort would be needed to build a “first unlock” type of system, where the full password is required after boot, with only PIN needed afterwards. I’m not sure of this adds any security if you are using a strong LUKS password, although if there were a feature to relock the PIN (manually or after sufficient time) then it may provide a small benefit.
As far as I can tell this would probably require a custom service unless someone has a clever way to implement it using existing tools. (Sudo timeout may help with the relock feature?)
What benefit do you want to get with? If it is to stop guessing, than it is probably better to build in a function to shut down the phone after n attempts, so that LUKS is active again (user editable). If you want to protect your data, store it on microSD where LUKS is always active when not on use. Next I wanted to look how the system can encrypt the microSD again without dismounting. In my opinion that should be enough.
Nothing wrong about the discussion how to harden the L5 against physical access, but that is better discussed on a new thread.
Yeah, as stated my “first unlock” suggestion wouldn’t add too much protection. Maybe it would add a layer of defense against non-technical shoulder surfing attackers if they reuse the PIN as the LUKS password, or if they don’t use LUKS at all, but both of these are ill-advised. I get the feeling that it would have some benefit that I’m missing, but maybe that’s just inherited from the typical mobile ecosystems where BFU/AFU state has importance.
For the same reason it’s fine to enable automatic graphical login on a desktop/laptop if you have LUKS enabled, but it still feels wrong! (I suppose requiring login would protect against someone managing to crash your X/Wayland session while the screen is locked, but that’s all I can think of.)
I think this is a good option. Let’s say that the normal login screen is re-instated and the purism password is set to something stronger than a PIN and subsequent screen unlock does not use the standard password mechanism then you get similar benefits to those offered in the linked topic (i.e. it’s an alternative approach) but with the added bonus that the PAM automatic keyring unlock at login might actually work (for those who want that).
This is good too. In fact, this is good regardless of whether any of the other suggestions ever get implemented.
However it does need to be an option because of the potential for annoying DoS and the potential for loss of data if there are any open applications at the time.
That would be brutal. Would anyone actually want that? Not me.
But, sure, once you decide you want this option at all, it should be possible to specify the number of attempts that are allowed i.e. to specify the value of ‘n’. I would suggest default n = 3.
I thought about people who need it for their jobs. NGO-activists in some countries, reporters on specific topics or just people who hold secrets of their companies/governments that nobody should get hands on. I think 3-5 is fine for common purpose.
The choice of ‘n’ in that case should be made in conjunction with considering the length of the PIN - because, for sure, lengthening the PIN makes more difference than whether n is 1 or 3 or 5. If the PIN is already at your personal maximum tolerable length then, yes, you may care to reduce ‘n’.
At a certain point though of super-secrecy, even a guess probability of 1/10^length may be unacceptable - and additional techniques are needed e.g. don’t hold that kind of information on a phone in the first place (!) / a second or third factor / other unlock techniques.
… and taking into account conflicting customer preferences (hence configurability is important)
… and taking into account the UX that duopoly phones have established in the public mind (e.g. when trying to bring across existing duopoly phone customers).
Agreed, for high security requirements it would be better to rely on something like a Yubikey/Nitrokey with its own PIN and hardware-enforced PIN limits. (I use this on a desktop but have not tried with L5 yet.) But for this use case I don’t think the Librem 5 hardware is a great fit in general, as there is a tradeoff with user serviceability. Perhaps if you filled the case with epoxy.
Maybe a dumb idea, but what if a USB conditional was needed for unlock on first boot? Something similar to the already-implemented USBguard toolset? Or maybe USBguard can be used in its stead?
Something you can use as either a GTK widget or even an option in Settings > Lock Screen > Enable PAM device unlock (use can then be shown a widget to set up, install, or otherwise register PAM for a 2FA-style unlock). Maybe have a feature in “Mobile Settings” that can be used to “enable beta/unstable features” which could through a separate PureOS repo enable some neat tools like that. Obviously either way, make it clear that if the user looses their PAM key for 2FA then the device cannot be unlocked.
Sorry for that joke, nothing against your opinion. 