4.4.5.130 / 1.0.1418 passwords

[Pluto]

Requiring a password to alter settings; good in principle. However, how many times do you need to ask for the password? I understand how the tree and check-box structure within "manage access" permits the user to choose which areas should be password protected but, for example, do you really need to keep asking for the password when flipping from tab to tab within "settings"?

I think you ought to decide upon a scope of validity for a successful password entry and settle for that. For example, make a successful password entry last for, say, 1/2/3 minutes or while the interface remains visible (i.e. not minimized). Right now, the repeated demands for a password will cause users to disable the need for passwords, and that will be counter-productive.

ALSO

The need for a password when disabling individual protections is understandable. But do you really need a password when re-enabling those protections?

[AdvancedSetup]

Thank you for the feedback @Pluto

I would tend to agree with you myself as well and I'll make sure the team sees your feedback as well.

Cheers

 

 

[ChuckOp]

What about a timed approached?  For example, it requests a password, after which, it stays unlocked for the next 5/10/30/60 minutes?

Or maybe it's per-session; entering the password unlocked the settings for the duration of the mbam.exe (main UI) session.  

[Pluto]

4 hours ago, ChuckOp said:

What about a timed approached?

Well, I thought that was what I was suggesting when I said...

On 8/8/2021 at 7:50 PM, Pluto said:

make a successful password entry last for, say, 1/2/3 minutes...

Perhaps make this time user-configurable. Sorry to answer questions with questions but when you say...

4 hours ago, ChuckOp said:

maybe it's per-session; entering the password unlocked the settings for the duration of the mbam.exe (main UI) session

It depends exactly what you mean by a “session“. If this means ‘until the next reboot’ then no, as (in my case) this can sometimes mean several days. Does a “session” terminate at a logout? Or when the machine enters a sleep state? Unless you can nail this down precisely, then I would say this is not the way to go.

Personally, I'm inclined to favour the "while the main interface remains visible” approach. Assume the MB service is happily running and no interface is visible apart from the M symbol in the notification area i.e. a standard, normal startup. The password is demanded the moment one of the ticked options is called. At that stage, the password remains valid until the interface is put away i.e. the top right × is pressed. I'm not sure if that covers it totally, but think that approach would be a good start.

Also, a timer element along the lines of the password validity never lasting more than n minutes between an event that demands the password and a subsequent such event – i.e. the password is demanded, it is given, I do whatever I wanted then leave my desk. At that point, the password remains valid for n minutes. If I return to the desk and then switch to another passworded operation within less than n minutes, I am not bothered for a further password entry.

Just to explain that another way: a successful password entry sets a timer running n minutes to extinction. Switching the interface to another password-protected operation before n minutes have elapsed resets the timer back to n minutes. But If the timer is not reset before n minutes elapses (i.e. I have gone away, got distracted etc.), the password is again demanded when a protected operation is called. But at any stage, pressing × causes the timer to go immediately extinct so the next password-protected event will demand the password.

Hope that all makes reasonable sense.

[Firefox]

Personally I would prefer per session, once you exit out of GUI, if you have to go back to it then prompt for password again.

[Pluto]

14 hours ago, Firefox said:

Personally I would prefer per session, once you exit out of GUI

I tend to agree, provided the logic of “what constitutes a session” is correct i.e. a GUI session, commencing at the point when the full MB GUI becomes visible and ending when the GUI is closed or, perhaps, minimized.

I think an element of timer is necessary just in case the GUI is left open on the screen. If the interface is devoid of activity, the password ought to time out after a few minutes.

Anyway, I dare say the MB back office folks now have a handle on what's required and will come up with something!