[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SSH revised

From: Marcus Brinkmann
Subject: Re: SSH revised
Date: Sun, 26 Mar 2006 21:42:48 +0200
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Sat, 25 Mar 2006 19:55:48 +0100,
Lluis <address@hidden> wrote:
> ok, I was thinking on something like:
> - event EV_FOO has multiple recipient, but all of them are registered as 
>   ID1
> - every 'useradd <user> ID1' makes <user> have access to the ID1 cap. user 
>   identifier
> - anyone wishing to recieve EV_FOO events has to register into the logger 
>   with ID1
> that's why I was talking about user ids as groups and each event class 
> being associated to a single group-as-a-user

I think I said something similar, if you look into the discussion of
how to implement groups.
> And if ID1 is a user identificator cap. it could convey some undesired 
> rights on other services, so it should really be ID1::ev_reciever, meaning 
> "the capability used to recieve events for ID1"

I think that the system should not really care about this.  The only
thing the system needs to ensure is that the user and the group ID1
can communicate _at all_.  Further capability exchange can be used to
negotiate specific authorizations, without the system needing to be

> Well, what I was thinking of is like:
> evil$ ssh address@hidden
> User does not exist [ or connection closed or something similar ]
> evil$ ssh address@hidden
> Password: 
> Now I have more information, I know that bertrand.doe can log into the 
> machine, so I could start a dictionary attack, knowing an account to attack 
> and, maybe, having some information about Bertrand Doe (google, trashing, 
> guessing, social engineering,...)
> Is this nonsense? Maybe. Is this paranoid? Sure, but after reading this 
> list, the little paranoid on me is growing XD

It's not nonsense.  Although it is security through obscurity, there
is nothing wrong with making it harder even for only some attackers.
Practical security also means to add some obstacles to thwart or delay
attacks.  However, your security model should not depend on this.

So, I think that the lack of something like this is not a fatal flaw.
There are other ways you can make attacks harder, for example by using
stronger/longer passwords, or by not using passwords at all but public
key authentication.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]