On 2007-07-12, ArameFarpado wrote:
> don't compare those md5sum to the encrypted passwords, ok?, because:

The principle is the same, even if the actual data is not: the original
data can *not* be reconstructed from the new hashed data.

> so, picking up a hash and turning it up-side-down, won't give you the
> password but it nerrows it to a small list of possibilities.

It does not. *Please* do as others have suggested and read up on the
current implementations of /etc/passwd and /etc/shadow. But even if you
were correct, normal users can't read /etc/shadow, where the hashed
passwords are stored, so you can't assume you even have the hash to
begin with.

> don't tell me it can't be done, because if it wore true, there wore no such
> thing as password cracker programs,

Most of the password crackers for linux are basically brute-force crackers.
The ones that aren't assume that you've somehow obtained a copy of
/etc/shadow.

> by the way, do we have a point when a user acount is blocked because of bad
> paswords? if so, how many wrong passwords are needed?
> I know windows does this after 3 or 5 wrong passwords, but never seen linux
> do it...

Most distros by default do not lock accounts on bad passwords, but it
can be easily configured. There is plenty of documentation online and
in the man pages.

> Now, let's go back to man sudo because there is another point to discusss:

If you don't like sudo, *don't use it*!

> ""Once a user has been authenticated, a timestamp is
> updated and the user may then use sudo without a password for a short
> period of time (15 minutes unless overridden in sudoers).""
>
> Once a sudoer uses sudo, he can do it again without password for some
> time...
>
> During this time, the trojan have a window of opportunity, and it only needs
> it once, since after gaining root previledges, he can change the user
> password then.

I'm getting off into speculation, since I don't know in detail how other
distros configure their /etc/sudoers file. *If* you have sudo, and
*if* you have sudo su, *then* yes, you are vulnerable to trojans in that
time period. The solution is to not be stupid when using sudo. It
appears that you are looking for a technical solution to what is
fundamentally a human problem, and it is not the OS's job to protect the
administrator from every conceivable mistake he could make. It is the
admin's job to act in such a way that he doesn't compromise his
security; it is the OS's job to ensure that the security measures the
admin has configured are enforced.

What I said earlier is still true: don't give root access to people you
don't trust. If you don't trust yourself, don't connect your machine to
the network!

--keith

--
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information

Alan Adams writes:
> If the hashed version contains less information than the original
> password, doesn't this imply that there is more than one possible
> password which will hash to the same result?

Yes, of course. As a result the search space is reduced slightly. It is
still, however, in the bajillions. It's a good tradeoff.
--
John Hasler
john@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA

Em Quinta, 12 de Julho de 2007 18:52, Keith Keller escreveu:

> current implementations of /etc/passwd and /etc/shadow. But even if you
> were correct, normal users can't read /etc/shadow, where the hashed
> passwords are stored, so you can't assume you even have the hash to
> begin with.
Yes, i figure that out myself, it is a running demon that reads the hashes,
i think it's logger.


>> by the way, do we have a point when a user acount is blocked because of
>> bad paswords? if so, how many wrong passwords are needed?
>> I know windows does this after 3 or 5 wrong passwords, but never seen
>> linux do it...
>
> Most distros by default do not lock accounts on bad passwords, but it
> can be easily configured. There is plenty of documentation online and
> in the man pages.
Ok, then i would sugest sudoers to use this funtion, or desable the password
timestamp.


>> During this time, the trojan have a window of opportunity, and it only
>> needs it once, since after gaining root previledges, he can change the
>> user password then.
>
> I'm getting off into speculation, since I don't know in detail how other
> distros configure their /etc/sudoers file. *If* you have sudo, and
> *if* you have sudo su, *then* yes, you are vulnerable to trojans in that
> time period.
> The solution is to not be stupid when using sudo. It
> appears that you are looking for a technical solution to what is
> fundamentally a human problem, and it is not the OS's job to protect the
> administrator from every conceivable mistake he could make.

the trojan could allready running and waiting to sudo be used.

ubuntu is becoming the most distro used allready, many people are using it
at home with every thing in default mode, most of then are not aware about
this, a user that can sudo, could install a bubble game that does other
things and be waiting to him to use sudo to atack.
note that a program can do things that we don't see, and closing there
window does not impose the program to terminate function, it can stay
running in backgroung.

i hope i'm wrong, but if this thing starts to be exploited, same linux users
will be starting using anti-virus and anti-spywares in there systems, and
that won't be good to see.

> It is the
> admin's job to act in such a way that he doesn't compromise his
> security; it is the OS's job to ensure that the security measures the
> admin has configured are enforced.
home computers are usualy administrated by is owner and usualy only user.

> What I said earlier is still true: don't give root access to people you
> don't trust. If you don't trust yourself, don't connect your machine to
> the network!
Cool... many people are changing to linux because they realise that windows
is the worst option for internet, while linux is a good choice, and i like
to see things continue that way...

Facilities like this, lowers security, and i think sudo should not be used
at least the way some distros are configuring it by default.
If we start to change the linux ways, then this system will stop been save
anymore... i hate to see linux became another target of malware like
windows.

Regards

Em Quinta, 12 de Julho de 2007 20:42, John Hasler escreveu:

> Alan Adams writes:
>> If the hashed version contains less information than the original
>> password, doesn't this imply that there is more than one possible
>> password which will hash to the same result?
>
> Yes, of course. As a result the search space is reduced slightly. It is
> still, however, in the bajillions. It's a good tradeoff.

So we have bajillions of diferent passwords all given the same hash?
i don't think so... how does the system knows you typed the exact password
when there is so many others that generates the same hash?
can't be...

On Thu, 12 Jul 2007 21:12:23 +0100, ArameFarpado wrote:

> Em Quinta, 12 de Julho de 2007 20:42, John Hasler escreveu:
>
>> Alan Adams writes:
>>> If the hashed version contains less information than the original
>>> password, doesn't this imply that there is more than one possible
>>> password which will hash to the same result?
>>
>> Yes, of course. As a result the search space is reduced slightly. It is
>> still, however, in the bajillions. It's a good tradeoff.
>
> So we have bajillions of diferent passwords all given the same hash?
> i don't think so... how does the system knows you typed the exact password
> when there is so many others that generates the same hash?
> can't be...
>
http://en.wikipedia.org/wiki/Hash_collision

Collision resistance is described in the above article as weak or strong,
with strong collision resistance being a desirable feature of any
cryptographic hashing function.

--
Douglas Mayne

On 2007-07-12, ArameFarpado wrote:
> Em Quinta, 12 de Julho de 2007 18:52, Keith Keller escreveu:
>
>>> by the way, do we have a point when a user acount is blocked because of
>>> bad paswords? if so, how many wrong passwords are needed?
>>> I know windows does this after 3 or 5 wrong passwords, but never seen
>>> linux do it...
>>
>> Most distros by default do not lock accounts on bad passwords, but it
>> can be easily configured. There is plenty of documentation online and
>> in the man pages.
> Ok, then i would sugest sudoers to use this funtion, or desable the password
> timestamp.

Read the manpage for sudoers to figure out how to disable the timestamp.

>> I'm getting off into speculation, since I don't know in detail how other
>> distros configure their /etc/sudoers file. *If* you have sudo, and
>> *if* you have sudo su, *then* yes, you are vulnerable to trojans in that
>> time period.
>> The solution is to not be stupid when using sudo. It
>> appears that you are looking for a technical solution to what is
>> fundamentally a human problem, and it is not the OS's job to protect the
>> administrator from every conceivable mistake he could make.
>
> the trojan could allready running and waiting to sudo be used.

Of course it could. The solution is to not be stupid when using sudo.

>> It is the
>> admin's job to act in such a way that he doesn't compromise his
>> security; it is the OS's job to ensure that the security measures the
>> admin has configured are enforced.
> home computers are usualy administrated by is owner and usualy only user.

It is still the admin's job to act in such a way that he doesn't
compromise his security. This is the same as with any OS; the problem
being that Windows (for example) has historically made it very easy to
always run as an administrator, and very difficult not to do so. Even
in the situation where sudo has a 5 minute timeout, that's a relatively
small window in which a trojan can do its damage. But it doesn't allow
an admin to do whatever he wants and not worry about security!

As an aside, processes can't actually read the sudo timestamps, so
trojans actually need to attempt a sudo (with sudo -l, for example) in
order to test whether sudo works. Since sudo attempts are logged, a
sysadmin (yes, even the only owner of a home system) can monitor these
attempts to detect a running trojan.

> Facilities like this, lowers security, and i think sudo should not be used
> at least the way some distros are configuring it by default.

You could lobby individual distributions to disable the sudo timestamp,
or you could post instructions on how to configure sudo for this
functionality. (If the user didn't want to be prompted he could sudo su,
with all the caveats that brings.) But I really think you should try to
better understand how all of these mechanisms work together before
commencing such a campaign; otherwise, distribution maintainers will
ignore (or ridicule) your suggestion.

--keith

--
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information

Alan Adams writes:
> If the hashed version contains less information than the original
> password, doesn't this imply that there is more than one possible
> password which will hash to the same result?

I wrote:
> Yes, of course. As a result the search space is reduced slightly. It is
> still, however, in the bajillions. It's a good tradeoff.

ArameFarpado writes:
> So we have bajillions of diferent passwords all given the same hash?

No. You have bajillions of possible passwords only a very small fraction
of which will produce the correct hash. This means that an attacker must
search through jillions of possible passwords before finding one that
produces the correct hash: an impossible task.

> i don't think so... how does the system knows you typed the exact
> password when there is so many others that generates the same hash?

The system never knows that you typed the exact password that you used to
generate tha hash nor do you want it to. It knows only that you typed a
password that generates the correct hash.
--
John Hasler
john@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA

Em Quinta, 12 de Julho de 2007 22:26, John Hasler escreveu:

> I wrote:
>> Yes, of course. As a result the search space is reduced slightly. It is
>> still, however, in the bajillions. It's a good tradeoff.
>
> ArameFarpado writes:
>> So we have bajillions of diferent passwords all given the same hash?
>
> No. You have bajillions of possible passwords only a very small fraction
> of which will produce the correct hash. This means that an attacker must
> search through jillions of possible passwords before finding one that
> produces the correct hash: an impossible task.
Then, if the hash could be readed and analised, it would narrow to a few
possibilities... but yes the hash can not be read easly.

>
>> i don't think so... how does the system knows you typed the exact
>> password when there is so many others that generates the same hash?
>
> The system never knows that you typed the exact password that you used to
> generate tha hash nor do you want it to. It knows only that you typed a
> password that generates the correct hash.
Is there an ideia of how many diferent password will colide in the same
hash?
just to have an ideia.

Regards

Em Quinta, 12 de Julho de 2007 22:18, Keith Keller escreveu:

> in the situation where sudo has a 5 minute timeout, that's a relatively
> small window in which a trojan can do its damage.
could be more then enough

> But it doesn't allow
> an admin to do whatever he wants and not worry about security!
in ubuntu, by default, everything is done with sudo.

> As an aside, processes can't actually read the sudo timestamps, so
> trojans actually need to attempt a sudo (with sudo -l, for example) in
> order to test whether sudo works. Since sudo attempts are logged, a
> sysadmin (yes, even the only owner of a home system) can monitor these
> attempts to detect a running trojan.
Ah, yes. I've made some tests wile ago:
i don't have sudo configured, there isn't a single sudoer in my system, only
apt doesn't let me unistall it, or i would have to unistall more things
that i need (like foomatic), so i try to use it, to see how it reacts.. it
sayd that the "incident will be reported", ok, but reported where?
after that i log in a konsole as root and no warning came...
are you expecting that the commom home user will be checking log files?

you got to see, i'm not worry about expert users or network administradors,
my worries goes to the commom home user, and i am not worried for my
security, but others...

>> Facilities like this, lowers security, and i think sudo should not be
>> used at least the way some distros are configuring it by default.
>
> You could lobby individual distributions to disable the sudo timestamp,
> or you could post instructions on how to configure sudo for this
> functionality.
i might do that, since i post on a blog... but if a distro cames out using
defauts like this and only a few portion read newsgroups or blogs, i can't
do much.


> (If the user didn't want to be prompted he could sudo su,
> with all the caveats that brings.) But I really think you should try to
> better understand how all of these mechanisms work together before
> commencing such a campaign; otherwise, distribution maintainers will
> ignore (or ridicule) your suggestion.
ok.

On 2007-07-12, ArameFarpado wrote:
> Em Quinta, 12 de Julho de 2007 05:27, Keith Keller escreveu:
>
>> On 2007-07-12, ArameFarpado wrote:
>>>
>>> BUT!!! if you can do "sudo something" and then gain more previleges with
>>> your own password, the one you can read and change it, what in hell will
>>> prevent a program to do the same? if you can read your pass so can
>>> programs started by you. right?
>>
>> No, they can't, unless you're stupid enough to store your password on
>> diskNo,
>
> Ah right! so my system knows i'm writing my password by magic!
> Even the root password is stored on disk!

Right.

> Don't you know you can recover a forgotten root password on any system,
> using a live-cd? I did it once.

No, you didn't. You could change the root password, but you could
not recover the old one.

> If the password is not stored in disk, then explain how the computer knows
> if i'm writing the right one? does it not going to need to "compare" one
> with the other to see if they match ?
>
> You're going to say, it's hard to read because it's encripted?
> it's only hard (not impossible) for humans, not programs.

A good password, encrypted, is hard (i.e., time consuming) for
machines to read.

>>> Can't you see that sudo, configured this way, is a nice way to a future
>>> and possible malware gain previleges? Security goes down the drain...
>>> This sudo stuff is just a dangerous point waiting to be exploited.
>>
>> No it's not. sudo can only do what the user explictly allows it to.
> my my...
>
>>> At least you should use sudo with the root password,
>>
>> There's little point to using sudo with the root password, just su
>> instead.
> how? we're talking about ubuntu here.
> there is no root acount. and every thing is made using sudo, so sudo gives
> access to everything.

Yes, there is a root account. How else would sudo work?

All that's missing is a root password.


--
Chris F.A. Johnson, author |
Shell Scripting Recipes: | My code in this post, if any,
A Problem-Solution Approach | is released under the
2005, Apress | GNU General Public Licence

On 12 Jul, 13:34, John Hasler wrote:
> Nico writes:
> > The password is stored only in encrypted format...
>
> The password is _not_ stored in encrypted form. A _one-way hash_ of the
> password is stored. This hash does not contain enough information to
> regenerate the password.

"In any reasonable amount of time". Brute force attacks have been
demonstrated as feasible where the hashing or encryption algorithm is
too easy such as the old 'crypt' function, which is defeatable in
reasonable time by a big wad of cheap parallel processors. But no one
sane uses crypt anymore, they use an md5 based hash or something
similar.

Crypt is still in use on old and very limited hardware and software.
The last time i looked, the "htpaswd" tool used it by default, which I
consider stupid.

On 2007-07-12, ArameFarpado wrote:
> Em Quinta, 12 de Julho de 2007 22:18, Keith Keller escreveu:
>
>> in the situation where sudo has a 5 minute timeout, that's a relatively
>> small window in which a trojan can do its damage.

> could be more then enough

Yes, it could.

>> But it doesn't allow
>> an admin to do whatever he wants and not worry about security!

> in ubuntu, by default, everything is done with sudo.

In any distro, the admin can modify sudoers, to the point of never
allowing it.

> i don't have sudo configured, there isn't a single sudoer in my system, only
> apt doesn't let me unistall it, or i would have to unistall more things
> that i need (like foomatic), so i try to use it, to see how it reacts.. it
> sayd that the "incident will be reported", ok, but reported where?

In your system logs, most likely in /var/log/ .

> are you expecting that the commom home user will be checking log files?
[...]
> you got to see, i'm not worry about expert users or network administradors,
> my worries goes to the commom home user, and i am not worried for my
> security, but others...

The common home user should check his logs. This applies to any OS, not
just Ubuntu. There are many nice logfile analyzers which will distill
syslog activity in a simple(r) format for a common home user to read.
LogWatch comes with CentOS; I don't know what's available OOTB for
Ubuntu.

--keith

--
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information

ArameFarpado writes:
> --the other side whe have passwords, and they are small strings, and
> let's face it, we can't have 1000 diferent passwords all generating the
> same hash can't we?

We can and do (actually, it's a lot more than 1000). This is ok because
for every string that generates a correct hash there are trillions that do
not.

> so, picking up a hash and turning it up-side-down, won't give you the
> password but it nerrows it to a small list of possibilities.

It does not. Possessing the hash gives you only a target for trial and
error.

> don't tell me it can't be done, because if it wore true, there wore no
> such thing as password cracker programs,

There are only two kinds of such programs: dictionary attacks which only
work against weak passwords and brute-force attacks which only work against
very short passwords (which Linux will not allow).

> i have a few for winblows and password protected documents... it takes a
> few seconds to crack a password of a MsOffice Word document, that is also
> encrypted.

We are discussing real security, not Microsoft security.

> ...instead there is a program named "logger"...

man login

> by the way, do we have a point when a user acount is blocked because of
> bad paswords?

There is a delay after each login failure. This limits the rate at which
passwords can be tried.
--
John Hasler
john@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA

Keith Keller writes:
> Most of the password crackers for linux are basically brute-force
> crackers. The ones that aren't assume that you've somehow obtained a
> copy of /etc/shadow.

Any attack via login can only hope to crack the very weakest passwords
because of the delay. I don't know of any password crackers that do not
use dictionary attacks. Brute-force is the only other possibility and that
is pointless even with a copy of /etc/shadow.
--
John Hasler
john@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA

ArameFarpado writes:
> Then, if the hash could be readed and analised, it would narrow to a few
> possibilities...

No it would not.

> Is there an ideia of how many diferent password will colide in the same
> hash? just to have an ideia.

Please read up on how this works. There is plenty about it on the Web.
--
John Hasler
john@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA

I wrote;
> The password is _not_ stored in encrypted form. A _one-way hash_ of the
> password is stored. This hash does not contain enough information to
> regenerate the password.

Nico writes:
> "In any reasonable amount of time".

No. Not in any amount of time. In an unreasonable amount of time it may
be possible to discover one of the many strings produce that hash (which
would suffice for an attacker's purpose) but there is no way to know which
one was used to generate it.
--
John Hasler
john@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA

On 2007-07-12, John Hasler wrote:
> Keith Keller writes:
>> Most of the password crackers for linux are basically brute-force
>> crackers.
>
> Any attack via login can only hope to crack the very weakest passwords
> because of the delay. I don't know of any password crackers that do not
> use dictionary attacks.

Oy--I don't know why I said brute-force. I meant to say dictionary.
Profuse apologies for the confusion!

--keith


--
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information

Em Sexta, 13 de Julho de 2007 00:21, John Hasler escreveu:

>> so, picking up a hash and turning it up-side-down, won't give you the
>> password but it nerrows it to a small list of possibilities.
>
> It does not. Possessing the hash gives you only a target for trial and
> error.
Are you saying that matematical operations, for more complex that they are,
can not be done in reverse? sorry, but i don't buy that, it is against
matematical laws.

>> by the way, do we have a point when a user acount is blocked because of
>> bad paswords?
>
> There is a delay after each login failure. This limits the rate at which
> passwords can be tried.
That is just about 1 or 2 seconds for each e attempts... it should have
bigger delays growing proportional to the number of failure attempts.

Regards

Em Sexta, 13 de Julho de 2007 01:44, ArameFarpado escreveu:
> That is just about 1 or 2 seconds for each e attempts...

mistype... sorry

That is just about 1 or 2 seconds for each 3 attempts...