Finally went and got a working USB hub to try out L5 with a keyboard and mouse. That is pretty cool, especially with dark mode enabled, but a few things get in the way doing this (in ‘landscape’ mode with the screen rotated). (Maybe portrait orientation resolves the first two?)
1 - A common issue is the on-screen keyboard continually popping up (say when using the terminal), when I want to use my USB keyboard. Is there any way to stop that or avoid having to click the hide keyboard button all the time?
2 - Another one I’ve had an issue with is when it prompts for credentials - the keyboard is different and there’s no button to hide it. But the keyboard itself covers the dialog prompt when the L5 is in landscape orientation.
3 - I pretty much have to use portrait mode for some applications like Telegram. I’ve tried using this “scale down broken applications” switch inside Mobile Settings, but it never seems to do anything. Is that a WIP or something? What’s it supposed to do? (Sorry I admit I didn’t search for this one first, it’s probably answered somewhere… but I already started typing this. )
4 - Is there any way to make unlocking the phone (the SECOND lock screen, not the encryption unlock) automatically move forward once the correct thing is typed in, without needing to press the “enter” key? Some spy bricks do this and it’s a nice touch.
The password is stored hashed and therefore the length of the original password is not available. Even if the length were available …
Making the length available does somewhat reduce the security of the password.
Having said that, sure, if you use a 4-digit unlock PIN, I’m sure it is possible to change the source code that solicits the password so that it just goes and does its thing immediately after the fourth digit is touched. Or if it became standard functionality then it would need to be an option for the reasons given above. (If it became standard functionality then ideally it would automatically notice the length of the password when you set the password so that if you subsequently set a 6-digit PIN then it won’t stop after 4 digits - because if it did stop after 4 digits then you just locked yourself out of your phone.)
Realistically, I would want that unlock screen to be able to take defensive action after too many incorrect unlock passwords before I would agree with revealing the length of the unlock password.
Edit to add: I guess the implementation could hash the password-entered-so-far on each character entered and if the hash matches then it could proceed without “Enter”. That would address the security concerns. I don’t know whether the CPU could do that fast enough to be sufficiently responsive.
It does slightly, I realize that’s a frequently considered aspect of passwords and such. I’ll suggest a few reasons I don’t believe that matters here. Thanks for the Edit: addition, you guessed one of my reasons.
A casual user just pressing keys will be slowed down pretty significantly by the “time out” the phone has built in. I forgot the pin recently and it was shutting down after some number of attempts. Someone can correct me if I’m wrong but I think it is taking defensive action. I’m pretty sure I remembered the pin after the fact but at least I learned how to flash the L5 (pretty cool).
A “serious” professional haxxor that has complete possession… well they’re not going to be using the lock screen to break in anyway. So I get what you’re saying, but I think I’m sacrificing enough convenience as it is.
But mostly it’s just not a level of security I even need. For people who really want the phone secure (and I bet it’s the majority here), maybe they like it this way. I won’t ask for it to be a standard or even default, but for me a setting to automatically unlock without that last keypress would be great.
Unfortunately my C/C++ days are far behind me so I probably wouldn’t be very efficient doing a pull request, were such a feature to be considered. Although I might be tempted to look at that anyway for fun if Purism takes such contributions.
Sounds like that’ll do it, thanks. I wonder if it’d be hard to detect if a keyboard is plugged in and automatically flip that toggle, but it’s probably not worth the effort compared to other stuff more important.
No I’m sure I haven’t done that. You’re saying that’s not a default feature? I’m SURE it was doing this. But that image would have been a pretty old one, from a few years ago probably, so maybe if it doesn’t do that now, it used to?
I guess another slightly variant approach is … automatically hash after 4 or more digits entered. So if you managed to set a 3 digit PIN, you will still need to touch Enter but if you set a 4 digit PIN, you will not need to touch Enter (provided that you correctly entered the PIN), and if you set a longer PIN, it will waste time hashing password prefixes - but not as much as if it hashed after every digit.
If the unlock screen ever did contain defensive actions against attempted brute forcing, you don’t want the functionality being discussed here to be able to bypass those defensive actions. On the other hand, you also don’t want the functionality being discussed here to trigger those defensive actions. So care is needed if this ever gets implemented.
But if you are not really concerned to that level then the easy fix is … assume you are using a 4 digit PIN and just force the input of exactly 4 digits, automatically stopping after 4.
One thing that was not clear to me is whether you want this functionality to apply to
a) the PIN entry numeric keypad, or
b) the password entry keyboard, or
c) both.
One neat feature of option (a) is that if the length of input mismatches with the length of the PIN (you set it to stop after 4 digits but then accidentally set a longer PIN) then you haven’t locked yourself out because you can still use the keyboard to enter the full PIN.
I’m probably misunderstanding what you’re asking, but I would imagine you’d only want this feature for the second keypad to “normal” unlock the phone. For the first decrypt unlock, anyone with an encrypted phone probably wants to maximize security and keep it entirely manual.
I have major doubt that speed of checking the input an issue. Doing a sha256sum on something like a downloaded ISO has to feed a lot of junk in to get a final resul. That’s what we’re used to seeing, which is slow. On a tiny password something like that should be trivial to any computer.
I wonder if this is something a random contributor could do a PR for.
Not sure why, but I found out that if I do the “scale all” option (I forget what it’s called, the “only as last resort” one), Telegram scales smaller like I thought it was going to. If I just toggle it on for Telegram, it does nothing.
It would be nice to control how extreme that scale-down is though. I can technically read the text still, but it’s uncomfortably small.
Yes, I understood that that is what we are talking about but … the second keypad actually combines a keypad (for the case that your user password is all numeric) and a full keyboard (for the case that your user password is not all numeric). See the little icon at bottom left of the keypad. You can even swap dynamically from one to the other while preserving what you have typed so far.
I think you are missing the point … the algorithm that is used to hash the user password is intentionally slow - so that it is more difficult to brute force. For example, by default it performs 5,000 iterations, and by default it uses SHA512, and on top of the basic hash operation (e.g. SHA512) it does a lot of messing around, again to combat brute force attack.
(The same - intentionally slow - is true for the LUKS passphrase but the technical details are totally different e.g. I have configured my Librem 5 to use an argon family algorithm, rather than the default? PBKDF2 algorithm, but neither of those algorithms applies to your user password.)
“intentionally slow” is calibrated as follows: It must be fast enough that it does not unreasonably delay access by a legitimate user. Within that constraint, it must be as slow as possible - so as to combat brute forcing. It must take into account the capabilities of an adversary who is armed with 100,000 computers each with multiple high-end GPUs, which can therefore perform SHAxxx hashes at a frightening rate.
So if you suddenly multiply the delay by 4 (hash after every character), you could impact usability. In particular, would saving the hassle of touching Enter be worth that extra delay?
Note that the usability considerations for LUKS passphrase are slightly different from the considerations for user password. The former is used exactly once at boot - so being a bit slow can be OK. The latter may be used many times per day.
Still, it’s your phone. I think you would just want to assess usability before committing to such a change.
Okay that makes sense, I didn’t realize the unlock algo was deliberately inefficient. I know about that security technique, sorry you had to type all that out!
I still don’t think it’s slow enough to matter for this. When I hit unlock there isn’t any perceptible delay. It’s certainly faster than I would be tapping unlock, I’m pretty sure it’s fast enough to do it a few times in between “key” presses.
But bottom line, doesn’t the fact that my other phone can do it fine prove it’s feasible?
The other phone may be using a completely different password hashing algorithm (or no hashing algorithm at all e.g. password or hash hidden in TPM or similar) and the other phone may have a faster CPU.
Anyway, if it’s too slow on the Librem 5, you can always reduce the number of rounds (below the default of 5000). A 4-digit password will always be able to be brute forced anyway at 5000 rounds.
@irvinewade Yep I was being intentionally imprecise since I knew my requirements are malleable enough to do what you said at the end to make it work one way or another. If I had hard security requirements I wouldn’t have decrypted the phone.
I’m not going to this level (funny post ), just “reasonable” security to thwart the casual.
So anyway, I didn’t expect that #4 idea to get so much attention. I think I sort of have an answer for #3 (I just wish it worked better). #1 I have a workaround for thanks @ASwyD2 and #2… is probably still an issue. I guess I can work around it by going into horizontal mode.
So I kind of have answers to the original questions, just not answers I like. Some automation or enhancements from Purism (or any source) to address some of this would be nice.
)
), just “reasonable” security to thwart the casual.