> > Before he gets in, he still has to run a brute-force/dictionary-att. on
> > all users. He wouldn't have much time if the admins have done their
> > jobs.
>
> Well no. Think about sysadmins who have to allow users to run crappy
> PHP code on a shared server (so glad I'm not one of those people
On Wed, 4 Jun 2014 12:22:04 -0400
Nick wrote:
> Well no. Think about sysadmins who have to allow users to run crappy
> PHP code on a shared server (so glad I'm not one of those people at
> the moment). An attacker can execute commands as a web user,
> probably far easier than brute-forcing an
Quoth FRIGN:
> Before he gets in, he still has to run a brute-force/dictionary-att. on
> all users. He wouldn't have much time if the admins have done their
> jobs.
Well no. Think about sysadmins who have to allow users to run crappy
PHP code on a shared server (so glad I'm not one of those peop
On Wed, 4 Jun 2014 17:40:39 +0200
"Roberto E. Vargas Caballero" wrote:
> WOW!, so, for you, it isn't important if you have a non legitimate
> user, that can use your machine as base for attacking another
> machines.
> And, of course, it isn't important if you have an atacker
> in your system with
On Wed, 4 Jun 2014 17:46:40 +0200
Markus Teich wrote:
> So for systems with large user counts it is easier to find a user with a weak
> password, but it does not influence your user account at all if you use a
> strong
> (strong = password is not one of the n most common ones) password.
And in
Heyho,
FRIGN wrote:
> In which way is a /etc/passwd with hundreds of users less secure than a
> smaller one? Do many hashes in one place magically reduce the overall
> security?
Not precisely. But if you have a large amount of users, the probability that one
of them chose a weak common password i
> Well, who cares if one of them uses a weak password?
WOW!, so, for you, it isn't important if you have a non legitimate
user, that can use your machine as base for attacking another
machines. And, of course, it isn't important if you have an atacker
in your system with all the time of the world
On Wed, 4 Jun 2014 17:28:02 +0200
"Roberto E. Vargas Caballero" wrote:
> It is not about the security of /etc/passwd, it is about you cannot
> ensure that hundred of users will use strong password, because you don't
> select theirs passwords, so at the end the security of your system
> depend of
> In which way is a /etc/passwd with hundreds of users less secure than a
> smaller one? Do many hashes in one place magically reduce the overall
> security?
It is not about the security of /etc/passwd, it is about you cannot
ensure that hundred of users will use strong password, because you don't
On Wed, 4 Jun 2014 17:14:19 +0200
"Roberto E. Vargas Caballero" wrote:
> The problem arises when you have a system with hundred of users. You have
> to ensure that all the users have a strong password (some of them without
> any basic knowledge about computers or security), so the only way is
> m
> Thus, the shadow file locks things up a bit more, brings some more
> complexity, but this doesn't mean /etc/passwd is insecure.
> If you use strong passwords, you don't need the shadow-file. If you
> have a weak password, the shadow-file on the other hand just delays the
> eventual breach.
The p
On Wed, Jun 04, 2014 at 02:21:51PM +0200, FRIGN wrote:
> On Wed, 4 Jun 2014 12:55:39 +0100
> Dimitris Papastamos wrote:
>
> > The implementation turned out to be simple enough. Factoring out
> > the routines in util/ should make the code more readable.
>
> The similarities between su and login
On Wed, 4 Jun 2014 12:55:39 +0100
Dimitris Papastamos wrote:
> The implementation turned out to be simple enough. Factoring out
> the routines in util/ should make the code more readable.
The similarities between su and login are a good reason to do the
handling in one place.
--
FRIGN
On Wed, Jun 04, 2014 at 12:44:01PM +0200, FRIGN wrote:
> Looking at it from the programmer's side: Implementing /etc/shadow
> brings more complexity to the program. Avoiding complexity is one goal
> to set, thus avoiding /etc/shadow is a good way to simplify things.
The implementation turned out t
On Wed, Jun 04, 2014 at 12:44:01PM +0200, FRIGN wrote:
> On Wed, 4 Jun 2014 00:15:58 +0200
> Alexander Huemer wrote:
>
> > You think so? That's not at all what I personally associate with this
> > feature. Can you elaborate?
>
> Many people don't understand how hashing-functions work.
Obviousl
On Wed, 4 Jun 2014 00:15:58 +0200
Alexander Huemer wrote:
> You think so? That's not at all what I personally associate with this
> feature. Can you elaborate?
Many people don't understand how hashing-functions work. The
shadow-file might suggest knowing the hash inherently unveils the
password
On Wed, Jun 04, 2014 at 12:12:51AM +0200, FRIGN wrote:
> On Tue, 3 Jun 2014 22:44:31 +0200
> Alexander Huemer wrote:
>
> > What here provides a false feeling of security?
>
> Well, the incorporation of this shadow-file.
> Some users might see this as a motivation for weak passwords.
You think s
On Tue, 3 Jun 2014 22:44:31 +0200
Alexander Huemer wrote:
> What here provides a false feeling of security?
Well, the incorporation of this shadow-file.
Some users might see this as a motivation for weak passwords.
Cheers
FRIGN
--
FRIGN
On Mon, Jun 02, 2014 at 06:41:45PM +0200, FRIGN wrote:
> […]
> If your password is strong, having the hashes won't help any attacker.
> […]
I think that's the whole point.
Hashing the password before writing it to disk does not hurt much.
In case an attacker got access to a box he does not know wh
On Tue, 3 Jun 2014 21:16:01 +0200
Markus Wichmann wrote:
> Well, it won't save you, but delay it significantly! Testing a password
> with login takes 5 seconds, testing a password with the hash at hand
> takes less than a microsecond.
Well, it depends on the hash and how strong the password is ;
On Mon, Jun 02, 2014 at 06:41:45PM +0200, FRIGN wrote:
> Well, I prefer /etc/passwd, given it gives a false feeling of security
> using the shadow-file.
> In reality, it's a solution for a very unimportant issue.
> If your password is strong, having the hashes won't help any attacker.
> On the othe
On Mon, 2 Jun 2014 17:23:03 +0100
Dimitris Papastamos wrote:
> I don't care personally. We should definitely add /etc/passwd support
> to su though because currently it only works with /etc/shadow.
Well, I prefer /etc/passwd, given it gives a false feeling of security
using the shadow-file.
In
On Mon, 2 Jun 2014 17:13:49 +0100
Dimitris Papastamos wrote:
> Yeah the uid, gid stuff are leftovers because I initially had shadow
> support but could not be arsed to test it so I removed it.
I don't see the reason behind shadow-support. Well, the purpose is to
prevent bruteforcing the password
On Mon, Jun 02, 2014 at 06:20:52PM +0200, FRIGN wrote:
> On Mon, 2 Jun 2014 17:13:49 +0100
> Dimitris Papastamos wrote:
>
> > Yeah the uid, gid stuff are leftovers because I initially had shadow
> > support but could not be arsed to test it so I removed it.
>
> I don't see the reason behind shad
On Mon, Jun 02, 2014 at 06:08:12PM +0200, FRIGN wrote:
> Hello,
>
> I was very glad to see the initial implementation of login by sin, but
> found some stuff that simplifies the code even more.
> Check the patch for more details, it should speak for itself.
Applied thanks. We should probably fac
On Mon, Jun 02, 2014 at 06:08:12PM +0200, FRIGN wrote:
> Hello,
>
> I was very glad to see the initial implementation of login by sin, but
> found some stuff that simplifies the code even more.
> Check the patch for more details, it should speak for itself.
Thanks.
Yeah the uid, gid stuff are le
Hello,
I was very glad to see the initial implementation of login by sin, but
found some stuff that simplifies the code even more.
Check the patch for more details, it should speak for itself.
Cheers
FRIGN
--
FRIGN
>From b39d86ebdaadfe4880fd1681bd021ea06ecadb75 Mon Sep 17 00:00:00 2001
From:
27 matches
Mail list logo
