Open Port Indicator?

[Arwyn Hainsworth]

On 16/03/07, Peter Whittaker <pwwnow at gmail.com> wrote:
> On Thu, 2007-15-03 at 14:14 +0100, Soren Hansen wrote:
> > I asked for a use case where it made sense to allow access without any
> > form of authentication.
> >
> > If no one comes up with a proper use case I'll just hack together a patch
> > that makes it impossible.
>
> There are at least four use cases, each of which requires a different
> level of authentication/access.
>
> UC1:    Jen needs remote access to her machine. Remote authentication
>         should be (at least) the same as local authentication, i.e.,
>         userid and password. This should be the default option when
>         enabling Remote Desktop (e.g., "Enable remote desktop for known
>         users, or for known user X, userid and password required").
>
>         By default, this setting would persist across sessions. This
>         could be disabled, making it one time only (that is, until
>         logout or reboot).
>
>         As an improvement, there could be a time filter ("during these
>         hours only"), a domain filter (yes, spoofable, but perhaps of
>         value), an IP or Mac filter (ditto), etc.
>
> UC2:    Bif needs assistance with a problem and invites a remote friend
>         to connect and "drive", so Bif can watch and learn. In this
>         case, Remote Desktop could prompt the current local user to
>         enable the connection from the remote friend (e.g., an "Enable
>         remote assistance" option, where each connection is vetted by
>         the current local user ("Someone is accessing your machine from
>         A.B.C.D - do you wish to permit this connection?") "No" or no
>         answer within X seconds means no; yes means yes; a third option
>         could be yes, for Y minutes (max value 30, after 30, prompt
>         again).
>
>         When the current sessions ends (logout, reboot, etc.), Remote
>         Desktop returns to its default, disabled. In other words, if
>         Bif had previously enabled UC1, he must reenable explicitly
>         after using UC2.
>
> UC3:    Fritz is setting up a classroom or other contained environment,
>         and wishes to be able to access all local machines quickly and
>         easily (for whatever reason). He selects "Enable Remote Desktop
>         without authentication", is warned this is potentially risky,
>         and is then prompted to enter the shutoff time/period, i.e.,
>         the time/period after which Remote Access will be disabled and
>         will return to the default of no access.
>
>         Remote Access reverts to disabled after logout/reboot.
>
> UC4:    Barbara is a security researcher setting up a honeypot. She
>         wants to enable Remote Access without authentication. This is
>         a special case of UC3: No authentication, no time limit. She
>         selects no time/period, is asked to confirm this is what she
>         really meant, perhaps even twice, three times, whatever makes
>         us comfortable.
>
> UC1 and UC2 would require no additional authentication (userid and
> password in UC1, local confirmation in UC2). UC3 and UC4 could require
> root privileges, e.g., require the use of gksudo. This would reduce the
> likelihood of just some person taking advantage of an unlocked local
> keyboard.
>
> Alternatively, UC[1234] could require the user to authenticate
> themselves when enabling the option, further reducing this risk.
>

I fail to see why UC[34] would require unauthenticated access.
Passwords do not take long to enter. I can enter my secure password in
around 1sec, no more than 2sec. And a simple password of say '123',
while not in any means secure is at least better than no
authentication at all. So speed of access is not a problem.

You are going to have to come up with a better reason, other that
"people don't want to enter password because they are too lazy", to
convince me that allowing unauthenticated access is a good idea.

Arwyn