I remember years ago a friend of a friend who happened to be a Computer Forensic dude mentioned something about keyboard wear patterns enhanced with digital photography that would put their focus on those keys only and their success rate was in the high 90 percent in opening an encrypted drive. IDK…just thought it was interesting to share.
3 Likes
Sounds like that could be countered by at least two ideas:
- Using a password that uses the entire keyboard for an even distribution.
- Replacing the keyboard entirely.
Or a silicone keyboard protector?
1 Like
Well I would assume someone who can measure wear on keyboard keycaps can also measure wear on keyboard silicone protectors.
Yeh, unless they were referring to finger print acidic deposits…IDK never sought sought an elaboration on it. Or you could just dispose of the protector and use a new one…
1 Like
There is also a significant assumption in that the wear of the keycaps directly correlate to the password, but keyboards are used for far more purposes then just that, like typing documents or news articles. Such forensic techniques cannot determine between these activities based on wear alone.
1 Like
That is true. But I would imagine the frequency of keys used as compared to other keys they would be able to eliminate other keys to a certain subset that would increase their chances of a brute attack …again all gotten I guess by acidic deposits and directional pushes of those deposits to gain letter associations with those keys?
1 Like
We need sources for these physical forensic techniques. I was unable to find any relevant information regarding them using various keywords from this discussion.
2 Likes
Yeh…pretty much assuming. Like I said in my original post that was coming from a friend of a friend in passing conversation years ago, which i used for my own security needs…like using keypad covers. and a very long password which is memorized upper lower case letters, numbers along with special characters and spaces.
Edit. A cursory search did pop up something else which is interesting…its a technological leap from what I described from years ago but interesting none the less
1 Like
That was my first thought too. And in fact, my keyboard for desktop is so old and heavy used, that I can see with my eyes easily(!) what keys are often used. But I can tell that it is definitely no indicator of my passwords.
That’s an attack for people who don’t use often a pc … maybe 90% of time for login into e-mail account to read them. They type passwords more often than anything else, but they are also uninteresting to hack them via this way (remember you need access to physical keyboard).
And people who’re interesting to get access are usually heavy pc users and do a lot of stuff with it. The usage of keys are higher on other activities. I think it’s more a laboratory method than something for real attacks.
I guess same with the heat-method. Someone needs local access and watch the heat via camera. But if you want to do it this way, you also could install a real camera or a keylogger.
2 Likes
Yeh, As i mentioned prior, this was said by a Computer Forensic dude years ago and I would imagine that it is under laboratory conditions like you mentioned. I am not sure what kind of equipment would be used for that.
As far.as the thermal goes maybe a small password can be had with this method…I used my Flir to test keyboard capture on my L13 and captured about 5 strokes and the rest dissipated before photographic capture…
Interesting thread however.
2 Likes
You may need a camera that can capture on 10th or even more parts of a degree to get more keys. I don’t know what’s the accuracy of a common heat cam, but it seems to be not good enough to get close to 16 keys. However, if you have a 8-sign password and 5 are captured, you can brute force the rest easily.
Yep, definitely interesting thread.
2 Likes
Or, in the specific case of a device like the Librem 5 with an on-screen keyboard, you can randomize the keyboard for the purposes of LUKS password entry. This counters or at least frustrates a number of techniques that might be able to recover the password. On the downside, it will force you to enter your LUKS password more slowly.
3 Likes
I would feel more secure if there were two passwords for the Librem 5’s unlock screen: one for an untrusted/restricted environment for use in public; one for a trusted environment in private. Instead, in place of that since such an implementation does not exist, I currently manage my identities, devices, and passwords using physical isolation: I bring out my Librem 5 in public; I keep my Librem 14 in my bedroom/bathroom.
The only time I ever bring out my Librem 14 in public is when I also bring my PureOS live image on a USB drive, in which I boot from that instead of Qubes OS. This practice also reinforces that PureOS is only for public use.
1 Like
… could mean one of two things:
- The LUKS unlock at boot time.
- The
purismpassword unlock whenever the phone locks e.g. due to being idle.
I think the second would be more realistic as far as implementing your request goes.
1 Like
I’m sure he’s speaking about the user password. The phone usually stays on and you often have to type in the user password and rarely the LUKS one.
And I agree that there should be a solution that addresses this threat. I want to be able to use my user password in front of other people without danger that they can change something on sudo level with same password.
1 Like
I primarily meant the latter, but the former is also possible by two installations of PureOS within the same drive, provided that the boot manager (assuming GRUB) also supports touch screen input.
The realistic solution I am thinking about would be to have two user accounts on the Librem 5: one of them could be a “guest” account; the other one is the administrative/root account. I have yet to read any documentation or mentions of this anywhere.
The idealistic solution is that the unlock screen accepts two passwords and automatically logs in to the associated account depending on the inputted password.
Just thinking aloud …
On the Librem 5, I think not. But then …
on the Librem 5 that is a given!
On the Librem 5, you can have as many user accounts as you want - and I think you can even re-instate the standard Linux login window (choose user to log in as).
AIUI, the GUI on the Librem 5 for creating extra user accounts isn’t there yet (not adaptive), so you need to create the user account from the shell (and that does work fine) or maybe use a dock.
The problem is …
the screen unlock is not necessarily logging in. If it is logging in, yes, you can probably get that approximate behaviour but if it is just unlocking (which seems to me the more likely “public” scenario) then it would be more complicated. You would kind of be saying that if you “log in” to the user that is not currently logged in then it should log out the current session and log in again, whereas if you “log in” to the user that is currently logged in then it should just unlock.
Of course, if you reinstate the standard login window, you can also choose from the various options, such as: after one user’s session locks, you can log in as a different user and come back to the original locked session later. That would be a more manual process but approximately meets your security requirement.
A complication with all this is that if, while the phone is in operation, you make and receive calls and you make and receive texts then they may end up filed under whatever user is logged in at the time, which means that you don’t have a very coherent record comprising call logs and text conversations.
Likewise, your contacts would be all over the place - but I guess that is fixable if you instead go for a distributed contact store (cloud or LDAP or something like that - even if hosted on the phone itself).
1 Like
The solution would be at the login window that you referenced. Instead of listing various users, it would only show the on-screen keyboard. This design would hide the amount of users and groups, but it also makes a very important assumption: each password is as unique as each user.
The shared modem problem cannot exist with how I currently operate: in public, only the cellular hardware kill switch is inactive; in private, only the Wi-Fi hardware kill switch is inactive.
I like that idea btw.
Things like calls and SMS are handled by another hidden user that’s always active as far as I know. So it’s no issue at all to receive them. Things just need to be written somewhere where the different users have access. In additional I would give users the right to read it or not, depending on what the phone owner wants (similar to the option to read notification on lockscreen or just the title without content).
1 Like