~anjan/public-inbox

4 2

peanutbutter feedback

Details
Message ID
<D08OUBZEXWSQ.3M648R47PDJC1@matfyz.cz>
DKIM signature
missing
Download raw message
Hello, Anjandev,

I have come across peanutbutter (the swmo screenlock) yesterday and I
was very pleased to see that there are ongoing efforts in this area --
thank you for working on this!

I have since then been using it on my samsung,coreprimevelte phone and
have several questions and suggestions if you don't mind. Please forgive
if I missed some important document -- actually I only found the README,
I haven't looked at the code itself -- where some of these concerns
would be addressed.

A probably obvious question is whether you intend to support changing
the touchcode without recompilation. I understand that for early
development the current mechanism is sufficient, but obviously it would
not make much sense security-wise if everyone who installs this from the
Alpine repo had the same passcode.

An automatic idea would be to have a configuration file for that, but I
don't know if that could be considered secure either if it was plain
text. Perhaps it could at least contain some sort of a hash of the code.

Possibly the best way would be if the program used some built-in Linux
authentication mechanisms -- I don't really know much about this, but
could maybe PAM be helpful here somehow?

I have found the current touchcode to be rather weak -- touching the
screen semi-randomly, I was able to unlock the phone (which however
might be rather because of another issue, please see below). I don't
know if the lower right is always reset and whether the touchcode must
be always 4 taps long (my simple experiment seems to suggest that
entering wrong 4 taps code and then the correct one does unlock the
screen), but if so, it doesn't give many combinations and would be easy
to brute force.

So if the code is eventually configurable, perhaps it should not be
limited in length. Another thing I can think of would be to add more
segments instead of the four corner, but that might be problematic for
small screens and even on big ones, it might be hard to tell where are
the segment borders without some visual aids -- perhaps the number of
segments could be configurable too.

Speaking of visual aids, do you plan to implement some visual feedback
for the user? Such as maybe display the segment borders (configurably),
indicate which segment was pressed, indicate wrong combination and so
on. There is some security-by-obscurity now without the feedback, but I
don't think that's a strong argument against adding some in the future.

This is something very marginal and currently unimportant but while I
like the default lock background (I don't see any images in your repo:
is it generated as a color gradient or is it the GNOME Mobile
background?), I would probably eventually like to have the option to
experiment with different ones.

It would probably make sense to somehow inhibit sxmo's buttons daemon:
currently, when the screen is locked, it is still possible to change
sound volume (which is a good thing) but also open the system menu
(using Volume Up), which is probably harmless since Power Button doesn't
seem to work through the lock, and kill windows (triple Button Down)
which could already be problematic.

I assume this is because sxmo listens to the input devices directly
(bypassing sway) using some daemon and runs the appropriate actions? If
that is the case, the daemon could either be completely suspended when
the lock is active, which would mean that peanutbutter would have to
somehow handle at least the Power Button presses and optimally even the
volume control (or it could let the user configure the Volume Buttons'
functions with active screenlock) which would probably mean more code.
Or (probably better), the daemon could be modified to recognize the
"lock active" state and behave accordingly.

Last thing that I noticed and which seems like a bug to me, unless I'm
missing something: it is actually possible to unlock the phone using a
different than the default combination. As I wrote above, randomly
tapping the screen lead to the screen unlocking for me. I originally
thought that is simply because I entered the correct combination by
accident, but then noticed that the screen unlocks when I press
different than the upper right corner. I have been able to determine
that for instance (I am not sure there are not others) starting at upper
left segment, going down, upper right and repeat four times ending on
the upper left (simply start at upper left and keep going
counter-clockwise) unlocks the screen. I believe this would definitely
be worth investigating.

May I ask what your plan is going forward for Xorg integration? I
understand that currently the lock is swmo-only. That doesn't matter
much to me as I use that flavour, but I wonder if it might be needed for
full integration with the sxmo project in the future. Of course, I
suppose sxmo could offer the lock for swmo only.

If you actually found some of these comments useful, I would be happy to
also put it up on the project's ticket tracker, should you create one.
Perhaps a dedicated mailing list might become appropriate soon too?

Thank you once again for starting this project, I really hope this will
catch on and sxmo will finally have an official screenlock.

Also thank you for reading this.

Kind regards,
K. B.
Details
Message ID
<D2UYYQ6C2LQG.1KYZEAJ0X2Z2N@momi.ca>
In-Reply-To
<D08OUBZEXWSQ.3M648R47PDJC1@matfyz.cz> (view parent)
DKIM signature
pass
Download raw message
Hi Karel!

Sorry for the late response.

> I have come across peanutbutter (the swmo screenlock) yesterday and I
> was very pleased to see that there are ongoing efforts in this area --
> thank you for working on this!
>
> I have since then been using it on my samsung,coreprimevelte phone and
> have several questions and suggestions if you don't mind. Please forgive
> if I missed some important document -- actually I only found the README,
> I haven't looked at the code itself -- where some of these concerns
> would be addressed.
>
> A probably obvious question is whether you intend to support changing
> the touchcode without recompilation. I understand that for early
> development the current mechanism is sufficient, but obviously it would
> not make much sense security-wise if everyone who installs this from the
> Alpine repo had the same passcode.
>
> An automatic idea would be to have a configuration file for that, but I
> don't know if that could be considered secure either if it was plain
> text. Perhaps it could at least contain some sort of a hash of the code.
>
> Possibly the best way would be if the program used some built-in Linux
> authentication mechanisms -- I don't really know much about this, but
> could maybe PAM be helpful here somehow?
>
> I have found the current touchcode to be rather weak -- touching the
> screen semi-randomly, I was able to unlock the phone (which however
> might be rather because of another issue, please see below). I don't
> know if the lower right is always reset and whether the touchcode must
> be always 4 taps long (my simple experiment seems to suggest that
> entering wrong 4 taps code and then the correct one does unlock the
> screen), but if so, it doesn't give many combinations and would be easy
> to brute force.
>
> So if the code is eventually configurable, perhaps it should not be
> limited in length. Another thing I can think of would be to add more
> segments instead of the four corner, but that might be problematic for
> small screens and even on big ones, it might be hard to tell where are
> the segment borders without some visual aids -- perhaps the number of
> segments could be configurable too.

So I chose the corner touch because it was quick and easy. The main
worry is that someone will see something sensitive on your phone screen.

I am against using pam because pam itself on linux is very complicated
and I want to avoid all complication for this lockscreen.

The best solution is saving a hash of the user's passcode.

I favour pattern passcodes. Moreover if we implement this, like to give users to just
"compile in the passcode" and remove the requirement to do file io.


> Speaking of visual aids, do you plan to implement some visual feedback
> for the user? Such as maybe display the segment borders (configurably),
> indicate which segment was pressed, indicate wrong combination and so
> on. There is some security-by-obscurity now without the feedback, but I
> don't think that's a strong argument against adding some in the future.

More visual feedback would be very welcome. Patches welcome!

> This is something very marginal and currently unimportant but while I
> like the default lock background (I don't see any images in your repo:
> is it generated as a color gradient or is it the GNOME Mobile
> background?), I would probably eventually like to have the option to
> experiment with different ones.

I accidentally "generated" that image by playing around with the
coordinates. Custom image support would be also welcome (provided it can
be disabled to remove fileio).

> It would probably make sense to somehow inhibit sxmo's buttons daemon:
> currently, when the screen is locked, it is still possible to change
> sound volume (which is a good thing) but also open the system menu
> (using Volume Up), which is probably harmless since Power Button doesn't
> seem to work through the lock, and kill windows (triple Button Down)
> which could already be problematic.
>
> I assume this is because sxmo listens to the input devices directly
> (bypassing sway) using some daemon and runs the appropriate actions? If
> that is the case, the daemon could either be completely suspended when
> the lock is active, which would mean that peanutbutter would have to
> somehow handle at least the Power Button presses and optimally even the
> volume control (or it could let the user configure the Volume Buttons'
> functions with active screenlock) which would probably mean more code.
> Or (probably better), the daemon could be modified to recognize the
> "lock active" state and behave accordingly.

This is all true. Sxmo has this issue where we directly read from
/dev/input 

https://gitlab.com/postmarketOS/pmaports/-/issues/1841

> Last thing that I noticed and which seems like a bug to me, unless I'm
> missing something: it is actually possible to unlock the phone using a
> different than the default combination. As I wrote above, randomly
> tapping the screen lead to the screen unlocking for me. I originally
> thought that is simply because I entered the correct combination by
> accident, but then noticed that the screen unlocks when I press
> different than the upper right corner. I have been able to determine
> that for instance (I am not sure there are not others) starting at upper
> left segment, going down, upper right and repeat four times ending on
> the upper left (simply start at upper left and keep going
> counter-clockwise) unlocks the screen. I believe this would definitely
> be worth investigating.

Huh, can you add logger support using: https://docs.rs/log/latest/log/

and investigate what variable is causing this?

> May I ask what your plan is going forward for Xorg integration? I
> understand that currently the lock is swmo-only. That doesn't matter
> much to me as I use that flavour, but I wonder if it might be needed for
> full integration with the sxmo project in the future. Of course, I
> suppose sxmo could offer the lock for swmo only.

Xorg will never be supported by peanutbutter.


> If you actually found some of these comments useful, I would be happy to
> also put it up on the project's ticket tracker, should you create one.
> Perhaps a dedicated mailing list might become appropriate soon too?

The mailing list and issue tracker are the sxmo's mailing list and issue
tracker.

> Thank you once again for starting this project, I really hope this will
> catch on and sxmo will finally have an official screenlock.
>
> Also thank you for reading this.

Thank you for emailing in! I am going to add this email to the readme as
it's a great FAQ.

Take care,
Anjan
-- 
w:] www.momi.ca
pgp:] https://momi.ca/publickey.txt
Details
Message ID
<D3FKMV92IGKB.2BTIZ0TH2R74E@matfyz.cz>
In-Reply-To
<D2UYYQ6C2LQG.1KYZEAJ0X2Z2N@momi.ca> (view parent)
DKIM signature
missing
Download raw message
Patch: +4 -3
Hello again, Anjandev,

thank you for your reply.

Anjandev Momi, 2024-07-20T22:31:44-07:00:
> > A probably obvious question is whether you intend to support changing
> > the touchcode without recompilation. I understand that for early
> > development the current mechanism is sufficient, but obviously it would
> > not make much sense security-wise if everyone who installs this from the
> > Alpine repo had the same passcode.
> >
> > An automatic idea would be to have a configuration file for that, but I
> > don't know if that could be considered secure either if it was plain
> > text. Perhaps it could at least contain some sort of a hash of the code.
> >
> > Possibly the best way would be if the program used some built-in Linux
> > authentication mechanisms -- I don't really know much about this, but
> > could maybe PAM be helpful here somehow?
> >
> > I have found the current touchcode to be rather weak -- touching the
> > screen semi-randomly, I was able to unlock the phone (which however
> > might be rather because of another issue, please see below). I don't
> > know if the lower right is always reset and whether the touchcode must
> > be always 4 taps long (my simple experiment seems to suggest that
> > entering wrong 4 taps code and then the correct one does unlock the
> > screen), but if so, it doesn't give many combinations and would be easy
> > to brute force.
> >
> > So if the code is eventually configurable, perhaps it should not be
> > limited in length. Another thing I can think of would be to add more
> > segments instead of the four corner, but that might be problematic for
> > small screens and even on big ones, it might be hard to tell where are
> > the segment borders without some visual aids -- perhaps the number of
> > segments could be configurable too.
>
> So I chose the corner touch because it was quick and easy. The main
> worry is that someone will see something sensitive on your phone screen.
>
> I am against using pam because pam itself on linux is very complicated
> and I want to avoid all complication for this lockscreen.
>
> The best solution is saving a hash of the user's passcode.
>
> I favour pattern passcodes. Moreover if we implement this, like to give users to just
> "compile in the passcode" and remove the requirement to do file io.

Sounds good, the version in the distribution's package repository would
allow for the configuration while users could also compile the program
themselves with the passcode built in and no file IO.

I see that there is already a patch for reading the passcode from an
environment variable too. This would probably be acceptable for the
first (distro package) variant too? Although with the current
implementation the passcode is visible in the environment, but it should
be possible to change it to set the hash instead (which would however
probably only make sense with a longer code anyway).

> > Last thing that I noticed and which seems like a bug to me, unless I'm
> > missing something: it is actually possible to unlock the phone using a
> > different than the default combination. As I wrote above, randomly
> > tapping the screen lead to the screen unlocking for me. I originally
> > thought that is simply because I entered the correct combination by
> > accident, but then noticed that the screen unlocks when I press
> > different than the upper right corner. I have been able to determine
> > that for instance (I am not sure there are not others) starting at upper
> > left segment, going down, upper right and repeat four times ending on
> > the upper left (simply start at upper left and keep going
> > counter-clockwise) unlocks the screen. I believe this would definitely
> > be worth investigating.
>
> Huh, can you add logger support using: https://docs.rs/log/latest/log/
>
> and investigate what variable is causing this?

So I finally got around to this, please see the patch below.

Thanks again and best regards,
K. B.
-- >8 --
Subject: [PATCH] clear the code state upon overflow

Reset the array of registered touches every time it overflows. This
prevents peanutbutter from accepting combinations in which the specified
order of the predefined touches is cycled.

With the previous behaviour it was for instance possible to unlock
peanutbutter (with the default code) by pressing the top right corner
four times and then pressing top left, top left and bottom left. This
was because those first four touches filled the entire array with
TopRight touches and the following three then overwrote the first three
elements to make it match the PASSCODE array.

Alternative solution would be to check if the code is valid only every
time the last element of the array is set.
---
 src/touch_pass.rs | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/src/touch_pass.rs b/src/touch_pass.rs
index 6f8043514920..959777b1f110 100644
--- a/src/touch_pass.rs
+++ b/src/touch_pass.rs
@@ -53,6 +53,10 @@ impl TouchState {
            return;
        }

        if self.last_touch >= TOUCHES {
            self.clear();
        }

        if x_val < self.half_width && y_val < self.half_height {
            touch = PasscodeItem::TopLeft;
        } else if x_val > self.half_width && y_val < self.half_height {
@@ -64,9 +68,6 @@ impl TouchState {
        self.touches[self.last_touch as usize] = touch;

        self.last_touch += 1;
        if self.last_touch >= TOUCHES {
            self.last_touch = 0;
        }
    }

    pub fn print(&self) {
-- 
2.46.0
Details
Message ID
<D3QDLMQUAJS2.3A7LJ9YNF7CJD@momi.ca>
In-Reply-To
<D3FKMV92IGKB.2BTIZ0TH2R74E@matfyz.cz> (view parent)
DKIM signature
pass
Download raw message
On Wed Aug 14, 2024 at 3:43 AM PDT, Karel Balej wrote:

> Subject: [PATCH] clear the code state upon overflow
>
> Reset the array of registered touches every time it overflows. This
> prevents peanutbutter from accepting combinations in which the specified
> order of the predefined touches is cycled.
>
> With the previous behaviour it was for instance possible to unlock
> peanutbutter (with the default code) by pressing the top right corner
> four times and then pressing top left, top left and bottom left. This
> was because those first four touches filled the entire array with
> TopRight touches and the following three then overwrote the first three
> elements to make it match the PASSCODE array.
>
> Alternative solution would be to check if the code is valid only every
> time the last element of the array is set.
> ---
>  src/touch_pass.rs | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/src/touch_pass.rs b/src/touch_pass.rs
> index 6f8043514920..959777b1f110 100644
> --- a/src/touch_pass.rs
> +++ b/src/touch_pass.rs
> @@ -53,6 +53,10 @@ impl TouchState {
>              return;
>          }
>  
> +        if self.last_touch >= TOUCHES {
> +            self.clear();
> +        }
> +
>          if x_val < self.half_width && y_val < self.half_height {
>              touch = PasscodeItem::TopLeft;
>          } else if x_val > self.half_width && y_val < self.half_height {
> @@ -64,9 +68,6 @@ impl TouchState {
>          self.touches[self.last_touch as usize] = touch;
>  
>          self.last_touch += 1;
> -        if self.last_touch >= TOUCHES {
> -            self.last_touch = 0;
> -        }
>      }
>  
>      pub fn print(&self) {


Hey,

It seems we cannot apply this patch with proycon's changes. Please give
the latest master a try and see if it fixes your issue.

Thanks,
Anjan
-- 
w:] www.momi.ca
pgp:] https://momi.ca/publickey.txt
Details
Message ID
<D3QVM7G4AC1P.3IF6S7B3A2ZMP@matfyz.cz>
In-Reply-To
<D3QDLMQUAJS2.3A7LJ9YNF7CJD@momi.ca> (view parent)
DKIM signature
missing
Download raw message
Hello, Anjan,

Anjandev Momi, 2024-08-26T20:32:33-07:00:
> It seems we cannot apply this patch with proycon's changes. Please give
> the latest master a try and see if it fixes your issue.

indeed, it seems the issue is solved on current main.

Best regards,
K. B.
Reply to thread Export thread (mbox)